Base de Datos II Modelo Relacional.

Slides:



Advertisements
Presentaciones similares
IBD Clase 13.
Advertisements

Pasaje a Tablas.
Diseño de Bases de Datos
Normalizaciones de Bases de Datos
Unidad II Modelo Entidad-Relación
Modelo Entidad Relación
Rocío Contreras Águila Primer Semestre 2010
Modelo entidad-relación
Diseño de Bases de Datos
Teórico: Modelo Relacional
MER.
Bases de Datos Modelo Relacional.
Maestría en Bioinformática Bases de Datos y Sistemas de Información Diseño Conceptual Ing. Alfonso Vicente, PMP
Elementos para Interpretar el Modelo Conceptual de Datos
MODELO RELACIONAL.
LLAVES EN BASES DE DATOS
MODELO ENTIDAD RELACIÓN MER
INTELIGENCIA ARTIFICIAL
Maestría en Bioinformática Bases de Datos y Sistemas de Información Del MER al MR Ing. Alfonso Vicente, PMP
B ASES DE DATOS 1 Teórico: Diseño Conceptual. M ODELADO C ONCEPTUAL Primera etapa en el diseño de una BD Sub-etapas: Estudio del problema real Especificación.
Pasaje a Tablas Prof. Leonardo Carámbula – Sistemas de Bases de Datos – Informática – E.M.T. – I.T.S.
MODELOS DE DATOS.
MODELO RELACIONAL.
MODELO RELACIONAL.
Modelo Relacional Base de Datos I.
Modelo Entidad-Relación
Universidad Interamericana de P.R. Departamento Informática Curso 3850 Dr. Rafael Nieves.
UNIDAD I Conceptos Básicos.
MÓDULO II: FUNDAMENTOS DE BASE DE DATOS
BASE DE DATOS I Clase # 1.
Tema 4. DISEÑO LÓGICO Objetivos
Sistemas de Bases de Datos I
Viviana Poblete López Módulo: Modelo de Datos
Métrica v2.1 Técnicas: Modelado de datos (Parte 2)
MODELADO DE DATOS (PARTE 2) Viviana Poblete L. Modelo de Datos I.
Colegio de Bachilleres Plantel 13 Xochimilco-Tepepan Integrantes: Karen Elizabeth González Monroy Elizabeth De Jesús Vergara Grupo:308.
Normalización en una base de datos
Lic. en Inf. Manuel Álvaro Pacheco Hoyo. Una base de datos o banco de datos (en inglés: database) es un conjunto de datos pertenecientes a un mismo contexto.
 RELACIÓN O TABLA (RELATION, TABLE): LISTA DE VALORES CON UN NOMBRE, DONDE CADA VALOR ES UNA FILA (REGISTRO), COMPUESTO POR 1 O MÁS COLUMNAS (CAMPOS).
Bases de datos relacionales
Diseño de una Base de Datos
DISEÑO DE BASES DE DATOS
Modelos de Datos.
APLICACIÓN DE NUEVAS TECNOLOGÍAS EN LA CONSERVACIÓN Y ANÁLISIS DEL PATRIMONIO CULTURAL Pensar Relacionalmente: Bases de Datos Relacionales (una visión.
DISEÑO DE BASES DE DATOS
Seminario de Informática Elementos Conceptuales
Restricciones de Integridad
PASO DEL ESQUEMA E-R AL MODELO RELACIONAL
Base de Datos I. El proceso por el que se definen las diferentes subclases de una superclase Ejemplo: Se requiere guardar la información de los empleados,
EQUIPO:#3 GRUPO:304 NOMBRES: Lizbeth Nava Barón y Erick Ali Mejía.
Diagramas.
Base de Datos I. El proceso por el que se define una superclase a través de diferentes subclase. Ejemplo: Se tiene las entidades Cuenta de Ahorro y Cuenta.
3. Modelo de datos Prof: Lcdo. Luis Peña.
Teórico: Pasaje del MER al MR
Curso Introductorio a Bases de Datos.
Bases de Datos Modelo Relacional.
2do. Parcial Bases de datos Octubre Introducción a bases de datos Efectúe la definición conceptual de Modelos de Datos. (T1) Mencione.
Unidad II Diseño Conceptual de una Base de Datos:
MODELO LOGICO BASE DE DATOS
UNIVERSIDAD LATINA II.- CONSTRUCCIÓN DE LA BASE DE DATOS. E.I. L.E. Prof. Ramón Castro Liceaga.
M ODELO DE DATOS DE ENTIDAD - VÍNCULO El modelo de entidad-vínculo es un modelo de datos conceptual de uso muy extendido. Este modelo, y sus variantes,
BASE DE DATOS DISTRIBUIDAS Objetivo
BASES DE DATOS CONCEPTOS BASICOS Elizabeth Maite Zarate Machaca “El tratamiento eficiente de la información al servicio del usuario”
Tema 2: Diseño de Bases de Datos relacionales
¿Qué es una base de datos? Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada. Desde.
Base de Datos I – Ing. Mary Carlota Bernal J.
Modelo entidad-relación extendido EER L.I. José de Jesús Eduardo Barrientos Avalos.
Modelo entidad/interrlación Tema 2. Parte 2. Modelo E/IR Utiliza un conjunto de símbolos y reglas para representar los datos y las relaciones entre ellos.
Base de Datos I – Ing. Mary Carlota Bernal J. BASE DE DATOS I Conversión del Modelo Entidad – Relación a Relacional.
 Gregorio López González  Norberto Misael Valtierra Ornelas  Ricardo Enrique Pérez Andrade  Luis Rodríguez Valencia.
Transcripción de la presentación:

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

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…. )

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)

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)

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)

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)

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)

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

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

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

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)

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

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 …

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