Un modelo de base de datos muestra la estructura lógica de la base, incluidas
las relaciones y limitaciones que determinan cómo se almacenan los datos y
cómo se accede a ellos. Los modelos de bases de datos individuales se diseñan
en base a las reglas y los conceptos de cualquier modelo de datos más amplio
que los diseñadores adopten. La mayoría de los modelos de datos se pueden
representar por medio de un diagrama de base de datos acompañante
Modelo entidad-relación
Este modelo capta las relaciones entre entidades del mundo real de forma muy
similar al modelo de red, pero no está directamente ligado a una estructura
física de la base de datos. En cambio, con frecuencia se lo usa para diseñar
una base de datos conceptualmente.
Aquí, a las personas, lugares y cosas, acerca de las cuales se almacenan puntos
de datos, se las denomina entidades, cada una de las cuales tiene ciertos
atributos que en conjunto forman su dominio. La cardinalidad, o relaciones
entre entidades, también se representan en diagramas.
Una forma común del diagrama entidad-relación ER es el esquema de estrella,
en el cual una tabla central de información se conecta a múltiples tablas
dimensionales
Modelo Entidad/Relación
Se trata de una técnica cuyo objetivo es la representación y definición de
todos los datos que se introducen, almacenan, transforman y producen
dentro de un sistema de información, sin tener en cuenta las necesidades
de la tecnología existente, ni otras restricciones.
Dado que el modelo de datos es un medio para comunicar el significado
de los datos, las relaciones entre ellos y las reglas de negocio de un
sistema de información, una organización puede obtener numerosos
beneficios de la aplicación de esta técnica, pues la definición de los datos
y la manera en que éstos operan son compartidos por todos los usuarios.
Las ventajas de realizar un modelo de datos son, entre otras:
Comprensión de los datos de una organización y del
funcionamiento de la organización.
Obtención de estructuras de datos independientes del entorno
físico.
Control de los posibles errores desde el principio, o al menos,
darse cuenta de las deficiencias lo antes posible.
Mejora del mantenimiento.
Aunque la estructura de datos puede ser cambiante y dinámica,
normalmente es mucho más estable que la estructura de procesos.
Como resultado, una estructura de datos estable e integrada proporciona
datos consistentes que puedan ser fácilmente accesibles según las
necesidades de los usuarios, de manera que, aunque se produzcan
cambios organizativos, los datos permanecerán estables.
Este diagrama se centra en los datos, independientemente del
procesamiento que los transforma y sin entrar en consideraciones de
eficiencia. Por ello, es independiente del entorno físico y debe ser una fiel
representación del sistema de información objeto del estudio,
proporcionando a los usuarios toda la información que necesiten y en la
forma en que la necesiten.
¿Qué es el modelo entidad-relación?
Como ya he comentado este modelo es solo y exclusivamente un
método del que disponemos para diseñar estos esquemas que
posteriormente debemos de implementar en un gestor
de BBDD (bases de datos). Este modelo se representa a través de
diagramas y está formado por varios elementos.
Este modelo habitualmente, además de disponer de un diagrama
que ayuda a entender los datos y como se relacionan entre ellos,
debe de ser completado con un pequeño resumen con la lista de los
atributos y las relaciones de cada elemento.
Elementos del modelo entidad-
relación
Entidad
Las entidades representan cosas u objetos (ya sean reales o
abstractos), que se diferencian claramente entre sí.
Para poder seguir un ejemplo durante el artículo añadiré ejemplos
sobre un taller mecánico, donde se podría crear las siguientes
entidades:
Coches (objeto físico): contiene la información de cada taller.
Empleado (objeto físico): información de los trabajadores.
Cargo del empleado (cosa abstracta): información de la
función del empleado.
Estas entidades se representan en un diagrama con un rectángulos,
como los siguientes.
Atributos
Los atributos definen o identifican las características de entidad (es
el contenido de esta entidad). Cada entidad contiene distintos
atributos, que dan información sobre esta entidad. Estos atributos
pueden ser de distintos tipos (numéricos, texto, fecha...).
Siguiendo el ejemplo de antes podemos analizar los atributos de
nuestra entidad "Coches", que nos darán información sobre los
coches de nuestro supuesto taller.
Unos posibles atributos serían los siguientes: número de
chasis, matrícula, DNI del propietario, marca, modelo y muchos otros
que complementen la información de cada coche.
Los atributos se representan como círculos que descienden de una
entidad, y no es necesario representarlos todos, sino los más
significativos, como a continuación.
En un modelo relacional (ya implementado en una base de datos)
una ejemplo de tabla dentro de una BBDD podría ser el siguiente.
Número de chasis Matrícula DNI del propietario
5tfem5f10ax007210 4817 BFK 45338600L
6hsen2j98as001982 8810 CLM 02405068K
5rgsb7a19js001982 0019 GGL 40588860J
Este ejemplo es con tres atributos, pero un coche podría tener
cientos (si fuese necesario) y seguirían la misma estructura de
columnas, tras implementarlo en una BBDD.
Relación
Es un vínculo que nos permite definir una dependencia entre varias
entidades, es decir, nos permite exigir que varias entidades
compartan ciertos atributos de forma indispensable.
Por ejemplo, los empleados del taller (de la entidad "Empleados")
tienen un cargo (según la entidad "Cargo del empleado"). Es decir,
un atributo de la entidad "Empleados" especificará que cargo tiene
en el taller, y tiene que ser idéntico al que ya existe en la entidad
"Cargo del empleado".
Las relaciones se muestran en los diagramas como rombos, que se
unen a las entidades mediante líneas.
Yo, bajo mi punto de vista, entiendo mejor esto en una tabla (de una
implementación en una BBDD), por lo que voy a poner el ejemplo de
como se representaría (resaltada la relación, que posteriormente
veremos como se haría).
Relaciones de cardinalidad
Podemos encontrar distintos tipos de relaciones según como
participen en ellas las entidades. Es decir, en el caso anterior cada
empleado puede tener un cargo, pero un mismo cargo lo pueden
compartir varios empleados.
Esto complementa a las representaciones de las relaciones, mediante
un intervalo en cada extremo de la relación que especifica
cuantos objetos o cosas (de cada entidad) pueden intervenir en esa
relación.
Uno a uno: Una entidad se relaciona únicamente con otra y
viceversa. Por ejemplo, si tuviésemos una entidad con distintos
chasis y otra con matrículas deberíamos de determinar que cada
chasis solo puede tener una matrícula (y cada matrícula un chasis, ni
más en ningún caso).
Uno a varios o varios a uno: determina que un registro de una
entidad puede estar relacionado con varios de otra entidad, pero en
esta entidad existir solo una vez. Como ha sido en el caso anterior
del trabajador del taller.
Varios a varios: determina que una entidad puede relacionarse con
otra con ninguno o varios registros y viceversa. Por ejemplo, en el
taller un coche puede ser reparado por varios mecánicos distintos y
esos mecánicos pueden reparar varios coches distintos.
Los indicadores numéricos indican el primero el número mínimo de
registros en una relación y posteriormente el máximo (si no hay
límite se representa con una "n").
Claves
Es el atributo de una entidad, al que le aplicamos una restricción que
lo distingue de los demás registros (no permitiendo que el atributo
específico se repita en la entidad) o le aplica un vínculo (exactamente
como comentábamos en las relaciones). Estos son los distintos tipos:
Superclave: aplica una clave o restricción a varios atributos de la
entidad, para así asegurarse que en su conjunto no se repitan varias
veces y así no poder entrar en dudas al querer identificar un registro.
Clave primaria: identifica inequívocamente un solo atributo no
permitiendo que se repita en la misma entidad. Como sería la
matrícula o el número de chasis de un coche (no puede existir dos
veces el mismo).
Clave externa o clave foránea: este campo tiene que estar
estrictamente relacionado con la clave primaria de otra entidad, para
así exigir que exista previamente ese clave. Anteriormente hemos
hablado de ello cuando comentábamos que un empleado
indispensablemente tiene que tener un cargo (que lo hemos
representado numéricamente), por lo cual si intentásemos darle un
cargo inexistente el gestor de bases de datos nos devolvería un
error.
El modelo de red es un modelo de base de datos concebido como un modo
flexible de representar objetos y su relación. 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.
Una estructura de base de datos de red, llamada algunas veces estructura de
plex, abarca más que la estructura de árbol: 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.
El modelo de red (definido por la especificación CODASYL) organiza datos
que usan dos fundamental construcciones, registros llamados y conjuntos. Los
registros contienen campos (que puede ser organizado jerárquicamente, como
en el lenguaje COBOL de lenguaje de programación). Los conjuntos (para no
ser confundido con conjuntos matemáticos) definen de uno a varias relaciones
entre registros: un propietario, muchos miembros. Un registro puede ser un
propietario en cualquier número de conjuntos, y un miembro en cualquier
número de conjuntos.
Modelo Jerárquico
Un modelo de datos jerárquicos es un modelo de datos en el cual los datos son
organizados en una estructura parecida a un árbol. La estructura permite a la
información que repite y usa relaciones padre/hijo: cada padre puede tener
muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un
registro específico son catalogados bajo un tipo de entidad.
Una base de datos jerárquica es un tipo de sistema de gestión de bases de
datos que almacenan la información en una estructura jerárquica que alcanza
los registros en forma de estructura de árbol en donde un nodo padre de
información puede tener varios modos hijo. De la misma manera se puede
establecer relación entre los nodos hermanos, en este caso la estructura en
forma de árbol se convierte en una estructura en forma de grafo dirigido.
El modelo jerárquico se clasifica en estructuras lineales y arborescentes. La
primera clase de estructura, cada tipo de registro padres sólo puede tener un
tipo de registro hijo. La segunda, un tipo de registro padre puede tener varios
tipos de registro hijos. El producto comercial de tipo jerárquico más extendido
y el único que ha llegado hasta nuestros días es el IMS de IBM.
Estructura
En un modelo jerárquico, los datos están organizados en una estructura
arbórea (dibujada como árbol invertido o raíz), lo que implica que cada
registro sólo tiene un padre. Las estructuras jerárquicas fueron usadas
extensamente en los primeros sistemas de gestión de datos de unidad central,
como el Sistema IMS por IBM, y ahora se usan para describir la estructura de
documentos XML, esta estructura permite relaciones 1:N entre los datos, y es
muy eficiente para describir muchas relaciones del mundo real: tabla de
contenidos, ordenamiento de párrafos y cualquier tipo de información anidada.
Sin embargo, la estructura jerárquica es ineficiente para ciertas operaciones de
base de datos cuando el camino completo no se incluye en cada registro. Una
limitación del modelo jerárquico es su incapacidad para representar manera
eficiente la redundancia en datos.
En la relación padre-hijo: el hijo puede tener un padre pero un padre puede
múltiples hijos. Los padres e hijos están unidos por enlaces, todo nodo tendrá
una lista de enlaces a sus hijos.
Un diccionario de datos es un conjunto de metadatos que contienen las
características lógicas y puntuales de los datos que se van a utilizar en el
sistema, incluyendo descripción, alias, contenido y organización