diseño lógico estándar - kybele.etsii.urjc.es · diseño de bases de datos y seguridad de la...

Diseño Lógico Estándar

Diseño Lógico

Tema 12

Diseño de Bases de Datos y Seguridad de la Información - 2010www.kybele.urjc.es

Tecnología y Diseño de Bases de Datos M. Piattini, E. Marcos, C. Calero y B. VelaEd.: RA-MA, 2006

Diseño de Bases de Datos. Problemas Resueltos.A. de Miguel et al. Ed.: RA-MA, 2001

Bibliografía


Índice

1. Introducción

2. Etapas del Diseño Lógico

3. Reglas de Transformación

Modelo Básico

Extensiones


Metodología propuesta

MUNDO REAL

UD

DISEÑADOR

PROFESOR

ALUMNO

Imparte

clase

ESQUEMA

CONCEPTUAL

ESQUEMA LOGICO

(Relacional)

Introducción


ESQUEMA

CONCEPTUAL

REQUISITOS

DE LOS

PROCESOS Y

DEL ENTORNO

ENTRADAS

ESQUEMA

LÓGICO

ESTANDAR

ESQUEMA

LÓGICO

ESPECÍFICO

Diseño

Lógico

ESPECIFICACIONES

PARA LOS

PROCESOS

MODELO

LÓGICO

ESTÁNDAR

MODELO

LÓGICO

ESPECÍFICO

Etapas del Diseño Lógico


Diseño Lógico Estándar Esquema conceptual + Requisitos del proceso y entorno

Esquema Lógico eStándar (ELS) basado en un Modelo Lógico eStándar (MLS) correspondiente al SGBD.

El MLS será el mismo modelo de datos soportado por el SGBD que se vaya a utilizar, pero sin las restricciones ligadas a ningún producto comercial.

En nuestro caso el MLS es el modelo relacional. Otros ejemplos de MLS son: Jerárquico, Codasyl, …

El ELS se describirá utilizando un lenguaje estándar. En nuestro caso se usa SQL.



Diseño Lógico Específico Esquema Lógico eStándar (ELS) + Modelo Lógico

Específico (MLE) del SGBD Esquema Lógico Específico (ELE).

ELE será descrito en el lenguaje de definición de datos (LDD) del producto comercial que estemos utilizando.

En nuestro caso el producto comercial es Oracle.



Tres reglas básicas: Todo tipo de entidad se convierte en una relación.

Todo tipo de interrelación N:M se transforma en unarelación.

Para todo tipo de interrelación 1:N se realiza lo que sedenomina propagación de clave (regla general), o secrea una nueva relación.

PÉRDIDA DE SEMÁNTICA:- El modelo E/R no distingue entre entidades y interrelaciones.

- En las 1:N se puede perder hasta el nombre de la interrelación.

Reglas de Transformación


Cod_dep

DEPARTAMENTO PROFESOR CURSOPertenece Imparte

Cod_prof Cod_curso

1:N N:M

CURSO (Cod_curso, Nombre, Num_horas)

Clave ajena

Clave ajena

Clave ajena

Ejemplo

PROFESOR (Cod_prof, Nombre_p, ..., Cod_dep)

DEPARTAMENTO (Cod_dep, Nombre, ...)

IMPARTE (Cod_curso, cod_prof)


Dominios DominiosCREATE DOMAIN Estados_Civiles AS CHAR(1)

CHECK (VALUE IN ('S', 'C', 'V', 'D'))

PERO: Los productos no suelen tener dominios.

Entidades RelacionesCREATE TABLE Profesor ( …)

Atributos de entidades Columnas de la relaciónIdentificador Principal Clave Primaria

Identificador Alternativo UNIQUE, ¿NOT NULL?

No identificadores columnas, ¿NOT NULL?

Reglas de TransformaciónModelo Básico (I)


CREATE TABLE Profesor(

Cod_prof Códigos,

Nombre Nombres,

DNI DNIS NOT NULL,

Dirección Lugares,

Teléfono Nos_Teléfono,

Materia Materias,

PRIMARY KEY (Cod_Prof),

UNIQUE (DNI));

PROFESORCod_prof

NombreDNI

MateriaTeléfonoDirección

PROFESOR (Cod_prof, Nombre, DNI, Dirección, Teléfono, Materia)

Ejemplo


Interrelaciones:

según tipo de correspondencia y otros aspectossemánticos

N:M RelaciónClave primaria: concatenación Identificador Principal de los tipos de

entidad que asocia que serán también claves ajenas.

Opciones de borrado y modificación: restringido, puesta a nulo,puesta a valor por defecto, operación en cascada

Cardinalidades mínimas: restricciones, aserciones o disparadores (noSQL92)

Reglas de TransformaciónModelo Básico (II)


CREATE TABLE trabaja(

Cod_Empl Codigos_E

Cod_Proy Codigos_P,

…. ,

PRIMARY KEY (Cod_Empl, Cod_Proy),

FOREIGN KEY (Cod_Empl)REFERENCES Empleado

ON DELETE CASCADE

ON UPDATE CASCADE,

FOREIGN KEY (Cod_Proy) REFERENCESProyecto

ON DELETE CASCADE

ON UPDATE CASCADE));EMPLEADO

PROYECTO

trabaja

Cod_Empl

Cod_Proy

(1,n)

(1,n)

N:M EMPLEADO (Cod_Empl, ...)

PROYECTO (Cod_Proy, ...)

TRABAJA (Cod_Proy, Cod_Empl, ...)

B:C, M:CB:C, M:C

Ejemplo


1:N 2 posibilidades Propagar los Identificadores Principales en el sentido de la flecha (regla

básica)

Transformarlo en una relación

Criterios para transformar en relación: Si aparecen muchos valores nulos

Cuando se prevé que dicha interrelación en un futuro se convertirá enuna de tipo N:M

Cuando la interrelación tiene atributos propios y no deseamospropagarlos (a fin de conservar la semántica)

Mecanismos de borrado y actualización

Cardinalidades mínimas

Reglas de Transformación Modelo Básico (III)


JUGADOR EQUIPOpertenece

Cod_Jugador Cod_Equipo

TEMA

consta

(0,n)

(1,1)(0,n)

(1,1)

Ejemplo


1:1 Caso particular de N:M o 1:N Propagar Identificador Principal (incluso en los dos sentidos)

Transformarlo en una relación

Criterios:A. (0,1), (0,1) relación, evitando valores nulos

B. (0,1), (1,1) propagar la clave, evitando así valores nulos y captandomás semántica

C. (1,1), (1,1) propagar la clave, o incluso las dos

Reglas de TransformaciónModelo Básico (IV)


HOMBRE MUJERMatrimonio

Cod_hombre Cod_Mujer

(0,1) (0,1)

1:1

MATRIMONIO (Cod_hombre, Cod_mujer)

HOMBRE (Cod_hombre)

MUJER (Cod_mujer)

B:C, M:C

B:C, M:C

CASO A

Ejemplo


ENTIDAD

AIP

Atributo

Atributo multivaluado

INTERRELACIÓN

N:M

1:N

1:1

Modelo E/R Modelo Relacional

RELACIÓN

Clave Primaria

Columna

Relación

Relación

Propagación de clave a la entidad con cardinalidad máxima n

Propagación de clave de la entidad con cardinalidad mínima 0

Reglas de TransformaciónModelo Básico (V)


Dependencias en identificación y en existencia

Propagación de clave ajena con nulos no permitidos

Modificación y borrado en cascada

En el caso de dependencia en identificación, se concatenanlas claves

Restricciones de interrelaciones (exclusión, inclusión)

Checks, aserciones...

Reglas de TransformaciónExtensiones (I)


Tipos y subtipos Opción a:

Englobar tipos y subtipos en una única relación. Subtipos similares enatributos e interrelaciones.

Atributo discriminante: estudiar su comportamiento en caso detotalidad y exclusividad

Mayor eficiencia

Opción b:Tantas relaciones como tipos y subtipos. Múltiples atributos einterrelaciones.

Estudio de las restricciones

Menos eficiente que opción a), pero conserva más la semántica

Reglas de TransformaciónExtensiones (II)


Tipos y subtipos Opción c:

Relaciones distintas por cada subtipo que incluya los atributospropios y comunes

Estudio de restricciones

Mayor eficiencia ante determinadas consultas (por ej., en el caso demuchos accesos a atributos comunes). Posibles redundancias en casode solapamiento. ¿En el caso de jerarquía parcial?

Reglas de TransformaciónExtensiones (III)


Documento

LibroArtículo

Opción a: una sola relación

Documento (código, titulo, idioma,... tipo)

Opción b: tres relaciones

Documento (código, titulo, idioma,...)

Artículo (código, ...) Libro (código, ...)

Opción c: dos relaciones

Artículo (código, titulo, idioma,...)

Libro (código, titulo, idioma,...)

Ejemplo


Atributos multivaluados

En entidades

En interrelaciones

Dimensión temporal

Atributos derivados

Almacenar las columnas o calcularlas

Atributos compuestos

Columnas

Reglas de TransformaciónExtensiones (IV)


Interrelaciones de grado > 2

Grafo Relacional

Claves primarias: subrayado

Claves alternativa: negrita

Claves ajenas: cursiva

Atributos que admiten valores nulos: asterisco

Opciones de borrado y modificación: restringido (R), en cascada (C), puesta a nulos (N), puesta a valor por defecto (D)

Reglas de TransformaciónExtensiones (V)

diseño lógico estándar - kybele.etsii.urjc.es · diseño de bases de datos y seguridad de la...

Documents