Base de Datos II Modelo Relacional.

Presentación del tema: "Base de Datos II Modelo Relacional."— Transcripción de la presentación:

1 Base de Datos II Modelo Relacional

2 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

3 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 EMPLEADOS Sexo {M,F} Dirección Nro_puerta Departamento Calle Ciudad EMPLEADOS( CI, Nombre, Sexo, Departamento, Ciudad, Calle, Nro_puerta)

4 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 Nombre EMPLEADOS Sexo {M,F} Dirección Teléfonos * Nro_puerta Departamento Calle EMPLEADOS + EMP_TELEFONOS( CI, nro_telefono)

5 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. A B R Clave_b Clave_a atributos R (Clave_a, Clave_b, atributos de R…. )

6 Pasaje – Relaciones (1) Ejemplo 1 (relación N:M, un alumno se puede inscribir a una materia varias veces) ALUMNOS MATERIAS Inscripto CodMateria NombreAlumno NroAlumno NombreMat Fecha ALUMNOS( NroAlumno, NombreAlumno) MATERIAS( CodMateria, NombreMat) INSCRIPTO (NroAlumno, CodMateria, Fecha)

7 Pasaje – Relaciones (2) Ejemplo 2 : Un alumno se puede inscribir a una materia pero una sola vez para cada fecha. Fecha CodMateria NroAlumno Inscripto ALUMNOS MATERIAS NombreMat NombreAlumno ALUMNOS( NroAlumno, NombreAlumno) MATERIAS( CodMateria, NombreMat) INSCRIPTO (NroAlumno, CodMateria, Fecha)

8 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. A B R Clave_b Clave_a 1:N 0:1 B (Clave_b, … atributos de B, Clave_a)

9 Pasaje – Relaciones (4) Ejemplo 1 : Un empleado trabaja en una única sección. EMPLEADOS SECCIONES Trabaja CodSec NomEmp CI NomSec 1:N 0:1 EMPLEADOS( CI, NomEmp, CodSec) SECCIONES( CodSec, NomSec)

10 Pasaje – Relaciones (4) EMPLEADOS( CI , NomEmp)
Ejemplo 2 : Un empleado trabaja en una única sección en un determinado período Periodo FecDesde FecHasta Trabaja EMPLEADOS SECCIONES Trabaja CodSec NomEmp CI NomSec 1:N 0:1 Genera una nueva tabla : EMPLEADOS( CI , NomEmp) SECCIONES( CodSec, NomSec) TRABAJA (CI, CodSec, FecDesde, FecHasta)

11 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.

12 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)

13 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. HOSPITAL SALA Pertenece NroSala Direccion NomHosp camas 1:N HOSPITAL( NomHosp, Direccion) SALA(NroSala, NomHosp, camas)

14 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

15 Pasaje – Categorizaciones (1)
Clave C Atributos_C S1 S2 Sm C( Clave_C, …Atributos_C….) S1(Clave_C, … Atributos_propios_S1) Existen diferentes implementaciones, dependiendo de la cantidad de atributos, solapamiento y completitud.

16 Pasaje – Categorizaciones (2)
Caso 1 : Relación No-total y C posee atributos propios 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 CI PERSONAS( CI, Nombre) ESTUDIANTES( CI, Nro_est) DOCENTES( CI , Grado) ESTUDIANTES.CI referencia PERSONAS.CI DOCENTES.CI referencia PERSONAS.CI PERSONAS Nombre Grado Nro_est ESTUDIANTE DOCENTE

17 Pasaje – Categorizaciones (3)
Caso 2 : Relación No-total y C no posee atributos propios (solo clave) Crear una tabla para cada sub-categoría Si conteniendo sus atributos propios + Clave(C) 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 aaa PERSONAS( CI, Nombre) ESTUDIANTES( CI, Nro_est) DOCENTES( CI , Grado) ESTUDIANTES.CI referencia PERSONAS.CI DOCENTES.CI referencia PERSONAS.CI AAAA Nombre Grado Nro_est ESTUDIANTE DOCENTE

18 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. CI PERSONAS Nombre Versión 1 PERSONAS( CI, Nombre, TipoPersona) ESTUDIANTE DOCENTE ADMINISTRATIVO Versión 2 PERSONAS( CI, Nombre, EsEstudiante, EsDocente, EsAdministrativo)

19 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 a ADMINISTRATIVO deben valer NULL o ser ignorados  Implementación obscura, lejana de modelo conceptual Ej: (sin solapamiento) CI PERSONAS Nombre Direccion ESTUDIANTE DOCENTE ADMINISTRATIVO PERSONAS CI Nombre Direccion Tipo NroEst Puesto Grado 1 Juan Mercedes 1467 ESTUDIANTE 557 NULL 2 Maria San jose 321 DOCENTE 3 Pedro 18 de Julio 1234 ADMINISTRATIVO Recepcionista 4 Ana Sarandi 320 558 Grado Puesto NroEst

20 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.  Fácil de implementar  Más prolijo que versión anterior  Puede generar redundancia !!!!!!!!! Ej: Si Ana es Docente y también Administrativo CI PERSONAS Nombre Direccion ESTUDIANTE DOCENTE ADMINISTRATIVO Grado Puesto DOCENTE ADMINISTRATIVO CI Nombre Direccion Grado 4 Ana Sarandi 320 1 … ... CI Nombre Direccion Puesto 4 Ana Mercedes 1451 Telefonista …

21 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.  Evita redundancia  Prolijidad : más cercano al diseño conceptual  Exige más “inteligencia” para agregar registros  Costo de implementar/mantener las vistas Vi = C Si C.Clave = Si.clave