Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema...

39
Tema 2 Diseño de bases de datos (E.T.S.I.A. y F.I.) Diseño conceptual de sistemas de información con el Modelo Entidad-Relación septiembre, 2006

Transcript of Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema...

Page 1: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Tema 2

Diseño de bases de datos

(E.T.S.I.A. y F.I.)

Diseño conceptual de sistemas de

información con el Modelo

Entidad-Relación

septiembre, 2006

Page 2: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

1 Introducción .......................................................................................................................................................... 1

2 Modelo Entidad-Relación .................................................................................................................................... 1

2.1 Entidad............................................................................................................................................................. 1

2.2 Relación ...........................................................................................................................................................2

2.3 Atributo ..........................................................................................................................................................3

2.4 Restricciones de integridad .......................................................................................................................4

2.5 Entidades compuestas ............................................................................................................................... 10

2.6 Generalización/Especialización.................................................................................................................11

2.7 Resumen de los diagramas del modelo Entidad-Relación ................................................................... 12

3 Obtención del diagrama Entidad-Relación.................................................................................................... 13

3.1 Identificar entidades y atributos ........................................................................................................... 13

3.2 Identificar generalizaciones/especializaciones................................................................................... 14

3.3 Identificar relaciones entre entidades ................................................................................................. 17

3.4 Identificar entidades débiles................................................................................................................. 23

3.5 Identificar objetos agregados ............................................................................................................... 23

3.6 Especificar restricciones de integridad............................................................................................... 23

4 Diseño de transacciones .................................................................................................................................. 23

5 Enfoques para el diseño de bases de datos complejas ............................................................................. 29

5.1 Integración de vistas................................................................................................................................. 29

6 Cuestiones sobre diseño conceptual ............................................................................................................. 33

7 Bibliografía ......................................................................................................................................................... 37

Page 3: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

1 INTRODUCCIÓN

Como ya se ha introducido en el tema 1, el diseño conceptual es la fase del diseño de una base de datos cuyo objetivo es “obtener una representación de la realidad que capture las propiedades estáticas y dinámicas de la misma que son necesarias para satisfacer los requisitos; esta representación debe suponer una imagen fiel del comportamiento del mundo real”.

Los modelos de datos conceptuales son las herramientas que se utilizan para realizar este diseño. En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología de diseño con él. La versión que se presenta del Modelo Entidad-Relación, ER a partir de ahora, es una de las muchas propuestas que se han hecho sobre el modelo original de Peter Pin-Shan Chen [Chen76], extendido con nuevas características. Hay que destacar que algunas de las extensiones que se pueden encontrar de este modelo incluyen un lenguaje para la representación de las propiedades dinámicas2, sin embargo, en este tema estas propiedades serán tratadas de manera informal posponiendo su especificación a la fase de diseño lógico.

2 MODELO ENTIDAD-RELACIÓN

El modelo ER permite representar, en lo que se llama diagrama ER, las estructuras que constituyen el contenido del sistema de información junto con restricciones de distintos tipos que limitan las ocurrencias válidas de las mismas. Para ello hace uso, fundamentalmente, de tres conceptos: entidad, atributo y relación. Además, para aumentar la capacidad expresiva del modelo también se contempla la definición de objetos compuestos mediante la agregación de entidades y la definición de objetos especializados (o generalizados). Todos estos conceptos se presentan a continuación con detalle.

2.1 Entidad La observación de la realidad permite detectar el conjunto de “objetos” (físicos o conceptuales) de

los que se quiere almacenar información para, mediante el uso de la clasificación, que es uno de los mecanismos de abstracción más primario que existen, descubrir el conjunto de “clases de objetos” (o tipos de objetos) que son de interés para la organización. Este mecanismo de abstracción, que es utilizado la mayor parte de las veces de forma inconsciente, permite no prestar atención a las ocurrencias concretas sino al conjunto de ocurrencias.

Ejemplo 1 Mundo real Modelo de la realidad

CLASIFICACIÓN

PERSONA

COCHE

Así pues, los componentes básicos de un sistema de información son los objetos o entidades de los

1 También llamado Entidad-Vínculo, del original en inglés Entity-Relationship. 2 Versiones anteriores de estos apuntes incluían un lenguaje de este tipo.

Diseño de bases de datos 26/09/2006 1

Page 4: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

que se quiere almacenar información; todos los objetos que son de la misma clase se representan con un tipo de entidad, aunque, por simplicidad, en adelante se hará referencia a él como entidad utilizando la expresión ocurrencia de entidad para hacer referencia a un objeto concreto de ese tipo.

Con una entidad se representará cualquier persona, concepto, suceso o evento (en definitiva cualquier “cosa”) sobre el que se quiera almacenar información.

En el modelo ER una entidad se representa con un rectángulo nominado.

Ejemplo 2 El siguiente diagrama representa al objeto de información Alumno.

Alumno

2.2 Relación Los objetos de un sistema de información se asocian unos con otros, siendo también de interés

modelar estas conexiones; para ello se utilizarán los tipos de relaciones o por simplicidad relaciones. Con las relaciones se representan las posibles asociaciones existentes entre los objetos del sistema de información. Cada ocurrencia de una relación asocia una ocurrencia de cada uno de los objetos relacionados.

En el modelo ER una relación se representa con un rombo nominado unido por un arco a cada una de las entidades que representan a los objetos asociados. Según el número de entidades asociadas, se habla de relaciones binarias, ternarias, etc. Si una entidad participa más de una vez en una relación se dice que ésta es reflexiva.

Ejemplo 3 Los siguientes diagramas representan algunas relaciones posibles.

Relación binaria:

Matrícula Alumno Asignatura

Relación ternaria:

Profesor AsignaturaDocencia

Grupo

Relación binaria reflexiva:

responsable

Alumno Equipo

colaborador

Los arcos que unen las entidades a la relación siempre pueden ser nominados indicando el papel que la entidad juega en la relación. En el caso de las relaciones reflexivas deben ser nominados

Diseño de bases de datos 26/09/2006 2

Page 5: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

necesariamente.

2.3 Atributo Los atributos permiten representar las propiedades de los objetos del sistema de información así

como de las asociaciones entre ellos.

En el modelo ER los atributos se representan con elipses nominadas unidas por un arco a la entidad o relación a la que describen.

Ejemplo 4 Nombre Alumno

Los atributos pueden clasificarse según varios criterios. Desde el punto de vista de su estructura

los atributos pueden ser de dos tipos:

• Simple: toma valores indivisibles.

• Compuesto o estructurado: los valores se componen de otros valores (que pueden ser de cualquier tipo). Este caso se representa uniendo con arcos las elipses de los atributos con las elipses de los atributos que lo componen.

Ejemplo 5

Calle

Dirección Domicilio

Número Ciudad

Según el número máximo de valores que puede tomar el atributo para cada ocurrencia de entidad o

de relación, se dice que el atributo es:

• Monovaluado: toma un valor como máximo.

• Multivaluado: puede tomar n valores como máximo. Se representa etiquetando el arco con una n (o con una constante numérica si el máximo está limitado).

Ejemplo 6

Zona_ventaVendedorn

Dependiendo del tipo de información que representa, el atributo es:

• Básico: información que debe almacenarse.

• Derivado: información que puede obtenerse a partir de otra información. Se representa con una elipse de trazos discontinuos.

Ejemplo 7

Edad

Fecha_nac Alumno

Diseño de bases de datos 26/09/2006 3

Page 6: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

2.4 Restricciones de integridad Para dar mayor capacidad expresiva al modelo ER, la definición de entidades y relaciones puede

enriquecerse con la inclusión de algunas restricciones que limitan el conjunto de ocurrencias válidas. Estas restricciones se pueden definir sobre atributos, sobre entidades y sobre relaciones.

2.4.1 Restricciones sobre atributos Restricciones de dominio

Estas restricciones limitan el conjunto de valores que puede tomar un atributo. Para ello se definen dominios como tipos de datos que se asocian a cada atributo. En el caso de los atributos derivados se debe incluir cómo se calculan.

Ejemplo 8

Nombre Alumno Edad

Fecha_nac

dom_nombre: Cadena(50) Nombre: dom_nombre Edad: A partir de la fecha de nacimiento y de la fecha actual, calcular los años del

alumno.

Restricción de valor no nulo

Esta restricción se define sobre aquellos atributos que necesariamente deben tener un valor para cada ocurrencia de la entidad o de la relación que describen. Se representa con un círculo pequeño sobre el extremo del arco que se une a la elipse e indica que ese atributo deberá tomar siempre valor para cada ocurrencia de la entidad o relación que cualifica.

Ejemplo 9 Fecha_nac

En el caso en que un atributo compuesto tenga restricción de valor no nulo, al menos alguno de sus

componentes debe tener la misma restricción.

Ejemplo 10

Dirección

Domicilio Calle

NúmeroCiudad

2.4.2 Restricciones sobre entidades Estas restricciones limitan el conjunto de ocurrencias posibles de una entidad. Se distinguen las de

unicidad y las de identificación.

Restricción de unicidad

Representa el hecho de que las distintas ocurrencias de una entidad deben tomar valores distintos para el atributo (o conjunto de atributos) sobre los que se define esta restricción. Se representa

Diseño de bases de datos 26/09/2006 4

Page 7: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

subrayando los atributos con una línea discontinua. En el caso de que haya varios conjuntos de atributos con restricción de unicidad, se añade un subíndice a la línea del subrayado.

Ejemplo 11

Empleado NSS1DNI2

Restricción de identificación

Esta restricción exige que cada ocurrencia de una entidad se identifique unívocamente de forma que se pueda diferenciar del resto de ocurrencias del mismo tipo. Esta identificación se puede conseguir de tres formas:

• Con la definición de un identificador. Un identificador es un conjunto de atributos con restricción de unicidad y de valor no nulo y se representa subrayando con una línea continua estos atributos. En una entidad sólo puede haber, como mucho, un identificador3.

• Definiendo la entidad como débil.

• Definiendo la entidad como especializada.

Estos dos últimos casos se verán más adelante.

Ejemplo 12

Empleado Num-emp

2.4.3 Restricciones sobre relaciones Restricción de unicidad

Al igual que en el caso de las entidades, esta restricción representa el hecho de que las distintas ocurrencias de una relación deben tomar valores distintos para el atributo (o conjunto de atributos) sobre los que se define esta restricción. También se representa subrayando los atributos con una línea discontinua. En el caso de que haya varios conjuntos de atributos con restricción de unicidad, se añade un subíndice a la línea del subrayado.

Restricciones de cardinalidad

Estas restricciones limitan el número mínimo y máximo de ocurrencias de una relación en las que puede participar una ocurrencia de entidad. Por simplicidad se estudiará primero el caso de las relaciones binarias, para generalizarlo luego a relaciones de orden superior.

Sea la relación binaria R definida entre las entidades A y B. El conjunto de ocurrencias posibles de la relación es un conjunto, llamado también R, tal que R ⊆ A × B. Las cardinalidades de A y B en la relación R se expresan por R(A(minA, maxA), B(minB, maxB)), que significa que:

• Cada ocurrencia de A se relaciona a través de R con n ocurrencias de B tal que minA ≤ n ≤maxA.

• Cada ocurrencia de B se relaciona a través de R con n ocurrencias de A tal que minB ≤ n ≤maxB.

Los valores más significativos de la cardinalidad máxima de una relación son:

• maxA = 1 → significa que cada ocurrencia de A sólo puede aparecer en una ocurrencia de R.

3 A los atributos que forman parte del identificador se les suele llamar “atributos identificadores”.

Diseño de bases de datos 26/09/2006 5

Page 8: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 6

• maxA = n (n > 1) → significa que cada ocurrencia de A puede aparecer como máximo en n ocurrencias de R (n indica que no existe un límite máximo; se puede instanciar a una constante entera, en cuyo caso representa un máximo limitado).

Habitualmente esta cardinalidad máxima se usa para calificar las relaciones, utilizándose la notación siguiente: maxA:maxB obteniéndose como casos más frecuentes las expresiones 1:1 (leída uno a uno), 1:M (leída uno a muchos) y M:M (leída muchos a muchos).

Los valores más significativos de la cardinalidad mínima son:

• minA = 0 → significa que la participación de cada ocurrencia de A en R es opcional.

• minA= n (n ≥ 1) → significa que la participación de cada ocurrencia de A en R es obligatoria n veces (aquí n siempre debe estar instanciado a una constante). En este caso se dice que la entidad A sufre una restricción de existencia respecto a R.

Ejemplo 13 En el contexto de una universidad, un alumno siempre pertenece a un centro y nada más que uno.

Matricula(Alumno(1,1),Centro(0,n))

A continuación se presenta el caso más general de relaciones de grado mayor que 2 (n-arias)

Sea R una relación n-aria (n > 2) definida sobre las entidades A1, A2, …, An. El conjunto de ocurrencias posibles de R es R ⊆ A1 × A2 × … × An. Sean A y B dos subconjuntos disjuntos del conjunto de entidades {A1, A2, … , An} tales que A ∪ B = {A1, A2,…, An}. Las cardinalidades se representan, para cada par de subconjuntos A y B que se puedan formar, con la expresión siguiente:

R(A(minA, maxA), B(minB, maxB))

Que significa que:

• Cada ocurrencia del conjunto de entidades A puede estar relacionada a través de R con n ocurrencias del conjunto de entidades B siendo minA ≤ n ≤ maxA.

• Cada ocurrencia del conjunto de entidades B puede estar relacionada a través de R con n ocurrencias del conjunto de entidades A siendo minB ≤ n ≤ maxB.

En el modelo ER no se pueden representar todas estas cardinalidades4:

• Cardinalidad mínima: sólo se puede expresar la cardinalidad mínima de cada entidad respecto a la relación. Esta cardinalidad mínima sólo puede ser 0 ó 1, definiendo esta última una restricción de existencia. Esta restricción de existencia se representa con una doble línea en el arco que une la relación a la entidad que tiene la restricción de existencia.

• Cardinalidad máxima: sólo se puede expresar la cardinalidad máxima de cada conjunto de n − 1 entidades respecto a la relación; estas cardinalidades se indican mediante una etiqueta con el valor de la cardinalidad en el arco que une entidad restante a la relación. Obsérvese que en el caso de relaciones binarias al se n = 2 se pueden representar todas las cardinalidades máximas.

4 Hay una alternativa para no perder expresividad en la representación, que consiste en trasladar al arco que une

la entidad y la relación los pares de valores que expresan la cardinalidad de esa entidad frente al resto de entidades. El inconveniente de esta variante es que es menos legible a primera vista, pero no cabe duda de que es más completa. Hemos elegido la otra por sencillez y porque permite representar los casos más frecuentes.

Page 9: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Ejemplo 14

Num_exp

Alumno Centro Matricula n 1

Código

Matricula(Alumno(1,1),Centro(0,n))

En el caso de relaciones de grado mayor que 2, para las cardinalidades que no se representan en el

diagrama, se supondrán los valores menos restrictivos, es decir 0 para las mínimas y n para las máximas, cualquier otro valor deberá ser especificado en una restricción añadida al esquema.

Ejemplo 15

Docencia

n

n 1

DNI Cod

Num

Asignatura

Grupo

Profesor

Docencia(Profesor(0,n),Asignatura-Grupo(1,1))

Docencia(Grupo(1,n), Profesor-Asignatura (0,n))

Docencia(Asignatura (1,n), Profesor-Grupo(0,n))

En este ejemplo las cardinalidades destacadas en negrita no se han representado. De todas ellas sólo se pierde la información de la cardinalidad minAsignatura-Grupo, que es 1 porque supone una restricción de existencia sobre el par Asignatura-Grupo que no tiene representación en el modelo; las demás tienen los valores que se asumen por defecto.

Restricción de identificación

Cada ocurrencia de una relación debe poder distinguirse de las demás, pero en una relación no se definen identificadores; esto último se debe a que no es necesario, ya que no puede haber dos ocurrencias de una relación en las que participen exactamente las mismas ocurrencias de las entidades implicadas y, por lo tanto, cada ocurrencia de relación se puede distinguir de las demás por medio del valor de los identificadores de las ocurrencias de entidades que la constituyen. Según la cardinalidad de las relaciones harán falta, para identificar una ocurrencia de relación, todos o sólo algunos de los identificadores de las ocurrencias de entidades que la constituyen.

Ejemplo 16 En el diagrama mostrado en el Ejemplo 14, para distinguir una ocurrencia de la relación Matricula basta con referirse al Num_exp del Alumno, puesto que cada alumno sólo puede aparecer una vez en la relación, y en el diagrama del Ejemplo 15, cada ocurrencia de la relación Docencia estará perfectamente identificada por los atributos Num de Grupo y Cod de Asignatura5.

5 Se deja como ejercicio deducir qué identificadores son necesarios en relaciones con otras cardinalidades.

Diseño de bases de datos 26/09/2006 7

Page 10: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Restricción de dependencia de identificación

Una entidad sufre restricción de dependencia de identificación cuando no puede identificarse con sus propios atributos de manera que sus ocurrencias son distinguibles gracias a su relación con otras entidades. A este tipo de entidades se les denomina entidades débiles. Esta restricción implica siempre una restricción de existencia.

Esta restricción de dependencia de identificación se representa utilizando una línea doble para la entidad débil y para la relación o relaciones de las que depende para su identificación, así como para el arco que las une.

En el esquema siguiente se muestra el patrón de una entidad débil en el caso de que se identifique con una sola relación; en la figura hay dos cardinalidades (las de A) que no se han especificado (indicado mediante un interrogante) ya que cualquier valor es posible.

?

a0

A BR1 ?

bnb0an ……

El hecho de que B sea una entidad débil supone que pueden existir varias ocurrencias con el mismo

valor para el atributo b0, pero cada una de ellas se relaciona obligatoriamente con una ocurrencia de A distinta, que sirve para identificarla.

Los interrogantes en el diagrama representan que las cardinalidades máxima y mínima de A pueden ser cualesquiera, 1 ó n para la máxima y 0 ó 1 para la mínima. Los casos más frecuentes se ilustran a continuación6:

• Caso 1: R(A(?, n), B(1,1)). En este caso, dado que una ocurrencia de A se puede relacionar con muchas ocurrencias de B, es necesaria la existencia de un atributo “semiidentificador” de B (b0) que ayude a distinguir entre todas las ocurrencias de B que se relacionan con la misma ocurrencia de A. (Ver el Ejemplo 17).

Ejemplo 17

nom_país

País CiudadEstá_en1 n

alcaldenom_ciurenta ……

Está_en(País(O,n), Ciudad(1,1))

La entidad Ciudad es débil ya que en la organización (información geográfica mundial) que se está modelando puede haber varias ciudades con el mismo nombre aunque evidentemente siempre en distintos países; entonces ¿cómo se distingue una ciudad de otra?. En primer lugar por el país al que pertenecen y en un mismo país por el atributo nom_ciu necesario en este caso ya que en un país puede haber muchas ciudades7.

6 Sólo se presentan los casos posibles respecto a la cardinalidad máxima de A, los otros no revisten especial

interés. 7 A la entidad País se le podría haber definido una restricción de existencia si no se quiere contemplar la

posibilidad de tener información de países sin tener información al menos de una de sus ciudades.

Diseño de bases de datos 26/09/2006 8

Page 11: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

• Caso 2: R(A(?, 1), B(1,1)). En este caso, dado que una ocurrencia de A como mucho se relaciona con una de B, no es necesaria la existencia de un atributo “semiidentificador” ya que en realidad cada ocurrencia de B se identifica gracias a la ocurrencia de A con la que se relaciona. (Ver el Ejemplo 18).

Ejemplo 18 Este caso no es muy frecuente por lo que el ejemplo requiere cierta explicación: “Una organización tiene informatizados los expedientes jurídicos de todos los pleitos en los que está involucrada; de cada pleito, entre otras informaciones, se conoce el número de pleito y el resultado de la sentencia que puede ser favorable o desfavorable. En caso de ser desfavorable se puede presentar como mucho un recurso ante el mismo órgano jurisdiccional; cada recurso se identifica por el número de pleito al que atañe y entre otros atributos interesa saber en qué fecha se realiza”

número

Pleito RecursoRecurrir1 1

fecharesultado ……

Recurrir(Pleito(0,1), Recurso(1,1))

Dado que un pleito se puede recurrir como mucho una vez, para distinguir un recurso de otro sólo se necesita saber qué pleito se está recurriendo no siendo necesario en este caso un atributo de la entidad recurso que ayude a distinguirlos8.

Resumiendo, las entidades débiles son aquéllas para las que no existe un identificador como se ha definido antes, sino que para distinguir entre sus ocurrencias es necesario utilizar una (o más de una) de sus relaciones siendo en ocasiones necesario la existencia de un atributo (o conjunto de atributos) llamado semiidentificador. Es decir, los tipos de entidades débiles tienen restricción de identificación respecto a una o más relaciones con otras entidades; para poder identificar cada ocurrencia de una entidad débil hacen falta los identificadores de dichas entidades.

En el caso de que la entidad se identifique gracias a varias relaciones con otras entidades, las cardinalidades máximas de todas estas entidades deben ser n siendo necesario un semiidentificador en la entidad débil (piénsese que si hay alguna relación con una entidad con cardinalidad máxima igual a 1, esa relación bastaría para identificar a la entidad débil incluso sin semiidentificador).

Ejemplo 19 Supónganse que se quiere almacenar información sobre las notas que han obtenido los alumnos en distintas asignaturas teniendo en cuenta que un alumno se puede presentar varias veces a una asignatura, pero en fechas distintas, y que los exámenes no están codificados. Una posible forma de identificar cada examen es sabiendo qué alumno lo ha hecho, de qué asignatura es y en qué fecha se realizó la prueba (para distinguir los exámenes del mismo alumno en la misma asignatura). El esquema que muestra esta solución es el siguiente.

8 Este caso admite otras soluciones.

Diseño de bases de datos 26/09/2006 9

Page 12: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

nombre

DNI

nombre

código

Hacer

1

Alumno Asignatura

fecha nota

Ser

Examen n n

1

2.4.4 Otras restricciones Hay que tener en cuenta que, dada la diversidad y complejidad de los sistemas de información que

se van a considerar, a menudo para representar la realidad no serán suficientes las restricciones presentadas en los apartados anteriores lo que obligará a completar el diagrama con un conjunto de restricciones de integridad explícitas que se expresarán lo más claramente posible en lenguaje natural en un anexo al diagrama (que también debe incluir la definición de los dominios).

Ejemplo 20 Sea el siguiente diagrama:

nombre

Alumno AsignaturaMatrícula

práctica

curso dni

estudios

n n

fecha código

Para completar la realidad expresada en el diagrama anterior se debe incluir el siguiente anexo.

ANEXO:

Restricciones de dominios: Definición de dominios: Estudios: dom_estudios dom_estudios: ('COU', 'FP', 'otros') Dni: dom_dni dom_dni: tira (10) … …

Curso: dom_curso dom_curso: 1..3

Restricciones de integridad:

Todo alumno con estudios de COU debe estar matriculado en un curso completo (1º, 2º ó 3º).

2.5 Entidades compuestas Cuando la relación que vincula dos o más entidades tiene a su vez características de entidad, de

manera que se relaciona como tal con otras entidades, se aplica el concepto de agregación. Este mecanismo sirve para expresar que las ocurrencias de la relación agregada se comportan también como entidades. Para ello, se engloba el símbolo de la relación con un rectángulo, lo que denota que esa relación es un objeto agregado.

Ejemplo 21 En el contexto de un centro docente en el que se quiere saber cada alumno a qué grupo acude

Diseño de bases de datos 26/09/2006 10

Page 13: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

para estudiar las distintas asignaturas:

n

Acude

Alumno

Grupo Incluye Asignatura n n

n

Las entidades agregadas nunca son débiles ni tienen identificador ya que heredan la identificación

de la relación que las define. Sin embargo sí que pueden tener atributos con restricción de unicidad o valor no nulo. También pueden sufrir restricciones de existencia.

2.6 Generalización/Especialización Cuando se detecta que entre distintas entidades definidas en el esquema existe una relación de

inclusión (esto es, que todas las ocurrencias de una entidad son a su vez ocurrencia de otra más general), este hecho se expresa por medio de la Generalización/Especialización. Esto significa que la entidad más general se especializa en una o varias entidades especializadas o subclases, o dicho a la inversa, que una o varias entidades se generalizan en una clase general o superclase. Este proceso se puede repetir a distintos niveles, siendo posible que una entidad tenga más de una superclase, siempre que la clase más general del conjunto sea única. La clase más general será además la única que tenga identificador. Todas las subclases de una clase tienen, además de sus atributos propios, todos los atributos de sus superclases (en cualquier nivel), aunque no se representan en el diagrama.

Una entidad puede participar en distintas Generalizaciones/Especializaciones que se definen atendiendo a criterios distintos. El criterio se puede indicar al lado del arco.

La especialización de una entidad en varias subclases puede ser total (T) con lo que todas sus ocurrencias deben participar en alguna subclase, o parcial (P) en caso contrario. También tendrá la propiedad de ser solapada (S) si una ocurrencia de la entidad puede pertenecer a distintas subclases a la vez, o disjunta (D) en caso contrario.

La especialización se representa uniendo todas las entidades especializadas según un criterio con la entidad general a través de un círculo en el que se indicará las propiedades de la Generalización/ Especialización.

En el caso de que sólo haya una subclase, se une a la entidad general con un arco, y no hace falta el círculo; la justificación es que al haber una sola entidad especializada la participación de las ocurrencias de la entidad general en ella será necesariamente parcial (pues si fuera total la entidad general y la especializada serían idénticas), y no se pueden aplicar los conceptos de disjunta o solapada ya que hacen referencia a más de una subclase.

Ejemplo 22 En el siguiente diagrama ER se expresa que los empleados de una empresa pueden especializarse según tres criterios: según el cuerpo al que pertenece, según sea o no gerente y según el tipo de contrato que tiene.

Diseño de bases de datos 26/09/2006 11

Page 14: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

DNI

P,D

nSS

T,D

Administrativo Técnico Ingeniero Gerente Asalariado Por_horas

Empleado Contrato Cuerpo

2.7 Resumen de los diagramas del modelo Entidad-Relación En el siguiente cuadro se muestran todos los símbolos utilizados en los diagramas ER.

Entidad

Entidad débil

Relación

Relación de identificación

Atributo

Atributo identificador

Atributo único

Atributo no nulo

Atributo derivado

n Atributo multivaluado

n n Cardinalidades

… Atributo estructurado

Agregación

Generalización

Diseño de bases de datos 26/09/2006 12

Page 15: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 13

3 OBTENCIÓN DEL DIAGRAMA ENTIDAD-RELACIÓN

El objetivo fundamental de este apartado es enseñar cómo se puede abordar la tarea del diseño conceptual de las propiedades estáticas de un sistema de información utilizando el modelo ER presentado, es decir, proponer una metodología de diseño así como destacar puntos conflictivos que pueden aparecer en el desarrollo de un sistema de información.

Para obtener un diagrama adecuado y fiable a partir del análisis de la realidad y de los reque-rimientos de la organización hay que realizar las siguientes actividades:

• Identificar tipos de entidad y atributos,

• Identificar generalizaciones/especializaciones,

• Identificar tipos de relación entre tipos de entidades,

• Identificar tipos de entidad débiles,

• Identificar agregaciones, y

• Especificar restricciones de integridad.

Estas actividades se realizan de forma iterativa hasta conseguir definir un diagrama ER lo más fiel posible a la realidad y en el cual el conjunto de restricciones de integridad explícitas incluidas en el anexo al diagrama sea lo más pequeño posible. A continuación se comentan todas ellas.

3.1 Identificar entidades y atributos Por cada tipo de objeto de la realidad, una vez concretada la información descriptiva que se desea

almacenar, se definirá una entidad9 en el diagrama. Una entidad viene definida por un conjunto de atributos que representan la información que se desea conocer de cada tipo de objeto. Para cada atributo se debe:

• Asociar un dominio o, si es derivado, especificar la forma de derivación; e

• Incluir un pequeño círculo en el arco que lo une a la entidad en el caso de que el atributo tenga restricción de valor no nulo.

De entre estos atributos, si es posible, se destacarán los atributos del identificador; si no existe identificador, la entidad debe ser considerada débil y habrá que decidir, cuando se estudien las relaciones, sobre cuál o cuáles se apoya para identificarse.

COMENTARIOS:

• En un diagrama ER todas las entidades tienen identificador o bien son débiles o especializaciones.

• Los nombres de las entidades y de las relaciones en un diagrama ER son únicos

• Los nombres de atributos en una entidad o en una relación son únicos.

(Nota: A lo largo de este apartado, con estos comentarios se pretende avisar al alumno de ciertos

9Recuérdese que por comodidad, a lo largo de todo este documento con los términos entidad y relación se hace

referencia a tipo de entidad y tipo de relación respectivamente. Cuando se quiere hacer referencia a una entidad o a una relación concreta se indica mediante el uso de la expresión ocurrencia de entidad u ocurrencia de relación respectivamente. Este abuso del lenguaje es habitual, pero no supone confusión ya que por el contexto se puede deducir si el comentario se refiere al tipo de entidad o de relación o bien a un individuo concreto de esos tipos.

Page 16: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

detalles que pueden ayudarle a definir un diagrama correcto al menos sintácticamente).

No hay que pensar en que antes de avanzar en el diseño hay que definir un conjunto de entidades que sea fijo, sino que éste puede cambiar a medida que se tomen ciertas decisiones de diseño. Por ejemplo es posible que algunos atributos inicialmente considerados desaparezcan luego y se conviertan en entidades como se ilustra en el Ejemplo 23:

Ejemplo 23 Sea una entidad con dos atributos entre los que se detecta una dependencia, ya que el atributo provincia representa en qué provincia nació el jefe del proyecto:

nombre

Proyectojefe ycod

provincia

En el siguiente diagrama se decide considerar el atributo jefe como una entidad, representado correctamente la dependencia anterior.

Responsable

nombre

Jefe Proyecto1 n

nombreycodprovincia

3.2 Identificar generalizaciones/especializaciones La especialización es el proceso por el que se clasifica una clase de objetos en subclases más

especializadas. La generalización es el proceso inverso por el que se generalizan varias clases para obtener una abstracta de más alto nivel que incluya los objetos de todas estas clases. La especialización es un refinamiento conceptual mientras que la generalización es una síntesis conceptual.

Se pueden distinguir tres procesos mentales que pueden conducir a definir una generalización/ especialización.

1) Estrategia descendente (especialización): en el conjunto de ocurrencias de una entidad, se pueden definir subconjuntos con propiedades estáticas (atributos) o de comportamiento (relaciones) distintas.

Ejemplo 24 En el contexto de una agencia de viajes se ha diseñado el siguiente diagrama:

Pertenece

nombre

Cliente Empresa n 1

nombre cif guía

dni

país n

Más tarde se detecta que hay dos clases de clientes: los turistas, a los que siempre se asignará un guía; y los viajantes de negocios, que siempre pertenecen a una empresa y de los que interesa conocer los países que suelen visitar; entonces, una solución más adecuada al problema sería la siguiente:

Diseño de bases de datos 26/09/2006 14

Page 17: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Pertenece Viajante Empresa n 1

nombre cif

país n

nombre

Cliente dni

Turista

guía

T,S

2) Estrategia ascendente (generalización): existe en el esquema un conjunto de entidades con algunas propiedades similares y que en la realidad se podrían clasificar en un objeto común.

Ejemplo 25 En el siguiente diagrama se han definido dos entidades independientes con algunos atributos comunes.

nombre

Secretariopulsaciones dni

idioma nombre

Técnicodni

categoría

Si además se observa que ambas entidades se refieren a trabajadores de la empresa que para algunos procesos conviene tener juntos, sería más correcto considerar una entidad general Empleado:

idioma

Secretariopulsaciones Técnico

categoría

nombreEmpleadodni

P,D

3) Jerarquía: se detecta una relación de inclusión entre entidades previamente definidas.

Ejemplo 26 En el contexto de una escuela universitaria, supóngase que se han definido dos entidades:

nombre

Alumnoespecialidad

exp nombre

Proyectanteexp

especialidad

títulodirector

Diseño de bases de datos 26/09/2006 15

Page 18: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Pero si se tiene en cuenta que todo proyectante es también un alumno, la solución más adecuada sería (recuérdese que cuando sólo hay una entidad especializada no es necesario dibujar el círculo de la generalización):

nombre

Alumno especialidad

exp

Proyectante

título director

Como se puede observar en los ejemplos, en cualquiera de estos casos se ha definido una ge-neralización/especialización de manera que los atributos identificadores y los descriptores que son comunes a todas las entidades estén en la entidad general, quedándose los atributos específicos y las relaciones específicas en cada una de las entidades especializadas.

Hay que darse cuenta de que la generalización/especialización no debe definirse por los nombres que puedan tener los atributos sino cuando realmente exista entre los objetos la relación de subclase que implica este concepto. Por otra parte, una generalización/especialización en la que las entidades especializadas no tienen propiedades distintivas (atributos o relaciones) no resulta muy útil pudiéndose representar la misma información y de forma más sencilla con un atributo discriminador en la entidad general (esta idea se ilustra en el Ejemplo 27).

Ejemplo 27 Supóngase que interesa saber si los libros de una biblioteca están escritos en español o en otros idiomas. Un diseño como el siguiente:

Español No-Español

títulolibrocod

T,D

es demasiado complicado si la única diferencia entre los libros es el idioma en el que están escritos. Se puede expresar lo mismo con el siguiente diagrama que por otra parte resulta mucho más sencillo:

español

títulolibrocod

español: dom_lógico (sí/no)

Por último, para terminar con este apartado, no hay que olvidar indicar qué tipo de generalización/especialización se está definiendo, especificando si es total o parcial y disjunta o

Diseño de bases de datos 26/09/2006 16

Page 19: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

solapada.

COMENTARIOS: • Las entidades especializadas nunca tienen identificador ni son débiles ya que heredan

la identificación de su entidad general.

3.3 Identificar relaciones entre entidades Una vez definido un conjunto inicial de entidades que, como ya se ha comentado, podrá ser

reconsiderado a lo largo del todo el diseño, hay que estudiar las relaciones (o vínculos) existentes entre ellas, ya que raramente existirán entidades sin conexiones con otras. Para definir una relación hay que especificar:

• Entidades implicadas,

• Cardinalidades máximas y mínimas aunque no todas son representables, y

• Atributos propios de la relación (con sus restricciones si las tienen).

Para la definición de un conjunto de relaciones adecuado es importante tener en cuenta las si-guientes indicaciones:

1) Las cardinalidades máximas y mínimas que se puedan expresar se indicarán con las etiquetas 1 y n (las máximas) y con la definición de restricciones de existencia (las mínimas). Ante la duda se recomienda elegir las cardinalidades menos restrictivas (0 para la mínima y n para la máxima).

2) Las relaciones redundantes deben ser eliminadas. Dos o más relaciones se consideran redundantes si representan el mismo concepto; sin embargo, hay que darse cuenta de que entre las mismas entidades se pueden definir más de una relación siempre que tengan significados diferentes.

Ejemplo 28 En el siguiente diagrama, aunque con nombres diferentes, se han definido dos relaciones que representan la misma información por lo que una debería eliminarse:

nombre

Proveedordirección

dni código

Pieza

color

pesoVende

Suministrann

nn

Sin embargo, pueden existir dos relaciones definidas sobre las mismas entidades pero con significados completamente distintos:

n

precio

Vuelo

nºvuelo nombre

Ciudad

paísDespega

Aterriza1

1n

3) Eliminar la redundancia que se deriva de dependencias transitivas

Diseño de bases de datos 26/09/2006 17

Page 20: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Ejemplo 29 En el siguiente diagrama se han definido tres relaciones:

habitantes

nombre

código

nombre

dir_ayunt

Pertenece

Es_de1

1

n

n

ComunidadAutónoma

nombre

Provincia Ciudad

Está_en

n

1

La relación Está_en es redundante ya que sus ocurrencias se pueden derivar a partir de Pertenece y Es_de (una ciudad está en la comunidad a la que pertenece su provincia); por ello debería ser eliminada.

habitantes

nombre

código

nombre

dir_ayunt

Pertenece

Es_de1

1

n

n

ComunidadAutónoma

nombre

Provincia Ciudad

Sin embargo, no siempre es posible eliminar la redundancia como se muestra en el Ejemplo 30.

Ejemplo 30

1 1Responsa-ble

teléfono

nombre

dni

nombre

código

Pertenece

1

n

Departa-mento

nombre

Profesor Asignatura

Adscrita

n

1

Diseño de bases de datos 26/09/2006 18

Page 21: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Si en este sistema de información se debe cumplir que los profesores sólo son responsables de asignaturas de su departamento, entonces el departamento al que pertenece un profesor puede derivarse a través del departamento al que está adscrita la asignatura de la que es responsable pero como puede darse el caso de que no sea responsable de ninguna asignatura no se puede eliminar. La misma reflexión puede hacerse respecto a la relación adscrita. Así pues, dado que pese a existir cierta redundancia no es posible eliminar ninguna relación sin perder por ello información, este diagrama necesita una restricción de integridad que controle la restricción: “los profesores sólo son responsables de asignaturas de su departamento”.

No hay que pensar sin embargo, que siempre que hay un ciclo entre entidades existe una de-pendencia transitiva como se ilustra en el Ejemplo 31.

Ejemplo 31

código

nombre

dir_ayunt

dni

nombre

Pertenece

Trabaja1

1

n

n

Provincia

nombre

Ciudad Persona

Nació

n

1

En este caso, pese a existir un ciclo de las mismas características que en el Ejemplo 29 no existe redundancia ya que una persona no tiene por que haber nacido en la misma provincia en la que está la ciudad en la que trabaja.

4) Hay que ser cuidadoso al elegir relaciones de grado mayor que dos.

Ejemplo 32 Sea la siguiente relación ternaria entre las entidades Alumno, Asignatura y Profesor que representa la información referente a la impartición de asignaturas a alumnos por los profesores:

nnombre

exp

nombre

dni

Docencia1Alumno Profesor

nnombre

código

Asignatura

Si se elige este diseño sólo se podrá saber quién imparte cada asignatura cuando haya alumnos matriculados, no antes; tampoco se podrá saber a qué asignaturas va a asistir un alumno hasta que no se sepa quién va a impartir las clases.

Diseño de bases de datos 26/09/2006 19

Page 22: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

COMENTARIOS: • En una ocurrencia de una relación n-aria siempre participan n ocurrencias de entidad,

una de cada una de las n entidades relacionadas.

5) Sea una relación R entre las entidades E1,…, En. Supóngase que se quiere tener constancia de que las mismas ocurrencias de E1,…, En, se relacionan más de una vez a través de la misma relación. Para contemplar esta situación se puede optar por una de las dos soluciones que se comentan:

• Introducir una nueva entidad relacionada con las anteriores (esta entidad será débil), o

• Especificar los atributos propios de la relación definida como atributos multivaluados.

Ejemplo 33 Sea la relación Visitar entre la entidad Médico y la entidad Paciente:

nnombre

nºcoleg.

nombre

dni

VisitarnMédico Paciente

fecha diagnóstico

Si un médico puede visitar al mismo paciente en distintas ocasiones realizando diagnósticos diferentes, entonces la solución propuesta no sirve ya que en ese esquema una ocurrencia de médico sólo se puede relacionar una vez con la misma ocurrencia de paciente.

Solución 1: definir una nueva entidad Visita.

nombre

nºcoleg.

nombre

dni

Visitar

1

Médico Paciente

fecha diagnóstico

Visitar

Visitann

1

Obsérvese que en la solución propuesta se asume que un paciente puede visitar en la misma fecha a distintos médicos pero que el mismo médico no puede visitar más de una vez al día al mismo paciente. Si se quiere prever esta situación habría que añadir otro atributo a la entidad Visita (como la hora o un contador de visitas diarias).

Solución 2: definir los atributos de la relación Visitar como atributos multivaluados.

n

nombre

nºcoleg. nombre

dni

Visitar n Médico Paciente

fecha diagnóstico Visita

n

Diseño de bases de datos 26/09/2006 20

Page 23: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Hay que darse cuenta de que las dos soluciones no son equivalentes ya que en el último caso el mismo médico puede visitar en la misma fecha al mismo paciente más de una vez. La elección de una u otra solución depende del problema concreto. En el Ejemplo 33 la segunda solución parece menos restrictiva y sencilla aunque hay otros casos en los que la más natural es la primera.

6) Si se ha definido una entidad con un identificador compuesto por varios atributos y éstos a su vez son identificadores de otras entidades, entonces la entidad original está enmascarando una relación entre estas últimas.

Ejemplo 34 Sean las tres entidades que se muestran:

código

dniPedidonombre

dni

Proveedor

dircolor

código

Pieza

descrip.

Como puede observarse, los atributos identificadores de la entidad Pedido son a su vez identificadores de las entidades Proveedor y Pieza por lo que hay una relación oculta entre estas dos entidades; el esquema correcto es el siguiente:

n Pedidonombre

dni

Proveedor

dir

color

código

Pieza

descrip.

n

7) Si se ha definido una entidad con un atributo que es el identificador de otra entidad, este atributo debe eliminarse definiéndose entonces una relación entre ambas entidades.

Ejemplo 35 En el siguiente diagrama se han definido dos entidades una de las cuales tiene entre sus atributos el atributo identificador de la otra con la intención de representar a qué departamento pertenece un profesor.

nombre

cod_dep

Departamento

teléfono

nombre

dni

Profesor

dir

cod_dep

La solución correcta es aquélla que representa explícitamente la relación entre Profesor y Departamento.

Pertenece

nombrecod_dep

Departamento

teléfono

nombre

dni

Profesor

dir

1n

Diseño de bases de datos 26/09/2006 21

Page 24: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

COMENTARIOS: • En el modelo ER no existen las claves ajenas (concepto propio del modelo relacional) de

forma que nunca se debe incluir un atributo en una entidad con la intención de que represente una relación con otra entidad.

8) Especificar el papel que cada entidad juega en una relación cuando alguna entidad participa más de una vez en la relación. El caso más sencillo se presenta en las relaciones binarias en las que las dos entidades relacionadas son la misma. En el Ejemplo 36, se muestran algunas relaciones de este tipo especificando el papel.

Ejemplo 36 1) Relación de prerrequisitos en el conjunto de las asignaturas de una carrera: “una asignatura puede ser prerrequisito de muchas asignaturas y tener también a muchas asignaturas como prerrequisito”.

Jerarquía

Asignatura

Es_p

rerr

equi

sito

Tiene_prerrequisito

nn

2) Relación de composición entre piezas: “una pieza se compone de muchas piezas y a su vez puede formar parte de muchas piezas”.

Compone

Pieza

Se_c

ompo

ne_d

e Forma_parte_de

nn

3) Relación entre los ríos por el hecho de que unos son afluentes de otros: “un río puede ser afluente de otro pero a su vez muchos ríos pueden afluir a él”

Afluencia

Río

Es_a

flue

nte_

deTiene_com

o_afluente

1n

En general, hay que ser cuidadosos con las relaciones reflexivas ya que normalmente exigen que se

especifiquen ciertas propiedades que no quedan contempladas en la definición de la relación. Por ejemplo, las tres relaciones representadas en el Ejemplo 36 son antisimétricas y antirreflexivas(las

Diseño de bases de datos 26/09/2006 22

Page 25: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 23

ocurrencias de la entidad no se pueden relacionar consigo mismas), propiedades que no se expresan en el diagrama.

Por último, también hay que tener cuidado con la definición de restricciones de existencia en este tipo de relaciones ya que son muy infrecuentes (¿tiene sentido pensar que todos los ríos son afluentes de otro río o que todos los ríos tienen al menos un afluente?).

3.4 Identificar entidades débiles Como ya debe saberse, una entidad sufre restricción de dependencia de identificación cuando no

puede identificarse con sus propios atributos de manera que sus ocurrencias son distinguibles gracias a su relación con otras entidades. Cuando en el diagrama ER aparezcan entidades de este tipo, hay que especificar con qué relaciones se identifica (pueden ser una o más de una) utilizando atributos semiidentificadores cuando sea necesario.

3.5 Identificar objetos agregados Cuando se necesite establecer una relación en la que participen ocurrencias de una relación R, hay

que especificar una agregación sobre R para que pueda comportarse como una entidad.

3.6 Especificar restricciones de integridad Como ya se ha comentado anteriormente, para terminar con el diseño, todas aquellas propiedades de

la realidad que no hayan quedado expresadas en el diagrama ER deben incluirse en el anexo. Dado que no se ha especificado ningún lenguaje formal para su representación, hay que intentar que la frase o frases que definan estas restricciones no sean ambiguas.

Ejemplo 37 Para el diagrama del Ejemplo 28 se podría incluir la siguiente restricción: “Para todo vuelo las ciudades de despegue y aterrizaje son distintas”.

4 DISEÑO DE TRANSACCIONES

En este apartado se muestra cómo se puede abordar la tarea del diseño conceptual de las propiedades dinámicas de un sistema de información.

Una transacción es una secuencia de operaciones de acceso a los datos que constituye una unidad lógica de ejecución10.Para modelar la evolución (dinámica) del sistema hay que diseñar un conjunto de transacciones que permitan actualizar la información almacenada. Esta actualización se consigue añadiendo información (con la inserción de ocurrencias de entidad o relación), eliminando información (con el borrado de ocurrencias de entidad o relación) o modificando la información ya almacenada (con la modificación del valor de los atributos de ocurrencias de entidad o relación). Se asume por tanto que para cada tipo de entidad, de relación o de especialización existe una operación de inserción, una de borrado y una de modificación.

Las transacciones deben ser diseñadas de forma que permitan realizar estas tareas por lo que las restricciones de integridad tendrán que ser tenidas en cuenta; aunque existen distintas formas de abordar esta trabajo, en este apartado se propone una metodología de diseño de transacciones que consiste en obtener un conjunto de transacciones, a partir del diagrama ER, a las que se denomina

10 Aunque a nivel lógico, el concepto de transacción es el mismo que se introdujo en la asignatura de Bases de

Datos. Recuérdese que un correcto procesamiento de las transacciones debe asegurar las propiedades de atomicidad, consistencia, persistencia y aislamiento.

Page 26: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

transacciones mínimas. Este conjunto incluirá, para cada entidad y para cada relación del diagrama una transacción de inserción, una de borrado y varias de modificación11, aunque hay algunas excepciones. Las transacciones mínimas son aquellas que incluyen todas las operaciones sobre distintos objetos (entidad o relación) que pueden ser necesarias para que la modificación del sistema de información sea válida; estas transacciones mínimas constarán siempre de una operación básica (de inserción, borrado o modificación) sobre el objeto (entidad o relación) para el que se está definiendo la transacción, y pueden incorporar operaciones sobre otras entidades o relaciones con las que estén vinculadas.

Las transacciones mínimas deben considerarse como la única forma permitida de modificar la información almacenada y podrán ser utilizadas en transacciones ya más complejas diseñadas a medida de cada aplicación.

Para simplificar el diseño, se puede asumir que todas las restricciones (expresadas en el diagrama o en el anexo) son controladas por el sistema por lo que no es necesario comprobarlas en las propias transacciones; sin embargo, éste debe ir guiado por esas restricciones ya que si no se tienen en cuenta, podrían definirse transacciones que siempre serían abortadas al conducir al sistema a un estado en el que se violase alguna restricción.

Ejemplo 38 Sea el siguiente diagrama ER:

Num_exp

Alumno Centro Matricula n 1

Código

Una transacción para insertar en la entidad Alumno que sólo considerase esa operación sería siempre rechazada por el sistema ya que cuando finalizase su ejecución se violaría la restricción de existencia de Alumno. Así, la transacción mínima para añadir un nuevo alumno debería también incluir una operación para añadir una ocurrencia de Matricula.

Para la definición formal de estas transacciones sería necesario extender el modelo ER con un lenguaje que proporcionara operaciones de inserción, borrado y modificación así como operaciones de control (iteración, secuencia, decisión, asignación, etc.); dado que en este tema no se incluye este lenguaje, el diseño de transacciones se va a realizar sólo en fase de análisis sin que se vayan a especificar formalmente.

Para realizar este análisis de transacciones se partirá del diagrama ER debiendo decidir, para cada entidad o relación del mismo, qué operaciones y sobre qué objetos serán necesarias para conseguir añadir, borrar o modificar una ocurrencia de esa entidad o relación. La determinación de dichas operaciones se deduce lógicamente del diagrama ER al considerar las restricciones representadas en él.

Si se consideran diagramas que no tienen restricciones de integridad añadidas, el análisis de transacciones se puede definir de forma simple en el caso de la inserción, siendo algo más complejo en el borrado. A continuación se describen brevemente los dos tipos:

• Inserción

Entidades: En este caso, si una entidad tiene restricción de existencia en alguna relación, hay que insertar en esa relación. Si otras entidades que participan en la

11 Las transacciones para modificar el valor de atributos de ocurrencias de entidad o relación son triviales y se

podría considerar que existe una por cada atributo que permitiría cambia el valor “viejo” por uno “nuevo”. Transacciones de modificación más complicadas dependerán del caso concreto que se esté considerando.

Diseño de bases de datos 26/09/2006 24

Page 27: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 25

relación también tienen restricción de existencia, habrá que diseñar una transacción que incluya la inserción en la relación y también en todas las entidades con restricción de existencia. Dependiendo de las cardinalidades máximas, esta transacción será única o no.

Relaciones: Si la relación R en la que se está insertando participa como objeto agregado con restricción de existencia en otra relación S, hay que insertar en S.

• Borrado: Se pueden definir operaciones de borrado de varios tipos, pero sólo se considerarán dos: restrictivo y en cascada12 respecto a cada relación en la que participe la entidad o el objeto agregado.

Entidades:

Restrictivo respecto a una relación R: sólo incluye la operación de borrado de la entidad. Como el sistema controla que se cumplan las restricciones, cuando se ejecute dicha transacción, si la ocurrencia a borrar está participando en R, no podrá realizarse el borrado.

En cascada respecto a una relación R: se incluye, además de la operación de borrado de la entidad, el borrado de las ocurrencias de R en las que interviene la entidad. Si la entidad tiene restricción de existencia respecto a R, el borrado siempre tendrá que ser de este tipo.

Relaciones: podrá ser de dos tipos, como en el caso de las entidades

Restrictivo respecto a una entidad o relación: no hay que añadir ninguna operación.

En cascada: si alguna de las entidades que participan en la relación tienen restricción de existencia en ella, hay que incluir, además del borrado de la relación, el borrado de dicha entidad para los casos en los que la ocurrencia de relación borrada sea la última en la que participaba la entidad. Además, si la relación participa como objeto agregado en otra relación, sea S, en la transacción se incluye, junto a las operaciones de borrado citadas, el borrado de S para las ocurrencias en las que interviene el agregado.

• Modificación: Dependiendo de las necesidades del sistema de información, puede haber muchas transacciones de modificación diferentes. Deben diseñarse las transacciones que posibiliten modificar cualquier atributo de cualquier objeto que sea necesario.

En todos los casos de borrado en cascada o de inserción de entidades con restricciones de existencia, las operaciones añadidas a la transacción pueden requerir a su vez una propagación, que también hay que incluir en la transacción.

Las transacciones mínimas también son distintas cuando aparece la generalización ya que dependiendo de las propiedades de la misma las operaciones a incluir serán unas u otras:

• Inserción:

Total y Disjunta: habrá que diseñar tantas transacciones como entidades especializadas haya; cada transacción insertará en la entidad general y en una de las especializadas.

Total y Solapada: habrá que diseñar tantas transacciones como entidades

12 Estos conceptos se utilizan con el mismo significado que en la asignatura “Bases de Datos”.

Page 28: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

especializadas haya; cada transacción insertará en la entidad general y en una de las especializadas. Para permitir el solape, también habrá que añadir tantas transacciones como entidades especializadas haya de forma que cada transacción inserte en una de las entidades especializadas.

Parcial (Disjunta o Solapada): habrá que incluir una transacción por cada entidad especializada y una por la entidad general.

• Borrado:

Total y Disjunta: habrá que diseñar una transacción que debe borrar de la entidad general y de todas las especializadas (aunque realmente sólo se conseguirá borrar de una de ellas al ser disjunta).

Total y Solapada: habrá que diseñar una transacción que borre de la entidad general y de todas las especializadas y tantas transacciones como entidades especializadas haya; estas últimas transacciones también podrán ser restrictivas o en cascada respecto a la entidad general:

Restrictivo: cada transacción borrará exclusivamente en una de las entidades especializadas.

En cascada: cada transacción borrará en una de las especializadas y en la entidad general si esta especialización era única.

Parcial (Disjunta o Solapada): habrá que diseñar tantas transacciones como entidades especializadas haya que incluirán sólo el borrado en la entidad especializada. También se diseñará una transacción que borre de la entidad general; esta transacción podrá ser restrictiva o en cascada respecto a las entidades especializadas:

Restrictivo: la transacción borrará exclusivamente en la entidad general.

En cascada: la transacción borrará en la entidad gene13ral y en todas sus especializaciones.

Ejemplo 39 Sea el siguiente diagrama ER en el que no se han incluido los atributos:

n 1 V E

n

n D T n

C

A B R n 1

S

1

T,D

T,S

P,D

C2 C1

D2 D1 A2 A1

n

F

U

n

13 En este caso también se podría considerar una transacción de borrado que fuera en cascada respecto a alguna

de las especializaciones y restrictivo respecto al resto.

Diseño de bases de datos 26/09/2006 26

Page 29: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 27

Las transacciones que habría que considerar en este caso serían las siguientes (obsérvese que hay transacciones que no tiene sentido que existan como por ejemplo la transacción para insertar en R): INSERCIÓN: • Transacción para insertar en A de tipo A1

o Insertar en A ⇒ Insertar en A1 ⇒ Insertar en R

• Transacción para insertar en A de tipo A2 o Insertar en A

⇒ Insertar en A2 ⇒ Insertar en R

Transacción para insertar en B o Insertar en B

⇒ Insertar en T

• Transacción para insertar en C de tipo C1 o Insertar en C

⇒ Insertar en C1 • Transacción para insertar en C de tipo C2

o Insertar en C ⇒ Insertar en C2

• Transacción para insertar en C1 o Insertar en C1

• Transacción para insertar en C2 o Insertar en C2

• Transacción para insertar en D o Insertar en D

⇒ Insertar en T • Transacción para insertar en B-D14

o Insertar en B o Insertar en D

⇒ Insertar en T • Transacción para insertar en D1

o Insertar en D1 • Transacción para insertar en D2

o Insertar en D2 • Transacción para insertar en E

o Insertar en E • Transacción para insertar en F

o Insertar en F • Transacción para insertar en S

o Insertar en S • Transacción para insertar en T

o Insertar en T • Transacción para insertar en U

14 Esta transacción es necesaria cuando no hay ocurrencias de B ni de D.

Page 30: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Diseño de bases de datos 26/09/2006 28

o Insertar en U ⇒ Insertar en V

BORRADO: en este caso, a diferencia de la inserción, existen varias transacciones posibles según se elija, cuando sea posible, borrado en cascada o restrictivo. Par destacar este hecho cuando existan ambas posibilidades se indicará entre paréntesis la opción elegida: • Transacción para borrar en A

o Borrar en A ⇒ Borrar en A1 ⇒ Borraren A2 ⇒ Borrar en R

• Transacción para borrar en B (restrictivo respecto a R15) o Borrar en B

⇒ Borrar en T (restrictivo respecto a D) ⇒ Borrar en S (cascada)

• Transacción para borrar en C (restrictivo respecto a S) o Borrar en C

⇒ Borrar en C1 ⇒ Borrar en C2

• Transacción para borrar en C1 (restrictivo respecto a C) o Borrar en C1

• Transacción para borrar en C2 (restrictivo respecto a C) o Borrar en C2

• Transacción para borrar en D (restrictivo respecto a D1 y D2) o Borrar en D

⇒ Borrar en T (restrictivo respecto a B) • Transacción para borrar en D1

o Borrar en D1 ⇒ Borrar en U (cascada)

⇒ Borrar en V • Transacción para borrar en D2

o Borrar en D2 • Transacción para borrar en E (restrictivo respecto a V)

o Borrar en E • Transacción para borrar en F (restrictivo respecto a U)

o Borrar en F • Transacción para borrar en S

o Borrar en S • Transacción para borrar en T (restrictivo respecto a B y D)

o Borrar en T • Transacción para borrar en U

o Borrar en U ⇒ Borrar en V

15 Esto debe formar parte de los requisitos de información y depende de cada sistema de información.. En este

caso, dado que el ejemplo es genérico, se podría haber elegido en cascada. Hay que tener en cuenta que si se propaga el borrado a R también habría que borrar de A y por consiguiente de A1 y de A2.

Page 31: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

5 ENFOQUES PARA EL DISEÑO DE BASES DE DATOS COMPLEJAS

Una vez se ha presentado con detalle cómo abordar el diseño conceptual de grandes sistemas de información16, a continuación se comentan dos posibles enfoques para la realización de esta tarea:

• Enfoque centralizado de diseño del esquema: en este enfoque, los requerimientos de las diferentes aplicaciones y grupos de usuarios se combinan en un solo conjunto de requerimientos antes de iniciarse el diseño del esquema (esta tarea puede ser muy difícil cuando hay muchos usuarios). A continuación se diseña un único esquema que corresponde al conjunto combinado de requerimientos. Una vez diseñado y terminado el esquema conceptual, el administrador de la base de datos puede especificar esquemas externos para diferentes grupos de usuarios y aplicaciones. Éste ha sido el enfoque utilizado tradicionalmente a pesar de la dificultad que plantea el conciliar las diferencias y conflictos entre los grupos de usuarios para establecer una definición clara de los requerimientos globales antes de abordar el diseño conceptual, por eso debido a la dificultad inherente a esta tarea, el enfoque de integración de vistas goza cada vez de mayor aceptación.

• Enfoque de integración de vistas: en este enfoque no se realiza la combinación de los requerimientos sino que se diseña un esquema (o vista) para cada grupo de usuarios o aplicación, diseño que se basa en sus propios requerimientos. Durante una fase posterior, llamada de integración de vistas, los esquemas obtenidos se combinan o integran para construir un esquema conceptual global para toda la base de datos. A partir de las vistas individuales se pueden definir posteriormente los esquemas externos. Aunque la integración de vistas puede efectuarse manualmente, su aplicación a una base de datos grande en la que intervengan muchos grupos requerirá una metodología y el empleo de herramientas automáticas que ayuden a realizar la integración.

Combinación de

requerimientos

Diseño del esquema

conceptual

Enfoque centralizado

Diseño de esquemas

conceptuales (Vistas)

Integración de

vistas

Enfoque de integración de vistas

Independientemente del enfoque seguido, en ambos casos la tarea fundamental a realizar es el

modelado de cierta organización (o parte de la organización). El modelo obtenido va a ser representado en su parte estática por un diagrama ER.

En el apartado siguiente se comenta brevemente cómo se puede abordar la tarea de la integración de vistas.

5.1 Integración de vistas En el caso de bases de datos complejas que se espera que tengan muchos usuarios y aplicaciones,

puede usarse el enfoque de integración de vistas, diseñando esquemas individuales y luego combinándolos. Ya que es posible tener vistas individuales relativamente pequeñas, el diseño de los

16 Hay que tener en cuenta que los ejemplos que se proponen para aprender a diseñar hacen referencia a pequeños

sistemas de información por lo que los enfoques que se comentan no serán de gran utilidad. Sin embargo se ha considerado interesante comentarlos para ampliar la perspectiva que debéis tener de esta tarea.

Diseño de bases de datos 26/09/2006 29

Page 32: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

esquemas se simplifica. Sin embargo, se requiere una metodología para integrar las vistas en un esquema conceptual global. La integración de vistas puede dividirse en los siguientes pasos:

1. Identificación de correspondencias y conflictos entre los esquemas.

2. Modificación de las vistas para ajustarlas entre sí.

3. Combinación de vistas.

4. Reestructuración.

A continuación se comentan brevemente estas actividades [EN97].

5.1.1 Identificación de correspondencias y conflictos Dado que los esquemas se diseñan individualmente, es necesario especificar elementos en los

esquemas que representen el mismo concepto en el mundo real. Esta correspondencia debe identificarse antes de poder efectuar la integración. Durante este proceso, es posible que se descubran varios conflictos entre los esquemas:

• Conflictos de nombre: en la denominación de algún objeto del esquema (entidad, relación o atributo). Son de dos tipos: sinonimia y polisemia. La sinonimia ocurre cuando dos esquemas usan diferentes nombres para describir el mismo concepto. La polisemia ocurre cuando dos esquemas usan el mismo nombre para describir diferentes conceptos.

Ejemplo 40

Comprador Cliente

Vista 1 Vista 2

… …

Si el objeto de la realidad que está representando en la vista 1 la entidad Comprador es el mismo que en la vista 2 la entidad Cliente entonces se presenta un conflicto por sinonimia.

Componente Componente

Vista 1 Vista 2

… …

Si el objeto de la realidad que está representando en la vista 1 la entidad Componente no es el mismo que en la vista 2 entonces se presenta un conflicto por polisemia.

• Conflictos de tipos: El mismo concepto puede representarse en dos esquemas mediante elementos de modelado distintos.

Diseño de bases de datos 26/09/2006 30

Page 33: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

Ejemplo 41

Asignatura Profesor

Vista 1 Vista 2

… …

Departamento

cod_dep

n

1

Pertenece

En la vista 1 no se ha diseñado una entidad para representar a los departamentos y por tanto el departamento al que está adscrita una asignatura es un atributo de la entidad que las representa. Sin embargo, en la segunda vista se ha considerado adecuado la inclusión de una entidad para representar a los departamentos.

• Conflictos de dominios: Un atributo puede tener diferentes dominios en dos esquemas.

Ejemplo 42

… …

dni dni

Cliente Cliente

Vista 1 Vista 2

dni: dom_dni; dom_dni: entero dni: dom_dni; dom_dni: char(10)

• Conflictos entre restricciones: Dos esquemas pueden imponer distintas restricciones

Ejemplo 43 dni

cod_cli Cliente Cliente

Vista 1 Vista 2

… …

dni

Pese a representar el mismo objeto en cada vista se ha elegido un identificador distinto.

Para finalizar con este punto hay que destacar que la dificultad de esta tarea reside en el hecho de que el descubrimiento de estos conflictos no es trivial ya que no siempre los casos son tan obvios como se han mostrado en los ejemplos.

5.1.2 Modificación de las vistas Esta tarea supone la modificación de algunos esquemas para que se ajusten mejor a los otros

resolviendo los conflictos identificados en el paso anterior. La solución a estos problemas puede resultar bastante sencilla como se muestra en el Ejemplo 44.

Ejemplo 44 En el Ejemplo 40 el problema de la sinonimia podría resolverse decidiéndose por uno de los dos nombres, Cliente o Comprador; y el de la polisemia con la inclusión de dos nombres, Componente_1 y Componente_2 (aunque sería mejor especificar nombres con mayor contenido semántico).

Diseño de bases de datos 26/09/2006 31

Page 34: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

En el Ejemplo 41 habría que decidirse por la inclusión o no de la entidad Departamento. Dado que en la segunda se había especificado explícitamente, lo más razonable parece ser respetar esta decisión y modificar la vista 1 de la siguiente forma:

Departamento

n

1

Adscrita

Asignatura Profesor

Vista 1 Vista 2

… …

Departamento

n

1

Pertenece

En el Ejemplo 42 habría que decidirse por uno de los dos dominios posibles para el atributo dni. En el Ejemplo 43 habría que decidirse por uno de los dos identificadores.

5.1.3 Combinación de vistas El esquema global se crea combinando los esquemas individuales. Los conceptos que se corresponden

se representan una sola vez en el esquema global, y se especifican las transformaciones de las vistas al esquema global para que después sea posible la definición de los esquemas externos.

5.1.4 Reestructuración Como último paso opcional, el esquema global podrá analizarse y reestructurarse para eliminar

cualquier redundancia o complejidad innecesaria. Una vez hecha esta reestructuración, el esquema obtenido debe examinarse desde el punto de vista de cada una de las vistas parciales y, si no es aceptado por alguna de ellas debe modificarse repitiendo este proceso las veces que haga falta.

Diseño de bases de datos 26/09/2006 32

Page 35: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

6 CUESTIONES SOBRE DISEÑO CONCEPTUAL

1. ¿Qué significa que la entidad A tiene restricción de existencia respecto a la relación binaria R definida entre las entidades A y B?.

2. Considere una relación binaria entre las entidades A y B, ¿cuáles serían las restricciones de cardinalidad de A y B respecto a R si la única restricción que se debe cumplir es que “toda ocurrencia de A se debe relacionar con una única ocurrencia de B”?.

3. Considere una relación ternaria R entre las entidades A, B y C con la siguiente restricción de cardinalidad: R(A(1,n), B-C(0,1)), ¿en cuántas ocurrencias de R participa una ocurrencia de la entidad A?.

4. Considere la siguiente relación ternaria R entre las entidades A, B y C, a la que no se han especificado las cardinalidades máximas

C

A B

R

¿cómo expresaría por medio de las restricciones de cardinalidad que una ocurrencia de la entidad A

sólo puede relacionarse con una ocurrencia de la entidad B?.

5. Considere un objeto agregado definido a partir de una relación ternaria R entre las entidades A, B y C, definida con las siguientes restricciones de cardinalidad:

R(C(1,n), A-B(0,1)) R(B(1,n), A-C(0,n)) R(A(1,n), B-C(0,n)) ¿cuál es el identificador de la entidad agregada R?. (Entiéndase como identificador un conjunto de

atributos únicos y no nulos de la entidad agregada).

6. ¿Qué significa que la entidad E es una generalización de las entidades E1 y E2?

a) que toda ocurrencia de E es también una ocurrencia de E1 o una ocurrencia de E2.

b) que toda ocurrencia de E1 y toda ocurrencia de E2 son también una ocurrencia de E.

c) que alguna ocurrencia de E es también una ocurrencia de E1 o una ocurrencia de E2.

d) que la entidad E se compone de las entidades E1 y E2.

Justifique por qué no son válidas las tres respuestas que no elija.

7. En el siguiente diagrama Entidad-Relación que representa una relación reflexiva R de cardinalidad 1:1, definida sobre la entidad A y con dos restricciones de existencia:

A

R1 1

¿cuál de estas ocurrencias es una ocurrencia válida del esquema?

a) A={a1,a2,a3}, R={(a1,a2), (a2,a3), (a3,a1)}

Diseño de bases de datos 26/09/2006 33

Page 36: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

b) A={ a1,a2,a3}, R={( a1,a2), (a2,a3), (a3,a3)}

c) A={ a1,a2,a3}, R={( a1,a2), (a1,a3), (a3,a3)}

d) A={ a1,a2,a3}, R={(a1,a3), (a2, a1)}

Justifique por qué no son válidas las tres respuestas que no elija.

8. Considerando que dos esquemas son equivalentes cuando permiten representar exactamente la misma realidad, ¿son equivalentes los siguientes pares de esquemas conceptuales?:

A) nA BR

n

C

n n

A BR

S

n n

C

n

B)

nA CSn

n

A BR

S

n n

C

n

n

R

B

n

C)

n

nA CS1

1

A BR

S

n 1

C

n

R

B

1

• Para aquellos pares que no sean equivalentes, ilústrelo con una ocurrencia válida para uno de

los esquemas que no sea representable en el otro. • Justifique la equivalencia de los pares que sí lo sean.

9. Dadas las entidades A y B y la relación binaria R que asocia estas dos entidades, la siguiente figura representa una posible ocurrencia del esquema representando las ocurrencias de las entidades con conjuntos de elementos y las ocurrencias de la relación con una correspondencia entre dichos conjuntos:

a4

a3a2

b4

b3

b2

b1

a6

a1

a5

• ¿Cuáles son todas las posibles cardinalidades máximas y mínimas de la relación R?. Utilícese

para ello la notación vista en clase.

Diseño de bases de datos 26/09/2006 34

Page 37: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

• ¿Qué diagramas Entidad-Relación pueden corresponder a esta ocurrencia?. Incluya todos los posibles.

10. Dado el siguiente esquema conceptual

Vecino

dni

edad

Administrador

T,S

nombre

Comunidad

nombre

dir

Preside

Administra

Casanº

clase

1

1

1

1

n

tfno

Pertenece

Reside

ntfno

n

1

Persona

categoría

¿Cómo se puede modificar el diagrama para expresar que los administradores de categoría superior

a 7 sólo administran comunidades de las clases “B”, “C”, o “D” y que los de categorías inferiores sólo pueden administrar una comunidad de clase “A” como mucho?

11. En el esquema conceptual siguiente se representa la información de un pabellón polideportivo que alquila por horas las diferentes pistas a equipos constituidos por socios. El atributo resp de la relación Composición es de tipo lógico o booleano y representa si un jugador es o no responsable de un equipo al que pertenece.

num_empnombre

nn

hora

resp

día num_pista

cod

Pista/día/hora

num_socionombre

Equipo Socio

nombre

Composición

Reserva

n

1

Empleado

¿Cómo se podría modificar el diagrama para expresar que cada pista tiene asignado a un empleado (y

sólo a uno) para su mantenimiento?

12. Usando el diagrama ER de la figura:

Diseño de bases de datos 26/09/2006 35

Page 38: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

n 1 1

D d0

d1

c1 co

1

n

a1

A B R

b1 b0

a0

r1

s C

• Analice cómo sería la transacción que permitiría la inserción de ocurrencias de la entidad A • Cite todas restricciones que el sistema de gestión de bases de datos debe controlar para

permitir la ejecución de la transacción anterior.

13. Dado el diagrama entidad-relación de la figura,

1

n

n

1

a2

A BSb1

b0a0

Rr

a1

g1

Gg2g0

F

f1

E

T,De1

• Analice cómo sería la transacción que permitiría el borrado de ocurrencias de la entidad A

considerando que sea restrictivo respecto a S y propagado respecto a los demás objetos. • Cite todas restricciones que el sistema de gestión de bases de datos debe controlar para

permitir la ejecución de la transacción que ha diseñado

14. Dado el siguiente esquema conceptual

n

cod

metal

valor

Colección

id

dueñoConsta_de

Substituye

clase

1 1

nMoneda

diamétro

Nue

va

Viej

a

Donde la relación Substituye indica que una nueva moneda ha substituido en el mercado a otra

moneda (vieja), analice cómo sería la transacción que permitiría el borrado monedas (el borrado debe ser propagado (o en cascada)).

15. A partir del siguiente diagrama Entidad-Relación,

Diseño de bases de datos 26/09/2006 36

Page 39: Tema 2 de DBD - users.dsic.upv.esusers.dsic.upv.es/~fpla/dbd06-07/Bol_tema2_07.pdf · En este tema se presenta uno de estos modelos, el Modelo Entidad-Relación1, así como una metodología

Departamento de Sistemas Informáticos y Computación

1

n

n ...

1

n

1

s1

n

n

...

a1 a0

A

T,S

an

...

b1 B

bn

R 1

E

C D

d1

T

S

U

W

1

1

1

t1

e0

e1 en

Analice la transacción de borrado de C, restrictivo respecto a U y en cascada respecto al resto.

16. Dado el esquema conceptual que muestra la figura analice la transacción que permitiría la inserción de nuevos matrimonios:

MUJER HOMBRE

PERSONA

T,D

MATRIMONIO n n

JUEZ JUZGADO CASÓ LUGAR n n 1 1

dni

fecha vigente

cod-juez nºjuz

… …

vigente: atributo de tipo lógico

7 BIBLIOGRAFÍA [Chen76] Peter Pin-Shan Chen

The Entity-Relationship Model -Toward a Unified View of Data. ACM Transactions on Database Systems, Vol. 1, nº 1, March 1976, pages 9-36.

[EN02] Elmasri, R.; Navathe, B. Fundamentos de Sistemas de bases de datos. Addison-Wesley. 3ª edición 2002.

[MCC94] Mota, L.; Celma, M.; Casamayor, J. C.; Bases de datos relacionales: teoría y diseño SPUPV 767.94, 1994.

Diseño de bases de datos 26/09/2006 37