Apuntes de oposiciones TIC: modelos de datos

Aquí os dejo unos apuntes sobre "Modelos de datos" que elaboré hace tiempo para construir un temario de las oposiciones TIC. Espero que os sirvan de ayuda.

Modelo de Datos en red.

Los modelos en red representa las entidades en forma de nodos de un grafo, y las asociaciones o interrelaciones entre ellos, mediante arcos que unen estos nodos. Esta representación permite el modelado de estructuras de datos tan complejas como se desee por no imponer ninguna restricción al número de arcos.
En el esquema se describen aspectos estáticos:

• Entidades {E1, E2…..En } Serían los nodos.
• Interrelaciones { Ij,k,…n} Se tratarían de los arcos.

El modelo no considera restricciones inherentes, las semánticas no están efinidas al tratarse de un modelo teórico.
En cuanto a la dinámica, los modelos en red se caracterizan por ser navegacionales, la recuperación y la actualización de la base de datos se
realiza registro a registro. Las funciones de manipulación de datos soportadas por el modelo son:

• Localizar un registro.
• Pasar de una registro padre a su primer hijo.
• Moverse de un hijo a otro.
• Pasar de un hijo a su padre.

Otras características a destacar serían:

• La implementación se lleva a cabo por medio de punteros
• Es un modelo muy flexible, debido a que no existen restricciones inherentes, razón por la cual su instrumentación física es difícil y poco

eficiente.
Los modelos Jerárquico y CODASYL están basados en el modelo de datos en red, pero con restricciones más fuertes. Las ventajas de un modelo en red son:

• Se mantiene la integridad referencial.
• Las actualizaciones y borrados son en cascada.

El inconveniente es que un pequeño cambio en un programa puede suponer grandes modificaciones en el sistema.

Modelo CODASYL

El modelo Codasyl toma el nombre del comité que propuso sus especificaciones (COnference on DAta SYstems and Languages) Data Base Task Group (DBTG). Por eso, a veces se le conoce como el modelo DBTG o el modelo CODASYL.
Supone una simplificación del modelo en red debido a que se admiten sólo determinados tipos de interrelaciones y se incluyen algunas
restricciones adicionales que no limitan en exceso la flexibilidad por la que se caracteriza el modelo de red. El modelo en red se estandarizó a finales de los sesenta mediante un informe de CODASYL.
El primer informe de CODASYL ya incluía la sintaxis y semántica de un lenguaje de definición de datos (DDL, Data Definition Language) y de un lenguaje de manipulación de datos (DML, Data Manipulation Language). Siguiendo muchos comentarios y revisiones de expertos y usuarios se realizó un nuevo informe en 1971, en el que ya se incluía la posibilidad de definir vistas para los distintos grupos de usuarios.
El término base de datos en red no se refería (al contrario de lo que se entendería hoy en día) a que la base de datos estuviera almacenada en una red de ordenadores, sino por la manera en la que los datos se enlazaban con otros datos. Se llama, por tanto, modelo en red porque representa los datos que contiene en la forma de una red de registros y conjuntos (en realidad listas circulares llamadas sets) que se relacionan entre sí, formando una red de enlaces. Para hacer esto utiliza registros, tipos de registro y tipos de conjunto.
Aunque este modelo permite más flexibilidad que el modelo jerárquico, y en algunos casos se adapta muy bien a algunos tipos de transacciones, se considera superado por otros modelos, como el relacional, o subsumido en parte por modelos más modernos, como el orientado a objetos.
El grupo Codasyl no se limitó a proponer un modelo de datos, sino que especificó la sintaxis de sus diferentes lenguajes:

• Lenguaje de definición de datos del esquema (LDDDE) Permite describir la estructura de la totalidad de elementos de la Base de datos.
• Lenguaje de definición de datos del Subesquemas (LDDS) Permiten la descripción de subconjuntos del esquema para diferentes usuarios.
• Lenguaje de manipulación de datos (LDM)
• Lenguaje de Control de Dispositivos /soporte (LcDS)
• Lenguaje de definición del esquema de almacenamiento(LDEA)

La arquitectura de las especificaciones CODASYL de 1971 pasó de ser una arquitectura a dos niveles (esquema y subesquema) a transformarse en 1978 en una descripción totalmente lógica de la base de datos al eliminarse los aspectos físicos que pasa al esquema de almacenamiento. Existen tres niveles, ya que se separan los aspectos físicos en un nuevo esquema llamado de almacenamiento, mientras que las características de tipo lógico siguen formando parte del esquema

Elementos básicos del modelo

• Campos o elementos de datos(data item): Unidad de datos mas pequeñas a la que se puede hacer referencia.
• Agregado de datos (data aggregate) Puede ser un vector o bien un grupo repetitivo. Se corresponde con los campos del fichero clásico y con los atributos de otros modelos, como el relacional
• Registro (record): Colección nominada de elementos de datos. Es la unidad básica de acceso y manipulación de la base de datos y se corresponde con el concepto de registro y de entidad.
• Conjunto (SET o COSET): es una colección nominada de dos o mas tipos de registros que establece una vinculación entre ellos.
• Área (area o realm): Es una subdivisión nominada del espacio de almacenamiento direccionable de la base de datos que contiene ocurrencias de registros. En 1981 paso a ser del esquema de almacenamiento.
• Clave de la base de datos (database-Key): identificador interno único para cada ocurrencia del registro que proporciona su dirección en la base de datos en principio, la clave de la bases de datos era permanente y se podía utilizar para acceder rápidamente a un registro de forma permanente.

Modelo Jerárquico

El modelo jerárquico se trata de un caso particular de los modelos en red. Y están organizados en estructuras de árbol, compuestas de nodos, que representan las entidades, enlazados por arcos, que representan las asociaciones o interrelaciones entre dichas entidades.
El modelo jerárquico se basa en almacenar los datos en una serie de registros, los cuales tienen campos asociados a ellos. Para crear enlaces entre los tipos de registros, el modelo jerárquico utiliza las relaciones padre-hijo, correspondencias 1:N entre tipos de registro. Esto se realiza mediante el uso de árboles.
A diferencia de otros modelos, el modelo jerárquico representa precisamente eso, todas las relaciones están jerarquizadas en un árbol, por lo que no es capaz de establecer enlaces entre hijos o entre capas, si no es padre-hijo.
En 1968, IBM introdujo el sistema IMS, derivado del programa Apolo de la NASA sobre sus System/360, basado en el modelo jerárquico. Este modelo fue adoptado por muchos bancos y compañías de seguros. No tiene una base teórica. Lo que se explique se extrae de la observación de un producto comercial como es IMS (Informatión Management System) de IBM con el lenguaje de datos DL/I.
La ventaja del modelo jerárquico es su gran estructuración, que en aquel tiempo se veía como una gran ventaja para mejorar el rendimiento de las transacciones (inserción, modificación y borrado de registros), así como para simplificar la interfaz para los usuarios.
La implementación del modelo jerárquico se lleva a base de punteros. La estructura física, organización y tipos de punteros, que varía según los productos, e incluso el mismo producto proporciona diferentes organizaciones físicas con el fin de conseguir una mayor eficiencia en el diseño del modelo físico.
La estructura del modelo jerárquico es un caso particular del modelo de red, tiene fuertes restricciones adicionales derivadas de las asociaciones deben formar un árbol en el que el orden de los nodos es importante.

Principales características del modelo de datos jerárquico.

1. El árbol se organiza en un conjunto de niveles.
2. El nodo raíz, el mas alto de la jerarquía se corresponde con el nivel 0.
3. Los arcos representan las asociaciones jerárquicas entre dos entidades y no tienen nombre, ya que no es necesario porque entre dos conjuntos de datos sólo puede haber una interrelación.
4. Un nodo de nivel superior (padre) puede tener un número ilimitado nodos de nivel inferior (hijos), al nivel inferior en cambio solo le puede corresponder un único nodo de nivel superior. Es decir, un registros padre puede tener un número indeterminado de hijos pero un hijo no puede tener más de un padre.
5. Todo nodo a Excepción del nodo raíz deben tener obligatoriamente un padre. Se llaman hojas los nodos que no tienen descendientes
6. Se llama altura al número de niveles de la estructura jerárquicas.
7. Se denomina momento al número de nodos.
8. Solo se permiten interrelaciones 1:1 o 1:n
9. La información se guarda árbol a árbol y de izquierda a derecha y de arriba a abajo.

Las funciones de manipulación de datos soportadas por el modelo son:

• Manipulación de los datos.
• Seleccionar un árbol determinado.
• Pasar de un árbol a otro.
• Pasar de un padre a su primer hijo.
• Pasar de un registro a otro dentro de un mismo nivel.
• Insertar/borrar registros de un nivel.

Frente al modelo en red, el modelo de datos jerárquico sí que introduce restricciones de integridad, lo que aumenta la potencia de modelado y restricción del modelo:

• No se puede tener un hijo sin su padre.
• Permite borrados y actualizaciones en cascada.

El modelo jerárquico es muy eficiente en accesos asociados con la jerarquía del árbol, en cambio presenta importantes inconvenientes como:

• Su rigidez e incapacidad de representar sin redundancias ciertas estructuras muy difundidas como las relaciones reflexivas y N:M
• Poca flexibilidad de este modelo puede obligar a la introducción de redundancias
• Un pequeño cambio en el programa puede suponer grandes modificaciones en el sistema.
• Las actualizaciones pueden originar problemas, toda alta que no se corresponda a un nodo raíz debe tener un padres y la baja de un

registro supone que desaparezca todo el subarbol que tiene dicho registro como nodo raíz.
Los SGBD basado en modelo jerárquicos suelen facilitar instrumentos que los dotan de mayor flexibilidad para representar estructuras no jerárquicas.

El modelo relacional.

El modelo relacional fue introducido por Codd en la década de las 70, siendo el modelo que se ha impuesto en las bases de datos comerciales de la actualidad, aunque éstas han ido introduciendo extensiones que las acercan desde un punto de vista semántico al modelo orientado a objetos, pero que trabajan con las primitivas de las bases de datos relacionales (tablas o tuplas, relaciones, claves, separación de niveles, etc.) por su gran estado de madurez.
Accede a una descripción más detallada del[modelo relacional]

El modelo orientado a objetos.

Introducción a la orientación a objetos.

Las bases de datos orientadas a objetos tratan de resolver el problema del almacenamiento persistente de la información desde el paradigma de la orientación a objetos. La principal ventaja es que no se introduce una ruptura entre ambas abstracciones: la del lenguaje de programación (objetos, estructuras de datos, etc.) y la del SGBD (relacional).
Para entender mejor los conceptos de los SGBD Orientado a Objetos, es necesario repasar los fundamentos de la orientación a objetos

Historia de los SGBD Orientados a Objetos.

El modelo de orientación a objetos aparece en los 80. Poco después comenzaron a surgir algunas iniciativas para construir bases de datos orientadas a objetos. No obstante, el avance era muy lento debido en parte a la inexistencia de un estándar.
En 1991, la reunión de algunas de las empresas que estaban desarrollando estos productos, frustradas por la falta de avance real hacia la consecución de un estándar, tuvo como consecuencia el nacimiento de un grupo de trabajo conocido como ODMG (Object Database Management Group). El resultado de sus primeros trabajos fue la publicación de la Release 1.0. Posteriormente en Febrero de 1994, este grupo se afilió al OMG (Object Management Group) y sucesivamente se establecieron relaciones con los grupos responsables de ANSI X3H2 (SQL), X3J16 (C++) y X3J20 (SmallTalk).
Ya en 1997 se publico la Release 2.0 de ODMG. Entre las empresas y organismos públicos que han colaborado en la elaboración de este estándar se encuentran Object Design, JavaSoft, UniSQL, Microsoft, Sybase, Fujitsu, Hitachi, Lucent Technologies, Andersen Consulting, EDS, AMS y el CERN. En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Entre los sistemas disponibles en el mercado están: GESTONE/OPAL de ServiLogic, ONTOS de Ontologic, Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjecStore de Object Design y O2 de O2 Technology.

Aplicación de la Orientación a Objetos a los SGBD

Hasta la aparición de las BD Orientadas a Objetos (BDOO), las BD tradicionales no estaban diseñadas para almacenar objetos, con lo que al guardar los datos de un programa OO se incrementaba significativamente la complejidad del programa, dando lugar a más código y más
esfuerzos de programación.
Las BDOO están diseñadas para simplificar la POO. Almacenan los objetos directamente en la BD, y emplean las mismas estructuras y relaciones que los lenguajes de POO. Las BDOO surgen de la combinación de las BD tradicionales y la POO.
Un SGBDOO es un Sistema de Objetos y un SGBD. Se puede decir que un SGBDOO es un SGBD que almacena objetos incorporando así todas las ventajas de la OO. Para los usuarios tradicionales de BD, esto quiere decir que pueden tratar directamente con objetos, no teniendo
que hacer la traducción a tablas o registros. Para los programadores de aplicaciones, esto quiere decir que sus objetos se conservan, pueden ser gestionados aunque su tamaño sea muy grande, pueden ser compartidos entre múltiples usuarios, y se mantienen tanto su integridad como sus relaciones.
Una clase después de programada es transportada a la BD tal como es, al contrario de lo que sucede en los SGBD relacionales donde el modelo de datos se distribuye en tablas.
Sin las BDOO, hay que hacer un complicado proceso de traducción de los objetos a registros o tablas de BD tradicionales. El problema de la traducción a tablas implica:

• Mayor tiempo de desarrollo. El tiempo empleado en generar el código para la traducción de objetos a tablas y viceversa.
• Errores debidos precisamente a esa traducción.
• Inconsistencias debidas a que el ensamblaje / desensamblaje puede realizarse de forma diferente en las distintas aplicaciones.
• Mayor tiempo de ejecución empleado para el ensamblaje / desensamblaje.

La utilización de una BDOO simplifica la conceptualización ya que la utilización de objetos permite representar de una manera más natural la información que se quiere guardar. Mejora el flujo de comunicación entre los usuarios, los diseñadores y los analistas.
Las BDOO permiten implementar los tres componentes de un modelo de datos:

1. Propiedades estáticas (objetos, atributos y relaciones)
2. Reglas de integridad de los objetos y operaciones
3. Propiedades dinámicas

Antes de los SGBDOO, los dos primeros componentes de un modelo de datos eran implementados en la BD dejando las propiedades dinámicas a cargo de la aplicación. Los SGBDOO implementan las tres características en la BD permitiendo, por ejemplo, aplicar reglas uniformes a objetos sin necesidad de desarrollar otra aplicación nueva cuando surge un cambio en el modo de trabajar con los datos.

Características Básicas de un SGBDOO

Un SGBDOO debe satisfacer dos criterios:

• Ser un SGBD lo que se traduce en 5 características principales: Persistencia, Concurrencia, Recuperación ante fallos, Gestión del almacenamiento secundario y facilidad de Consultas.
• Ser un Sistema OO: todo sistema OO debe cumplir algunas características como son: Encapsulación, Identidad, Herencia y Polimorfismo.

Además existen otras características deseables como Control de tipos y Persistencia.

Manifiesto de las BDOO

El conocido “Manifiesto de los sistemas de BDOO”, que es resultado de la colaboración de un cierto número de expertos, ha tenido mucha influencia al definir los objetivos del movimiento de las BDOO. Los aspectos principales de dicho manifiesto son los siguientes:

1. Objetos complejos: deben permitir construir objetos complejos aplicando constructores sobre objetos básicos.
2. Identidad de los objetos: todos los objetos deben tener un identificador que sea independiente de los valores de sus atributos.
3. Encapsulación: los programadores sólo tendrán acceso a la interfaz de los métodos, de modo que sus datos e implementación estén ocultos.
4. Tipos o clases: el esquema de una BDOO incluye un conjunto de clases o un conjunto de tipos.
5. Herencia: un subtipo o una subclase heredará los atributos y métodos de su supertipo o superclase, respectivamente.
6. Ligadura dinámica: los métodos deben poder aplicarse a diferentes tipos (sobrecarga). La implementación de un método dependerá del tipo de objeto al que se aplique. Para proporcionar esta funcionalidad, el sistema deberá asociar los métodos en tiempo de ejecución.
7. Su LMD debe ser completo
8. El conjunto de tipos de datos debe ser extensible: Además, no habrá distinción en el uso de tipos definidos por el sistema y tipos definidos por el usuario.
9. Persistencia de datos: los datos deben mantenerse después de que la aplicación que los creo haya finalizado. El usuario no tiene que hacer ningún movimiento o copia de datos explícita para ello.
10. Debe ser capaz de manejar grandes BD: debe disponer de mecanismos transparentes al usuario, que proporcionen independencia entre los niveles lógico y físico del sistema
11. Concurrencia: debe poseer un mecanismo de control de concurrencia similar al de los sistemas convencionales.
12. Recuperación: debe poseer un mecanismo de recuperación ante fallos similar al de los sistemas convencionales
13. Método de consulta sencillo: debe poseer un sistema de consulta ad-hoc de alto nivel, eficiente e independiente de la aplicación.

Si te ha gustado esta entrada, suscríbete para recibir las próximas entradas por correo electrónico. Por favor, apoya este blog.