Lectura Fundamental 1

Unidad 1 / Escenario 1 Lectura fundamental Surgimiento y evolución de las bases de datos Contenido 1 2 3 4 5 Introducc

Views 44 Downloads 0 File size 534KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Unidad 1 / Escenario 1 Lectura fundamental

Surgimiento y evolución de las bases de datos Contenido 1 2 3 4 5

Introducción Sistemas enfocados a la gestión de archivos Bases de datos jerárquicas Bases de datos en red Bases de datos relacionales y SGBD

Palabras clave: bases de datos, manejo de archivos, bases de datos jerárquicas, bases de datos en red, bases de datos relacionales, Sistema de Gestión de Bases de Datos.

1. Introducción

¿Sabía que...? Una empresa para tomar decisiones debe hacerlo a partir de la información disponible, siendo la información una interpretación de los datos.

Teniendo en cuenta lo anterior, podemos decir que los sistemas de información son diseñados y construidos por los informáticos basados en las necesidades de las compañías, empresas u organizaciones de todas las industrias actuales, tal y como lo afirma Elmasri (2000). Dichos sistemas se pueden hallar, por ejemplo, en:



Soluciones para la industria automotriz: en la fabricación y venta de automóviles o en la gerencia de un taller de mecánica para la venta y distribución de partes.



Servicios públicos: en el manejo de los semáforos de una ciudad, las rutas de buses, la seguridad en un sistema masivo de transporte o en la facturación del acueducto, teléfono y energía, etc.



La industria del turismo: en la administración de cadenas hoteleras o de un hotel, el manejo de rutas y transporte a sitios turísticos o al momento de ofrecer de manera coordinada atracciones que se encuentren en una región, entre otros.



La educación: en el manejo del sistema de notas de los colegios, sus indicadores, nóminas y el inventario de sus instalaciones; o en la gerencia de las facultades y programas que ofrecen las universidades; etc.



Los intermediarios financieros o bancos: en la gestión de los clientes, regionales, oficinas y productos que se ofrecen; llevando la contabilidad; o en el manejo de instrumentos financieros para inversión, como son los de renta fija o variable; etc.

POLITÉCNICO GRANCOLOMBIANO

2



Los procesos de distribución de bienes: en almacenes de cadena, llevando el inventario de los artículos, clientes, promociones, proveedores, entre otros.



El ámbito científico y de investigación: en el manejo de modelos de predicción del clima; en métodos numéricos para resolver problemas de la física matemática o ingeniería aplicada, la química computacional, la cristalografía, la inteligencia artificial y la computación gráfica; o en el manejo de modelos predictivos de la dinámica de fluidos.

Por eso es importante conocer los antecedentes, características, ventajas y desventajas de los diferentes modelos que han servido para manejar los datos que las organizaciones usan para abordar la solución a dichas necesidades y contribuir con nuevas y mejores soluciones.

2. Sistemas enfocados a la gestión de archivos Tradicionalmente las grandes organizaciones han tenido la necesidad de enfrentarse con los problemas que conllevan grandes volúmenes de información. Inicialmente, la tecnología provee soluciones para manejar un conjunto de aplicaciones que definen y administran sus propios datos almacenados físicamente en archivos y en muchos casos en diferentes marcas de computadores, lo cual, en su momento, implicaba distintos métodos de almacenamiento; ese enfoque se conoce como almacenamiento orientado a archivos. Teniendo en cuenta que un archivo se puede representar como una colección de registros que contienen datos lógicamente relacionados, y que deben ser manipulados, esto hizo que existiera una estrecha dependencia entre el lenguaje de programación utilizado (FORTRAN, COBOL, Pascal) y los datos (definidos en la “división de datos” de COBOL como se muestra en el ejemplo). IDENTIFICATION DIVISION. PROGRAM-ID. Manejo de estudiante. AUTHOR. Pedro Pérez. * Comentario: Muestra cómo crear un archivo secuencial.

POLITÉCNICO GRANCOLOMBIANO

3

ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT Archivo_estudiante ASSIGN TO "ESTUDIA.DAT"

ORGANIZATION IS LINE SEQUENTIAL.

DATA DIVISION. FILE SECTION. FD Archivo_estudiante. 01 Detalle_estudiante. 02 Cédula_Id

PIC 9(10).

02 Nombre_completo. 03 Nombres

PIC X(18).

03 Apellidos

PIC X(20).

02 Género

PIC X.

02 FechaDeNacimiento. 03 Anyo 03 Mes 03 Día 02 Carnet

PIC 9(4). PIC 9(2). PIC 9(2). PIC X(8).

En Pascal, el ejemplo anterior sería: PROGRAM . Manejo_de_estudiante; TYPE

POLITÉCNICO GRANCOLOMBIANO

4



Detalle estudiante = RECORD

Cédula_Id : STRING[10]; Nombres: STRING[18]; Apellidos: STRING[20]; Género: CHAR; FechaDeNacimiento: INTEGER; Carnet: INTEGER;

END;

Por lo tanto, dichas aplicaciones que son o fueron escritas en los diferentes lenguajes, debían generar conjuntos de archivos para guardar los datos relevantes que satisficieran las necesidades de los procesos específicos de la organización. Como nos podemos dar cuenta, los archivos definidos en cada programa no necesariamente comparten información unos con otros, haciendo que cada archivo opere de manera independiente con respecto a otros archivos en el sistema. Un ejemplo de esto se puede ver en la manera como una universidad manejaba en su momento el dato de la dirección de un estudiante para mantener actualizada la información. Analizándolo, dicha dirección se utilizaba en varios procesos y, por lo tanto, en varios sistemas de información: en el proceso de registro, en el proceso para la gestión bibliotecaria de la universidad, en el proceso contable y de deudores del área financiera, y en el proceso del desarrollo académico del estudiante. Si tomamos el dato -de la dirección-, este era manipulado por cada programa en diferentes aplicaciones que generalmente fueron desarrolladas por distintos equipos de programadores y donde sus archivos (de datos) no necesariamente estaban definidos bajo el mismo estándar, ni se actualizaban de manera simultánea. Por ejemplo, si la dirección del estudiante cambiaba, lo más probable era que se actualizara en el sistema financiero, pero no en la gestión bibliotecaria. Inclusive se podían presentar diferencias entre los sistemas porque el formato de un mismo “dato” (la dirección del estudiante para la universidad) fuera diferente, empezando con el nombre del campo donde se almacenaba el dato (para el sistema contable se podía llamar dirección deudor y para la biblioteca dirección estudiante), la longitud del campo o incluso el tipo de dato utilizado por cada sistema.

POLITÉCNICO GRANCOLOMBIANO

5

Creando así un sobre costo en los procesos de coordinación entre las áreas de la universidad, en caso de que se hiciera la actualización de la dirección del estudiante, porque debía replicarse por cada aplicación que existiera en la institución. Además, en algunos casos no era suficiente replicar la dirección, sino que se debían utilizar equivalencias; por ejemplo, si se guardaba en una aplicación la dirección completa como Carrera 3Este Número 57-21 y en la otra como Cra. 3E #57-21, lo cual también podía generar problemas en la digitación de los datos. Las principales limitaciones del enfoque de manejo de sistemas de archivos fueron:



Producto del manejo separado de archivos: existían esfuerzos redundantes para introducir datos “replicados” que de hecho generaban espacio de almacenamiento desperdiciado para el manejo de grandes volúmenes de datos. Pero aún más importante era poder mantener la coherencia del dato dentro de la empresa, lo que ocasionaba graves problemas para la toma de decisiones.



Dependencia excesiva entre los datos y los programas, ya que la definición de datos debía estar explícita en el programa de aplicación, implicaba una estructura fija.



El mantenimiento de las aplicaciones era laborioso debido a la duplicación y cambio en los procedimientos, teniendo en cuenta que las relaciones entre archivos debían estar codificadas en los programas.



Tendencia a aislar y separar datos lógicamente relacionados.

¿Sabía que...? Una base de datos es una colección organizada de datos que sirve para un objetivo central, entendiendo que “organizada” significa, almacenada, accesible, con formato y representada de manera coherente; y el objetivo central significa que no contiene datos superfluos.

POLITÉCNICO GRANCOLOMBIANO

6

Para tratar de solucionar las debilidades propias de los sistemas de archivos, y permitir la descripción de los datos que usa la organización, incluyendo la semántica de los datos y las relaciones entre ellos, se desarrollaron los primeros modelos de bases de datos; de los cuales estudiaremos los siguientes:

3. Bases de datos jerárquicas El modelo fundamental de las bases de datos jerárquicas, como su nombre lo indica, establece categorías o jerarquías entre segmentos y segmentos secundarios, en donde el primer segmento se denomina raíz. Los segmentos son bloques de datos que contienen varios datos y se llaman campos. Para entender mejor esto veamos un ejemplo: tomemos una base de datos para ventas. Esta puede tener un segmento raíz (o el segmento inicial de la jerarquía) cliente con campos como nombre, dirección, teléfono, e-mail, género y edad. Asociado a este debe existir un segmento secundario de pedido debajo de cada segmento de cliente que representa cada pedido que un cliente ha realizado a la empresa, con sus correspondientes campos como número de factura, fecha de expedición y valor total. Del mismo modo, cada segmento de pedido puede tener muchos segmentos secundarios para cada artículo del pedido con sus campos, como nombre del artículo, cantidad y precio unitario. Esquemáticamente el modelo jerárquico se puede visualizar en la siguiente figura:

POLITÉCNICO GRANCOLOMBIANO

7

(Texto)

Cliente (Juan, Cra. 8, 222, [email protected]. M, 51)

Artículo (tenis, 1, 100)

Cliente (María, Calle 2,765, m@yy. com, F, 27)

Factura (001, 15dic1970,500)

Factura (028, 12mae1980,200)

Factura (005, 3jul1975,3500)

Artículo (medias, 8 50)

Artículo (sudadera,5,40)

Artículo (balón, 10, 200)

Artículo (bicicleta,1,1500)

Figura 1. Esquema modelo jerárquico Fuente: elaboración propia

¿Sabía que...? El modelo jerárquico más popular fue el IMS desarrollado por IBM, Caterpillar y Rockwell, para el programa Apollo para inventariar la lista de materiales del cohete lunar Saturno V y el vehículo espacial.

¿Podría esquematizar el modelo? Aunque el modelo de una base de datos jerárquica tiene muchos casos en los que es evidente su aplicabilidad, existen negocios que resulta muy complejo modelar de acuerdo con eso, tal sería el caso de la industria farmacéutica donde se quiere ver los vendedores de líneas de productos que atienen varias ciudades a la vez.

POLITÉCNICO GRANCOLOMBIANO

8

4. Bases de datos en red Para resolver el caso anterior, se hace notar que en una ciudad pueden ofrecer muchos productos y estos ser ofrecidos por muchos vendedores. O se podría parafrasear que muchos productos pueden ser ofrecidos por muchos vendedores en muchas ciudades. Para modelar este tipo de negocios, se resuelve usando el principio de una base de datos jerárquica, pero en lugar de segmentos se utilizan “nodos” con las mismas características de los segmentos (ciudades con el nombre, la población, el clima); luego se organizan jerárquicamente (siguiente nivel o hijos son los vendedores), pero la diferencia radica en que un nodo hijo (vendedor con el nombre, la cédula, la comisión) puede tener más de un nodo padre y, por último, los nodos nietos (productos con el nombre del producto, presentación). Para poder identificar las diferentes conexiones entre los niveles de la jerarquía se crean unos campos adicionales llamados apuntadores, que permiten acceder a cualquier nodo por diferentes vías simplemente yendo en dirección descendente por las diversas ramas. Esquemáticamente se puede visualizar el modelo de acuerdo con la figura 2 o la figura 3.

Bogotá

Ana

Ácido clorhídrico

Arena sílica

Medellín

Camila

Carbón activado

Cali

José

Cartagena

Consuleo

Morfolina

Andrés

Soda cáustica

Urea

Figura 2. Esquema modelo jerárquico Fuente: elaboración propia

POLITÉCNICO GRANCOLOMBIANO

9

Ácido clorhídrico

Arena sílica

Ana

Bogotá

Carbón activado

Camila

Medellín

Morfolina

José

Soda cáustica

Consuleo

Cali

Urea

Andrés

Cartagena

Figura 3. Esquema modelo jerárquico Fuente: elaboración propia

Como nos podemos dar cuenta, para la creación en ese momento, los modelos para la construcción de Sistemas de información muestran las siguientes falencias: No existen lineamientos claros, se sigue teniendo la visión tradicional acerca de las estructuras de datos que son tratados como registros almacenados en disco más los enlaces, que conceptualmente es una mezcla entre el diseño lógico y el físico, persisten los programas extensos y complejos debido a que la programación sigue siendo procedimental, ya que todos los accesos a la base de datos se hacen mediante esta programación, la navegación entre los nodos se hace mediante rutas de acceso físico y un solo registro a la vez, por lo tanto, la optimización del rendimiento depende del programador. Con todos esos problemas mencionados se había despertado poco interés en el ámbito informático por la investigación de las bases de datos, ya que las bases teóricas diferían grandemente del sentido práctico, ahí es donde surge el modelo relacional.

POLITÉCNICO GRANCOLOMBIANO

10

5. Bases de datos relacionales y SGBD

¿Sabía que...? Este modelo se basa en dos teorías matemáticas bien establecidas como son: la teoría de conjuntos y la lógica de predicados de primer orden.

El modelo relacional con esa fuerte teoría formal subyacente -que desde el punto de vista de ingeniería siempre es interesante, ya que es confiable y disminuye el riesgo de lo impredecible-, de acuerdo con Date (2001), pronto atrajo la atención de los centros de investigación y su progreso fue rápido en los años 70. Uno de los más importantes fue IBM, encabezado por Edgar Frank “Ted” Codd, buscando que el modelo planteado fuera lo suficientemente general como para resolver los problemas de procesamiento de datos en las empresas. Así se empezó con un diseño disciplinado de las bases de datos, que se enfocaba en tener clara la visión semántica o conceptual de los requerimientos o requisitos mediante estructuras de fácil comprensión (por ejemplo, E-R), simplificando los procesos de análisis y diseño significativamente. Otros aspectos importantes, según manifiesta Silberschartz (2016), fueron: la separación –real- entre el diseño físico de la base de datos y el entendimiento que tenían los usuarios de este, ya que las estructuras de datos son simples y abstractas, independientes de las consideraciones físicas. Así las cosas, los usuarios no necesitaban conocer ni dominar toda la teoría que hay detrás de las bases de datos relacionales. En ese momento se logró demostrar que un lenguaje menos procedimental de manipulación de datos no solo era prácticamente factible sino también altamente productivo, creando así lenguajes de bases de datos interactivos de alto nivel, basados en “set-at-a-time”. Creando el SQL Standard que permitía la portabilidad de aplicaciones.

POLITÉCNICO GRANCOLOMBIANO

11

Una vez se empezó a ver las bondades de este, hay un gran auge en la industria, especialmente en: la construcción de máquinas de bases de datos; la implementación de los modelos clienteservidor; la investigación de las bases de datos distribuidas; la creación de nuevas herramientas para el cliente; la generación de nuevos lenguajes (4GLs), de acuerdo con Kroenke (2007). Por último, y no menos importante, es que se empieza a desarrollar software especializado basado en la arquitectura ANSI/SPARC de tres niveles que permite la separación entre la base de datos física y las aplicaciones. A saber, los niveles son: Interno o de almacenamiento (modelo físico), conceptual o de diseño (modelo conceptual) y externo o de aplicación (modelo lógico). La arquitectura ANSI/SPARK permitió la independencia de los datos, tanto lógica como física. Dicho software especializado, según avala Peter (2002), tiene como principal misión la de servir de interfaz entre la base de datos, el desarrollo de las aplicaciones y el usuario final, y se le denomina Sistema de gestión de bases de datos (SGBD o en la literatura anglosajona DBMS Data Base Management System), con optimizadores de consultas eficientes, la construcción y manipulación de las bases de datos, el manejo de concurrencia –lo que implica una gestión de “transacciones” para múltiples usuarios sin que se pierda la fiabilidad de los datos–, aumento en la confiabilidad de los datos almacenados y recuperación de las bases de datos a fallas del sistema.

POLITÉCNICO GRANCOLOMBIANO

12

Referencias Date, C. J. (2001). Introducción a los sistemas de bases de datos (séptima edición). México DF, México: Pearson Educación. Elmasri, R. y Navathe, S. (2000). Sistemas de Bases de Datos Conceptos Fundamentales (cuarta edición). Pearson Education. Kroenke, D., & Auer, D. (2007). Database Concepts (3rd ed.). New York: Prentice. Peter, R. y Coronel, C. (2002). Sistemas de Bases de Datos: diseño, implementación y administración (quinta edición). Stamford: Thomson. Silberschatz, A., Korth, H., & Sudarshan, S. (2016). Database System Concepts (6th ed.). Mc Graw Hill.

POLITÉCNICO GRANCOLOMBIANO

13

INFORMACIÓN TÉCNICA

Módulo: Bases de Datos Unidad 1: Generalidades de las bases de datos Escenario 1: Surgimiento y evolución de las bases de datos Autor: Néstor David González Navarro Asesor Pedagógico: Jeimy Lorena Romero Perilla Diseñador Gráfico: Juan Sebastián Moreno Asistente: Laura Delgado Este material pertenece al Politécnico Grancolombiano. Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO

14