Mostrando entradas con la etiqueta Jerarquías. Mostrar todas las entradas
Mostrando entradas con la etiqueta Jerarquías. Mostrar todas las entradas

viernes, 16 de septiembre de 2011

Modelo de Datos Jerárquico: Transformación E/R - Jerárquico


Ya se han señalado los inconvenientes que presenta el modelado del mundo real según esquemas jerárquicos, y también hemos indicado una técnica de diseño jerárquico que consiste en introducir redundancias.


A partir del modelo E/R, vamos a analizar la forma de transformar algunos tipo, de interrelaciones al modelo jerárquico. 

A) Interrelaciones 1:N con cardinalidad mínima 1 en la entidad padre. 

En este caso no existe ningún problema y el esquema jerárquico resultante será prácticamente el mismo que en el ME/R.


B) Interrelaciones 1:N con cardinalidad mínima 0 en el registro propietario. 

El problema es que podrían existir hijos sin padre, por lo que o se crea un padre ficticio para estos casos o se crean dos estructuras arborescentes. 


La primera estructura arborescente tendrá como nodo padre el tipo de registro A y como nodo hijo los identificadores del tipo de registro B. De esta forma no se introducen redundancias, estando los atributos de la entidad B en la segunda arborescencia, en la cual sólo existiría un nodo raíz B sin descendientes. 

C) Interrelaciones N:M 

La solución es muy parecida, creándose también dos arborescencias. 


La solución es independiente de las cardinalidades mínimas. Se podría suprimir, en la primera arborescencia 
o en la segunda, el registro hijo, pero no se conservaría la simetría. 


D) Interrelaciones reflexivas 

La jerarquía a) se utilizaría siempre que se desee obtener la explosión. 

La aplicación de estas normas de diseño evita la introducción de redundancias, así como la pérdida de simetría, pero complica enormemente el esquema jerárquico resultante que estará constituido por más de un árbol, lo que no resulta fácilmente comprensible a los usuarios.








Modelo de Datos Jerárquico: Restricciones de Integridad


Estas restricciones 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

Fuente: http://es.wikipedia.org/wiki/Base_de_datos_jer%C3%A1rquica