Tarea 03 - Modelo de Datos y Datos orientados a Objetos

Conceptos avanzados de modelo de datos

El modelo ER extendido (EER) incluye los conceptos del modelo ER, la diferencia esta en que el EER incluye también los conceptos de subclase, superclase, especialización,
generalización y herencia de atributos.

Subclases y superclases:Algunos tipos de entidades tienen subagrupaciones a parte de sus entidades que tambien son importantes, estas son
las subclases. Y el tipo de entidad a la que pertenece es la superclase.
Por ello cualquier entidad que sea parte de la subclase será también parte de la superclase.

Especializacion:Es un proceso en el cual se define un conjunto de subclases a partir de un tipo de entidad. Este tipo de entidad de llama superclase de la especializacion.
Se puede tener varias especializaciones del mismo tipo de entidad, estas se basan en diferentes características.

Retícula de especialización:Es una reticula de especialización cuando una subclase puede ser subclase de varias superclases.

Generalización:Es un proceso en el cual se define superclases, para ello se trata de eliminar las diferencias existentes entre varios tipos de entidades, se busca rasgos comunes y se generaliza para obtener una sola superclase. Las superclases de esta superclase se llaman subclases especiales.

Herencia:Una subclase hereda los atributos de la superclase, pero no solo de la superclase directa (la que la precede), si no también de todas las superclases que le preceden.
Si una subclase tiene varias superclases se llama subclase compartida. Esto genera una herencia múltiple, esta subclase hereda directamente los atributos de las superclases.
Vale aclarar que a pesar que una subclase sea compartida, las superclases tienen a su vez una misma superclase.

Categorías y la categorización:En el caso que una subclase tenga mas de una superclase se la llama categoria.Esta categoría es la representacion de una clase que es la unión de todas las entidades que se necesita representar.Una categoria tiene dos o más superclases que representan diferentes tipos de entidades, una antidad que sea miembro de una categoria debe estar por lo menos en algunas de las superclases, pero no necesariamente en todas.

Bases de datos orientadas a Objetos

El modelo objeto difiere en este sentido bastante. Utiliza varios sistemas diferentes dependiendo de la implementación que se esté utilizando. Hay sistemas, directamente imbuidos en el lenguaje de programación que hacen esta recuperación de los datos transparente al programador, trabajando con los objetos persistentes como si fueran objetos de memoria normales. Esta visión es muy eficiente e intuitiva pero al no tener un lenguaje específico para trabajar con las consultas no controla de forma alguna este acceso siendo vulnerable a errores del programador.

Otra forma de implementar las consultas ha sido el estándar OQL (Object Query Language) definido por el Object Data Management Group (ODMG) que busca ser un estándar declarativo para consultas a bases de datos orientadas a objetos. Su uso sería análogo al de SQL pero, debido a su complejidad aún no hay ninguna implementación completa del estándar, sólo se han llegado a realizar subconjuntos como JDOQL y EJB QL.

La forma de trabajar con los datos persistentes en el modelo relacional es seleccionando los datos que queremos que persistan en el tiempo y grabándolos de manera explicita mediante consultas de alta/modificación de SQL, previa transformación de los datos. Los objetos trabajan de otra forma. Dependiendo de la implementación particular puede ser que haya clases persistentes, cuyos objetos siempre se almacenen en disco, marcar especiales para los objetos que permitan discriminar cuáles se almacenarán, y otras técnicas.

Esta es una de las partes más complejas de implementar de un sistema gestor de bases de datos orientados a objetos ya que se busca que este paso a datos persistentes sea lo más transparente posible para el programador de aplicaciones orientadas a objetos.

Obviamente el modelo objeto es una forma de centrar el desarrollo y explotación de un sistema en la semántica del dato. En el modelo relacional había que adaptar la semántica a las capacidades del sistema de una manera bastante estricta. En cambio, cuando trabajamos con objetos podemos aplicar la semántica propia del problema de una manera mucho más natural, ya que este paradigma se basa en modelar el mundo real.

Las relaciones entre entidades des modelo es una característica muy importante que cualquier base de datos moderna debe poseer. La orientación a objetos facilita mucho esta tarea gracias a los OID y a la herencia. Las relaciones de herencia, para lo cual se permite la herencia entre clases de la misma forma que en los lenguajes de programación, heredando el hijo todos los atributos y métodos que hubiera definido su padre. El resto de relaciones que hubiera que representar se haría mediante los OID que identifican univocamente a un objeto.

En las bases de datos relaciones, las relaciones de herencia se pueden simular mediante complejos sistemas que obligaban al programador a aplicar una serie de mecanismos que garantizaran la integridad. Y el resto de relaciones, por norma general crean una serie de tablas intermedias que complica las sentencias SQL necesarias para recuperar los datos.

El acceso a los datos, en la gran mayoría de los sistemas gestores de bases de datos orientados a objetos, se realiza de una forma navegacional, al estilo de los modelos jerárquico y red lo cual obliga al usuario a conocer la ruta de acceso a los objetos. Esto, además de complicar el uso para usuarios no programadores, unido a la necesidad de requisitos indirectos de hardware y software debido al uso de objetos ralentiza las transacciones respecto al modelo relacional, lo que lo convierte en muchos casos en algo inaceptable.

Las bases de datos orientadas a objetos permiten el almacenamiento de archivos multimedia ya que un objeto puede ser cualquier cosa. Las bases de datos relacionales no permiten esto y hay que simularlo guardando la dirección del archivo, con lo que no se garantiza que el archivo exista, o almacenando en un campo binario de longitud indeterminada el archivo completo sin capturar la propia base de datos de que tipo de archivo se trata.

Tarea 02 - Modelos Base de Datos

Base de datos de red

Una base de datos de red es una base de datos conformada por una colección o set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional.

Un registro es una colección o conjunto de campos (atributos), donde cada uno de los que contiene solamente un único valor almacenado, exclusivamente el enlace es la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria.

Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol, porque un nodo hijo en la estructura red puede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa.

Así, la estructura de árbol se puede considerar como un caso especial de la estructura de red.

Uso de la transformación ER-Red para el diseño de bases de datos de red

Una base de datos de red se compone por una colección de registros que se conectan entre sí por medio de ligas.

Un registro equivale a una entidad y un campo a un atributo del modelo entidad relación. Los campos contienen exclusivamente valores atómicos. Una liga es una relación que se establece solamente entre dos registros; es decir; debe utilizarse una liga para cada relación entre una pareja de registros.

Ejemplo

Para ilustrar la estructura de los registros en una base de datos de red, mostraremos la base de datos alumno – materia, con los siguientes registros (en el Lenguaje de programación Pascal):

type materia = record
     clave: string[7]
     nombreM: string[25]
     cred: string[2];
     end;

type alumno = record
     nombre: string[30];
     control: string[8];
     materia: Materia; {Enlace a materia}
     end;

En síntesis una base de datos en red puede tener 1 o mas elementos padre.

Base de datos jerárquica

Una base de datos jerárquica es un tipo de sistema de gestión de bases de datos que, como su nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo.

Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden establecerse relaciones entre nodos hermanos. En este caso la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido. Esta variante se denomina Bases de datos de red.

Cómo funcionan

A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica de una vista física de la base de datos. De manera que las relaciones entre datos se establecen siempre a nivel físico, es decir, mediante referencia a direcciones físicas del medio de almacenamiento (sectores y pistas).

Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en inglés), el equivalente a las tablas del modelo relacional.

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea.

Obsérvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el modelo jerárquico. Salvo que se simulen mediante varias relaciones 1:N. No obstante, esto puede provocar problemas de inconsistencia, ya que el gestor de base de datos no controla estas relaciones.

Como ya se ha mencionado, las relaciones se establecen mediante punteros entre registros. Es decir, un registro hijo contiene la dirección física en el medio de almacenamiento de su registro padre. Esto tiene una ventaja fundamental sobre las bases de datos relacionales: el rendimiento. El acceso de un registro a otro es prácticamente inmediato sin necesidad de consultar tablas de correspondencia.

Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea muy sencillo responder a determinadas preguntas, pero muy difícil el contestar a otras.

Limitaciones del modelo jerárquico

A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias.

Duplicidad de registros

No se garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos "clave". Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos.

Integridad referencial

No existe garantía de que un registro hijo esté relacionado con un registro padre válido. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que éstos últimos están relacionados con un registro inválido o inexistente..

Desnormalización

Este no es tanto un problema del modelo jerárquico como del uso que se hace de él. Sin embargo, a diferencia del modelo relacional, las bases de datos jerárquicas no tienen controles que impidan la desnormalización de una base de datos. Por ejemplo, no existe el concepto de campos clave o campos únicos.

La desnormalización permite ingresar redundancia de una forma controlada, seguir a una serie de pasos conlleva a:

• Combinar las relaciones
• Duplicar los atributos no claves
• Introducción de grupos repetitivos
• Crear tablas de extracción

Cuando se debe desnormalizar:

• Se debe desnormalizar para optimizar el esquema relacional
• Para hacer referencia a la combinación de 2 relaciones que forman una sola relación

Ejemplo:
Proveedor (Nro_proveedor, calle, ciudad, cod_postal, descripción) La relación Proveedor esta desnormalizada, ya que para normalizarla deberíamos crear una tabla con ciudad y código postal

Gestores de bases de datos jerárquicas

• Adabas
• GT.M
• IMS
• Focus

 

Tarea 01 - Formas Normales

El proceso de normalización.

La teoría de la normalización permite reconocer propiedades indeseables en las relaciones y convertirlas. Tiene como fundamento el concepto de formas normales. Se dice que una relación está en una determinada forma normal si satisface un cierto conjunto de restricciones. El proceso de normalización es reversible y no se pierde información.

1) Primera Forma Normal (1FN)

Una relación está en primera forma normal o  (1FN) si todos los atributos de cada tupla contienen un solo valor tomado de sus dominios respectivos (valores atómicos), todos los atributos de una relación tienen valores simples, todos los valores de cualquier columna son del mismo tipo y no hay grupos ni arreglos repetidos como valores.

Ejemplo:

Fallas:
Las fallas en el almacenamiento de una relación que ya está en 1FN, se deben a la presencia de uno o más atributos no-clave que no son DFC con la clave primaria (PK). Los defectos se pueden eliminar con el siguiente procedimiento. Quitar de la relación 1FN todos los atributos no-clave que no estén en DFC de la PK. Guardar esos atributos no-clave en relaciones nuevas y adecuadas.




2) Segunda Forma Normal (2FN)
Una relación está en segunda forma normal o (2FN) si es 1FN y cada atributo no clave de la relación es total y funcionalmente dependiente (DFC) de su clave primaria.



Ejemplo:

 

 

Fallas:
Los defectos de almacenamiento de una relación 2FN son causados por la dependencia transitiva (DT) de atributos no-clave con la clave primaria. Se puede normalizar como sigue: Examinar cada atributo no-clave para ver si está en DF con otro atributo diferente de la PK. Crear una nueva relación para almacenar la no-clave transitivamente dependiente.





3) Tercera Forma Normal (3FN)
Una relación está en tercera forma normal o (3FN) si es 2FN y ningún atributo no-clave en la relación esta en DF con algún otro atributo no-clave.


Ejemplo:

Fallas:
Si está en 2FN y no tiene dependencias transitivas.




4) Cuarta Forma Normal (4FN)
Una relación está en cuarta forma normal (4FN) si es BCFN y no contiene dependencias multivalor.


Ejemplo:

EJEMPLO con todos los pasos: