PDF de programación - Tema 2 - Entidad-relación

26/02/2012

1

El Dr. Peter Pin-Shan Chen es el creador del Modelo Entidad-Relación
(Modelo ER). En el año 1968, obtuvo el grado de Licenciado en Ciencias
en la Universidad Nacional de Taiwán. Posteriormente, en el año 1973,
obtuvo el grado académico de Doctor en Ciencias de la Computación y
Matemáticas Aplicadas en la Universidad de Harvard. Desde 1983, el Dr.
Peter Chen disfruta del cargo de M. J. Distinguished Chair Professor of
Computer Science en la Universidad del Estado de Louisiana.

El artículo original de Peter Chen[1] sobre el Modelo ER es
uno de los trabajos más citados en el campo de las ciencias
de la computación. Este artículo ha sido recientemente
galardonado como uno de los 38 artículos más influyentes
para las ciencias de la computación, según una encuesta
realizada a cerca de 1000 investigadores universitarios.

[1] Peter P. Chen. The Entity-Relationship Model: Toward a
Unified View of Data Export. ACM Transactions on Database
Systems, Vol. 1 (1976), pp. 9-36.



2

El E-R (y posteriormente el EER, Entidad-Relación Extendido) es la
frontera entre los modelos de datos clásicos y semánticos. Aún cuando
tiene alguna herramienta de representación más que el modelo relacional,
son muy cercanos los dos. Hay que decir, también, que no todo lo que se
puede expresar en modelo relacional tiene su correspondencia en E-R, es
decir, aunque asumimos que el modelo E-R es posterior y algo más rico
expresivamente, las cosas que podemos "decir" usando el modelo
relacional NO es un subconjunto exacto del E-R.



En cualquier caso, no se resuelve la falta de conceptos para expresar
restricciones dinámicas, las que tiene que ver con los procesos en los que
usan los datos, la parte estática: cómo se genera una factura, cómo se
realiza un pedido a proveedores, etc.

3

No existen SGBD... que hayan tenido éxito, alguna propuesta hubo.



El concepto de forma normal se verá en un tema posterior pero, para
entendernos, el E-R consigue "automatizar" un paso de diseño que
trabajando únicamente con modelo relacional es casi obligador realizar
hasta obtener una estructura de datos eficiente. Por contra, esta
"automatización" hace que "perdamos" algún detalle que el modelo
relacional sí es capaz de representar; no hay peligro, son muy pocos
estos casos y, en cualquier caso, para eso está el diseño lógico y físico.



Notaciones hay muchas, unas más comunes que otras. En nuestro caso,
hemos decidido adoptar una variante definida por nosotros, sin detrimento
de que puede transformarse sin pérdidas a cualquier otro sistema de
símbolos E-R.

4

Las entidades son el primer paso, los ladrillos con los que vamos a
construir todo nuestro sistema de información.

5

Una vez que ya tenemos entidades, podemos enriquecer el esquema con
las relaciones que hay entre ellas.



Téngase en cuenta que el diseño del esquema de una base de datos es
una tarea compleja que está más allá de los objetivos de la asignatura.
Hablamos de decenas, cientos de entidades, y tantas o muchas más
relaciones entre ellas, como escenario normal de un diseñador de bases
de datos. Aquí solo estamos mostrando los fundamentos del modelo y
sistemas de información extremadamente simples.



Al definir relaciones, estamos estableciendo ciertos límites a la hora de
insertar datos en nuestra base de datos. Cosas como que si permitimos
que un empleado trabaje en más de una empresa simultáneamente o no.
Son decisiones que toma el diseñador en función de cómo quiere que se
comporte el operador que maneja los datos a almacenar.

6

Los triángulos, rellenos o vacíos, son redundante, los utilizamos para que,
visualmente, sea más fácil identificar el tipo de cardinalidad que se está
representando. Por ejemplo, y en este caso, el EMPLEADO tiene unos
valores mínimo y máximo de (0,N), una relación "uno a muchos" con
EMPRESA, que se corresponde con el triángulo relleno opuesto.



De hecho, los triángulos hacen referencia a la cardinalidad máxima
únicamente (el número a la derecha: x..N o x..1). Los valores mínimos,
"1" como se verá más adelante, solo se pueden definir en las expresiones
numéricas que acompañan a la relación y la entidad.

7

8

9

Casi diríamos que "coloquialmente" se suele hablar de relaciones "uno a
uno", "uno a muchos" y "muchos a muchos". En realidad, falta todavía
hablar de restricciones de existencia y, en el caso de las 1:N, quién es el
"uno" y quién el "muchos".



Pero es perfectamente válido para describir lo general de la relación.

10

Las restricciones de existencia indican que un elemento de la base de
datos NO puede existir, no puede ser almacenado en nuestra base de
datos si no está relacionado con otro individuo de la otra entidad. Aquí,
que los empleados, al ser dados de alta en nuestro sistema,
obligatoriamente hay que decir en qué empresa trabajan. Si no es así, no
se puede almacenar al empleado en la base de datos.

11

Mucho cuidado. Esta es una de las cosas que SÍ se pueden decir en E-R
y NO se pueden traducir luego a modelo relacional.

12

Hay que tener mucho cuidado con lo que se diseña. Aquí estamos
estableciendo una situación que tiene una difícil solución en la base de
datos final, típicamente relacional. Si el empleado necesita que exista
previamente una empresa en la que va a trabajar, y la empresa necesita
que exista al menos un empleado que asignarle, ¿por dónde empezamos
a insertar datos en la BD? Habría que implementar un proceso especial
de inserción de datos para este caso.



En general, hay que poner única y exclusivamente las restricciones de
existencia que consideremos imprescindibles.

13

Esta es otra cosa que sí se puede decir en E-R pero no en modelo
relacional. Posteriormente, seguramente mediante el programa que
accede a la base de datos, se podría implementar el proceso que
verifique esta restricción tan especial.

14

Hasta ahora no habíamos mostrado entidades trabajando para varias
relaciones. En todo caso, cada relación tiene sus propias restricciones
independientemente de las demás.

15

16

Este es un caso bastante habitual en los sistemas de información
administrativos. Los documentos tipo pedido, albarán, factura, etc. Son
estructuras de datos que se componen de una cabecera con los datos
generales y una serie de líneas de detalle que muestran, en este caso, los
artículos que se están facturando.



Todas las facturas tienen varias líneas que comienzan a contar por la
línea número 1. Así, tenemos un problema porque son con "línea 1" no
tenemos suficiente información para distinguir entre líneas de detalle.

17

Aquí vemos varias líneas "L001", por poner un caso. ¿Cómo puedo
diferenciar entre ellas y consultar una en concreto?

18

Se trata de un problema de diseño: la dependencia de identificador. Sí, es
la línea L001 pero de la factura F001 o de la F002.



LÍNEA no dispone de información suficiente para construir un identificador
válido y necesita agregar el identificador de otra entidad con la que se
relacione, FACTURA en este caso.



En realidad, el identificador de cada línea es compuesto:

F001-L001,

F001-L002,

F002-L001...



Todas son líneas diferentes.

19

"Desde", "hasta", "importe" y "descuento" solo tienen sentido cuando
acompañan a una pareja CLIENTE-VEHÍCULO; solo pueden existir como
valores asociados a una relación entre un cliente y un vehículo.

20

Esta "agregación" es, en realidad, un caso particular del concepto
"agregación general" de todos los modelos de datos. Entiéndase que
agregar es tanto definir una entidad por sus atributos como construir una
relación que tiene en alguno de sus extremos otra relación que es,
esto último, a lo que realmente nos referimos en E-R cuando hablamos de
agregación.



21

Podemos agregar con las restricciones que nos apetezcan, dependerá del
sistema de información que queramos respresentar.

22

Es exactamente el mismo concepto visto en el tema "Modelos de datos".

23

24

Las restricciones de dominio son aquellas que definen que valores
podemos utilizar en cada atributo. En una base de datos implementada en
un SGBD relacional se convierte en el tipo de datos de cada columna
definida.



CASE = Computer Aided Software Engineering

25

26/02/2012

26