Arquitectura de Bases de Datos.
En 1975, el comité ANSI-SPARC (American National Institute – Standards Plannings and Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de datos cuyo objetivo es el de separar las aplicaciones de la base de datos física.
Modelo de Datos.
La idea primaria de los sistemas informáticos es poder plasmar, a través de diferentes herramientas, situaciones del mundo real. Para traspasar la realidad de una situación en concreto a una base de datos existe una serie de pasos intermedios que facilitan esta tarea. Una de estas herramientas es el modelo de datos, que permite describir de modo abstracto en qué forma se va almacenar y a recuperar la información existente en una base.
Quizás el más conocido sea el relacional, pero existen otros modelos de administración de datos, los cuales detallaremos a continuación:
- Modelo jerárquico.
- Modelo de red.
- Modelo orientado a objetos.
Ahora haremos un análisis de todos ellos para conocer sus diferencias y sus características más sobresalientes en lo que se refiere al diseño de bases de datos.
Modelo Jerárquico.
Las bases de datos que ingresan de este modelo organizan su información utilizando niveles de jerarquías. Cada nivel de jerarquías puede tener un número N de nodos, con la particularidad de que cada uno no puede tener más de un padre.
Fig. 1 Modelo Jerárquico.
En la Figura 1, el nodo 1 no tiene padre – cuando se da esta situación se lo llama nodo raíz y tiene dos hijos. De esos hijos solo hay uno que es padre. Haciendo semejanza entre los tipos de relaciones que admite el modelo relacional, el modelo jerárquico admite relaciones uno a varios y uno a uno.
Este modelo tiene muchos puntos en común con las estructuras de tipo árbol.
En comparación con el modelo relacional aquí si importa, como en el modelo de red, el orden en que se ubiquen los datos.
Uno de los inconvenientes del modelo jerárquico consiste en la redundancia de datos. Supongamos una relación Maestro.Detalle, como es pedidos y productos. Cada pedido puede contener más de un producto y, a su vez, cada producto puede encontrarse contenido en más de un pedido. Si intentamos simular esta situación por medio del modelo jerárquico, llegaremos a la conclusión de que es imposible, a menos que repita informaciones.
Fig 2. Maesto – Detalle en el modelo jerárquico.
Un problema aparte es el de eliminar un nodo padre. Se tendría que eliminar toda su descendencia. Esta clase de problemas se solucionan en los demás modelos.
Modelo de red
Es ligeramente similar al modelo jerárquico. Una de las diferencias fundamentales es que aquí un nodo puede tener varios padres. Administrar la información en una base de datros de este tipo puede llegar a ser demasiado dificultoso, debido a que existe la posibilidad de que haya una gran cantidad de interrelaciones entre nodos.
Fig. 3 Modelo de red.
En la imagen anterior se puede observar algunas de las posibles relaciones existentes entre nodos: el nodo 2 y el nodo 3 son padres del nodo 4, que a su vez es padre del nodo 5. El nodo 1 no tiene padres ni hijos.
Este modelo admite relaciones uno a varios y uno a uno.
Modelo de relacional
Se trata, sin dudas del modelo más popular desde hace un tiempo, y con él se imponen conceptos tales como tabla – arreglo bidimensional-, fila y columna. Es un modelo relativamente nuevo (tomó notoriedad en 1970 y a su autor, Edgar Frank Codd,) quizás el único que llego tanto a los usuarios finales como también a los desarrolladores. Se recuperan los datos por medio de lenguajes de programación de consulta (el más popular e SQL, pero también existen otros lenguajes de este tipo) que mantienen la compatibilidad aun entre sistemas gestores de bases de datos de distintas compañías e incluso entre sistemas operativos diferentes.
Entendemos el modelo relacional como una propuesta de ver los datos como si se trataran de objetos del mundo real, diferenciables entre sí por sus características básicas. Un objeto dado puede ser descrito por la colección de características que tiene (denominadas atributos), y diferenciable a partir de eso mismo de otros objetos. Este modelo admite relaciones uno a varios, uno a uno, y varios a varios.
En este modelo las tablas deben cumplir las siguientes reglas:
- Cada fila debe ser única.
- Cada columna debe ser única.
- Los valores de las columnas deben pertenecer al dominio de cada atributo.
- Debe tener un solo tipo de fila.
- El valor de la columna para cada fila debe ser único.
Modelo orientado a objetos
Al intentar trabajar con sistemas de información geográfica o también con sistemas multimedia, los modelos anteriormente mencionados no se sienten demasiado cómodos e incluso algunos ni siquiera pueden soportarlos por, entre otros, los motivos que se enumeran a continuación.
- La estructura de los objetos es más compleja;
- Las transacciones son de larga duración;
- Se necesitan nuevos tipos de datos para almacenar imágenes y textos;
- Hace falta definir operaciones no estándar, específicas para cada aplicación.
Este modelo admite relaciones uno a varios, uno a uno, y varios a varios.
No hay comentarios.:
Publicar un comentario