Вы находитесь на странице: 1из 24

Gestin de Base de Datos 1

CAPITULO I. MODELO ENTIDAD RELACION

1. RESUMEN DEL MODELO ENTIDAD RELACION

Se basa en las entidades y en las relaciones que se establezcan entre estas entidades y pone nfasis en el
tipo de las relaciones y la cardinalidad que hay entre los elementos.

1.1. Esttica del Modelo E/R

Entidad. Persona, lugar, cosa, concepto o suceso real o


abstracto de inters en la empresa. Tiene existencia
propia. Cada ocurrencia de entidad debe poder
distinguirse de las dems. Ocurrencias de un tipo de
entidad tienen los mismos tipos de atributos. Se tiene dos
tipos de entidad: Figura 1.1. Entidades Regulares y Dbiles
- Entidad Regular: Existencia por si misma.
- Entidad Dbil. Existencia depende de otro tipo de entidad

Relaciones. Correspondencia entre entidades, representan asociaciones del mundo real. Las
interrelaciones se caracterizan por su nombre, el grado (numero de entidades que participan en la
interrelacin), el tipo de correspondencia (Numero mximo de ejemplares de una entidad asociados a
una combinacin de ejemplares de las otras entidades en la interrelacin, que puede ser 1 o N). dentro
de los elementos de una relacin se tiene:

- Nombre. nico que lo distingue uninovamente


- Grado. Numero de entidades que participa en una relacin
- Conexin. Arco que une la entidades
- Cardinalidad. Numero mximo de ocurrencias de cada tipo de entidad.
Relaciones (1:1) uno a uno
Relaciones (1:n) uno a muchos
Relaciones (n:1) muchos a uno
Relaciones (n:m) muchos a muchos
- Participacin. Total o Parcial segn participen algunas o todas las ocurrencias de las entidades
(60:5)
Lleva (es llevado por)
Alumno Lleva Curso
(10:60) (1:5)
Figura 1.2. La relacin Lleva (Alumno,Curso) con sus elementos

Alumno Presenta Proyecto

Lenguaje

Figura 1.3. Relacin Desarrolla (Alumno, Proyecto, Lenguaje) ternaria: o de grado 3

Se definen cardinalidades mximas y mnimas de las entidades que participan en una interrelacin
como el nmero mximo y mnimo de ejemplares de una entidad que puede relacionarse con un nico
ejemplar de la otra, u otras entidades que participan en la interrelacin.
(1:n)
(0,1) (1:n)
Proyecto Presenta Empleado

Figura 1.4. Relacin entre dos entidades.

- 1:n en Empleado indica que un ejemplar de la entidad proyecto esta relacionado con 1 o mas
ejemplares de la entidad empleado en la interrelacin Participar.
Henry George Maquera Quispe
Gestin de Base de Datos 2

- 0:1 en Proyecto indica


que un ejemplar de la Aula
entidad empleado esta
relacionado con 0 o 1 (1:1)
ejemplar de la entidad
Proyecto en la
interrelacin Participar. (n:1) Se_dicta en

- 1:n en Participar
indica que un (n:m) (1:n)
Empleado participa (1:1) (10:60) (1:5)
como mximo en un Alumno Lleva Curso
Proyecto y en un
Proyecto participan (1:5) (n:m) (1:3)
como mximo n
Empleados
(1:n)
Desarrolla Dicta
(1:2)
(1:1) (1:1)
(0:1)
Dirige Proyecto Profesor

Figura 1.5. DER con sus respectivas cardinalidades.


1.2. Atributos

Un tipo de entidad o relacin queda definido por sus caractersticas. Cada una de las caractersticas de un
tipo de entidad o relacin se llama atributo. Un atributo detalla a las entidades asignndoles propiedades
descriptivas tales como nombre, color y pero. Existen dos tipos de atributos:

- Identificadores. Distinguen de manera


Denominacio
nica cada una de las ocurrencias de una Serie
entidad (distinguindose entre CURSO n
Identificadores Principales e Ciclo Horas
Identificadores Alternativos).
- Descriptores. Se utiliza para describir una Creditos
ocurrencia de una entidad. Figura 1.6. La entidad Curso con sus atributos

Se debe tener presente que las relaciones entre dos entidades tambin pueden albergar componentes
propios. Se debe considerar que una relacin puede ser simple sino tiene componentes o compuesto si los
tiene.
Fecha_inicio Turno
Profesor

(es llevado
Lleva
por)
Alumno Lleva Curso
(10:60)
(1:5)
(60:5)
Figura 1.7. La relacin Lleva(Alumno, Curso) con atributos

Otra forma de representar los atributos en a travs de Curso


una pila de caracteres:
Serie
Denominacion
Ciclo
Horas
Creditos
Figura 1.8. La relacin Curso con sus atributos
Henry George Maquera Quispe
Gestin de Base de Datos 3

1.3. Dominio y Valores

Las caractersticas de un tipo de entidad o una relacin toman valores para cada ocurrencia de estas. El
conjunto de todos los posibles valores de una caracterstica se llama dominio. Por ejemplo: Valor
FACULTAD se toma del dominio: Especialidad {ESIS, ESIQ, ESFI, ESBM}

Tipo de Entidad (Ei) Atributos (Ai) Dominios (Di)

Series
XX-999 Series

Denominaciones
Cadena Denominaciones

Ciclo
Curso XXXX Ciclo

Horas
9 Horas

Creditos
9 Creditos

Figura 1.9. Atributos y Dominios de la entidad Curso

Tipo de Relacion(Ri) Atributos (Ai) Dominios (Di)

Fecha_inicio
99 Dias

Mese
99
s

Lleva 99 Aos

Turno
{"M","T","N"} Turnos

Profesor Profesore
Cadena
s
Figura 1.10. Atributos y dominios de la relacin Lleva (Alumno, curso)

1.4. Cardinalidad de Atributos

- Card_min(A,E). Mnimo numero de valores de atributos asociados a una entidad o relacin.


- Card_max(A,E). mximo numero de valores de atributos asociados a una entidad o relacin.

- Si Card_min(A,E)= 0. Atributo es opcional y puede ser especificado o no para algunas ocurrencias.


- Si Card_min(A,E)= 1. Atributo es obligatorio y al menos un valor del atributo debe especificarse
para todas las ocurrencias de la entidad.
- Si Card_max(A,E)= 1. Atributo es monovalente
- Si Card_max(A,E)> 1. Atributo es polivalente

1.5. Claves

Clave Primaria. Identifica unvocamente una entidad o relacin.

Clave Candidata. Identifica alternativamente en una entidad o relacin, pero no necesariamente en


forma univoca.

Por ejemplo sea la entidad Alumno(Cdigo_alumno, Apellido, Nombre, Sexo, Fecha_nacimiento,


Especialidad, Foto, Direccin, Telfono).
Henry George Maquera Quispe
Gestin de Base de Datos 4

- SK = [Cdigo_alumno, Apellido, Nombre, Sexo] es una superclave para la entidad Alumno.


Cualquier superconjunto de SK lo es tambin.

- [Cdigo_alumno] es suficiente para identificar unvocamente a Alumno.

- [Apellido, Nombre) tambin es suficiente para identificar unvocamente a Alumno.

- En consecuencia [Cdigo_alumno] y [Apellido, Nombre] son claves candidatas para la entidad


Alumno.

- Observar que [Apellido, Nombre] es minimal porque ni el atributo Apellido, ni en atributo Nombre
por si solos son suficientes para identificar unvocamente ala entidad Alumno.

Una clave simple tiene un solo atributo, una clave compuesta tiene ms de un atributo. Mientras que
una entidad fuerte tiene clave primaria y una entidad dbil no tiene clave primaria.

Clave Fornea es una clave primaria de una entidad E2 y que esta presente en E1. Por ejemplo:
Alumno (Cdigo_alumno, Apellido, Nombre, Sexo, Fecha_nacimiento, Especialidad, Foto, Direccin,
Telfono) y Especialidad (Especialidad, descripcin). => Especialidad es clave fornea para Alumno.

Asimismo se puede Clave For nea


considerar que entre las Proyecto
entidades Proyecto y N mero Responsable Fecha Inicio ...
Alumno la clave fornea es
Responsable (Entidad 96-015 94- 2568 01/01/01 ...
Proyecto) que sirve para 96-025 93- 1212 01/12/02 ...
enlazar y mantener una
comunicacin entre ambas Clave Primaria
entidades. Alumno
Matr cula Apellidos Nombres Especialidad ...
94- 2568 Rejas Perez Jaime Matemticas ...
... ... ... ... ...
Figura 1.11. Clave Fornea entre Proyecto y Alumno.

Representacin grafica. Tambin se tiene presente que las claves se pueden representar con los
siguientes grficos.
Atributo
Clave primaria PK
Clave Candidata Clave Compuesta Atributo Compuesto
CK
Clave Foranea FK
Figura 1.12. Notacin de atributos y claves

Apellido Nombre Alumno


PK Codigo_alumno
Codigo_alumno Sexo Fecha_nacimiento
Apellido
Nombre
Sexo
Alumno Fecha_nacimiento
FK Especialidad
Foto
Especialidad Foto Direccion Telefono Direccion
Figura 1.13. Entidad Alumno, sus atributos y claves Telefono
Figura 1.14. Representacin alternativa de una
entidad, sus atributos y sus claves

Henry George Maquera Quispe


Gestin de Base de Datos 5

2. MODELO ENTIDAD RELACION EXTENDIDO

El modelo entidad relacin extendido (EER) abarca todos los conceptos de modelado del modelo ER,
asimismo incluye conceptos de subclase y superclase, los conceptos relacionados de especializacin y
generalizacin. Otro concepto que tiene el modelo EER es el de categora, que se usa para representar
una coleccin de objetos que es la unin de objetos de diferentes tipos de entidad. Asociado a esto esta el
importante mecanismo de herencia de atributos y relaciones. Desafortunadamente ni existe una
terminologa estndar para estos conceptos, de modo que se utilizara los trminos de uso mas frecuente.

2.1. Superclases, Subclases y Herencia.

Existen entidades que posees sub agrupaciones. Por ejemplo, el tipo de entidad Empleado describe el tipo
(atributos y relaciones) de las entidades: Secretaria, Ingeniero, Gerente, Tcnico, Empleado_asalariado,
Empleado_por_horas, etc. El conjunto de entidades de cada una de estas agrupaciones es un subconjunto
de las entidades que pertenecen al tipo Empleado, lo que significa que toda entidad que sea miembro de
una de estas sub agrupaciones tambin ser empleado.

2.2. Dependencias en Existencia e Identificacin

Las entidades pueden ser regulares y dbiles. Las Profesor


relaciones pueden regulares y dependientes. Se
distingue: (1:1)
E
(1:n)
Dependencia en Existencia. Por lo que una Tiene a cargo
entidad dbil puede ser identificada sin
necesidad de identificar la entidad regular por
la cual existe. tambin se entiende como (0:n)
cuando las ocurrencias de un tipo de entidad
Familiar
no puede existir si desaparece la ocurrencia
del la entidad regular de la cual depende. Figura 2.1. Datos de familiares solo tienen sentido si
este es una ocurrencia de la entidad profesor.

Dependencia en Identificacin. Por lo que una


entidad dbil no puede ser identificada Libro
(reconocida y diferenciada del resto de las
entidades del mismo u otro tipo) a no ser que se (1:1)
identifique una entidad regular por cuya Cod_libro
existencia esta presente la debilidad. Tambin (1:n)
se entiende que sii ocurre la dependencia en Tiene
existencia y adems las ocurrencias del tipo de
entidad dependiente no se puede identificar (1:n)
unvocamente mediante sus propios atributos y
necesitan aadir una clave de la entidad regular Ejemplar
de la cual dependen
Figura 2.2. Un libro esta identificado con la clave
libro respectivo mas una clave propia.

La dependencia de identificacin implica una dependencia de existencia, pero no al contrario. Un tipo de


entidad dbil por existencia no necesariamente requiere para su identificacin del tipo de entidad fuerte
por la cual tiene existe.

2.3. Tipos de Interrelaciones

El modelo E-R permite la representacin de cualquier tipo de relacin existente entre los objetos del mundo
real que forman parte del dominio del problema en estudio. Las ltimas actualizaciones del modelo ER, que
han dado lugar a los que se conoce como el Modelo Entidad-interrelacin Extendido (EER), permiten la
representacin de cualquier tipo de relaciones existentes entre clases de objetos que consideran los
principios de la abstraccin.

Interrelaciones Reflexivas. Las interrelaciones reflexivas son relaciones unarias, que consideran que
el tipo de interrelacin se ve involucrado un nico tipo de entidad. Por ejemplo considere el tipo de
interrelacin presentado por la figura 2.3, que describe la relacin existente entre el tipo de entidad
Henry George Maquera Quispe
Gestin de Base de Datos 6

Alumno con ella misma, y que representa que un alumno dirige a 0 o varios alumnos, mientras que un
Alumno es dirigido por 0 (el jefe de grupo) o 1 Alumno.

Se trata de un tipo de interrelacin reflexiva en la


(0,n) dirige_a
que interviene un nico tipo de entidad que Alumno
desempea dos papeles diferentes en el mismo
tipo de interrelacin. No todos los modelos de 1:n
datos permiten representar este tipo de
interrelaciones, tal y como se presentan en el Dirige
(0,1) es_dirigido_por
mundo real.
Figura 2.3. La relacin reflexiva Dirige (Alumno)

Interrelaciones Exclusivas. En un problema del mundo real, un tipo de entidad puede mantener
relaciones con un conjunto de otros tipos de entidad, pero no siempre estas relaciones son
independientes. Por ejemplo si se tiene tres entidades Articulo, Proveedor y Fabricante, y el problema
en el que los artculos son suministrados por los proveedores o por los fabricantes, pero un articulo
nunca puede ser suministrador por un proveedor que no fabrica el articulo, de forma que si el fabricante
puede suministrarlo, en ningn momento ser solicitado ese articulo a ningn proveedor. Para indicar la
exclusividad entre dos tipos de interrelacin que mantiene un mismo tipo de entidad se procede a
representar un segmento que corta a los dos arcos que representan la relacin del tipo de entidad con
los tipos de interrelacin exclusivas.

suministra Son_servidos
Suministra Proveedor
(0,1)
(1,n)
(n:1)
Articulo
(n:1)
(1,n)
Son_servidos
Suministra Fabricante
suministra (0,1)

Figura 2.4. Tipo de interrelacin exclusiva.

Interrelaciones Inclusivas. Cuando una entidad puede mantener relaciones con varias entidades a la
vez. Por ejemplo si se tiene tres entidades Alumno_Maestria, Beca y Ayudantia_practica, y se puede
dar que un Alumno_Maestria puede tener una Beca y apoyar con una Ayudantia_practica a la vez.

Tiene Beca

Alumno_Maestria

Conduce Ayudantia_practica

Figura 2.5. Tipo de interrelacin Inclusiva.

2.4. Generalizacin y Herencia

El modelo EER permite representar las relaciones jerrquicas existentes entre los tipos de entidad de los
problemas del mundo real. La generalizacin es una abstraccin que identifica una relacin jerrquica que
representa un tipo de entidad EN_UN subtipo de otro tipo de entidad representada a un nivel de abstraccin
mayor. Este tipo de relaciones entre tipos de entidad implica la consideracin de tipo de entidad (o
supertipos) y de subtipos de entidad (clases, superclases y subclases de objetos.

Un subtipo de entidad es un tipo de entidad que mantiene un tipo de interrelacin jerrquica con otro tipo de
entidad, y que:

Representa a un conjunto de entidades cuyas propiedades y comportamiento general es considerado


por el tipo de entidad con la que mantiene el tipo de interrelacin.

La relacin jerrquica puede ser n-aria entre un tipo entidad y un conjunto de sub tipos de ese tipo de
entidad.

Henry George Maquera Quispe


Gestin de Base de Datos 7

Las propiedades y el comportamiento de los subtipos son heredados del tipo de entidad con el cual
mantienen un tipo de interrelacin jerrquica. La herencia es una abstraccin incorporada al modelo E-R
recientemente e implica la consideracin de que con una nica definicin de las propiedades y
comportamiento de un conjunto de entidades, esta definicin es automticamente considerada para
todos aquellos conjuntos con los que exista una relacin jerrquica (una especializacin).

Bien las propiedades y/o bien el comportamiento de un subtipo pueden y deben cambiar con respecto a
otros subtipos que intervengan en la misma relacin jerrquica n-aria entre todos estos subtipos y un
mismo tipo entidad. Puesto que los subtipos son tipos de entidad a un nivel de abstraccin menor, estos
deben poder distinguirse sin ambigedad del resto de los tipos de entidad existentes en la
representacin del problema y. por tanto, deben tener un conjunto de propiedades que permita esta
discriminacin.

Para cada subtipo de entidad pueden ser redefinidas tanto las propiedades, como el comportamiento
del tipo de entidad con la que mantiene un tipo de interrelacin jerrquica. Esta caracterstica permite la
inexistencia de mecanismos para diferenciar a los diferentes subtipos de una misma clase y, adems,
permite la cancelacin condicionada de la herencia producida por la relacin jerrquica.

Un tipo de entidad puede ser un subtipo para ms de un tipo de entidad con las que puede mantener
diferentes relaciones jerrquicas. Esta caracterstica, denominada herencia mltiple, permite que un tipo
de entidad herede propiedades y comportamiento de ms de otro tipo de entidad. La herencia mltiple
puede dar lugar, en ocasiones, a inconsistencias en las propiedades y/o comportamiento que se hereda,
lo que se debe solucionar mediante la redefinicin de las herencias.

Un tipo de interrelacin jerrquica representa una especializacin de un tipo de entidad en otros tipos de
entidad. Esta especializacin puede ser debida a:

Una diferencia en cuanto al nmero de propiedades que definen los subtipos de entidad. De esta forma,
diferentes subtipos que mantienen un mismo tipo de interrelacin jerrquica son definidos sobre la base
de la agregacin de un conjunto diferente de propiedades, si bien entre el conjunto de subtipos puede
existir un subconjunto de propiedades comunes.

Diferentes valores que pueden ser medidos para una propiedad que existe en el conjunto de subtipos
que mantienen un mismo tipo de interrelacin jerrquica.

Que se cumplan ambas condiciones.

Una especializacin de un tipo de entidad en un conjunto de subtipos puede ser: exclusiva o inclusiva. Una
especializacin exclusiva, denominada especializacin sin solapamiento, representa el hecho de que una
instancia del tipo de entidad ms general solo puede pertenecer o estar asociada a una y solo una instancia
de los subtipos de entidad especializados. Una especializacin inclusiva, denominada especializacin sin
solapamiento, representa el hecho que una instancia del tipo de entidad ms general puede tener asociadas
instancias de cualquiera de los subtipos.

Por otro lado, la especializacin de un tipo de entidad en un conjunto de subtipos puede ser total o parcial.
Una especializacin total representa el hecho de que las entidades que son reconocidas en el problema que
se esta representando son de alguno de los subtipos especializados, no existiendo entidades que no
pertenezcan a alguno, varios o todos estos subtipos de entidad. Una especializacin parcial representa el
hecho de que pueden existir entidades que pertenezcan al tipo de entidad y no a ninguno de los subtipos en
los cuales este tipo de entidad esta especializado. Una especializacin parcial describe el refinamiento
incompleto del problema que se representa, debido a un conocimiento incompleto del mismo y/o a una
simplificacin de la representacin del mismo. Asimismo se debe tener presente que la especializacin se
hace usando una condicin o atributo al que se llama discriminante asociada a la relacin

Total y Sin Solapamiento (exclusividad). Un entidad Persona podr ser especializada en dos subtipos
en entidad: al subtipo Hombre o al subtipo Mujer de forma total; no existir una entidad Persona que no
sea de alguno de estos dos subtipos y adems de forma exclusiva, por que una entidad pertenecer a
uno y solo a uno de estos subtipos.

Henry George Maquera Quispe


Gestin de Base de Datos 8

Adems cada entidad de estos subtipos vendr


caracterizadas por algn atributo o conjunto de atributos Persona Supertipo
definidos para estos subtipos o heredados del tipo de
(1:1)
entidad Persona, ms el atributo Sexo, el cual tiene la
funcin de clasificador de las entidades Persona en
alguno de estos subtipos. Es_un Sexo

(0,1) (0,1)
Hombre Mujer Subtipos

Figura 2.6. Especializacin Total y Sin


Solapamiento

Parcial y Sin Solapamiento. La entidad Enfermedad


Enfermedad
puede ser especializada en dos subtipos: Vrica y
Bacteriana. Este diagrama representa el hecho de que en (1:1)
el problema se consideran un conjunto de entidades
Enfermedad las cuales pertenecern bien a alguno de los Es_un Tipo
subtipos considerados Vrica o Bacteriana, pero que (0,1) (0,1)
adems existirn entidades Enfermedad las cuales no
puedan ser clasificadas en ninguno de estos subtipos Virica Bacteriana
debido, posiblemente, al desconocimiento del valor del
atributo tipo utilizado como discriminador. Figura 2.7. Especializacin Parcial y Sin
Solapamiento

Total y con Solapamiento. La entidad Empresa


Empresa
puede ser refinada en dos subtipos: Pblica y Privada.
Se representa el hecho de que podrn existir en el (1:1)
dominio del problema entidades que puedan ser
consideradas tanto del tipo Pblica como Privada o
bien ambos tipos al mismo tiempo y adems el hecho Es_un Clase
de que no podrn existir entidades que no puedan ser ({0 1}, 1) ({0 1} ,1)
especializadas en alguno de estos dos subtipos.
Publica Privada

administracion Empresa
Figura 2.8. Especializacin Total y con
Solapamiento

Parcial y con Solapamiento. Una Persona puede ser


refinado en dos subtipos Trabajador y Estudiante de Persona
forma parcial con solapamiento. Una entidad Persona
puede ser del tipo Trabajador y/o del tipo Estudiante y (1:1)
que adems puede existir entidades Personas que no Es_un Tipo
puedan clasificarse en ninguno de estos dos subtipos.
({0 1}, 1) ({0 1},1)

Trabajador Estudiante

#nss #matricula
Figura 2.9 Especializacin Parcial con
Solapamiento
2.5. Cardinalidades en la Jerarqua

Dependiendo del tipo de interrelacin jerrquica que se presente, y por tanto exista en el dominio del
problema, los tipos de entidad que intervienen en el mismo participan o pueden participar con un nmero
determinado de ocurrencias. As se tienen que tener en cuenta las siguientes consideraciones en la
representacin de este tipo de interrelaciones:

El tipo de entidad mas general o el supertipo de entidad que es especializado participa siempre con la
cardinalidad mnima 1 y con la cardinalidad mxima 1, puesto que se esta representando como una
entidad de este tipo puede especializarse en otros subtipos.
Henry George Maquera Quispe
Gestin de Base de Datos 9

Para cualquier clase de este tipo de interrelaciones jerrquicas, la cardinalidad mxima con la que
participan los subtipos de entidad en el tipo de interrelacin es 1, puesto que se esta representando
para cada entidad del supertipo una especializacin o refinamiento de la misma.

Si el tipo de interrelacin es total o parcial sin solapamiento, los subtipos participan siempre con
cardinalidad mnima 0, puesto que una entidad del tipo no puede pertenecer al mismo tiempo a mas de
un subtipo (Figura 2.6, 2.7)

Si el tipo de interrelacin es total o parcial con solapamiento, los subtipos pueden participar con la
cardinalidad mnima 0 1, puesto que una entidad del supertipo puede a su vez ser especializada en
cualquiera de los subtipos simultneamente (Figura 2.8, 2.9).

2.6. Jerarquas Mltiples

Puede existir jerarquas mltiples que


parten de un supertipo comn como Curso
puede verse en la figura 2.10, donde se
muestra El supertipo Curso tiene segn el Especialidad Turno
discriminante Especialidad los subtipos A B
Ingeniera en Informtica y Sistemas,
Ingeniera Qumica, Fsica Aplicada y
Biologa/Microbiologa y segn el ESIS ESIQ ESFI ESBM M T N
discriminante Turno los subtipos Maana,
Tarde, Noche. Figura 2.10. Jerarqua de la Entidad Curso.

Una forma alternativa o ms bien complementaria, de representar una abstraccin de


generalizacin/especializacin consiste en tablas jerrquicas, que permiten representar la herencia con
todas sus caractersticas, de manera clara y concisa, sobre todo en el caso de existir varias jerarquas que
parten de un mismo supertipo.

Estas tablas, de las que se Tipo de Entidades


muestra el ejemplo en la
figura 2.11 (relativo a la Combinaciones Curso ESIS ESIQ ESFI ESBM M T N
jerarqua de la figura 2.10) A 1 1 0 0 0 0 1 0
representan mediante 1 las
combinaciones posibles. B 1 1 0 0 0 0 0 1
Adems, en la parte inferior C 1 0 1 0 0 0 0 1
de la tabla se refleja la
jerarqua a la que pertenecen D 1 0 0 1 0 1 0 0
las entidades (cuando se trate E 1 0 0 1 0 0 1 0
de una raz estar vaca); el
tipo de jerarqua (D-Disjunta, F 1 0 0 1 0 0 0 1
S-Solapada, T-Total), G 1 0 0 0 1 0 0 1
aparece en la entrada que
tiene como etiqueta definida Jerarquia A A A A A B B B
como; el atributo Definida como RAIZ D/T D/T D/T D/T S/T S/T S/T
discriminante sobre el que se
define la jerarqua y la entidad Definida como - Espec. Espec. Espec. Espec. Turno Turno Turno
de la que el subtipo hereda Definida como - Curso Curso Curso Curso Curso Curso Curso
tienen tambin sus
correspondientes entradas. Figura 2.11. Tabla jerrquica del ejemplo de la figura 2.10

Hasta ahora se ha considerado jerarquas estrictas, es decir, que podan solaparse ejemplares de subtipos
que dependan del mismo supertipo, pero no subtipos de ramas distintas; puede ocurrir, sin embargo, que
un subtipo tenga mas de un supertipo, formndose un verdadero retculo o red de generalizacin (Figura
2.12), en este caso, la herencia ya no es simple, sino que se convierte en mltiple, pudindose presentar
conflictos a la hora de heredar atributos.

Henry George Maquera Quispe


Gestin de Base de Datos 10

Existen modelos de datos que en caso Persona


de conflicto definen un orden de
prioridad en la herencia; otros, por el (1,1)
Ocupacion
contrario, permiten heredar atributos
iguales de dos supertipos distintos pero A
teniendo que renombrar alguno de ellos.
Empleado Estudiante
Clase de
Trabajo Tipo
B C

Docente No Docente Becario No Becario

Categoria
B

Catedratico Titular No Numerario


Figura 2.12. Ejemplo de red de generalizacin
2.7. Agregacin

La agregacin, tambin llamada por algunos autores como meronimia, es una abstraccin que permite
representar tipos de entidad compuestos que se obtienen por unin de otros ms simples. Al tipo
compuesto nos referimos con todo. Mientras que los componentes son las partes.

Agregacin Compuesto/Componente. Es una


Auto
abstraccin que permite representar que un todo se
obtiene por la unin de diversas partes que pueden ser
tipos de objetos distintos y que desempean diferentes
papeles en la agregacin. Un Auto puede verse como la
(1:1) (1:1) (4:4)
unin de chasis, motor y 4 ruedas
Chasis Motor Rueda
Figura 2.13. Ejemplo de agregacin
Compuesto/Componente.

Agregacin Miembro/Coleccin. Es la abstraccin que


permite representar un todo como una coleccin de partes,
donde todas las partes son de un mismo tipo y desempean el Bosque Arbol
mismo papel. Un bosque es un todo formado por la agregacin Figura 2.14. Ejemplo de agregacin
de rboles; cada rbol es una parte, pero todos ellos son de un Miembro/Coleccin
mismo tipo y desempean el mismo papel.

En la Agregacin miembro/coleccin a veces se desea


establecer un orden entre las partes. Por ejemplo una flota (n1,n2)
esta compuesta de barcos, pero, a diferencia de lo que Flota Barco
{Orden por
ocurre con el bosque, en la flota cada barco tiene un
Num_barco}
determinado orden. Esto se representa mediante una
restriccin de orden tal y como se puede observar en la Figura 2.15. Ejemplo de agregacin
figura 2.15, donde los barcos se ordenan, dentro de la miembro/coleccin con orden
flota, segn el valor del atributo Num_barco. Esta
restriccin se puede recoger, igualmente, en los actuales
modelos de objetos.

Para paliar los problemas que plantea la restriccin inherente del modelo E/R que no permite establecer
interrelaciones de las que forma parte una interrelacin, se puede, mediante una agregacin, crear un tipo
de entidad compuesto por un tipo de interrelacin y los tipos de entidad vinculados por la misma, de modo
que este nuevo tipo de entidad se pueda interrelacionar con otros.

Un profesor explica asignaturas utilizando distintos medios (pizarra, transparencias, diapositivas,


computador, etc.) pero el ME/R no permite establecer la interrelacin Utiliza sobre la interrelacin Explica

Henry George Maquera Quispe


Gestin de Base de Datos 11

Profesor Explica Asignatura Profesor Explica Asignatura

Utiliza
Explicacion

Medio
Figura 2.16 Ejemplo de interrelacin no permitida Utiliza

Una solucin a este problema es crear un tipo de


entidad Explicacin por agregacin de Profesor Medio
explica Asignatura.
Figura 2.17. solucin por agregacin del ejemplo de
la figura 2.16

Como segundo ejemplo considere a los alumnos


Codigo Apellido Horas Numero
participan en Proyectos de Software y usan
distintos lenguajes y distintas PC.
Alumno Ejecuta Proyecto

Horas

Hace_uso_de
Licenciatura
Serie

Software Se_corre_en PC

Titulo

Figura 2.18. Diagrama entidad relacin no permitido,


relaciones redundantes.

La solucin esta en usar la jerarqua de agregacin, Codigo Apellido Horas


mediante la cual se puede tratar a las entidades Numero
Alumno y Proyecto y a la relacin Ejecuta como un
solo tipo de entidad. De la misma manera se trata a Alumno Ejecuta Proyecto
Software y PC y a la relacin Se_corre_en.
Nombre
Codigo Apellido Nombre Trabajo
Numero Hace_uso_de Horas
Recurso
Trabajo
Licenciatura Serie

Software Se_corre_en PC
Hace_uso_de
Titulo

Recurso Figura 2.19. solucin por agregacin del ejemplo de


la figura 2.18

Titulo Licenciatura Serie


Figura 2.20 Diagrama Entidad relacin Completo

Henry George Maquera Quispe


Gestin de Base de Datos 12

Trabajo Trabajo

Licencia Titulo Serie


Codigo Apellido Parte_de Numero Parte_de

Alumno Ejecuta Proyecto Software Se_corre_en PC

Horas Titulo Nombre

Figura 2.21. Trabajo como agregacin de Alumno y Figura 2.22. Recurso como agregacin de Software
Proyecto y Pc

La agregacin ayuda a construir entidades de niveles superiores

(1:n) (0:n) Trabajo


Empleado Trabaja Proyecto
(1:n) (0:n)
(1:1) (1:1) Empleado Trabaja Proyecto

Usa
(1:1)
(1:n)
Usa
Maquinaria
(1:n)
Figura 2.23. Diagrama Entidad relacin no Permitido
Maquinaria
Figura 2.24. Diagrama entidad relacin con
agregacin

Hay tres casos en los que es posible


relacionar este concepto con el modelo EER. (0:n) (1:1)
Asignatura Trabaja Profesor
Caso 01. Es la situacin en la que se
agrega valores de atributos de un objeto
para formar el objeto completo. (0:n) (1:1)
Asignatura Trabaja Profesor
Caso 02. Es la representacin de una
relacin de agregacin como una relacin
ordinaria.
(1:n) Curso
Toma
Caso 03. no contempla explcitamente el
modelo EER, implica la posibilidad de (1:n)
combinar objetos que se relacionen
mediante una instancia de relacin Alumno
especfica para formar un objeto Figura 2.25. Diagrama Entidad relacin Valido
agregado de ms alto nivel.

La abstraccin de asociacin sirve para asociar objetos de varias clases independientes. Por tanto, es de
algn modo similar a la segunda aplicacin de la agregacin. Se representa en el modelo EER mediante
tipos de relaciones.

Considere el esquema EER que se muestra DireccionE NombreContacto Nss Nombre Direccion
en la figura 2.26, que almacena informacin
sobre entrevistas de solicitantes de empleo en
varias empresas. La clase Empresa es una
agregacin de los atributos (u objetos Empresa Entrevista Solicitante_empleo
componentes) NombreE (Nombre de la
Fecha
empresa) y DireccionE (direccin de la
empresa), en tanto que Solicitante_Empleo es NombreE TelefonoContacto
un agregado de Nss, Nombre, direccin. Figura 2.26. El tipo de relacin Entrevista

Henry George Maquera Quispe


Gestin de Base de Datos 13

Los atributos de la relacin NombreContacto y TelefonoContacto representan el nombre y el nmero


telefnico de la persona de contacto en la empresa que se encarga de la entrevista.

Suponga que algunas entrevistas dan lugar a


ofertas de empleo pero otras no. Seria agradable Empresa Entrevista Solicitante_empleo
tratar a Entrevista como una clase para asociarla
a Oferta_Empleo. El esquema que se muestra
en la figura 2.27 es Incorrecto porque requiere Oferta de Empleo
que cada instancia de la relacin entrevista Figura 2.27. Relacin incluyendo Oferta_Trabajo en una
tenga una oferta de empleo. relacin ternaria (Incorrecto)

El esquema de la figura 2.28 no esta permitido,


porque el modelo EER no permite relaciones Empresa Entrevista Solicitante_empleo
entre relaciones.

Una forma de representar esta situacin consiste Da_Lugar_a


en crear una clase agregada de ms alto nivel
formada por Empresa, Solicitante_Empleo y
Entrevista y en relacionar esta clase con Oferta de Empleo
Oferta_Empleo como se muestra en la figura
2.27. Figura 2.28. Incluyendo Oferta_Trabajo considerando
una relacin en la que participa otra (generalmente no
permitido en ER)

Aunque el modelo ER aqu descrito no


cuenta con este recurso, algunos modelos Empresa Entrevista Solicitante_empleo
semnticos de datos si lo permiten y llaman
al objeto resultante un objeto compuesto o
molecular. Otros modelos tratan a los tipos Da_Lugar_a
de entidad y a los tipos de relaciones de la
misma manera y, por lo tanto, permiten
relaciones entre relaciones (Figura 2.29). Oferta de Empleo
Figura 2.29. Usando una agregacin y un objeto (molecular)
compuesto generalmente no permitido en ER).

Para representar correctamente Nss Nombre Direccion


esta situacin en el modelo EER
tal y como se ha descrito aqu, DireccionE
se necesita crear un nuevo tipo
Empresa ESE Solicitante_empleo
de entidad dbil Entrevista,
como se muestra en la figura
2.30 y relacionarlo con NombreE
Oferta_Empleo. Fecha
NombreContacto
Entrevista Da_Lugar_a Oferta de Empleo
TelefonoContacto
Figura 2.30. Representacin correcta en ER.

As siempre se podr representar correctamente estas situaciones en el modelo EER si se crea tipos de
entidad adicionales, aunque puede ser mas deseable, desde el punto de vista conceptual, permitir una
representacin directa de la agregacin, como en la figura 2.29, o permitir relaciones entre relaciones, como
en la figura 2.28.

La distincin estructural principal entre la agregacin y la asociacin es que cuando se elimina una instancia
de asociacin, los objetos participantes pueden seguir existiendo. Sin embargo, si se maneja la nocin de
objeto agregado (por ejemplo, un Coche se compone de los objetos Motor, Chasis, neumticos), entonces
la eliminacin del objeto agregado Coche equivale a eliminar sus objetos componentes.

Henry George Maquera Quispe


Gestin de Base de Datos 14

3. CONTROL DE REDUNDANCIA

Es preciso, en los esquemas ER, analizar la existencia de redundancias, por lo problemas de


inconsistencias a los que pueden dar lugar. Se dice que un elemento de un esquema es redundante cuando
puede ser eliminado sin prdida de semntica.

Existen dos formas principales de redundancia, segn el elemento del modelo ER al que est asociada:
redundancia en los atributos (atributos derivados) y redundancia en las interrelaciones (denominadas
tambin por algunos autores interrelaciones derivadas).

3.1. Atributos Derivados

Se entiende por atributos derivados (o calculados) aquellos que se obtienen a partir de otros ya existentes,
por lo que, aunque son redundantes, no dan lugar a inconsistencias, siempre que en el esquema se indique
su condicin de derivados y la frmula mediante la que han de ser calculados.

En la figura 3.1 se tiene el atributo nmero de


Edicion 1:N Curso
ediciones, que puede ser calculado a partir de los
ejemplares de edicin mediante la interrelacin tiene. (1:N) Id (1:1)
Para indicarlo grficamente se utilizar la etiqueta Id en
Tiene
el atributo calificado como derivado, almacenando la
regla de derivacin en el diccionario de datos.
Figura 3.1. Ejemplo de atributo derivado

Incluir en el esquema conceptual atributos derivados, a pesar de que pueden ser generados a partir de otros
ya existentes, tiene a veces inters por razones semnticas. Aunque tambin se podra hacer por motivos
de eficiencia; slo por esta causa no se deberan incluir dichos atributos en el esquema conceptual, sino en
el lgico, o mejor an, en el fsico.

Un atributo derivado puede ser calculado en dos momentos distintos: bien en actualizaciones que pueden
provocar cambios en su valor, bien cuando se recupera. En el primer caso, el atributo derivado se calcula y
almacena (por lo que, por ejemplo, en el modelo de datos Codasyl se dice que es real); en el segundo no
est almacenado y se calcula cuando se realiza una consulta (por lo que se dice que es virtual). El tomar
una u otra decisin es propio del diseo fsico, ya que se hace por motivos de eficiencia, y depender del
nmero de actualizaciones frente al de recuperaciones. Tampoco hay que confundir un atributo derivado,
cuyo valor no se introduce nunca sino que se calcula con las restricciones que comprueban la consistencia
entre valores que estn almacenados en la base de datos por haberlos introducido el usuario.

3.2. Interrelaciones Redundantes

Se dice que una interrelacin es redundante cuando su eliminacin no implica prdida de semntica porque
existe la posibilidad de realizar la misma asociacin de ejemplares por medio de otras interrelaciones. Es
condicin necesaria, aunque no suficiente, para que una interrelacin sea redundante que forme parte de un
ciclo, por lo que hay que estudiar detenidamente los ciclos en el diagrama ER.

En el ejemplo de la figura
3.2 se da un ciclo entre
Profesor
(1:n) (1:n) Redundante
Profesor, Curso y
Departamento, por lo que en
principio es posible que
Imparte (n:m) (1:n) Pertenece
aparezca alguna
interrelacin redundante. (1:n) 1:n (1:1)
Curso Adscrito Departamento
(1:n) (1:1)
Pertenece = Imparte + Adscrito
Figura 3.2. Ciclo en el que aparece una interrelacin redundante

Suponga que un Profesor slo puede impartir Cursos de doctorado que estn adscritos al Departamento al
que l pertenece; en este caso, si se conocen los Cursos de doctorado que imparte un Profesor y el
Departamento al que est adscrito cada curso, se deduce inmediatamente a qu Departamento pertenece
dicho profesor; de-forma anloga, dado un departamento, si se sabe qu Cursos de doctorado tiene

Henry George Maquera Quispe


Gestin de Base de Datos 15

adscritos y los Profesores que imparten dichos Cursos, se conocer que Profesores pertenecen a dicho
Departamento, por lo que la interrelacin pertenece entre las entidades Profesor y Departamento es
redundante, su eliminacin no produce prdida de informacin.

En la figura 3.3, a pesar de que


tambin existe un ciclo, no hay Profesor
(1:n) (1:n)
ninguna interrelacin redundante.
En este ejemplo la semntica es
distinta y un departamento puede n:m Imparte (1:n) Pertenece
no tener adscritos cursos de
doctorado; adems un mismo
curso puede estar adscrito a (1:n) n:m (1:1)
distintos departamentos y puede
haber profesores que no impartan Curso Adscrito Departamento
(0:n) (1:n)
ningn curso.
Figura 3.3. Ciclo en el que no aparece una interrelacin redundante

La interrelacin pertenece no puede deducirse en este caso de las otras dos, ya que aunque sepamos los
cursos que ha impartido un Profesor y los Departamentos a los que estn adscritos dichos Cursos, no se
puede saber a qu Departamento en concreto pertenece dicho profesor; tampoco se tiene esta informacin
para los Profesores que no imparten ningn curso. La interrelacin imparte tampoco es redundante, ya que
un Curso de doctorado puede ser impartido por diversos Departamentos a cada uno de los cuales
pertenecen varios Profesores, por lo que no se puede saber qu Profesor en concreto imparte un
determinado curso. Por ltimo, la interrelacin adscrito tampoco es redundante, ya que un curso impartido
por un Profesor no tiene por qu estar necesariamente adscrito al Departamento al que pertenece dicho
Profesor: hay Departamentos que no tienen Cursos adscritos y los Profesores de estos Departamentos
pueden colaborar en cursos adscritos a otros Departamentos distintos del suyo.

Existen otros casos en los que la interrelacin, a pesar de poder ser deducida a partir de otras presentes en
el esquema, no se puede eliminar porque posee atributos.

Se puede decir, como norma general, que la existencia de un ciclo no implica la existencia de
interrelaciones redundantes. Deben estudiarse con mucho detenimiento las cardinalidades mnimas de las
entidades, as como la semntica que aportan las interrelaciones, para poder afirmar con seguridad que
existen interrelaciones redundantes. Habr que analizar si al eliminar una interrelacin es siempre posible el
paso, tanto en un sentido como en el inverso, entre las dos entidades unidas por la interrelacin que se
considera redundante, y habr que comprobar tambin que no se pierdan atributos.

En resumen, para que una interrelacin pueda ser eliminada por redundante se tiene que cumplir:

- Que exista un ciclo.

- Que las interrelaciones que componen el ciclo sean equivalentes semnticamente.

- Que se puedan asociar los ejemplares de las dos entidades que estaban interrelacionadas, an
habindose eliminado la interrelacin.

- Que la interrelacin o bien no tenga atributos o bien stos puedan ser transferidos a otra a fin de no
perder su semntica.

4. PROBLEMAS Y CASOS

4.1. HABITANTES Y MUNICIPIOS

Suponga el siguiente universo del discurso sobre municipios, viviendas y personas. Cada persona slo
puede habitar en una vivienda y estar empadronada en un municipio, pero puede ser propietaria de varias
viviendas. Interesa tambin conocer las personas que dependen del Cabeza de Familia (C.F.). Se indicarn
los supuestos semnticos que se consideren oportunos para justificar todas las decisiones de diseo.

4.1.1. Discusin del Enunciado

Primer Paso: Elaborar las listas de conceptos candidatos a ser entidades e interrelaciones e indicar
tambin los conceptos que no se sabe cmo catalogar. Las listas obtenidas son:
Henry George Maquera Quispe
Gestin de Base de Datos 16

Entidades: Interrelaciones:
Municipio Habita entre Persona y Vivienda
Vivienda Empadronada entre Persona y Municipio
Persona Propiedad entre Persona y Vivienda
Cabeza de Familia?

Las entidades e interrelaciones anteriores estn explcitamente representadas en el enunciado. En


principio, no se sabe cmo representar el concepto Cabeza de Familia, pues en realidad es tambin una
Persona. Se deja la clasificacin de este concepto para el siguiente paso.

Segundo Paso: Construir una matriz Entidades/Entidades para representar todas las interrelaciones
junto con su tipo de correspondencia. Para ello, se ira analizando los supuestos semnticos
explcitamente representados en el enunciado, as como los que estn implcitos o son de sentido
comn.

Supuestos dados en el enunciado:

- Cada Persona slo puede Habitar en una Vivienda. (interrelacin Habita (1:?) entre Persona y
Vivienda)

- Cada Persona puede ser Propietaria de ms de una Vivienda. (interrelacin Propiedad (?:N) entre
Persona y Vivienda)

- Las Personas dependen del Cabeza de Familia. (interrelacin C.F. (?:?) entre Persona y Persona)

- Una Persona est empadronada en un nico Municipio. Interrelacin Empadronada (1:N) entre
Persona y Municipio

Supuestos no dados en el enunciado:

- En una Vivienda pueden Habitar muchas Personas (supuesto lgico del mundo real). interrelacin
Habita (1:N) entre Persona y Vivienda

- Una Vivienda puede ser Propiedad de muchas Personas (supuesto legal). interrelacin Propiedad
(M:N) entre Persona y Vivienda.

- Una Persona slo puede tener un Cabeza de Familia y un Cabeza de Familia puede serio de varias
Personas. Interrelacin C.F. (1:N) entre Persona y Persona.

- Un Municipio puede tener muchas Viviendas y una Vivienda pertenece a un solo Municipio.
Interrelacin Est_En (N:1) entre Municipio y Vivienda

La matriz obtenida se muestra.

Persona Municipio Vivienda


Persona C.F. (1:N) Empadrona (1:N) Habita (1:N) Propiedad (N:M)
Municipio Esta_en (N:1)
Vivienda

Tercer Paso: Obtener una versin preliminar del esquema E/R. Se muestra una primera versin del
Esquema E/R correspondiente a los supuestos mencionados.

Cuarto Paso: Anlisis de las cardinalidades mnimas. Hasta ahora se han estudiado slo las
cardinalidades mximas de las interrelaciones. A continuacin, se estudiarn las cardinalidades
mnimas.

- Interrelacin. C.F: Una Persona tiene obligatoriamente como mnimo una Persona que es Cabeza
de Familia y una Persona que es Cabeza de Familia puede que no tenga ninguna persona a su
cargo.

Henry George Maquera Quispe


Gestin de Base de Datos 17

- Interrelacin Habita: Una Persona


C.F.
habita como mnimo en una Vivienda y 1:n
en una Vivienda puede que no habite
1:n
ninguna Persona.
Persona Empadrona
- Interrelacin Propiedad: Una Persona
puede que no sea propietaria de
ninguna Vivienda y una Vivienda puede 1:n
Minicipio
que no sea propiedad de ninguna Habita Propiedad
Persona (una vivienda podra ser n:m
propiedad de una empresa, por n:1
ejemplo).
Vivienda Esta_en

Figura 4.1. Versin preliminar del esquema E/R

- lnterrelacin Empadronada: 1:n


Una Persona est empadronada C.F.
como mnimo en un Municipio (y
como mximo tambin) y en un (1:1) (0:n) 1:n
Municipio como mnimo est
(1:n)
empadronada una Persona. Persona Empadrona

- Interrelacin Est_En: Una (0:n) (0:n)


(1:1)
Vivienda est en un nico
Municipio y en un Municipio hay 1:n Minicipio
como mnimo una Vivienda. Habita Propiedad
n:m
(1:1)
Quinto Paso: Anlisis de
redundancias. Como existen dos (1:1) (0:n)
ciclos en el esquema E/R hay que
estudiar si existe alguna Vivienda Esta_en
(1:n)
interrelacin redundante, es decir, si n:1
hay alguna interrelacin cuya Figura 4.2. Esquema E/R con restricciones de cardinalidad
semntica pueda obtenerse a partir
de las otras interrelaciones.

- El primer ciclo lo constituyen las interrelaciones Propiedad, Est_En y Empadronada. La primera


condicin para saber si se tiene un ciclo en el que haya alguna interrelacin susceptible de ser
redundante es que las tres interrelaciones estn semnticamente relacionas. En este caso la
interrelacin Propiedad no es semnticamente equivalente a Est_En y Empadronada, puesto
que el poseer o no una vivienda no influye en si la persona reside en el municipio en el que se
encuentra la vivienda.

- El segundo ciclo lo constituyen las interrelaciones Habita, Est_En y Empadronada. En este caso
las tres interrelaciones estn semnticamente relacionadas 1. Observe si alguna de estas
interrelaciones es redundante:

Interrelacin Habita: Si se intenta eliminar la interrelacin Habita debe ser posible obtener su
semntica a partir de Est_En y Empadronada; as, si se quiere obtener las personas que habitan
en una determinada vivienda, a partir de Est_En se obtiene el municipio en el que se encuentra la
vivienda y con la interrelacin Empadronada se obtienen las personas que habitan en ese
municipio, pero no se sabe las personas que habitan en la vivienda sino las que habitan en todas las
viviendas del municipio. Por ello, la interrelacin Habita no se puede eliminar.

Interrelacin Est_En: Si se intenta suprimir la interrelacin Est_En debe ser posible obtener su
semntica a partir de las interrelaciones Habita y Empadronada. Para conocer las viviendas que se
encuentran en un determinado municipio, a partir de Empadronada se obtiene todas las personas
empadronadas en ese municipio y mediante la interrelacin Habita se obtiene las viviendas en las
que habitan esas personas (pues una persona obligatoriamente debe habitar en una vivienda); de
esta forma, se sabr las viviendas de ese municipio. En el otro sentido de la interrelacin Est_En,

1 Se ha supuesto que las personas habitan en los municipios en los que estn empadronadas.
Henry George Maquera Quispe
Gestin de Base de Datos 18

para conocer en qu municipio est una determinada vivienda, a partir de Habita se obtiene las
personas que habitan en ella; sin embargo, puede ocurrir que en una determinada vivienda no
habite nadie (cardinalidad mnima 0), por lo que no se puede alcanzar la interrelacin
Empadronada entre persona y municipio. As la interrelacin Est_En no es redundante.

Interrelacin Empadronada: Si se elimina la interrelacin Empadronada, debera ser posible


obtener su semntica a partir de Habita y Est_En. Para conocer el municipio en que est
empadronada una persona, mediante Habita se obtiene la vivienda en la que habita esa persona y
con la interrelacin Est_En se obtiene el municipio en que se encuentra la vivienda; Por ello, se
conoce el municipio en que est empadronada esa persona.

En el otro sentido de la 1:n


interrelacin Empadronada, C.F.
debe ser posible conocer las
personas empadronadas en un (1:1) (0:n)
determinado municipio; mediante
la interrelacin Est_En se Persona
conoce las viviendas de ese
municipio y a partir de Habita se (0:n) (0:n)
sabe todas las personas que
viven en esas viviendas, 1:n Minicipio
conociendo as todas las Habita Propiedad
n:m
personas empadronadas en el (1:1)
municipio. Consecuentemente, la
interrelacin Empadronada se (1:1) (0:n)
puede eliminar del esquema E/R
sin perder semntica. Vivienda Esta_en
(1:n)
n:1
Figura 4.3. Esquema E/R sin redundancia.
4.2. CURSOS DE FORMACIN

El departamento de formacin de una empresa desea construir una base de datos para planificar y
gestionar la formacin de sus empleados.

La empresa organiza cursos internos de formacin de los que se desea conocer el cdigo de curso, el
nombre, una descripcin, el nmero de horas de duracin y el coste del curso.

Un curso puede tener como prerrequisito haber realizado otro(s) previamente, y, a su vez la realizacin de
un curso puede ser prerrequisito de otros. Un curso que es un prerrequisito de otro puede serlo de forma
obligatoria o slo recomendable.

Un mismo curso tiene diferentes ediciones, es decir, se imparte en diferentes lugares, fechas y con
diferentes horarios (intensivo, de maana o de tarde). En una misma fecha de inicio slo puede impartirse
una edicin de un curso.

Los cursos se imparten por personal de la propia empresa.

De los empleados se desea almacenar su cdigo de empleado, nombre y apellidos, direccin, telfono, NIF
(Nmero de Identificacin Fiscal), fecha de nacimiento, nacionalidad, sexo, firma y salario, as como si est
o no capacitado para impartir cursos.

Un mismo empleado puede ser docente en una edicin de un curso y alumno en otra edicin, pero nunca
puede ser ambas cosas a la vez (en una misma edicin de curso o lo imparte o lo recibe).

4.2.1. Discusin del Enunciado

Parte 1

La empresa organiza cursos internos de formacin de los que se desea conocer el cdigo de curso, el
nombre, una descripcin, el nmero de horas de duracin y el coste del curso.

Henry George Maquera Quispe


Gestin de Base de Datos 19

Un curso puede tener como prerrequisito haber realizado otro(s) previamente, y, a su vez la realizacin
de un curso puede ser prerrequisito de otros. Un curso que es un prerrequisitos de otro puede serio de
forma obligatoria o slo recomendable.

Parece evidente a partir de los primeros prrafos que cada Curso de formacin ser una entidad: un
Curso tiene un "Cdigo" que lo identifica, y tendr como atributos el "Nombre" (el cual se considera que
adems es nico, es decir, es un identificador alternativo), una "Descripcin", el nmero de horas de
"Duracin" y su "Coste". Para modelar que un Curso puede ser prerrequisito de otros no se puede
utilizar un atributo, ya que un curso puede ser prerrequisito de varios. La forma de representarlo es
mediante una interrelacin reflexiva en la entidad Curso. Las cardinalidades mnimas y mximas en
ambos sentidos de la interrelacin son (0,n), lo cual significa que:

- Un Curso puede ser prerrequisito de ninguno o de varios otros Cursos.


- Un Curso puede tener como prerrequisito haber cursado previamente ninguno o varios Cursos.

codigo_curso

Descripcion
Por otra parte, el atributo que indica

Duracion
Nombre
la obligatoriedad ha de figurar en la

Coste
interrelacin, y no en la entidad, ya
que no es propio del curso el ser
obligatorio o recomendable, sino de
un curso con respecto a otro del que
es prerrequisito. Las (0:n)
consideraciones anteriores N:M Obligatorio
aparecen en el esquema de la figura Curso Prerrequisitos

(0:n)

Figura 4.4. Diagrama de la parte 1


Parte 2

Un mismo Curso tiene diferentes ediciones, es decir, se imparte en diferentes lugares fechas y con
diferentes horarios (intensivo, de maana o de tarde). En una misma fecha de inicio slo puede
impartirse una edicin de un curso.
codigo_curso

Puesto que en una misma fecha


Descripcion

slo puede comenzar una nica


Duracion
Nombre

edicin del mismo curso, ser


Coste

suficiente con la fecha (junto con


el cdigo del Curso) para poder
identificarla. Por lo tanto, una
Edicin ser una entidad dbil (0:n)
que tendr una dependencia en N:M Obligatorio
identificacin con respecto a Curso Prerrequisitos
Curso. Las cardinalidades con
(1:1)
respecto a Curso sern (1,1), ya (0:n)
que toda edicin lo es de uno y
slo un Curso (adems, toda Id
dependencia en identificacin ha 1:N
Impartido
de tener, evidentemente,
cardinalidades (1,1) con
respecto a la entidad regular). (0:n)
Fecha
Edicion

Id_Edicion
Lugar Horario
Figura 4.5. Diagrama de la parte 2

La cardinalidad mxima de una Edicin con respecto a un Curso ser N (puesto que puede haber
distintas ediciones de un mismo Curso). En cuanto a la mnima, ser 0 si pueden existir Cursos de los
que no se hayan impartido Ediciones, y 1 si todo Curso ha de tener al menos una Edicin. Se ha elegido

Henry George Maquera Quispe


Gestin de Base de Datos 20

la cardinalidad menos restrictiva, esto es, 0, para permitir que la empresa pueda tener planificados
distintos Cursos de los que todava no se haya celebrado ninguna Edicin.

Parte 3

Los cursos se imparten por personal de la propia empresa.

De los empleados se desea almacenar su cdigo de empleado, nombre y apellidos, direccin, telfono,
NIF (Nmero de Identificacin Fiscal), fecha de nacimiento, nacionalidad, sexo, firma y salario, as{ como
si est o no capacitado para impartir cursos.

Un mismo empleado puede ser docente en una edicin de un curso y alumno en otra edicin, pero
nunca puede ser ambas cosas a la vez (en una misma edicin de curso o lo imparte o lo recibe)

El esquema modelado hasta ahora ha sido bastante sencillo. Sin embargo, para modelar toda la
semntica asociada al hecho de que los Empleados participen (impartan o reciban) en las ediciones de
los cursos, se tiene varias posibilidades. En cualquier caso, se tendr una entidad Empleado, con un
conjunto de atributos, de los cuales "Cdigo de Empleado" ser identificador principal, y "NIF
identificador alternativo. Adems de otros atributos, como el "Telfono", "Fecha de Nacimiento",
"Nacionalidad", etc., existir un atributo que especificar si un empleado est o no "Capacitado" para
impartir cursos2.

A continuacin se ofrece distintas


posibilidades para modelar la
participacin de los empleados en Participacion
las ediciones de los cursos, y se
observa las ventajas y Edicion participa Empleado
desventajas de cada una de ellas (0:n) (1:n)
(por claridad, en estas figuras no
se incluyen los atributos de las
N:M
entidades): Figura 4.6

La solucin ms sencilla (figura anterior) sera modelar la participacin de los empleados en las
ediciones de los cursos mediante una interrelacin Participa entre Empleado y Edicin. Dicha
interrelacin tendra un atributo "Participacin", cuyos posibles valores seran "Docente" y "Alumno",
Esta solucin recoge que en un Curso un Empleado slo puede participar como docente o como
alumno, pero no como ambas cosas a la vez, Sin embargo esta solucin no recoge las siguientes
caractersticas:
N:M
- Que un Empleado no capacitado
para impartir Cursos no pueda imparte
participar en una Edicin como (0:n)
Docente (1:1)

- Que en una Edicin deba haber al Edicion Empleado


menos un Alumno y un Docente
(la solucin slo exige que haya
un participante)
(0:n) (1:n)
recibe
N:M
Figura 4.7

Se puede ampliar la solucin anterior, dividiendo la interrelacin Participa en dos interrelaciones,


Imparte y Recibe, como muestra la figura anterior. De esta manera se resuelve que en una edicin
deba haber un Docente y, al menos, un Alumno. La cardinalidad mxima de Imparte sera 1 si un Curso
lo imparte una nica persona o N si se supone que lo pueden impartir ms. Sin embargo, se sigue sin
resolver el hecho de impedir que Empleados no capacitados puedan impartir Cursos, y adems se ha
aadido un problema que con la solucin de la figura 4.6 se tena resuelto: que en una misma Edicin

2 Esto es as porque en los requisitos se indica que la capacitacin depende nicamente del Empleado. Podra
plantearse una ampliacin del problema permitiendo que dicha capacitacin dependiera no slo del Empleado sino
tambin de cada Curso (es decir, que un empleado estuviera capacitado para impartir unos Cursos y no otros).
Henry George Maquera Quispe
Gestin de Base de Datos 21

un mismo Empleado participe como Docente y como Alumno. Esto no se resolvera mediante una
restriccin de exclusividad (en Empleado), ya que significara que un Empleado o siempre es Alumno, o
siempre es Profesor, pero no que pueda ser unas veces Alumno y otras Profesor, pero siempre en
distintas ediciones de cursos.

Una mejora a la solucin de la figura 4.7 sera aadir una jerarqua de empleados (Capacitados y
No_Capacitados. o nicamente Capacitados) en la que el atributo discriminante fuera "Capacitado", y
dos interrelaciones, Imparte y Recibe. Con esta solucin que se muestra en la figura 4.8, se resolvera
los dos aspectos que no se recogan con la solucin de la figura 4.6, pero se sigue sin resolver el
impedir que un mismo empleado participe en la misma edicin como Alumno y como Docente, ya que
en la interrelacin Recibe participan tanto los Empleados Capacitados como los No Capacitados. Para
resolverlo se debera exigir que una ocurrencia de la interrelacin Recibe no apareciera en la
interrelacin Imparte y viceversa, es decir, una restriccin de exclusin.

(1:n)
recibe Empleado
(0:n) (1:1)
(Exclusion)
Edicion
(0:n)
imparte (0:1) (0:1)
N:1 (1:1) Capacitado No_capacitado
Figura 4.8

4.2.2. Propuesta de Solucin

Se ha elegido la opcin de la figura 4.8 porque, como se ha visto, es la que ms semntica recoge. La figura
4.9 muestra el esquema definitivo.
codigo_curso

Descripcion
Nombre

Duracion
Coste

(0:n)
N:M Obligatorio ado
l e
Curso Prerrequisitos p
_ em s n o
(1:1) i go bre llido ccio fon
d m e e le IF
(0:n) Co No Ap Dir Te N
fecha_nac
Id Nacionalidad
Impartido 1:N N:M Sexo
(1:n)
recibe Empleado Firma
Salario
(0:n) (0:n) (1:1)
Fecha (Exclusion) Capacidad
Edicion
(0:n)
imparte (0:1) (0:1)
Id_Edicion
Lugar Horario N:1 (1:1) Capacitado No_capacitado

Figura 4.9. Propuesta de solucin al problema dado

Henry George Maquera Quispe


Gestin de Base de Datos 22

4.2.3. Supuestos Semnticos Complementarios y Semntica No Reflejada

Se ha considerado el nombre del curso como un identificador alternativo.

4.3. CATASTRO MUNICIPAL

Se desea considerar la informacin correspondiente al catastro de viviendas de un determinado municipio.


En el municipio existe una serie de zonas urbanas en las cuales se ha edificado un conjunto de viviendas,
las cuales pueden ser:
Viviendas unifamiliares o casas en las que solo habita una familia.
Bloques de pisos en los cuales existe un conjunto de viviendas, indeterminado a priori; en cada una de
las cuales habita una familia.

En el sistema es necesario mantener la informacin correspondiente a las personas que viven en cada una
de las viviendas, as como el cabeza de familia de las personas que habitan o son propietarias de las
viviendas. Para cada vivienda, adems de la informacin correspondiente a las caractersticas de las
mismas, es necesario conocer al propietario.

4.3.1. Supuestos Semnticos

Dentro de la construccin se van a considerar los siguientes supuestos semnticas en el problema:

Supuesto 1: Toda persona habita en una y solo una vivienda, la cual es considerada como su vivienda
o residencia principal.

Supuesto 2: Cada vivienda tiene uno y solo un propietario.

Supuesto 3: Las viviendas se encuentran en una nica zona urbana correspondiente al municipio, de
las cuales interesa mantener informacin.

Supuesto 4: Las zonas urbanas en las que esta dividido geogrficamente el municipio tienen nombres
diferentes.

Supuesto 5: en cada zona urbana del municipio existen una serie de calles en las que se construyen
las viviendas. Los nombres de las calles son nicos para el municipio con independencia de la zona
urbana en la que se encuentren (para simplificar el problema no se considerar informacin sobre las
calles).

Supuesto 6: En el contexto del problema, una familia es un conjunto de personas que tienen una
relacin familiar directa y que habita, o no, en una misma vivienda. Este conjunto podr ser unario.

Supuesto 7: Como se indica en el enunciado del problema las viviendas pueden ser casas unifamiliares
o bloques de pisos en los cuales existen una serie de viviendas unifamiliares.

4.3.2. Anlisis del Modelo

Se trata de representar la informacin de las viviendas construidas en un municipio incluyendo tanto la de


los propietarios de las mismas como la de las personas que habitan en ellas. Tambin se solicita la relacin
familiar de las personas consideradas en el problema.

Tipo de Entidad ZonaUrbana. El cual representa al objeto del mundo real barrio o distrito, y que se
puede definir como la zona geogrfica que forma parte del municipio y donde se encuentran las
viviendas. Se van a considerar dos atributos para este tipo de entidad: nombre_zona y od_zona.

El atributo nombre_zona identifica a la zona geogrfica, pues como indica el enunciado no puede
repetirse, el atributo od_zona hace referencia a cualquier otro dato que se considere que sea de inters
representar (Supuesto 3- 4)

Tipo de entidad Vivienda. El cual representa al objeto del mundo real vivienda, y que representa al
solar o zona en la que se ha construido un edificio con el objetivo de ser utilizado como vivienda.
Como se puede observar en el enunciado, existen dos tipos de viviendas: aquellas que son
unifamiliares y aquellas que son bloques de pisos.

Henry George Maquera Quispe


Gestin de Base de Datos 23

Para el tipo de entidad Vivienda se van a considerar los atributos calle y nmero cuya agregacin
identifica a las entidades de este tipo. Adems, considere que otros atributos como codigo_postal,
metros y od_vivienda los cuales representan el cdigo postal asignado a la direccin de la vivienda, los
metros cuadrados del solar y/o edificio y cualquier otro conjunto de datos que se desee representar con
respecto a la vivienda, respectivamente.

El tipo de Vivienda podra considerarse como un tipo de entidad dbil por existencia con respecto al tipo
de entidad ZonaUrbana, pues el lgico considerar que una vivienda no existe si no existe una zona
urbana en la que se pueda construir (Supuesto 3). Sin embargo, y si se considera que no existen calles
con el mismo nombre ni nmeros iguales en una misma calle, la debilidad no ser por identificacin,
puesto que es posible identificar una vivienda con independencia de la identificacin de la zona urbana
en la que se encuentre (supuesto 5)

Por otra parte, el tipo de entidad Vivienda es posible especializarlo en dos subtipos de entidad: El tipo
de entidad CasaParticular, el cual hace referencia a aquellas viviendas en las que solo vive una familia y
que puede ser identificada por la agregacin de los atributos calle y numero; y el tipo de entidad
BloqueCasas, para los cuales es conveniente considerar otros atributos que representen informacin
sobre los metros construidos (metros_c y metros_b) y cualquier otra informacin de inters (od_casa y
od_bloque)

Tipo de entidad Piso. El cual representa a cada una de las viviendas que pueden existir en un bloque
de pisos y que necesitan para su identificacin los atributos escalera, planta y puerta. Se trata de un
tipo de entidad dbil por identificacin con respecto al tipo de entidad BloqueCasas puesto que no existe
un piso si no existe un bloque, y adems es necesario conocer la calle y el numero en el cual se
encuentra el bloque para identificar sin ambigedad un piso del municipio (Supuesto 5).

Tipo de entidad Persona. El cual representa al objeto del mundo real personas que viven o son
propietarias de una determinada vivienda. Para este tipo de entidad se van a considerar cuatro
atributos :dni, nombre_persona, apellidos_persona y od_persona (Supuesto 1)

Considere que el atributo dni puede servir para identificar sin ambigedad las entidades de este tipo, por
lo que se lo considera identificador principal 3. El atributo od_persona representa, en este caso, a
cualquier conjunto de atributos que se deseen considerar tambin.

Tipo de interrelacin ZonaUrbana/Vivienda (Z-V). El cual relaciona los tipos de entidad ZonaUrbana y
Vivienda, la interrelacin es del tipo 1:N, ya que una vivienda se encuentra en una nica zona urbana,
por tanto, el tipo de entidad ZonaUrbana participa con las cardinalidades (1,1) en este tipo de
interrelacin, mientras que una zona urbana pueden existir muchas viviendas. Se puede considerar que
una zona urbana tiene existencia independiente de que existan o no viviendas construidas en la misma,
por lo que el tipo de entidad Vivienda participa en el tipo de interrelacin Z-V con las cardinalidades
(0,n), como se puede observar en la figura 4.10 (Supuesto 3).

Tipo de interrelacin Vivienda/Persona. El cual representa la relacin existente entre las viviendas y
las personas que habitan en las mismas. Se puede ver este tipo de interrelacin como una relacin
exclusiva entre el tipo de entidad Persona y los tipos de entidad CasaParticular y Piso, puesto que una
persona vivir en una, y solo en una, vivienda de un tipo al mismo tiempo, la residencia principal)
(Supuesto 1)

As, los tipos de entidad CasaParticular y Piso participan en los tipos de interrelacin (PP-P) y (PP-C)
con las cardinalidades (0,1), mientras que el tipo de entidad Persona participa de forma exclusiva con
las cardinalidades (0,n) (Supuesto 1), considerndose que las viviendas puedan estar deshabitadas o
bien habitadas por varias personas (Supuestos 1 , 6)

Tipo de interrelacin Propietario/Vivienda. El cual representa a los propietarios de cada una de las
viviendas, tanto pisos como casas particulares. Se trata, como se aprecia en la figura 4.10, de dos tipos
de interrelacin en los que participa el tipo de entidad Persona, uno con el tipo de entidad Piso (PP-PI),
y con el tipo de entidad CasaParticular (PP-CP), puesto que una persona puede ser propietaria de

3Es evidente que entre las personas consideradas en este problema existir un gran numero de ellas que carezcan de
documento nacional de identidad (los menores de edad), por lo que se puede pensar que no es adecuado tomar este
atributo como identificador principal. La eleccin se ha realizado simplemente para no aadir una mayor complejidad a
este ejercicio.
Henry George Maquera Quispe
Gestin de Base de Datos 24

cualquier tipo de vivienda. Como se ha considerado que una vivienda solo puede ser propiedad de una
y solo una persona, el tipo de entidad Persona participa en estos tipos de interrelacin con las
cardinalidades (1,1) (Supuesto 2). Por otro lado, una persona puede ser propietaria de ninguna, una o
varias viviendas, por lo que los tipos de entidad CasaParticular y Piso participan con la cardinalidad
(0,n).

Tipo de interrelacin Piso/BloqueCasas (P-BC). El cual representa a los pisos que existen en cada
uno de los bloques de casas. Se considera que un bloque de casas esta formado por dos o mas pisos,
por lo que el tipo de entidad Piso interviene en este tipo de interrelacin con las cardinalidades (2,n),
mientras que un piso solo se encuentra ubicado en un bloque de casas, interviniendo el tipo de entidad
BloqueCasas con las cardinalidades (1,1) (Supuesto 7).

Tipo de interrelacin Persona/Persona (PP-PP). El cual representa la relacin existente entre cada
persona con su cabeza de familia. Se trata de un tipo de interrelacin reflexiva en la que, por un lado,
una persona puede ser cabeza de familia de una o varias personas (cada persona es al menos cabeza
de familia de una persona, ella misma) cardinalidad (1,n) mientras que, por otro lado, una persona
solo tiene como cabeza de familia a una y solo una persona - cardinalidad (1,1) -. Por tanto, y como se
muestra en la figura 4.10, se trata de una relacin reflexiva 1:N entre el tipo de entidad Persona con el
mismo.

Este tipo de interrelacin tiene su razn de ser en base al enunciado del problema en el cual se indica
que es de inters el conocimiento de la relacin familiar de las personas que habitan en la misma o
distinta vivienda (Supuesto 6).

Nombre_zona od_zona calle numero Codigo_postal


1:N
metros
(1,1) (0,n)
ZonaUrbana
estan_en
EX Z-V
existen
Vivienda
Vivienda
od_vivienda
(1,1)

tiene se_encuentra_en Es_Un Tipo_vivienda


P-BC ID
numero (2,n) (1,1) (0,1) (0,1)
escalera
(0,n)
calle Vivienda
Piso planta BloqueCasas CasaParticular
puerta
(0,n) (0,1) metros_p (0,1)
od_piso metros_b od_bloque metros_c od_casa habita_en

habita_en
N:1 es_habitada_por
PP-C
PP-P dni nombre_persona
apellidos_persona N:1
(0,n) od_persona
es_habitada_por es_habitada_por
(0,n)
(1,1) Persona (1,1)
PP-PI PP-CF
es_propietario_de es_propiedad (1,1) (1,n) es_propiedad es_propietario_de
1:N 1:N 1:N
es_familiar_de es_cabeza_de_familia_de
PP-PP

Figura 4.10. Propuesta de solucin al problema dado

Henry George Maquera Quispe

Вам также может понравиться