Vous êtes sur la page 1sur 27

MINISTERIO TESORERÍA GENERAL

DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

TEMA 1

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1- 1
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Tema 1
Modelo Entidad/Relación

1. Modelos de datos ..................................................................................................................... 2


2. Concepto de modelo de datos.................................................................................................. 4
3. Diseño de una base de datos ................................................................................................... 5
4. Modelo entidad/relación ........................................................................................................... 6
4.1 Estática del modelo E/R...................................................................................................... 6
4.1.1 Entidades ..................................................................................................................... 6
4.2 Relaciones....................................................................................................................... 8
4.3 Dominio ........................................................................................................................... 9
4.4 Atributos .......................................................................................................................... 9
5. Semántica de las relaciones en el modelo E/R ...................................................................... 10
5.1 Tipo de correspondencia................................................................................................... 11
5.2 Papel o rol ......................................................................................................................... 12
5.3 Cardinalidad de una entidad ............................................................................................. 12
5.4 Ejemplo de cardinalidades ............................................................................................ 13
6. Extensiones al modelo E/R..................................................................................................... 14
6.1 Dependencia en identificación .......................................................................................... 14
6.2 Jerarquía subconjunto....................................................................................................... 14
6.3 Generalización .................................................................................................................. 15
7. La fecha en el modelo de datos.............................................................................................. 16
7.2 Fecha en entidades........................................................................................................... 16
7.3 Fecha en relaciones ...................................................................................................... 17
8. Obtención del modelo relacional a partir del modelo E/R....................................................... 18
8.1 Reglas para la transformación del modelo E/R básico ..................................................... 18
8.2 Reglas para la transformación de las extensiones al modelo básico ............................... 22
Ejemplo práctico ......................................................................................................................... 23

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 1
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Tema 1
Modelo Entidad/Relación

1. Modelos de datos
Los modelos de datos son herramientas de abstracción que permiten representar la realidad
captando las restricciones semánticas que en ella se puedan dar.
En primer lugar, y antes de pasar a analizar el modelo de datos Entidad/Relación, vamos a
analizar lo que se entiende por modelo de datos en profundidad y analizaremos el papel que
los modelos de datos tienen en el diseño de bases de datos.
Cuando en el mundo real se da información de cualquier suceso u objeto siempre los datos
suministrados van acompañados de una semántica o de un significado. De la misma manera
estos datos están sujetos a unas restricciones y nosotros entendemos los datos suministrados
solo si entendemos el dominio y las restricciones de significados que acompañan a la
información. Sin embargo, cuando aparecen los ordenadores y las bases de datos se
empiezan a informatizar ocurre que se tiende a almacenar datos separando a estos de su
interpretación, esto es, de su semántica. Como consecuencia fue necesaria la aparición de los
modelos de datos como una herramienta que ayudara a incorporar significado a los datos
almacenados.
De esta manera, los modelos de datos proporcionan mecanismos de abstracción que permiten
la representación de la parte del mundo real que nos interesa registrar. Esta representación se
concibe en dos niveles: el de las estructuras que hacen posible al representación de la
información, y el de la información en sí misma.
Esto nos lleva a diferenciar entre lo que se denomina el esquema de la base de datos y la
colección de datos en sí misma que es lo que denominamos base de datos.
Asociados a los modelos de datos están los lenguajes de datos que son los que van a permitir
definir , consultar y actualizar la base de datos.
Tal y como es conocido, modelo de referencia de ANSI/Sparc define 3 niveles de abstracción:
Global
Externo e
Interno
A grandes rasgos el nivel interno es el más cercano al almacenamiento físico, está relacionado
con la forma de almacenar físicamente los datos.
El nivel externo es el más cercano al usuario, está relacionado con la forma de ver los datos
cada usuario de la base de datos, y por último, el nivel global es un nivel de indirección entre el
nivel interno y externo, ocultando los detalles de implementación y almacenamiento al usuario.
Este nivel contiene una representación del conjunto de los datos de la organización.
Si el nivel externo está relacionado con los usuarios de la base de datos, cada uno de los
cuales puede tener una visión diferente de la base de datos, el nivel conceptual tiene que ver
con una visión completa de la base de datos abstrayendo la implementación de la misma y
todos los aspectos relacionados con la máquina en la que está ejecutando el SGBD.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 2
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Usuario A1 Usuario A2 Usuario B1 Usuario B2 Usuario B3

Lenguaje máquina
+ DSL
Lenguaje máquina
+ DSL
Lenguaje máquina
+ DSL
Lenguaje máquina
+ DSL
Lenguaje máquina
+ DSL ...

Esquema
externo A Vista externa A
Esquema
externo B
Vista externa B ...
Mapping A Mapping B
conceptual/externo conceptual/externo

Esquema
Vista conceptual Sistema gestor
conceptual
de base de datos
(SGBD)
DBA

Mapping
conceptual/interno

Definición de la estructura
de almacenamiento Vista interna
(Esquema interno)

En la figura se muestra con más detalle la arquitectura ANSI/SPARC de tres niveles


Como consecuencia de esta arquitectura existen en una base de datos 3 clases de esquemas:
el esquema global,
los esquemas externos (uno por aplicación)
y el esquema interno que aunque en un momento determinado es único, un mismo
esquema global puede admitir distintos esquemas internos.
De entre todos estos tipos de modelos, los que a continuación se van a describir son los
modelos globales puesto que el modelo Entidad/Relación pertenece a este tipo de modelos.
Dentro de los modelos globales a su vez podemos hacer otra distinción entre los que se
denominan:
Modelos conceptuales: son los modelos que facilitan la descripción global del conjunto de
información al nivel más próximo al usuario.
El modelo E/R es un modelo conceptual
Los modelos convencionales que se encuentran soportados por los sistemas de gestión de
bases de datos por lo que también se les denomina modelos lógicos o modelos de bases de
datos. El modelo relacional es un modelo lógico.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 3
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

2. Concepto de modelo de datos


Aunque como se ha visto, existen muchos modelos de datos, se puede extraer una serie de
características de todos ellos y se puede dar la siguiente definición de modelo de datos [2]:
Un modelo de datos es un conjunto de conceptos, reglas y convenciones bien definidos que
permiten aplicar una serie de abstracciones a fin de describir y manipular los datos de un
cierto mundo real que se desean almacenar en la base de datos.
Los modelos de datos permiten crear categorías mediante la aplicación de los tipos de
abstracción, lo que lleva a diferenciar dos tipos de modelos, al estilo de los lenguajes de
programación:
Modelos de datos fuertemente tipados
Cada dato debe pertenecer a una categoría previamente definida en el esquema del
modelo.
Modelos de datos débilmente tipados
No es obligatorio que los datos pertenezcan a una categoría determinada, pudiendo
existir por si mismos. En este caso puede haber categorías, pero en caso de existir se
tratan como datos individuales.
En el mundo de bases de datos se utilizan modelos fuertemente tipados, también conocidos
como modelos estrictamente tipados, puesto que a pesar de sus inconvenientes (falta de
flexibilidad) tienen como ventaja que permiten el tratamiento de grandes volúmenes de datos al
agruparlos en categorías o tipos.
Un modelo de datos define las reglas mediante las cuales se han de estructurar los datos del
mundo real.
La representación de un mundo real mediante un determinado modelo da lugar a un esquema,
el cual describe las categorías existentes. Sin embargo, la realidad contempla además de los
aspectos estáticos, los aspectos dinámicos. Por tanto las propiedades del mundo real son de
dos tipos:
Estáticas
Relativamente invariantes en el tiempo, que es lo que se suele conocer como
estructuras. Este tipo de propiedades está compuesto por:
Elementos permitidos como:
los objetos (entidades, relaciones, registros, …),
asociaciones entre objetos,
propiedades o características de los objetos y asociaciones (atributos,
elementos de datos, …),
dominios, que son conjuntos de valores que pueden tomar las
propiedades.
Elementos no permitidos o restricciones, puesto que no todos los valores,
cambios de valor o estructuras están permitidos en el mundo real.
Además cada modelo tiene por sí mismo limitaciones en cuanto a las estructuras
que permite:
Las restricciones impuestas por el modelo se conocen como
restricciones inherentes,
y las restricciones que permiten captura la semántica del universo de
discurso que se quiere modelar y verificar la corrección de los datos

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 4
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

almacenados en la base de datos. Estas últimas restricciones se


conocen como restricciones de integridad o semánticas. Las restricciones
de integridad son impuestas por el usuario, mientras que las restricciones
inherentes al modelo son impuestas directamente por el modelo.
Dinámicas
Son las operaciones que se aplican a los datos o valores almacenados en las
estructuras, los cuales varían a lo largo del tiempo al aplicarles dichas operaciones. La
aplicación de cualquier operación sobre los valores de la base de datos debe dejar la
base de datos en un estado válido, es decir los valores de los elementos deben
pertenecer a alguna de las categorías definidas en el esquema y deben cumplir las
restricciones de integridad.
La componente estática de un modelo de datos se define a través del lenguaje de definición de
datos (DDL) y la componente estática se define a través del lenguaje de manipulación de datos
(DML), constituyendo ambas componentes el lenguaje de datos.

3. Diseño de una base de datos


Se conoce como diseño de una base de datos al conjunto de pasos que son necesario realizar
para pasar del mundo acerca del cual se quiere guardar información a la base de datos que lo
representa.
En este proceso son los modelos de datos los que juegan el papel más importante por
suministrar las herramientas de abstracción necesarias.
Los objetivos que se consiguen con los modelos de datos son:
Por una parte, permite formalizar las estructuras permitidas y las restricciones
Por otra parte, establece la metodología de diseño de bases de datos
Los pasos, por tanto, que se aconsejan en el diseño de toda base de datos son los siguientes:
1. Definición del universo de discurso o parcela del mundo real que se quiere
diseñar. De esta manera, por ejemplo, en un hospital se pueden definir distintos
universos de discurso, como puede ser el universo concerniente a ingresos
hospitalarios, otro diferente para la gestión del personal y podríamos distinguir
otro universo diferente para por ejemplo la gestión de recursos del hospital. De
esta manera podemos ver que el mundo real es solo uno pero hay que distinguir
en cada caso cual es la parte de ese mundo real que queremos conceptuar
2. Una vez definido el universo de discurso, se procede a la estructuración y dentro
de esta fase la primera parte es la definición del esquema conceptual de datos.
Mientras se realiza el modelado conceptual se intenta describir el mundo real de
acuerdo a un modelo conceptual que en nuestro caso será el modelo E/R. Se
tratará en esta fase de capturar toda la semántica del mundo real que sea
posible y hacer que el esquema resultante sea independiente del sistema de
gestión de bases de datos que se utilice con posterioridad para la
implementación de la base de datos.
3. Una vez realizado el esquema conceptual se pasará a su transformación a
modelo convencional o lógico. En la metodología de diseño que aquí
proponemos, el modelo lógico elegido es el modelo relacional por lo que se
analizarán las reglas de transformación de modelo E/R en modelo relacional.
4. Se terminará el diseño con el esquema interno y, por último, la implementación
de la base de datos física.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 5
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

4. Modelo entidad/relación
Los modelos de datos convencionales como el modelo relacional, no ofrecen la suficiente
capacidad de abstracción ni el poder expresivo para poder captar la semántica del mundo real.
Esto dificulta en gran medida la comunicación del diseñador con el usuario.
Como consecuencia, con posterioridad a la aparición del modelo relacional, surgen todas una
serie de modelos para tratar de paliar las carencias del primero.
De esta manera, en 1976 Chen propone el Modelo Entidad/Relación. Según el propio autor del
modelo, “el modelo E/R puede ser usado como una base para una vista unificada de los datos,
adoptando el enfoque más natural del mundo real que consiste en entidades y relaciones”.
El modelo E/R permite al diseñador concebir la base de datos a un nivel superior (conceptual)
de abstracción, aislándolo de consideraciones relativas a la máquina.
El modelo, como su nombre indica se apoya en dos conceptos, el concepto de entidad y el
concepto de relación. Este modelo de datos permite representar casi cualquier restricción del
diseño de datos.
El modelo E/R percibe el mundo real como una serie de objetos relacionados entre sí y
pretende representarlos gráficamente mediante un mecanismo de abstracción. Este
mecanismo de abstracción está basado en una serie de símbolos, reglas y métodos que
permitirán representar los datos de interés del mundo real.
Desde que el modelo de datos fue propuesto, se ha extendido por toda la comunidad de
diseñadores de bases de datos siendo el modelo mas utilizado en diseño de bases de datos y
el modelo mas extendido entre las herramientas CASE.
Tendremos que distinguir cuando analicemos el modelo las estructuras del modelo E/R básico
tal y como fue propuesto por Chen y todas las extensiones que desde su proposición se han
realizado para conseguir captar la mayor semántica del mundo real.
Tal y como veíamos en los apartados anteriores distinguiremos entre la estática del modelo y la
dinámica del mismo.

4.1 Estática del modelo E/R


Chen distingue en el modelo E/R los siguientes elementos:
Entidad
Relación
Atributo
Dominio

4.1.1 Entidades
Una entidad es un objeto real o abstracto de interés en una organización y acerca del cual se
puede y se quiere guardar determinada información en la base de datos.
Ejemplos de entidades pueden ser personas, cosas o lugares.
La estructura genérica que describe un conjunto de entidades aplicando la abstracción se
denomina tipo de entidad, mientras que entidad se refiere a cada una de las ocurrencias o
ejemplares de ese tipo de entidad. De esta manera, Hospital es un tipo de entidad mientras que
“Gregorio Marañón” es una ocurrencia o ejemplar.
Para poder distinguir o encontrar entidades en un problema de la vida real conviene resaltar las
propiedades que ha de cumplir la entidad:

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 6
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Debe tener existencia propia (veremos que hay un tipo de entidades que en puro rigor
no cumple esta restricción como son las entidades débiles)
Cada ocurrencia de un tipo de entidad tiene que poder distinguirse de los demás
Todas las ocurrencias de un mismo tipo de entidad deben tener las mismas
propiedades
Una entidad se representa gráficamente en el modelo E/R mediante un rectángulo y en el
interior del mismo se escribe el nombre de la entidad.

Nombre de la entidad

Figura 1: Representación gráfica de una entidad en el modelo E/R

Así pues, asociado al concepto de entidad surge el concepto de ocurrencia de entidad. Una
ocurrencia de entidad es una realización concreta de una entidad.
Cuando por el contexto se sobreentiende que nos estamos refiriendo a un tipo de entidad
hablaremos solo de entidad.
A continuación se representa la entidad hospital.

Hospital

Existen dos clases de entidades:


Regulares: son las que sus ejemplares tienen existencia por sí mismos
Débiles en las que la existencia de un ejemplar depende de que exista un cierto
ejemplar de otro tipo de entidad. Esto conlleva que la desaparición de las
ocurrencias de la entidad de la cual depende su existencia lleve a la desaparición de
las ocurrencias de la entidad débil que dependan de ellas. La entidades débiles se
representan gráficamente por dos rectángulos concéntricos y en el interior el
nombre de la entidad.

Nombre de la entidad

Figura 2: Representación gráfica de una entidad débil en el modelo E/R

Como ejemplo de entidad débil asumamos que estamos representado la información de un


videoclub y que tenemos que guardar la información de las películas que se alquilan. En este
caso claramente tendremos que distinguir entre lo que es la información de la película que
existe aunque no hay copias de esa película en el videoclub y lo que es la información de los
ejemplares de películas. Es obvio ahora comprobar cómo al menos tendremos que distinguir
entre dos entidades:
1. Entidad regular película
2. Entidad débil ejemplar de película

Película Ejemplar de pelicula

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 7
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

4.2 Relaciones
Una relación es una asociación entre entidades y se caracteriza por tener unas determinadas
restricciones que determinarán las entidades que pueden o no pueden participar de dicha
relación.
Nuevamente debemos distinguir entre lo que se denomina el tipo de relación que es la
estructura genérica que describe el conjunto de relaciones y lo que es la relación propiamente
dicha o cada una de las ocurrencias del tipo de relación. De esta manera trabaja es la relación
que hay entre un médico y un hospital mientras que una ocurrencia de este tipo de relación
será que Carlos Ruiz trabaja en el hospital Gregorio Marañón.
Gráficamente, en el modelo E/R la relación se representa por medio de un rombo y en el
interior del mismo se escribe el nombre de la relación, y unido mediante líneas a las entidades
correspondientes.

Médico trabaja Hospital

Figura 3: Ejemplo de relación binaria


Es importante resaltar que entre dos tipos de entidad puede haber más de un tipo de relación.
De esta manera, en una base de datos de cidudades y personas , asumiendo que tenemos una
entidad ciudad y una entidad persona, podemos establecer entre estas dos entidades una
relación para almacenar las personas empadronadas en una determinada ciudad, y otra
relación diferente para mantener el registro de las personas que han nacido en cada ciudad.
Las relaciones se caracterizan por dos propiedades:
Grado: es el número de entidades sobre las que se realiza la asociación. Es decir,
es el número de entidades que participan en la relación. En el caso de la relación
trabaja el grado de dicha relación es dos, puesto que participan dos entidades
(médico y hospital). Un caso especial de relaciones de grado dos o binarias es el
caso de las relaciones reflexivas, las cuales relaciona una entidad consigo misma.
Un ejemplo de este tipo de relaciones se puede ver en la Figura 4, donde se
observa la relación de dependencia (por ejemplo en una empresa) entre el personal.

persona

depende

Profesor

imparte Curso

Tema
_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 8
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Figura 4: Ejemplo de relación reflexiva

También pueden existir relaciones que asocien más de dos relaciones, por ejemplo de grado
tres, cuatro, … aunque no son habituales. Un ejemplo de relación de grado tres se puede
observar en la figura , en la que se establece una relación entre los profesores, los cursos y los
temas.
Cardinalidad o tipo de la relación: de esta manera se analiza en el apartado de
semántica de las relaciones el tipo de correspondencia que se tiene. De esta
manera, se pueden tener relaciones muchos a muchos o relaciones uno a muchos.

4.3 Dominio
Las distintas propiedades o características de un tipo de entidad o relación, toman valores para
cada ocurrencia de las mismas. El posible conjunto de valores que puede tomar cada
propiedad se denomina dominio. Con lo que se puede decir que el dominio es un conjunto de
valores homogéneos con un nombre.
Gráficamente se representan los dominios como un ovalo con el nombre del dominio en su
interior. Es importante resaltar en este punto que los dominios tienen existencia propia y es el
que realmente captura una semántica del mundo real. Lo que ha ocurrido muy a menudo es
que se tiende a confundir dominio con atributo.

4.4 Atributos
Cada una de las propiedades o características de un tipo de entidad o tipo de relación se
denomina atributo. Los atributos toman valor en un dominio por lo que un atributo es una
determinada interpretación de un dominio y varios atributos pueden tomar valores en el mismo
dominio. La representación gráfica de los atributos en el modelo E/R consiste en etiquetar con
el nombre del atributo la línea que una entidad con un dominio.
Lo que ocurre es que como decíamos con anterioridad a menudo atributo y dominio se
confunden y en cierto modo los culpables de esta no distinción son los sistemas de gestión de
bases de datos en lo cuales no queda clara la definición de los dominios y más se tiende a
hablar de tipos de datos de atributos que en realidad no captan la semántica subyacente al
dominio.
Debido a este motivo a menudo se representan en el modelo E/R solo los atributos y se hace
mediante la representación de un ovalo con el nombre del atributo en su interior (tal y como
habíamos especificando para los dominios) uniendo el ovalo al tipo de entidad o relación que
corresponda tal atributo tal y como se muestra en la figura.

Nombre del atributo

Nombre de la entidad

Figura 5: Representación gráfica de un atributo en el modelo E/R

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 9
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

En función de las características del atributo respecto de la entidad se distinguen dos tipos
de atributos:
Atributo identificador o clave: distingue de manera única una ocurrencia de entidad del
resto de ocurrencias de entidad. Normalmente, el atributo identificador es único, pero
puede haber caso en los que haya varios atributos identificadores, incluso se puede dar
el caso de que no exista un atributo identificador dentro de la entidad. Los atributos
identificadores se distinguen del resto en los diagramas E/R porque su nombre aparece
subrayado.
Atributo descriptor: caracteriza una ocurrencia de entidad pero no la distingue del resto
de ocurrencias de entidad.
Una relación puede tener atributos al igual que las entidades. Un ejemplo de atributos
en una relación se puede ver en la Figura 6, donde se representa que un cliente puede
comprar el mismo producto varias veces, pero se distinguirá cada compra del mismo
producto mediante la fecha en la cual se realiza la compra del mismo.

Cliente

compra precio

Producto

Figura 6: Ejemplo de atributos en las relaciones

5. Semántica de las relaciones en el modelo E/R


Decíamos que el interés de los modelos de datos es captar tanta semántica como sea posible
del mundo real. Con lo que hemos visto hasta el momento comprobamos que se permite
establecen cualquier número de relaciones diferentes entre tipos de entidad pero no podemos
establecer restricciones del tipo:
Un médico solo trabaja en un hospital
La base de datos solo almacenará información de individuos censados
En un hospital trabajan n médicos
Todos los socios del videoclub han alquilado al menos una película
....
A continuación se analiza en detalle todos los aspectos de las relaciones que nos permitirán
captar toda la semántica deseada.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 10
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

5.1 Tipo de correspondencia


Se denomina tipo de correspondencia al tipo de asociación que se establece entre las
entidades relacionadas. Concretamente, se puede definir el tipo de correspondencia como el
número máximo de ocurrencias de una entidad asociada a una ocurrencia de otra o de la
misma entidad a través de una relación.
Para una relación binaria, es decir, de grado dos, entre las entidades X e Y, existen tres tipos
posibles de correspondencias:
Correspondencia 1:1
Una ocurrencia de la entidad X se asocia como máximo con una ocurrencia de la
entidad Y y viceversa, como se puede observar en la

x1 y1

x2 y2
... ...

xn yn
Entidad X Entidad Y
Figura 7: Ejemplo de correspondencia 1:1

Un ejemplo de este tipo de correspondencia puede ser que un cliente tiene una
única cuenta bancaria en una sucursal determinada y una cuenta determinada
de una sucursal pertenece a un único cliente.
• Correspondencia 1:N
Una ocurrencia de la entidad X se asocia con un número indeterminado de
ocurrencias de la entidad Y, pero una ocurrencia de la entidad Y se asocia como
máximo con una ocurrencia de la entidad X. Si fuera al revés la correspondencia
sería N:1.

y1
x1
y2
x2
y3
...
...
xn
yn
Entidad X Entidad Y
Figura 8: Ejemplo de correspondencia 1:N

Un ejemplo de este tipo de correspondencia puede ser que una persona vive en
una ciudad y en una ciudad viven muchas personas-.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 11
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

• Correspondencia N:M
Una ocurrencia de la entidad X se asocia con un número indeterminado de
ocurrencias de la entidad Y y viceversa.
Un ejemplo de este tipo de cardinalidad puede ser que un proveedor suministra
varios productos y cada producto puede ser suministrado por varios
proveedores.

x1 y1

x2 y2
... ...

xn yn
Entidad X Entidad Y

padre
Persona

hijo

Figura 9: Ejemplo de correspondencia N:M

5.2 Papel o rol


Es la función que cada una de las entidades realiza en la relación. Gráficamente se representa
indicando el nombre del rol en la línea que une las entidades con las relaciones como se
muestra en la Figura. Los roles juegan un papel especialmente importante en relaciones
reflexivas donde es necesario conocer los dos roles que el mismo tipo de entidad juega en una
determinada relación.

5.3 Cardinalidad de una entidad


Se define como el número máximo y mínimo de ocurrencias de una entidad que pueden estar
relacionadas con ocurrencias de otra entidad. Se representa gráficamente mediante una
etiqueta del tipo (0, 1), (1, 1), (0, N) ó (N, M), según corresponda, al lado de las entidades
asociadas por la relación tal como se puede observar en la , donde el primer elemento de la
tupla es la cardinalidad mínima, y el segundo elemento de la tupla es la cardinalidad máxima,
que coincide con el tipo de correspondencia.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 12
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

La cardinalidad mínima permite establecer si todas las ocurrencias de una entidad participan o
no en la relación establecida con otra entidad.

(0, 1) (0, n)
Autor escribe Libro

1:N

Si toda ocurrencia de una entidad X debe estar asociada con al menos una ocurrencia de la
entidad Y con la que tiene establecida una relación, la cardinalidad mínima es 1, pero si no
tiene porque estar asociada con alguna ocurrencia de la entidad Y, la cardinalidad mínima es 0.
Las etiquetas de las cardinalidades, según la notación propuesta por Chen, están
intercambiadas, es decir la cardinalidad de una entidad aparece al lado de la otra entidad
participante en la relación.
Por ejemplo en la cardinalidad que aparece al lado de libro es la correspondiente a la entidad
autor y la que aparece al lado de la entidad autor es la correspondiente a la entidad libro. Así la
forma de leer la figura es la siguiente: un autor escribe o ninguno o muchos libros y un libro
puede se escrito por ningún autor (anónimo) o por un único autor.

5.4 Ejemplo de cardinalidades


En este apartado se va a detallar el diseño completo del diagrama E/R para un ejemplo muy
sencillo, como puede ser una base de datos para almacenar los productos que suministra un
determinado proveedor y en que cantidad y fecha los suministra.

Id_prov Id_prod

direccion
(1, N) (0, N)
Proveedor suministra Producto color

telefono N:M

cantidad fecha tamaño


nombre

Figura 10: Ejemplo completo de un diagrama E/R

En la Figura 10 se puede observar como hay dos entidades proveedor y producto con sus
atributos y claves correspondientes y una relación entre ambas suministra. El tipo de
correspondencia de la relación es N:M y la relación tiene dos atributos que son cantidad de
producto suministrado y fecha en la que se suministra el producto.
Recordar que la cardinalidad correspondiente a la entidad proveedor es la que aparece al lado
de la entidad producto (1, N), lo que quiere decir que todos los productos que aparezcan en la

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 13
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

tabla producto se relacionaran al menos con una ocurrencia de la entidad proveedor, y la


cardinalidad de la entidad producto es la que aparece al lado de la entidad proveedor (0, N), lo
que quiere decir que pueden existir ocurrencias de entidad de la entidad proveedor que no se
relacionen con ninguna ocurrencia de entidad de la entidad producto.

6. Extensiones al modelo E/R


Posteriormente a la aparición del modelo E/R se propusieron nuevas formas de notación
adicionales al modelo E/R para poder capturar más semántica en los diagramas E/R. Las
principales extensiones al modelo E/R fueron la dependencia en identificación, la jerarquía de
subconjunto y la generalización o jerarquía de generalización.

6.1 Dependencia en identificación


Surge este concepto porque hay veces que tenemos una entidad que no tiene el atributo
adecuado para ser identificador principal. Entonces se tiene una entidad débil. Estas entidades
únicamente tienen una atributo discriminador, que las diferencia del resto, y por tanto necesitan
una clave, que provendrá de una entidad regular, con clave primaria.
En este caso la clave principal se forma con la clave de la entidad fuerte más el atributo
discriminador de la entidad débil. La representación gráfica de la dependencia en identificación
se realiza mediante una línea en el rombo de la relación y una I para indicar que es en
identificación.
La entidad débil se representa mediante un rectángulo con doble línea, y el atributo
discriminador se marca de alguna manera, en este caso, mediante un asterisco.
En la figura se ve un ejemplo de dependencia en identificación, donde la entidad facturas no
tiene un identificador claro, únicamente tiene un atributo discriminador, que es el número de
factura. Está entidad depende de la entidad clientes, puesto que sino existe un cliente, tampoco
existirá una factura.

Id_cli n_fact *

(1, 1) (0, N)
nombre Clientes I tiene Facturas importe

1:N

direccion descuento

6.2 Jerarquía subconjunto


El concepto de especialización establece que una entidad X es un subconjunto de otra entidad
Y cuando toda ocurrencia de la primera es también una ocurrencia de la segunda, y lo contrario
no tiene porque ser cierto.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 14
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Por tanto, se tiene una jerarquía subconjunto cuando cada ocurrencia de una entidad genérica
pueda ser también una ocurrencia de otras entidades que potencialmente son subconjuntos no
disjuntos. Es decir, en las entidades subconjunto pueden aparecer ocurrencias repetidas.
Por ejemplo en la Figura 12 se aprecia una jerarquía subconjunto, donde la entidad genérica es
profesor y las entidad subconjunto son profesores, alumnos y personal docente, pudiendo
existir elementos repetidos en las entidades subconjunto, por ejemplo, puede haber personal
docente que sea alumno.
La entidad subconjunto puede tener atributos, además de tener los atributos de la entidad
genérica, pero siempre las entidades subconjunto se encuentran identificadas por la clave de la
entidad genérica. Además todos los atributos comunes de las entidades subconjunto deberían
aparecer en la entidad genérica para evitar repetir los atributos en cada una de las entidades
subconjunto.
La forma de representar gráficamente la jerarquía subconjunto se puede ver en la Figura 11, y
es un triangulo invertido, con la punta hacia las entidades subconjunto, y se conectan al
triangulo invertido todas las entidades subconjunto así como la entidad genérica.

Apellidos
Nombre DNI

Personas

Pesonal
Profesores Alumnos Puesto
docente

Año_mat

Figura 11: Ejemplo de jerarquía subconjunto

6.3 Generalización
El concepto de jerarquía de generalización o generalización establece que una entidad
genérica X es una generalización de otras entidades especializadas si cada ocurrencia de la
primera es una ocurrencia y solamente una de las otras entidades. A veces este concepto se
conoce también como jerarquía de especialización.
Se tendrá una jerarquía de generalización cuando la entidad genérica se divida en una serie de
entidades en función del valor que tome un determinado atributo de la entidad genérica. Como
en el caso de las jerarquías subconjunto, las entidades especializadas pueden atributos propios
además de los atributos de la entidad genérica.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 15
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

A diferencia con la jerarquía subconjunto, en la jerarquía generalización, en las entidades


especializadas no puede haber elementos repetidos.
La representación gráfica de la jerarquía de generalización se puede observar el la figura en la
que se representa al igual que la jerarquía subconjunto pero con un arco para indicar que las
entidades especializadas son disjuntas. Además unido al triangulo de la jerarquía, se indica el
atributo diferenciador de cada una de las entidades de la jerarquía.
En la siguiente figura se puede observar un ejemplo de este tipo de jerarquías de
generalización, donde se tiene la entidad genérica automóviles con sus atributos, más el
atributo diferenciador, que son comunes a todas las entidades especializadas motos, coches y
autobuses que tienen sus atributos propios, aunque pueden no tenerlos. En este caso no
puede haber ocurrencias de una entidad especializada que aparezcan como ocurrencias de
otra de las entidades especializadas como ocurría con las jerarquías subconjunto.

Marca
Modelo Matricula

Automoviles

tipo

cilindrada Motos Coches Autobuses Nº asientos

color

7. La fecha en el modelo de datos


El tratamiento de la fecha en las bases de datos es un tema complejo que requiere gran
atención si se quiere modelar bien.

7.2 Fecha en entidades


Almacenar fechas en las entidades generalmente no es un problema pues simplemente se
almacena esta como un atributo más de la entidad. El primer problema aparece cuando sea
necesario almacenar la evolución de una entidad a lo largo del tiempo. Si en esta evolución
simplemente se tienen ciertos estados por los que puede pasar cada ocurrencia de la entidad,
entonces bastará con añadir un atributo estado a la entidad.
Una situación mas compleja es la que requiere almacenar no sólo estos posibles estados sino
las fechas y posiblemente otras características asociadas al estado. En este último caso, la

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 16
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

solución más aconsejable pasa por modelar una nueva entidad estado que tenga como
atributos un identificador de estados así como tantos atributos como sea necesario almacenar
de cada estado.

7.3 Fecha en relaciones


Un caso diferente lo tenemos cuando lo que tenemos que almacenar es la fecha en la que
ocurre un hecho, cosa que generalmente estará modelizada en la relación. En este caso
tenemos que distinguir entre si será necesario almacenar un histórico o no.
En el caso en el que sólo se quiere guardar la fecha en la que un evento ocurre pero no se
quiere histórico. Es decir, tan sólo interesa el momento actual, entonces bastará con agregar
un atributo fecha a la relación. Si ocurre que es necesario almacenar la fecha de comienzo y la
de finalización del evento entonces se almacenarán dos atributos cada uno para reflejar la
respectiva situación.
Ahora bien, a menudo es necesario no solo almacenar el momento sino almacenar un histórico
del evento en cuestión. En esta situación hay que realizarse solo una pregunta. Si las
ocurrencias de las entidades que participan en la relación no pueden relacionarse en
momentos diferentes entonces un atributo fecha en la relación soluciona el problema. Sin
embargo, si ocurre que las mismas ocurrencias pueden relacionarse en momentos de tiempo
diferenciados y esto es necesario reflejarlo en la base de datos entonces téngase en cuenta
que la fecha es atributo que diferencia cada posible relación de estas entidades. Por ejemplo,
piénsese en la situación del préstamo bibliotecario en el que hubieramos modelizado las
entidades libro, bibliotecario y usuario y el préstamo como la relación entre ellos. En este caso
claramente el mismo bibliotecario puede prestar el mismo libro al mismo usuario en fechas
diferentes. De este modo si quisiéramos guardar el histórico del préstamo, con un atributo en la
relación no quedaría solventado pues cada vez que el mismo usuario sacase el mismo libro y
se lo prestara el mismo bibliotecario, estaríamos perdiendo la última vez que ese evento
ocurrió. En estos casos ocurre que sería necesario que la fecha fuera atributo identificador en
la relación con lo cual el problema estaría solventado y todas las ocurrencias se podrían
almacenar en la base de datos sin ningún problema.

usuario libro
bibliotecario

presta

fecha

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 17
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

8. Obtención del modelo relacional a partir del modelo E/R

8.1 Reglas para la transformación del modelo E/R básico


Una de las ventajas que ofrece el modelo relacional, es que a partir de un diseño conceptual
como es el modelo E/R se puede obtener un diseño relacional casi automáticamente, y a partir
de ahí su implementación en un sistema gestor de bases de datos es casi inmediato. El
obtener el modelo relacional a partir del modelo E/R se conoce como paso a tablas.
Las reglas para realizar el paso a tablas de un modelo E/R son las siguientes:
• Entidades:
Toda entidad que aparece en un modelo E/R genera una tabla cuyo nombre es el nombre
de la entidad, y tiene como atributos los atributos pertenecientes a la entidad a partir de la
cual se genera dicha tabla. Además, la clave de la entidad en el modelo E/R también es
clave en la tabla del modelo relacional.
Si se toma por ejemplo el modelo E/R que aparece en la Figura 10, se generaran dos tablas
correspondientes a las entidades proveedor y producto de la siguiente manera.

PROVEEDOR(Id_prov, dirección, telefono, nombre)


PRODUCTO(Id_prod, color, tamaño)

Las relaciones que aparecen en el diagrama E/R se convierten dependiendo del tipo de
correspondencia de la relación.
• Relaciones N:M
Siempre generan tabla. El nombre de la tabla es el nombre de la relación y los atributos son
los propios de la relación si es que los tiene más los atributos claves principales de las
entidades que participan en la relación. La clave principal de una tabla que provienen de
una relación N:M es la formada por concatenación de los atributos que son claves
principales de la entidades participantes en la relación. Como ejemplo se va a ver el paso a
tablas de la relación que analizábamos en el ejemplo entre proveedores y productos.
Además como consecuencia de la transformación de relaciones n:m surge una duplicidad
en el modelo que es la provocada por la propagación de las claves de las entidades
participantes en la relación. Como consecuencia y para evitar inconsistencias se generan
tantas claves ajenas como entidades participen en la relación. De esta manera, si la
relación es binaria, esto es dos entidades participantes, entonces nos encontraremos con 2
claves ajenas la primera hará referencia a la clave primaria de la primera entidad
participante y la segunda hará referencia a la segunda entidad participante. De la misma
manera se establecería si en lugar de binaria la relación fuera ternaria. En el caso que nos
ocupábamos de la figura 10, se genera la tabla:

SUMINISTRA(Id_prov, Id_prod, cantidad, fecha)

Además en este caso, como puede observarse, la clave primaria es Id_prov, Id_prod y a su
vez tenemos dos restricciones de clave ajena: por un lado Id_prod es clave ajena que hace
referencia a la clave primaria de la entidad Producto y por otra parte la clave ajena Id_prov
que hace referencia a la calve primaria de la tabla de Proveedores.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 18
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Téngase en cuenta además que habría que establecer la política de borrados y de


modificaciones caso que se modificaran o borraran las claves primarias a las que
referencian.

Esta política se establecería de acuerdo a la semántica del problema en cada caso pero es
importante tener en cuenta que en el caso de relaciones n:m la única política que no se
podrá establecer es la de “Puesta a nulos “ puesto que esto supondría una violación de la
restricción de entidad puesto que si cualquier componente de la clave primaria se queda a
NULL esto hace nula a la clave primaria. Tal y como acabamos de establecer el elegir la
política de borrados (actualizaciones ) en cascada o restringidos dependerá de la
semántica de la aplicación.

Por otra parte, es necesario hablar en este punto también de cómo se plasman en el
modelo relacional las cardinalidades mínimas puesto que estas llevan asociadas cierta
semántica del mundo real. En este caso sin embargo, no hay una manera directa de
plasmar estas restricciones en el modelo relacional. Ya decíamos al principio que los
modelos de datos tratan de capturar el máximo de semántica pero no siempre lo consiguen.

En cuanto a las cardinalidades mínimas entonces nos ocurre que en el modelo relacional
no se pueden plasmar con lo uqe tales restricciones si las hubiera se dejarán
documentadas y luego se buscará la mejor manera de implementarlas dependiendo del
gestor que se utilice. Es muy importante recordar que las restricciones se deberán dejar
documentadas y siempre tratar de implementarlas puesto que ellas van cargadas de
semántica, semántica que caso de no implementarlas se perdería con el consiguiente
pérdida de información e incluso de consistencia que ello podría provocar
• Relaciones 1:N

Este podría pensarse que es un caso particular de una relación n:m. No obstante, ocurre
que en este caso es importante recordar que hay una entidad cuyas ocurrencias o no
participan o si lo hacen lo hacen solo una vez. Como consecuencia, podemos tomar partido
de esta propiedad para no tener que generar la tabla de la relación. De esta manera, en
este caso no se genera una tabla en el modelo relacional, lo que se hace es que la clave
principal de la entidad que participa con cardinalidad máxima N se pasa como atributo a la
tabla de la entidad cuya cardinalidad máxima es 1.

Como ejemplo se va a tomar el diagrama E/R que en la que se tenía que un autor escribe
muchos libros pero un libro es escrito en este caso por un único autor. En este caso
entonces téngase en cuenta que por cada tupla de autor no se podrían almacenar los libros
que ha escrito puesto que son muchos. Sin embargo, ocurre que en el problema que
estamos modelizando un libro es escrito por un único autor como consecuencia en la tupla
correspondiente a cada libro es posible almacenar la información del código del autor del
libro manteniendo en todo caso la información del autor en la tabla de autores.

A este mecanismo de poner la clave de una entidad en la otra entidad se lo denomina


propagación de clave extranjera.

Es importante además resaltar que el atributo que se propaga no pasa a formar parte de la
clave de la entidad es solamente un atributo más de la tabla que tendrá asociada una
restricción de calve ajena puesto que tal y como hemos visto, este atributo proviene de otra
entidad con lo que habrá que mantener la consistencia de la duplicidad que se acaba de
generar.

En el ejemplo entonces del libro y los autores se tendría el siguiente paso a tablas:

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 19
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

AUTOR(nombre, …)
LIBRO(titulo, n_paginas, …, nombre)

Como se puede ver en la la entidad que participa con N en la relación es autor, y la que
participa con 1 es libro. En este caso se añade en la tabla libro el atributo que es
identificador principal de la tabla autor y este atributo es una clave ajena.

En cuanto a las políticas de borrado y modificación se establecerán en este caso


nuevamente de acuerdo a la semántica del problema teniendo en cuenta que en principio
en este caso no hay restricción sobre el tipo de política que se puede establecer (cascadas,
set null o restringida).

En cuanto a las restricciones por cardinalidades mínimas, en este caso si se tiene que la
entidad que participa con cardinalidad máxima 1 lo hace también con cardinalidad mínima 1
entonces adicionalmente a la propagación de clave ajena habrá que establecer que el
atributo propagado no puede tomar valores Nulos en la tabla en la que está como clave
ajena.

Supongamos por claridad de nuevo el ejemplo del libro y el autor y supongase que se
tuviera que un libro lo escribe uno y solo un autor esto es, que la cardinalidad de libro en la
relación es (1,1) en este caso lo que se está diciendo es que no puede haber libros en la
base de datos de los que no se conozca su autor, como consecuencia cuando el código
del autor (en este caso el nombre) se propague a la tabla de libro entonces habrá que
obligar a la entrada de datos es en este campo o lo que es lo mismop habrá que imponerle
la restricción de NOT NULL. En el caso en que la restricción del 1 mínimo estuviera en la
entidad que participa con la n máxima (en este caso el autor), entonces no hay manera de
establecerlo ni en el paso a tablas ni con una restricción de not null. En este caso y como
ocurriera con las relaciones n:m habrá que dejarlo establecido en la documentación para
que dependiendo del gestor en el que finalmente se implemente se realice la restricción de
una u otra manera.
• Relaciones 1:1

Es el mismo caso que las relaciones 1:N pero no está definido a qué entidad se le atribuye
el atributo identificador de la otra. Se suele hacer por sentido común y haciendo un estudio
de la eficiencia. No obstante dependiendo del caso aunque el sentido común nos lo
establece vamos a estudiar aquí cual es la mejor transformación. Es muy importante en
este caso recordar que independientemente de cual sea la propagación siempre el atributo
que se propaga ha de establecerse que tiene restricción de ser UNIQUE en la tabla a la que
se ha propagado pues es la única manera de establecer la restricción de uno máximo por
ambos lados. Analizamos en detalle los casos que se pueden dar.

Caso1.
Supóngase el caso de la siguiente figura:

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 20
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

(0,1) (0,1)
A B
R

a
b

En este caso como se tiene que las dos cardinalidades mínimas son 0 ocurre que se
podría propagar la clave de a a la entidad de B o al revés indistintamente. En este
caso solo dependería de motivos de eficiencia. De esta manera si muchos de los
accesos a la base de datos que piden datos de A también requieren información de
la clave de B entonces podríamos plantearnos el propagar la clave de B a A con lo
que estaríamos evitando hacer joins en estos tipos de consultas.
De esta manera las dos posibilidades de transformación en este caso son:
A(a, …b)
B(b, …)
Recuérdese que además se ha de establecer que b ha de ser UNIQUE en A puesto
que B solo se puede relacionar con un A y de no establecer la restricción de
UNIQUE se podría estar permitiendo que la misma ocurrencia de b ocurriera mas de
una vez con diferentes A.
ó:

A(a, …)
B(b, …a)
Estableciendo ahora en este caso que a ha de ser UNIQUE en B

Caso 2:

(1,1) (0,1)
A B
R

a
b

En el caso en el que tengamos un uno mínimo y solo uno entonces para no perder
la restricción del 1 mínimo la mejor propagación es la que respeta este uno mínimo.
En el caso de la figura ocurre que B se relaciona con uno y solo un A como
consecuencia la mejor propagación será:
A(a, …)
B(b, …,a)

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 21
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

En la que al atributo a en la tabla de B se le establecerá la restricción de que ha de


ser UNIQUE (valores no repetidos) puesto que A solo se puede relacionar con un B
y además se establecerá que ha de ser NOT NULL puesto que B además de
relacionarse con como máximo 1 A lo hace obligatoriamente con un A lo que
establece que a no puede ser vació en B.

Caso 3:
En este caso ocurre que al tener unos mínimos por ambos lados, hay un 1 mínimo
que se va a perder y que la única manera que tendremos de conservarlo será
documentarlo para que dependiendo del gestor se implemente de la mejor manera.
Como comentábamos en este caso podemos propagar indistintamente para un lado
o para el otro y será nuevamente como en el caso 1 la eficiencia de la aplicación la
que nos marcará la mejor propagación. De esta manera las dos posibilidades
serían:

(1,1) (1,1)
A B
R

a
b

A(a, …)
B(b, …,a)

El atributo a en la tabla de B se le establecerá la restricción de que ha de ser


UNIQUE (valores no repetidos) puesto que A solo se puede relacionar con un B y
además se establecerá que ha de ser NOT NULL puesto que B además de
relacionarse con como máximo 1 A lo hace obligatoriamente con un A lo que
establece que a no puede ser vació en B. Además en este caso hay que
documentar que es necesario añadir una restricción que obligue a que todo A
además ha de estar relacionado con algún B, esto es, que no puede haber
ocurrencias en la base de datos de A que no estén relacionadas con ningún B
La otra posibilidad sería propagando b a A y estableciendo la restricción de NOT
NULL y UNIQUE en este caso para el atributo a que se acaba de propagar y
además añadiendo la restricción de que todo B se ha de relacionar con algún B.

8.2 Reglas para la transformación de las extensiones al modelo básico


Dependencia en identificación
Toda dependencia en identificación es una relación 1:n y como tal podemos aplicar los
criterios que hemos venido aplicando en el epígrafe anterior. No obstante en este tipo
de dependencias tenemos una peculiaridad y es que la entidad débil necesita de la
clave de la entidad regular de la cual depende para poder identificar a sus ocurrencias.
Como consecuencia lo que va a ocurrir es que vamos a propagar la clave como si de
una relación 1: normal se tratara pero además vamos a hacer que la clave de la entidad
débil (a la cual se le está propagando el atributo), sea su atributo identificador
concatenado con la clave ajena que se acaba de propagar. Resumiendo, el paso a

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 22
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

tablas de una dependencia en identificación se realiza añadiendo como atributo de la


entidad débil, la clave de la entidad fuerte, y este atributo formará junto con el atributo
discriminador de la entidad débil, la clave principal de la entidad débil. Si se toma como
ejemplo el diagrama E/R de la figura del ejemplo entre clientes y facturas el paso a
tablas queda:

CLIENTES(Id_cli, nombre, dirección)


FACTURAS(Id_cli, n_fact, importe, descuento)
Además hay que recordar que se genera la restricción de clave ajena que habrá que definir.
Nótese que en este caso no es necesario imponer la restricción de NOT NULL puesto que
el atributo forma parte de la clave lo que hace que nunca vaya a poder ser nulo.
Jerarquías

El paso a tablas de las jerarquías se realiza construyendo una tabla por la entidad
genérica y una tabla por cada entidad hija de la jerarquía. La entidad genérica tiene
como atributos los suyos propios con su calve principal, y si es una jerarquía de
especialización además lleva también como atributo el atributo diferenciador. Las
entidades hijas tienen como atributos los propios y además llevan como la clave de la
entidad genérica, siendo clave principal también en las entidades hijas. Si se toma
como ejemplo el diagrama E/R que aparece en la que se veía con anterioridad, las
tablas que se generan son las siguientes:
AUTOMÓVILES(matricula, marca, modelo, tipo)
MOTOS(matricula, cilindrada)
COCHES(matricula, color)
AUTOBUSES(matricula, nºasientos)

Se puede observar como la clave primaria de la entidad genérica, que en este caso es
automóviles, aparece como atributo en cada una de las entidades hijas, y además forma
su clave principal. Esta clave además es clave ajena en las tablas hijas de la jerarquía.
Si en lugar de una jerarquía de especialización, hubiera sido una jerarquía subconjunto,
la diferencia hubiera sido que en la entidad genérica no aparecería el atributo
discriminador, en este caso el atributo tipo.

Ejemplo práctico
A continuación se presenta un ejemplo práctico que permite ilustrar los conceptos
fundamentales que se han analizado en el presente tema.
Supóngase que se quiere modelar la base de datos de soporte a las transacciones realizadas
en comercio que dispone de página web. Tan sólo estaremos interesados en realizar el diseño
de la base de datos de soporte a las operaciones realizadas a través de dicha página web.
Para el comercio es interesante no sólo almacenar la información de compradores sino la de
los navegantes.
Toda persona que quiere entrar en la página web ha de registrase la primera vez que entra
suministrándole un login y una clave de acceso que podrá ser utilizada en futuros accesos al
sitio web.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 23
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Los navegantes se convierten en clientes del comercio la primera vez que realizan una compra
y en ese momento se le solicitará al navegante al menos su nombre completo, dirección,
teléfono de contacto y fecha de nacimiento.
Los clientes al realizar una compra han de suministrar la tarjeta de crédito contra la que se
realiza el pago de la compra.
Un cliente puede tener dada de alta mas de una tarjeta de crédito pero para cada compra sólo
se especifica una tarjeta.
De todas las tarjetas es necesario conocer además del titular, el número de la tarjeta y la
fechas de caducidad de la misma.
De las compras además es necesario almacenar la fecha de la compra el importe total de la
compra y lo s productos que incluya la compra. De todos los productos se almacena en la base
de datos su código, nombre, descripción, marca y el precio.
Para finalizar la base de datos almacenará información relativa a los accesos de los
navegantes. De esta manera, cada vez que un navegante entre en la página web se
almacenará la fecha de tal acceso y la duración total de la visita.
Se pretende realizar el diagrama entidad/relación que mejor modele las características de la
base de datos que se acaba de exponer y el paso a modelo relacional

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 24
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

El diagrama entidad relación en el ejemplo propuesto es el siguiente:

Navegante
Clientes
(0,1 (1,1 Login (1,1 hac
Código E
Password e
Nombre
Apellidos (0,n
(1,1
ó Hace c Accesos
(1,1 Id acceso
(0,n
Tiene Fecha
Compra duración
(0,n Id_compra
(1,1 (0,n)
Tarjeta asoc Fecha
Número
Fecha de (0,n
caducidad

involucra

(0,n)

Productos
Id_producto
Nombre
Descripción
Precio

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 25
MINISTERIO TESORERÍA GENERAL
DE LA SEGURIDAD SOCIAL
DE TRABAJO
Gerencia de Informática
Y ASUNTOS SOCIALES Subdirección General de
Informática

Recordando brevemente las reglas del paso a tablas del modelo básico tenemos:
Toda entidad genera una tabla.
Toda relación n:m genera una tabla
Las relaciones 1:n se transforman por el mecanismo de propagación de clave
extranjera.
Como consecuencia se tiene:

Navegante(login, passwd)
Acceso(id_acceso, fecha_comienzo, fecha_fin, navegante)

En este caso navegante es una clave extranjera que referencia a la clave de la tabla de
navegantes

Productos(código, descripción, nombre, precio )


Cliente (código, nombre, apellidos, dirección, navegante )

Navegante es una clave ajena que referencia a la clave de la tabla de navegantes

Compras(Id_compra, id_tarjeta, id_cliente, cuantía)


Id_ tarjeta es clave ajena que referencia a la lave de la tabla de tarjetas. ID_cliente es clave
ajena que referencia a la clave de la tabla de cliente

Involucra(Id_compra, Id_producto)
Id_compra es clave ajena que referencia a la clave de la tabla de compras e Id_producto es
clave ajena que hace referencia a la clave de la tabla de productos .

Bibliografía

“Una introducción a los sistemas de base de datos”. Date C. J. .Addison Wesley 2000.
“Diseño de bases de datos relacionales” Adoración de Miguel, Mario Piattini, Esperanza
Marcos. Editorial RA-MA, 1999
“Un primer curso es sistemas de bases de datos”. Jeffrey D. Ullman, Jennifer Widom.
Editorial Prentice Hall, 2000
“Implementación de los sistemas de base de datos”. Hector Garcia-Molina, Jeffrey Ullman,
Jennifer Widom. Editorial Prentice Hall, 2000
“Procesamiento de bases de datos. Fundamentos, diseño e instrumentación”. David M.
Kroenke. Editorial Prentice Hall
“Diseño e implementación de bases de datos”. Gary W. Hansen. James V. Hansen.
Segunda edición. 1997. Editorial Prentice Hall.

_________________________________________________________________________________________________________
Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 26