Base de Datos II Modelo Relacional

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

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

6. Fecha CodMateria NroAlumno Inscripto MATERIAS ALUMNOS NombreMat NombreAlumno Pasaje – Relaciones (1) Ejemplo 1 (relación N:M, un alumno se puede inscribir a una materia varias veces) 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 MATERIAS ALUMNOS NombreMat NombreAlumno ALUMNOS( NroAlumno, NombreAlumno) MATERIAS( CodMateria, NombreMat) INSCRIPTO (NroAlumno, CodMateria, Fecha)

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

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

10. CodSec CI Trabaja 0:1 1:N SECCIONES EMPLEADOS NomSec NomEmp FecDesde FecHasta Periodo Trabaja Pasaje – Relaciones (4) Ejemplo 2 : Un empleado trabaja en una única sección en un determinado período 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. NroSala NomHosp Pertenece 1:N 1:N SALA HOSPITAL camas Direccion 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( 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 Sm S2 . . . . . . . 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 DOCENTE ESTUDIANTE

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 DOCENTE ESTUDIANTE

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 Versión 1 PERSONAS( CI, Nombre, TipoPersona) Nombre ADMINISTRATIVO DOCENTE ESTUDIANTE 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 DOCENTE ESTUDIANTE ADMINISTRATIVO PERSONAS Puesto Grado 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 ADMINISTRATIVO DOCENTE ESTUDIANTE Puesto Grado DOCENTE ADMINISTRATIVO

21. C.Clave = Si.clave 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