Transcript Pasaje – Relaciones

Base de Datos
II
Modelo Relacional
Pasaje MER - Relacional
Proceso de transformación de un concepto a una
implementación
Se convierten en tablas:
Entidades fuertes y Atributos
Relaciones
Agregaciones
Entidades Débiles
No existe un pasaje totalmente automatizado
Pasaje – Entidades Fuertes (1)
Cada atributo común se coloca como un atributo de la tabla
Atributos compuestos se colocan como un atributo separado por cada
hoja
Atributos claves se colocan como subrayados (puede ser clave compuesta)
CI
Nombre
Sexo {M,F}
EMPLEADOS
Dirección
Nro_puerta
Departamento
Calle
Ciudad
EMPLEADOS( CI, Nombre, Sexo, Departamento, Ciudad, Calle, Nro_puerta)
Pasaje – Entidades Fuertes (2)
Atributos multivaluados generan una nueva tabla
Contiene un atributo por cada componente (similar a caso
anterior)
Debe contener además la clave de la Entidad.
CI
EMPLEADOS
Nombre
Sexo {M,F}
Dirección
Teléfonos *
Departamento
EMPLEADOS +
EMP_TELEFONOS( CI, nro_telefono)
Nro_puerta
Calle
Pasaje – Relaciones (1)
Por regla general se debe crear una nueva tabla conteniendo las claves de las
entidades que relaciona.
Si contienen atributos propios se deben incluir.
La clave dependerá de restricciones de la realidad. Por lo general será la pareja de
claves de ambas entidades.
atributos
Clave_a
A
R
R (Clave_a, Clave_b, ...... atributos de R…. )
Clave_b
B
Pasaje – Relaciones (1)
Ejemplo 1 (relación N:M, un alumno se puede inscribir a una materia varias veces)
Fecha
NroAlumno
ALUMNOS
Inscripto
CodMateria
MATERIAS
NombreAlumno
ALUMNOS( NroAlumno, NombreAlumno)
MATERIAS( CodMateria, NombreMat)
INSCRIPTO (NroAlumno, CodMateria, Fecha)
NombreMat
Pasaje – Relaciones (2)
Ejemplo 2 : Un alumno se puede inscribir a una materia pero una sola vez para cada
fecha.
Fecha
NroAlumno
ALUMNOS
Inscripto
CodMateria
MATERIAS
NombreAlumno
ALUMNOS( NroAlumno, NombreAlumno)
MATERIAS( CodMateria, NombreMat)
INSCRIPTO (NroAlumno, CodMateria, Fecha)
NombreMat
Pasaje – Relaciones (3)
Si la relación es 1:N puede NO CREARSE nueva tabla
Se “incrustan” la clave en la entidad con cardinalidad N
Si contiene atributos propios es mejor crearla.
Si la relación es PARCIAL sobre B, cuando un elemento de B no esté
relacionado con alguno de A Clave_a contendrá NULL
Si la relación es TOTAL sobre B, se debe definir una restricción de
integridad (referencial) de B hacia A.
Clave_b
Clave_a
0:1
A
R
1:N
B
B (Clave_b, … atributos de B, Clave_a)
Pasaje – Relaciones (4)
Ejemplo 1 : Un empleado trabaja en una única sección.
CI
CodSec
0:1
EMPLEADOS
1:N
Trabaja
NomEmp
EMPLEADOS( CI, NomEmp, CodSec)
SECCIONES( CodSec, NomSec)
SECCIONES
NomSec
Pasaje – Relaciones (4)
Ejemplo 2 : Un empleado trabaja en una única sección en un determinado período
FecDesde
Periodo
CI
0:1
EMPLEADOS
FecHasta
CodSec
1:N
Trabaja
SECCIONES
NomEmp
Genera una nueva tabla :
EMPLEADOS( CI , NomEmp)
SECCIONES( CodSec, NomSec)
TRABAJA (CI, CodSec, FecDesde, FecHasta)
NomSec
Pasaje – Relaciones (5)
Mínimos y máximos definidos
Cuando existen mínimos > 1 o cotas superiores no se
pueden definir mediante restricciones estáticas.
Deben ser definidas por código. Ej : triggers o
mediante el programa que utilice la base de datos, por
ejemplo Visual Basic.
Pasaje – Agregaciones
Se tratan como una relación.
Independientemente de las cardinalidades se debe
implementar como una tabla aparte (pues van a ser
nuevamente relacionadas con alguna otra Entidad)
Pasaje – Entidades Débiles (1)
Son casos particulares de relación 1:N
No se crea tabla adicional para la relación.
Se agrega en la tabla correspondiente a la Entidad Débil la clave
de la Entidad Fuerte.
La nueva clave está formada entonces por este nuevo conjunto.
Debe haber una clave foránea desde la Entidad Débil a la Fuerte.
NroSala
NomHosp
1:N
1:N
HOSPITAL
Pertenece
Direccion
HOSPITAL( NomHosp, Direccion)
SALA(NroSala, NomHosp, camas)
SALA
camas
Pasaje – Entidades Débiles (2)
CLAVE FORÁNEA
Se dice que B posee clave foránea hacia A si todo elemento de tabla
B debe tener su atributo clave dentro de un atributo clave de alguna
tupla de tabla A.
Decimos que Fk(B) referencia Pk(A)
En nuestro ejemplo :
Toda tupla de SALAS debe tener una pareja <NomHosp, NroSala> en alguna
tupla de HOSPITALES con el mismo NomHosp.
Además :
NomHosp debe ser CLAVE en HOSPITALES
NomHosp,NroSala es CLAVE en SALAS
Pasaje – Categorizaciones (1)
C
S1
S2
Clave
Atributos_C
.......
Sm
C( Clave_C, …Atributos_C….)
S1(Clave_C, … Atributos_propios_S1)
Existen diferentes implementaciones, dependiendo de la cantidad de
atributos, solapamiento y completitud.
Pasaje – Categorizaciones (2)
Caso 1 : Relación No-total y C posee atributos propios
1.
2.
3.
Crear una tabla para C
Crear una tabla para cada sub-categoría Si conteniendo sus atributos propios +
Clave(C)
Crear restricciones de integridad desde cada clave de Si a C
C( Clave_C)
 Si  Si (Clave_C, … Atributos_propios_Si)
y crear Integridad Referencial de Si a C
Ejemplo
PERSONAS
CI
PERSONAS( CI, Nombre)
Nombre
Grado
Nro_est
ESTUDIANTE
DOCENTE
ESTUDIANTES( CI, Nro_est)
DOCENTES( CI , Grado)
ESTUDIANTES.CI referencia PERSONAS.CI
DOCENTES.CI referencia PERSONAS.CI
Pasaje – Categorizaciones (3)
Caso 2 : Relación No-total y C no posee atributos propios (solo clave)
1. Crear una tabla para cada sub-categoría Si conteniendo sus atributos
propios + Clave(C)
2. No es necesario crear C pues es una abstracción.
C se puede implementar como una vista : C = П(S1) U П(S2) … U П(Sn)
Clave_C
Clave_C
Clave_C
Ejemplo
AAAA
aaa
PERSONAS( CI, Nombre)
Nombre
Grado
Nro_est
ESTUDIANTE
DOCENTE
ESTUDIANTES( CI, Nro_est)
DOCENTES( CI , Grado)
ESTUDIANTES.CI referencia PERSONAS.CI
DOCENTES.CI referencia PERSONAS.CI
Pasaje – Categorizaciones (4)
Caso 3 : Relación Total y sub-categorias SIN atributos propios.
Crear una tabla para C
2 variantes :
a) Agregar a C un atributo para discriminante que indica la
categoria a que pertenece cada tupla.
b) Agregar a C tantos atributos booleanos como sub-categorias de
C existan.
Ej.
PERSONAS
CI
Nombre
Versión 1
PERSONAS( CI, Nombre, TipoPersona)
ESTUDIANTE
DOCENTE
ADMINISTRATIVO
Versión 2
PERSONAS( CI, Nombre, EsEstudiante, EsDocente, EsAdministrativo)
Pasaje – Categorizaciones (6)
Caso 4 : Si todas las categorías poseen atributos propios
Opción 1 :
Implementar una única tabla conteniendo la unión de todos los atributos de C
+ Si utilizando 1 de las 2 técnicas de caso anterior (tener en cuenta si hay o no
solapamiento)
 Rápido de implementar
 Genera gran cantidad de datos NULL
 Exige correspondiencia entre atributos : implementar código

Ej: Si Tipo=“ADMINISTRATIVO”  atributos que no correspondan
PERSONAS
a ADMINISTRATIVO deben valer NULL o ser ignorados
Implementación obscura, lejana de modelo conceptual
CI
Nombre
Direccion
Ej: (sin solapamiento)
DOCENTE
ESTUDIANTE
ADMINISTRATIVO
PERSONAS
CI
Nombre
Direccion
Tipo
NroEst
Puesto
Grado
1
Juan
Mercedes 1467
ESTUDIANTE
557
NULL
NULL
2
Maria
San jose 321
DOCENTE
NULL
NULL
2
3
Pedro
18 de Julio 1234
ADMINISTRATIVO
NULL
Recepcionista
NULL
4
Ana
Sarandi 320
DOCENTE
558
NULL
1
NroEst
Grado
Puesto
Pasaje – Categorizaciones (7)
Caso 4 : Si todas las categorías poseen atributos propios
Opción 2 :
a) No implementar C
b) Implementar cada subcategoria Si como una tabla independiente conteniendo sus
atributos + atributos de C
Cubre solapamiento y totalidad.
PERSONAS
 Fácil de implementar
 Más prolijo que versión anterior
 Puede generar redundancia !!!!!!!!!
Nombre
Direccion
ADMINISTRATIVO
DOCENTE
ESTUDIANTE
Ej: Si Ana es Docente y también Administrativo
DOCENTE
CI
Puesto
Grado
ADMINISTRATIVO
C
I
Nom
bre
Direccion
Gra
do
C
I
Nom
bre
Direccion
Puesto
4
Ana
Sarandi 320
1
4
Ana
…
…
…
...
Mercedes
1451
Telefonist
a
…
…
… …
Pasaje – Categorizaciones (8)
Caso 4 : Si todas las categorías poseen atributos propios
Opción 3 :
a) Implementar C como una tabla independiente
b) Implementar cada subcategoria Si como una tabla independiente + Clave( C )
c) Incluir restricciones de integridad desde Si hacia C
Cubre solapamiento y totalidad.
Luego se pueden definir vistas de cada Si para presentar una visión más cercana a la
conceptual.
Vi = C
Si
C.Clave = Si.clave
 Evita redundancia
 Prolijidad : más cercano al diseño conceptual
 Exige más “inteligencia” para agregar registros
 Costo de implementar/mantener las vistas