• No se han encontrado resultados

Estructura de Datos E/R. Recordando Introducción. Etapas del diseño lógico Diseño lógico estándar Diseño lógico específico

N/A
N/A
Protected

Academic year: 2021

Share "Estructura de Datos E/R. Recordando Introducción. Etapas del diseño lógico Diseño lógico estándar Diseño lógico específico"

Copied!
25
0
0

Texto completo

(1)

Tema III:

Tema III:

Transformación del

Transformación del

esquema conceptual al relacional

esquema conceptual al relacional

3.1 Introducción. Etapas del diseño lógico Diseño lógico estándar Diseño lógico específico 3.2 Transformación elementos básicos

3.3 Reglas concernientes a las extensiones del modelo E/R

Transformación de dependencias en identificación y en existencia Transformación de interrelaciones exclusivas

Transformación de tipos y subtipos Transformación de la dimensión temporal Transformación de atributos derivados

Transformación de interrelaciones de grado superior a dos

Tema 3.1:

Tema 3.1: Introducción.

Introducción.

Etapas del diseño Lógico

Etapas del diseño Lógico

Estructura

de Datos

E/R

(2)

- 3 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Tema 3.1:

Tema 3.1: Introducción.

Introducción.

Etapas del diseño Lógico

Etapas del diseño Lógico

A) Diseño lógico estándar

Ø Elaboración del Esquema Lógico Estándar que se apoya en el modelo lógico estándar -Relacional, Codasyl, Jerárquico-Ø El Esquema Lógico Estándar se describirá utilizando el lenguaje

estándar, si existe, del modelo de datos correspondiente (v.g. el SQL92)

B) Diseño lógico específico

Ø Con el Esquema Lógico Estándar, y teniendo en cuenta el modelo lógico específico propio del SGBD, se elabora el esquema lógico específico, que será descrito en el lenguaje del producto comercial que estemos utilizando (p. e. Oracle)

REQUISITOS DE LOS PROCESOS Y EL ENTORNO ESQUEMA CONCEPTUAL ESQUEMA ESQUEMA LÓGICO ESTANDAR ESQUEMA ESQUEMA LÓGICO ESPECÍFICO Diseño lógico ESPECIFICACIONES PARA LOS PROCESOS

ESPECIFICACIONES PARA LOS PROCESOS

MODELO LÓGICO ESTANDAR ESPECÍFICO MODELO LÓGICO ESPECÍFICO ENTRADAS

Tema 3.1:

Tema 3.1: Introducción.

Introducción.

Etapas del diseño Lógico

Etapas del diseño Lógico

(3)

- 5 ©LABDA Tema III: Transformación del esquema conceptual al relacional

diagrama

E/R

grafo

Relacional

Script

SQL

Modelo Conceptual

Modelo Lógico (estándar)

Modelo Lógico (específico)

Tema 3.1:

Tema 3.1: Introducción.

Introducción.

Etapas del diseño Lógico

Etapas del diseño Lógico

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

tipo_nombre

PERSONA

confía

• Los dominios en E/R se mantienen

como dominios en Relacional

• Las entidades en E/R se traducen en

relaciones del modelo Relacional

• Las interrelaciones en E/R se traducen en

- relaciones del modelo Relacional

- propagación de claves (clave ajena) *

Nota *: aunque una clave ajena parece recoger menos semántica que una relación E/R, esta semántica se complementa con la que aporta la restricción referencial.

(4)

- 7 ©LABDA Tema III: Transformación del esquema conceptual al relacional

PERSONA

Los ATRIBUTOS de una entidad serán atributos de la relación

correspondiente, con ciertas salvedades:

• Los atributos ‘no obligatorios’ serán

marcados como atributos opcionales (*)

• Un atributo multivaluado origina una nueva relación que

contiene dicho atributo y la clave primaria de la entidad

(que será clave ajena sobre la relación a la que esta dé lugar).

La clave de esta relación será todo el esquema de relación.

• Los atributos identificadores principales

serán marcados como clave primaria

• Los atributos identificadores alternativos

serán marcados como claves alternativas

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Se traducen en una relación.

• Esta relación contendrá las claves de las relaciones asociadas,

que en conjunto serán clave de la nueva relación.

• También incluirá los atributos de la interrelación original.

• Las opciones de borrado y modificación dependerán del cada caso

particular

(si bien, en general, se escogerá en ambas la opción cascada)

PERSONA ha visto ha visto PELÍCULA

N:M

DNI veces Título

director nombre

apellidos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones N:M

(5)

- 9 ©LABDA Tema III: Transformación del esquema conceptual al relacional

ha_visto (DNI, Título, veces)

Persona (DNI, Nombre, Apellidos,...)

DC / UC Película (Título, Director,...) DC / UC

Ejemplo:

PERSONA ha visto ha visto PELÍCULA

N:M

DNI veces Título

director nombre

apellidos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones N:M

Dos posibilidades:

• Propagar la clave de la entidad que interviene con cardinalidad 1

(en la relación correspondiente a la otra entidad aparecerá esta clave como clave ajena; junto a ella, irán los atributos de la interrelación si los hubiera)

• Transformarla en una nueva relación

Dicha relación tendría como atributos las claves de ambas entidades (y los atributos propios de la interrelación). Su clave sería la clave de la entidad que interviene en la interrelación con N ocurrencias).

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

apellidos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

(6)

- 11 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Persona (DNI, Nombre, Apellidos,...)

Factura (Nº_factura, DNI, importe,...)

Ejemplo: propagar clave

PERSONA paga FACTURA

1:N

DNI fecha Nº_factura

importe nombre

apellidos

D? / UC

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

paga (Nº_factura, DNI, fecha)

Persona (DNI, Nombre, Apellidos,...)

DC / UC Factura (Nº_factura, importe,...)

D? / UC

Ejemplo: crear nueva relación

PERSONA paga FACTURA

1:N

DNI fecha Nº_factura

importe nombre

apellidos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

(7)

- 13 ©LABDA Tema III: Transformación del esquema conceptual al relacional

¿Qué hacer con las cardinalidades mínimas ‘cero’?

• (0,1): la entidad que interviene con una ocurrencia es opcional

(pueden existir ocurrencias de la otra entidad no relacionadas). Resultado:

- si se propaga, la clave ajena propagada será opcional (*) (habrá ocurrencias de la otra entidad cuya clave ajena sea NULL) - si se crea una nueva relación, habrá identificadores de la entidad opcional que no aparezcan en ninguna ocurrencia de esta relación. (no hay que hacer nada)

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

apellidos (0,1) (0,n)

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

• (0,n): la entidad que interviene con varias ocurrencias es opcional.

(pueden existir ocurrencias de la otra entidad no relacionadas). Resultado: no hay que tomar ninguna medida especial

- si se propaga, habrá ocurrencias de la clave de identificación propagada que no aparezcan en ninguna tupla de la otra relación. - si se crea una nueva relación, habrá identificadores de la entidad opcional que no aparezcan en ninguna ocurrencia de esta relación.

¿Qué hacer con las cardinalidades mínimas ‘cero’?

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

(8)

- 15 ©LABDA Tema III: Transformación del esquema conceptual al relacional

• (1,1): la entidad interviene con una y solo una ocurrencia.

Resultado:

- si se propaga, la clave ajena tomará siempre un valor (obligatoriedad). - si se crea una nueva relación, en ella debería haber una tupla por

cada ocurrencia de la relación que interviene con N (pero esto no quedará garantizado a priori; habría una pérdida de semántica).

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

apellidos (1,1) (1,n)

Nota: estas pérdidas de semántica se suplirán con la inclusión de restricciones semánticas; en concreto, se añadirán aserciones que vigilen que estas condiciones se cumplen.

¿Qué hacer con las cardinalidades mínimas ‘uno?

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

• (1,n): la entidad interviene con una o varias ocurrencias.

Resultado: no se toma ninguna medida especial (pérdida de semántica). - si se propaga, toda valor de la clave propagada debería aparecer

en alguna ocurrencia de la otra relación (pero no se garantiza) - si se crea una nueva relación, en ella debería haber al menos una

tupla por cada ocurrencia de la relación que interviene con una ocurrencia (pero tampoco esto está garantizado a priori)

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

apellidos (1,1) (1,n)

¿Qué hacer con las cardinalidades mínimas ‘uno?

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

(9)

- 17 ©LABDA Tema III: Transformación del esquema conceptual al relacional

¿Cuál de las opciones es más conveniente?

En general, es preferible propagar la clave

Se creará una nueva relación si:

a) la interrelación tiene caracterización propia (atributos propios) b) se prevé que la interrelación podría ser N:M en el futuro c) la cardinalidad mínima de la interrelación para la entidad que

propaga es 0 (opcional), y en la otra entidad el número de

ocurrencias no relacionadas es elevado (la clave ajena sería NULL)

PERSONA paga FACTURA

1:N

DNI fecha Nº_Factura

importe nombre

apellidos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:N

Las soluciones aplicables son:

a) crear una nueva relación b) propagar una de las claves

c) propagar las claves de las dos entidades (mutuamente)

d) fusionar ambas entidades (interrelacionadas) en una sola relación

PERSONA HISTORIAL

MÉDICO tiene

1:1

DNI fecha_apertura nº_historial

localización nombre

apellidos

Se puede considerar un caso particular de las anteriores, y por tanto

las soluciones anteriores son válidas también en este caso.

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:1

(10)

- 19 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Crear una nueva relación: (justificación similar al caso 1:n)

a) si las cardinalidades mínimas son cero (ambas), esto evitará

valores nulos en las claves ajenas y mantendrá la simetría

natural (entidades mantienen su independencia en relaciones

separadas)

b) si la interrelación tiene caracterización propia (atributos) o

c) si se prevé que posteriormente puedan variarse las

cardinalidades

EMPLEADO utilizautiliza ORDENADOR

1:1

DNI horario nº_serie

memoria nombre apellidos (0,1) (0,1)

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:1

Ejemplo: (crear una nueva relación)

utiliza (nº_serie, DNI, horario)

Empleado (DNI, Nombre, Apellidos,...)

DC / UC Ordenador (nº_serie, memoria,...)

DC / UC

Nota: observar la pérdida de eficiencia, ya que muchos consultas implican combinar dos relaciones, e incluso hay consultas que implican combinar las tres relaciones.

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:1

EMPLEADO utilizautiliza ORDENADOR

1:1

DNI horario nº_serie

memoria nombre

apellidos

(0,1) (0,1)

(11)

- 21 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Propagar una clave: (

justificación similar a la anterior)

• si una de las cardinalidades mínimas es cero y la otra no (será 1,1), conviene propagar la clave de esta última (la obligatoria).

EMPLEADO dirigedirige SUCURSAL

1:1

DNI fecha_inicio nº_sucursal

dirección nombre

apellidos

(0,1) (1,1)

Empleado (DNI, Nombre, Apellidos,...)

Sucursal (nº_sucursal, DNI_director, dirección,...) DNA / UC

Ejemplo:

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:1

Propagar una clave:

• Inconvenientes:

• se pierde la simetría

• consultas a la información de la entidad que interviene con (1,1) suponen combinación natural (por ejemplo, empleados que no dirigen sucursal)

• Ventajas:

• no pierde semántica (sobre la cardinalidad mínima 1) • se evitan valores nulos

• algunas consultas no precisan combinación de relaciones • NOTA: observar que la opción de borrado debe ser restringido o en cascada

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Interrelaciones 1:1

(12)

- 23 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Interrelaciones con atributos:

• si se crea una nueva relación, esos atributos se incluyen en esta relación. • si se propaga una clave, los atributos acompañan a la clave.

• si se propagan ambas claves, los atributos se incluyen en una de las entidades interralacionadas.

• si se fusionan en una relación, esta también contendrá esos atributos.

Interrelaciones con un atributo multivaluado:

• la interrelación habrá de transformarse en una relación, y su clave deberá contener ese atributo (además de la clave de una de las entidades o las dos)

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

POSEE(Cod_persona, cod_casa, participación_% )

PERSONA (Cod_persona, ...) CASA (Cod_casa, ...) PERSONA CASA Cod_persona (0,N) Posee N:M (0,N) Cod_casa %

(13)

- 25 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Tema 3.2:

Tema 3.2: Transformación

Transformación

Elementos Básicos

Elementos Básicos

Ejemplo Interrelación con atributos multivaluados

presta presta (1,N) (0,N) N:M Fecha_i. Fecha_f EJEMPLAR_DVD PERSONA Cod_Ejemplar Cod_Persona

EJEMPLAR _DVD( Cod ejem, título, ...

PERSONA( Cod )

PRESTA ( Cod_ejem, cod_pers., Fecha_i, Fecha_f ) )

_persona, nombre, apellidos, ...)

PRESTA ( Cod_ejem, cod )

5.3.1 Dependencias en Existencia/Identificación

5.3.2 Interrelaciones Exclusivas

5.3.2 Generalizaciones

5.3.4 Dimensión Temporal

5.3.5Atributos Derivados

5.3.6 Interrelaciones de grado superior a 2

Tema 3.3:

Tema 3.3: Transformación

Transformación

de las extensiones del E/R

de las extensiones del E/R

(14)

- 27 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Se transforman de la misma forma que las interrelaciones 1:N

Tema 3.3.1:

Tema 3.3.1: Dependencias en

Dependencias en

Existencia/Identificación

Existencia/Identificación

DVD tiene EJEMPLAR 1:N Cod_dvd N_orden ID (1,1) (0,n) Cod_Ejemplar DVD (Cod_dvd, …)

EJEMPLAR (Cod_dvd, N_orden, …) M E/R M R ¿Restricciones de Integridad? DC/UC

Tema 3.3.2:

Tema 3.3.2: Interrelaciones

Interrelaciones

Exclusivas

Exclusivas

ACTAS_CONGRESO(Cod_A., …) REVISTA(Cod_Rv, …)

ARTICULO(Cod_articulo, …, Cod_Rv, Cod_Actas) M E/R M R ARTÍCULO aparece aparece publica publica ACTAS CONGRESO REVISTA (1,n) (0,1) (1,n) (0,1) DC/UC DC/UC ¿QUÉ FALTA? CHECK

CHECK ((Cod_Rv IS NULL AND Cod_Ac IS NOT NULL) OR

(15)

- 29 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w El Modelo Relacional no dispone de instrumentos que

permitan representar tipos y subtipos.

w Se definen distintos métodos de transformación,

dependiendo de los objetivos perseguidos:

n Información semántica representada en el modelo n Eficiencia de acceso a los datos

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

TIPO

SUBTIPO 1 SUBTIPO 2

w Método 1

Utilizar una única relación para representar un tipo y todos

sus subtipos, añadiendo un atributo que indique el tipo de

entidad al que se hace referencia.

Puede hacerse cuando:

n los atributos de los subtipos son similares

n las interrelaciones que involucran a los subtipos son las mismas (o

no existen)

Será necesario implementar las restricciones semánticas

necesarias a través de CHECKS o DISPARADORES.

Tema 3.3.3:

(16)

- 31 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Método 1

Según los parámetros de la jerarquía, ¿qué restricciones hay

que definir?

Solapamiento

Sí ? El atributo discriminante puede tomar varios valores combinados.

No ? Verificar que sólo los atributos adecuados al subtipo toman valores.

Totalidad

Sí (Total) ? El atributo discriminante no puede tomar valores nulos. No (Parcial) ? El atributo discriminante debe admitir valores nulos.

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

w Método 1. Ejemplo, jerarquía parcial con solapamiento

PERSONA (DNI, nombre, dirección, tipo*, sueldo*, teléfono*, Curso*, Nota_media*)

¿Totalidad? El tipo admite valores

nulos

M E/R M R

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

PERSONA es_un es_un ESTUDIANTE (1,1) (0,1) (0,1) EMPLEADO TIPO

DNI nombre dirección

(17)

- 33 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Método 1. Ejemplo, Restricción exclusividad

Check (( Tipo= ‘Emp’

AND curso IS NULL AND nota_media IS NULL AND sueldo IS NOT NULL AND tfno IS NOT NULL OR

( Tipo = ‘Est’

AND sueldo IS NULL AND tfno IS NULL AND curso IS NOT NULL

AND nota_media IS NOT NULL ))

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

w Método 2

Utilizar una relación para representar al supertipo y tantas

relaciones como subtipos haya. Como antes habrá que

añadir un atributo que indique el tipo de entidad al que se

hace referencia.

Puede hacerse cuando:

n los subtipos tienen atributos dispares y/o interrelaciones

diferentes

n Incorporar mayor semántica en el grafo relacional

Será necesario implementar las restricciones semánticas

necesarias a través de CHECKS o DISPARADORES.

Tema 3.3.3:

(18)

- 35 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Método 2

Según los parámetros de la jerarquía, ¿qué restricciones hay

que definir?

Solapamiento

Sí ? El atributo discriminante puede tomar varios valores combinados. No ? Verificar que sólo aparecen entradas en la relación del subtipo

correspondiente.

Totalidad

Sí (Total) ? El atributo discriminante no puede tomar valores nulos y es necesario verificar que hay entradas para todas las tuplas del tipo. No (Parcial) ? El atributo discriminante debe admitir valores nulos.

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

w Método 2. Ejemplo, jerarquía parcial con solapamiento

PERSONA (DNI, nombre, dir, tipo*)

M E/R M R

EMPLEADO (DNI,sueldo, tfno)

ESTUD.(DNI,curso, nota_media)

DC/UC DC/UC

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

PERSONA es_un ESTUDIANTE (1,1) (0,1) (0,1) EMPLEADO TIPO

DNI nombre dirección

(19)

- 37 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Método 3

Se emplea una relación para cada subtipo; cada una de ellas

incluye los atributos comunes asociados al tipo.

Puede hacerse cuando:

n los subtipos tienen atributos dispares y/o interrelaciones

diferentes

n La mayoría de los accesos a los datos de los subtipos involucran en

mayor medida a los atributos comunes ? Eficiencia

Será necesario implementar las restricciones semánticas

necesarias a través de CHECKS o DISPARADORES.

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

w Método 3

Según los parámetros de la jerarquía, ¿qué restricciones hay

que definir?

Solapamiento

Sí ? Nada que controlar.

No ? Verificar que sólo aparecen entradas en la relación del subtipo correspondiente.

Totalidad

Sí (Total) ? Nada que controlar.

No (Parcial) ? NO PUEDE UTILIZARSE ESTA TRANSFORMACIÓN

Tema 3.3.3:

(20)

- 39 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Método 3. Ejemplo, jerarquía parcial con solapamiento

M R

EMP(DNI, nombre, dir, sueldo, tfno)

EST(DNI, nombre, dir, curso, nota_media)

M E/R

Tema 3.3.3:

Tema 3.3.3: Generalizaciones

Generalizaciones

PERSONA es_un ESTUDIANTE (1,1) (0,1) (0,1) EMPLEADO TIPO

DNI nombre dirección

sueldo tfno Curso Nota_media

EJEMPLOS

w Una empresa de estudios forestales desea almacenar en una base de datos información sobre sus empleados, que pueden ser administrativos u operarios de campo. Estos datos serán DNI, nombre, apellidos, fecha de contrato y fecha de baja. Además, para el caso de los operarios es necesario almacenar el coste por hora, así como el número de horas trabajadas.

w Los operarios de campo tienen la misión de tomar medidas sobre determinadas parcelas y los administrativos serán los encargados de grabar los datos de los formularios rellenados por los operarios de campo.

Tema 3.3.3:

(21)

- 41 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Se emplean las reglas de transformación de atributos multivaluados.

M E/R M R

N:M

PERSONA prestapresta DVD

DNI f_inicio f_fin Cod_DVD

(0,n) (0,n)

PERSONA (DNI, ……….) DVD (Cod_DVD, ……….)

PRESTA (DNI, Cod_DVD, f_inicio, f_fin, ……….)

DC/UC DC/UC

Tema 3.3.4:

Tema 3.3.4: Dimensión Temporal

Dimensión Temporal

Atributos cuyo valor se obtiene a través de una expresión.

Será necesario incluir un disparador para el cálculo del atributo

M E/R M R

DVD (Cod_DVD, Título, N_ejemplares)

N_ejemplares

D1

Tema 3.3.5:

Tema 3.3.5: Atributos Derivados

Atributos Derivados

DVD tiene EJEMPLAR_DVD 1:N Cod_DVD N_orden ID (1,1) (0,n) Cod_Ejemplar

(22)

- 43 ©LABDA Tema III: Transformación del esquema conceptual al relacional

En el modelo E/R se permiten interrelaciones entre más de dos

entidades.

INVESTIGADOR habla TEMA CONFERENCIA N:M:P

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

Siempre que sea posible, este tipo de interrelaciones se

representarán a través de varias interrelaciones binarias.

¿Semántica equivalente?

NO

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

INVESTIGADOR

investiga investiga

TEMA abarcaabarca CONFERENCIA

participa participa publica publica (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N) (1,N)

(23)

- 45 ©LABDA Tema III: Transformación del esquema conceptual al relacional

Otro ejemplo:

¿Semántica equivalente?

SI

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

INVESTIGADOR

escribe escribe

ARTÍCULO acepta CONFERENCIA

participa participa publica publica (1,N) (1,N) (1,1) (1,N) (1,N) (1,N) (1,1) (1,N) (1,N)

¿Cómo se transforma al Modelo Relacional este tipo de

interrelaciones?

wRegla General:

A I C B C_A C_B Atrib. C_B A ( C_A, ...) B ( C_B, ...) C ( C_C, ...) I (C_A, C_B, C_C, Atrib) DC/UC DC/UC DC/UC M E/R M R

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

(24)

- 47 ©LABDA Tema III: Transformación del esquema conceptual al relacional

wEs necesario un análisis más profundo teniendo en cuenta las

cardinalidades de la interrelación.

wCaso 1. Cardinalidad máxima n y mínima 1 en todas las

ramas de la interrelación:

Es aplicable la regla general.

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

w Caso 2. Cardinalidad máxima n y mínima 0 en una rama:

A ( C_A, ...) B ( C_B, ...) C ( C_C, ...) I (C_A, C_B, C_C, Atrib) I1 (C_A, C_B) DC/UC DC/UC DC/UC M E/R M R A I C B C_A C_C Atrib. C_B (0,n) (1,n) (1,n) I1

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

(0,n)

(25)

- 49 ©LABDA Tema III: Transformación del esquema conceptual al relacional

w Caso 3. Cardinalidad máxima n en dos ramas y máxima 1 en

la otra:

A ( C_A, ...) B ( C_B, ...) C ( C_C, ...) I (C_A, C_B, C_C, Atrib) DC/UC DC/UC DC/UC M E/R M R A I C B C_A C_C Atrib. C_B (0,1) (1,n) (1,n)

Tema 3.3.6:

Tema 3.3.6: Interrelaciones

Interrelaciones

Ternarias

Ternarias

Bibliografía

w BÁSICA:

[1] D. Cuadra, E. Castro, A. Iglesias, P. Martínez, F.J. Calle, C. de Pablo, H. Al-Jumaily y L. Moreno. Desarrollo de Bases de Datos: casos prácticos desde el análisis a la

implementación. Capítulo 2. RA-MA. 2007.

[2] M. Piattini, E. Marcos, C. Calero y B. Vela. Tecnología y Diseño de Bases de Datos. Capítulos 6 y16. RA-MA 2006.

w RECOMENDADA:

[3] A. Silberschatz, H. Korth & S. Sudarskhan. Fundamentos de Bases de Datos. 5ª Edición. Capítulo 7. McGraw Hill. 2006.

[4] R. Elmasri and S.B. Navathe. Fundamentos de Sistemas de Bases de Datos. Capítulo 3. Addison Wesley. 2007.

[5] A. de Miguel, M. Piattini y E. Marcos. Diseño de Bases de Datos Relacionales. Capítulo 3. RA-MA. 1999.

[6] A. de Miguel, P. Martínez, E. Castro, J.M. Cavero, D. Cuadra, A. Iglesias y C. Nieto. Diseño de Bases de Datos: Problemas Resueltos. Capítulo 2. RA-MA. 1999.

Referencias

Documento similar

Así pues, ha sido en esta fase donde se han puesto en práctica elementos referidos en los apartados de diseño gráfico, como la importancia de los elementos básicos del diseño como

Las actividades de este funcionario en una empresa pueden evaluarse con base en los estados financieros básicos de la misma. Esta función se refiere a la transformación de datos

Dado que la Industria 1 se proyectará para tarificar en alta, será necesario el diseño de un centro de transformación, de tipo cliente realizándose por tanto la medición del

Autor: Juan Antonio Cánovas Rebollo Director: Roque Molina Legaz. Cartagena, 31 de Mayo

Objetivo de la unidad: Identificar los conceptos básicos de la investigación mediante estructuras cognitivas de razonamiento lógico para que los alumnos obtengan un sustento real de

Se utilizan los principios de la Tecnología de la Enseñanza, propuesta por Skinner (1976), como instrumento lógico para el diseño instruccional de un programa

El proyecto tiene por objeto dotar de las instalaciones necesarias, tales como, líneas eléctricas de media tensión, líneas eléctricas de baja tensión y centros de transformación

Las señales con las que trabaja este puerto serie son digitales, de +12V (0 lógico) y -12V (1 lógico), para la entrada y salida de datos, y a la inversa en las señales de control.