unidad ii esp parte 2
TRANSCRIPT
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
UNIDAD II (CAP 3)Modelando Datos utilizando El Modelo Entidad-Relación(ER)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 3
Esquema del Capitulo.
Visión general del proceso de diseño de base de datos Ejemplo de aplicación de base de datos (EMPRESA) Conceptos del modelo ER
Entidades y AtributosTipos de entidad, conjuntos de valores y atributos claveLas relaciones y los tipos de relacionesEntidad de Tipo Débil Funciones y atributos en los tipos de relaciones
Diagramas ER – Notación Diagrama ER para el esquema EMPRESA Notaciones alternativas - diagramas de clases UML, otros
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 4
Visión general del proceso de diseño de base de datos Dos principales actividades :
Diseño de Base de datos Aplicaciones de diseño
Enfoque en este capítulo en el diseño de bases de datos Para diseñar el esquema conceptual para una
aplicación de base de datos Aplicaciones de diseño se centra en los
programas y las interfaces que el acceso a la base de datos En general se considera parte de la ingeniería de
software
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 5
Visión general del proceso de diseño de base de datos
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Uso de Modelos Conceptuales de Datos de Alto Nivel para el diseño de base de datos Recolección y Análisis de Requerimientos.
Diseñadores de base de datos entrevista a los usuarios de base de datos para comprender y documentar los requisitos de datos.
Resultado: los requerimientos de datos. Requisitos funcionales de la aplicación
Slide 3- 6
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Uso de Modelos Conceptuales de Datos de Alto Nivel para el diseño de base de datos Esquema conceptual
Diseño conceptual Descripción de los requisitos de datos Incluye descripciones detalladas de los tipos de
entidades, relaciones y restricciones. Transformado a partir del modelo de alto nivel de
datos en la aplicación del modelo de datos
Slide 3- 7
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Uso de Modelos Conceptuales de Datos de Alto Nivel para el diseño de base de datos Diseño Lógico o Mapeo de Modelamiento de
Datos. El resultado es un esquema de base de datos en
la aplicación del modelo de datos del DBMS
Fase de diseño físico Estructuras internas de almacenamiento, las
organizaciones de archivo, índices, las vías de acceso, y los parámetros de diseño físico de la base de datos de archivos especificados
Slide 3- 8
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 9
Un ejemplo de Aplicacion de BD
Tenemos que crear un esquema de base de datos basado en lo siguiente (simplificado) los requisitos de la base de datos EMPRESA : Los empleados, departamentos y proyectos Empresa está organizada en departamentos Departamento controla un número de proyectos Empleado: almacenar el nombre de cada
empleado, número de seguro social, dirección, salario, sexo (género), y fecha de nacimiento
Lleva un registro de las personas a cargo de cada empleado
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Cada empleado trabaja para un departamento, pero puede trabajar en varios proyectos.
Hacemos un seguimiento del número de horas por semana que un empleado en la actualidad trabaja en cada proyecto.
También no perder de vista el supervisor directo de cada empleado. Es decir, Cada empleado puede tener un número de dependientes.
Slide 3- 10
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 12
Conceptos del Modelo Entidad-Relacion
Entidad Cosa en el mundo real con existencia independiente
Atributos Las propiedades en particular que describen la entidad
Los tipos de atributos: Atributo Compuesto vrs Simples (atómicas) Atributo de un solo valor vrs varios valores Atributo Almacenado vrs derivado Valores NULL Los atributos complejos
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 13
Tipos de Atributos(1)
Simple Cada entidad tiene un valor único atómica para el atributo.
Por ejemplo, número de seguro social o sexo. Compuesto
El atributo puede estar compuesto por varios componentes. Por ejemplo:Dirección (número de apartamento, Casa, calle, ciudad, estado, código postal, país), o Nombre (Nombre, Segundo Nombre, apellidos).
Compuestos Puede formar una jerarquía en algunos componentes que
en si mismos son compuestos. Mutivaluado
Una entidad puede tener varios valores para ese atributo. Por ejemplo, el color de un coche o grados previos de un estudiante.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 16
Tipos de Entidades y Atributos(1)
Las entidades con los atributos básicos misma se agrupan en un tipo de entidad. Por ejemplo, la entidad tipo EMPLEADO y
PROYECTO. Un atributo de un tipo de entidad para la
que cada entidad debe tener un valor único se llama un atributo clave del tipo de entidad. Por ejemplo, número de Seguro Social del
Empleado. .
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 17
Entity Types and Key Attributes (2)
Clave o restricción de unicidad Atributos cuyos valores son distintos para cada
entidad individual en conjunto de entidades. Clave de atributo
Propiedad de unicidad debe tener para cada conjunto de entidades del tipo de entidad.
Cada llave esta subrayada. Simple o compuesto.
Conjunto de Valor (o dominio de valores) Especifica el conjunto de valores que pueden ser
asignados a ese atributo para cada entidad individual
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 18
Desplegando Tipo Entidad
En los diagramas ER, un tipo de entidad se muestra en una caja rectangular Los atributos se muestran en óvalos Cada atributo está relacionada con su tipo de
entidad Componentes de un atributo compuesto están
conectados con el óvalo que representa el atributo compuesto
Cada atributo clave aparece subrayado
Los atributos multivalorados aparecen en los óvalos doble.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 19
Entidad Tipo Vehiculo, con dos llaves y atributos.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Tipo Entidad, Conjunto Entidad
Tipo Entidad Coleccion ( o conjunto) de entidades que tienen
los mismos atributos.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 21
Diseño Inicial Tipo Entidad:EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 22
Introducción a las Relaciones
Relación Cuando un atributo de un tipo de entidad se
refiere a otro tipo de entidad. Representar a referencias como las relaciones no
los atributos El Modelo ER tiene tres conceptos principales:
Entidades Atributos Relaciones
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 23
Relaciones y Tipos de Relaciones(1)
Una relación se relaciona dos o más entidades distintas con un significado específico.
Por ejemplo, EMPLEADO John Smith trabaja en el proyecto ProductX o empleado de Franklin Wong maneja el departamento de investigación.
Las relaciones del mismo tipo se agrupan o escrito en un tipo de relación.
Por ejemplo, el tipo de relación TRABAJA_EN en que los empleados y los proyectos participan, o el tipo de relación GESTIONA en el que participan empleados y departamentos.
El grado de un tipo de relación es el número de tipos de entidades participantes.
Tanto la gestión y TRABAJA_EN son las relaciones binarias.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 24
Instancia de relación WORKS_FOR N:1 Relación entre EMPLOYEE y DEPARTMENT
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 25
Instancias de Relación de M:N WORKS_ON relación entre EMPLOYEE y PROJECT
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 26
Tipo Relación vs Conjunto Relacion(1)
Tipo de relación: Es la descripción del esquema de una relación Identifica el nombre y la relación de los tipos de
entidad participante También identifica ciertas limitaciones relación
Conjunto Relación: El actual conjunto de instancias de relación
representados en la base de datos El estado actual de un tipo de relación
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 27
Tipo Relación vs Conjunto Relacion(2)
En un diagrama ER, nosotros representamos el tipo de relación como los siguientes: Cuadro en forma de diamante se utiliza para
mostrar un tipo de relación Relacionada con los tipos de entidades que
participan a través de líneas rectas
.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 28
Refinando el Esquema Compañia Mediante el examen de los requisitos, seis tipos de
relaciones se identifican Todas las relaciones son binarias( grado 2) Se enumeran a continuación con sus tipos de entidades
participantes: WORKS_FOR (entre EMPLOYEE, DEPARTMENT) MANAGES (tambien entre EMPLOYEE, DEPARTMENT) CONTROLS (entre DEPARTMENT, PROJECT) WORKS_ON (entre EMPLOYEE, PROJECT) SUPERVISION (entre EMPLOYEE (como subordinado),
EMPLOYEE (como supervisor)) DEPENDENTS_OF (entre EMPLOYEE, DEPENDENT)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 29
DIAGRAMA ER – Tipos de Relación son:WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 30
Tipo Relación Recursiva
Un tipo cuya relación con el tipo de la misma entidad que participan en distintas funciones
Ejemplo: La Relación SUPERVISION EMPLOYEE participa dos veces en dos funciones
distintas : Rol supervisor (o jefe) el papel Rol supervisado (o subordinado)
Cada instancia de relación relaciona dos distintas entidades Empleado:
Un empleado en el rol supervisor Un empleado en el rol supervisado
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 31
Entidades Tipo Débil Una entidad que no tiene un atributo clave. Una entidad débil debe participar en un tipo de relación con la
identificación de propietario o la identificación de tipo de entidad Las entidades se identifican por la combinación de :
Una de las claves parciales del tipo de entidad débil. La entidad particular que esta relacionado en la identificación del
tipo de entidad. Example:
Una entidad dependiente es identificado por el nombre del dependiente, y el específico empleado con quien el dependiente esta relacionado.
Nombre del dependiente es la clave parcial Dependiente es un tipo de entidad débil EMPLEADO es su tipo de identificación de la entidad a través de
identificar el tipo de relación «Depende de» DEPENDENT_OF
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 32
Restricciones sobre Relaciones
Restricciones sobre Tipos de Relaciones (Tambien conocido como relación de restricciones) Relación de cardinalidad (especifica la máxima
participación) Uno a Uno (1:1) Uno a muchos (1:N) o Muchos a uno (N:1) Muchos a Muchos (M:N)
Existencia de dependencia de restricción (especifica la participación mínima) (también llamada restricción de participación)
cero (participación opcional, no existencia-dependiente) uno o más (la participación obligatoria, la existencia-
dependiente)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 34
Relación de Muchos a Muchos (M:N)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 35
Desplegando una relación Recursiva. En un tipo de relación recursiva.
Ambas participaciones son el mismo tipo de entidad en diferentes roles.
Por ejemplo, Relación SUPERVISION entre EMPLOYEE (en role de supervisor o jefe) y (otro) EMPLOYEE (en rol de subordinado o trabajador).
En la siguiente figura, primer rol participa etiquetado con 1 y el segundo rol participa etiquetado con 2.
En Digrama ER, necesita desplegar nombre rol a distinguir participación.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 36
Una relación recursiva supervisión
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 37
Tipo de relación recursiva es: SUPERVISION(Nombre de rol participante se muestra)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 38
Atributos de Tipos de Relaciones.
Un tipo de relación puede tener atributos: Por ejemplo, Horas por semana de WORKS_ON
“TRABAJAR EN” Su valor para cada instancia de relación se
describe en el número de horas por semana que un EMPLEADO trabaja en un PROYECTO.
Un valor de HoursPerWeek depende de un particular combinación (de los empleados, proyecto).
La mayoría de los atributos se utilizan relación con M:N
En uan relación 1:N ,Ellos pueden ser transferidos a el tipo de entidad sobre el N-lado de la relación
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 39
Ejemplo Atributo de un tipo de Relación: Horas de WORKS_ON
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 40
Notación para constraints sobre Relaciones.
Relación de cardinalidad (de una relación binaria): 1:1, 1: N, N: 1, o M: N Se muestra mediante la colocación de números
adecuados en los bordes relación. Restricción de participación (en cada tipo de
entidad participante): total (llamada dependencia de existencia) o parcial. Total muestra por la línea doble, parcial por una
sola línea. NOTA: Estos son fáciles de especificar para tipos
de relaciones binarias.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 41
Alternativa (min, max) notación para las restricciones relación estructural : Especificada en cada participación de una entidad de tipo E en un tipo de
relación R Especifica que cada entidad E en E participa en al menos min y en la
mayoría de los casos máxima relación en R Por defecto (sin limitación): min = 0, n = max (que significa sin límite) Debe tener como máximo minmax, min0, max 1 Derivadas del conocimiento de las limitaciones del mini mundo
Ejemplos: Un departamento tiene exactamente un gerente y un empleado puede
administrar más de un departamento. Especificar (0,1) para la participación de EMPLEADO en GESTIONA
Especificar (1,1) para la participación de departamento en GESTIONA Un empleado puede trabajar para exactamente un departamento, pero
un departamento puede tener cualquier número de empleados. Especificar (1,1) para la participación de EMPLEADO en WORKS_FOR
Especificar (0, n) para la participación de departamento en WORKS_FOR
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 42
La notación (min,max) para restricciones de relación
Leer min,max números siguientes junto al tipo de entidad y mirando a otro lado del tipo de entidad
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 43
ESQUEMA COMPAÑIA Digrama ER usando notación (min, max)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 44
Notación Alternativa Diagramatica
Diagramas ER es un ejemplo popular para la visualización de esquemas de bases de datos
Muchas otras anotaciones existentes en la literatura y en el diseño de bases de datos diferentes y herramientas de modelado
Apéndice A ilustra algunas de las notaciones alternativas que se han utilizado
Diagramas de clases UML es representante de otra forma de mostrar los conceptos de ER que se utiliza en varias herramientas de diseño comercial
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 45
Resumen de Notaciones para Diagramas ER
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 46
UML : Diagrama de Clases
Representar a las clases (similar a los tipos de entidad), como grandes cajas redondeadas con tres secciones:
La sección superior incluye el nombre del tipo de entidad (clase)
La segunda sección incluye los atributos Tercera sección incluye las operaciones de clase
(operaciones no son en el modelo ER de base)
Relaciones (asociaciones llamada) representan como líneas que unen las clases.
Otros terminología UML también difiere de la terminología ER.
Se utiliza en el diseño de base de datos y diseño de software orientado a objetos.
UML tiene muchos otros tipos de diagramas para el diseño de software (ver capítulo 12).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 47
Diagrama de Clases UML para Esquema de Base de Datos COMPAÑIA
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 48
Otra notación alternativa diagramatica.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 49
Las relaciones de Grado Superior
Relación con otros tipos de grado 2 se llaman binarios.
Relación con otros tipos de grado 3 son llamados ternarios y de grado n se llama n-ario
En general, una relación n-aria no es equivalente a n relaciones binarias
Las restricciones son más difíciles de especificar para las relaciones de grado superior (n> 2) que para las relaciones binarias
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 50
Discusión de las relaciones n-arias (n> 2)
En general, tres relaciones binarias pueden representar información diferente a una relación ternaria simple (véase Figura 3.17a y b en la siguiente)
Si es necesario, las relaciones binarias y n-arias todas se pueden incluir en el diseño de esquema (ver Figura 3.17a y B, donde todas las relaciones expresar significados diferentes)
En algunos casos, una relación ternaria puede ser representada como una entidad débil si el modelo de datos permite un tipo de entidad débil como para tener varias relaciones de identificación (y por lo tanto varios tipos de entidad titular) (véase la figura 3.17c)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 52
Discusión de las relaciones n-arias (n> 2)
Si una relación binaria en particular puede ser derivado de una relación de grado superior en todo momento, entonces es redundantePor ejemplo, la relación binaria
TAUGHT_DURING «Enseñando durante» en la Figura 3.18 (ver diapositiva siguiente) se puede derivar de la OFERTAS relación ternaria (basado en el sentido de las relaciones)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 53
Otro ejemplo de una relación ternaria.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 54
Viendo las limitaciones en las relaciones de grado superior
El (min, max) las limitaciones se pueden visualizar en los bordes - Sin embargo, no describe completamente las restricciones
Viendo un 1, M, o N indica restricciones adicionales Una M o N indica que no hay restricción Un 1 indica que una entidad puede participar en la instancia
de relación lo más una que tiene una combinación particular de las otras entidades participantes
En general, tanto (min, max) y 1, M, o N son necesarios para describir completamente las restricciones
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 55
Herramientas de Modelado de Datos Una serie de herramientas populares que cubren el
modelado conceptual y la cartografía en el diseño de esquema relacional.
Ejemplos: Erwin, S-Designer (Enterprise Application Suite), ER-Studio, etc
Aspectos positivos: Sirve como documentación de requerimientos de aplicación, la
interfaz de usuario sencilla - en su mayoría de apoyo editor de gráficos.
NEGATIVOS: La mayoría de herramientas carecen de una notación adecuada
para distintas relaciones con la relación de los atributos Sobre todo representan un diseño relacional en forma de
diagrama en lugar de un diseño conceptual ER basado en(Vea el Capítulo 12 para más detalles).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 56
Some of the Currently Available Automated Database Design Tools
COMPANY TOOL FUNCTIONALITY
Embarcadero Technologies
ER Studio Database Modeling in ER and IDEF1X
DB Artisan Database administration, space and security management
Oracle Developer 2000/Designer 2000 Database modeling, application development
Popkin Software
System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design
Platinum (Computer Associates)
Enterprise Modeling Suite: Erwin, BPWin, Paradigm Plus
Data, process, and business component modeling
Persistence Inc.
Pwertier Mapping from O-O to relational model
Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA
Resolution Ltd. Xcase Conceptual modeling up to code maintenance
Sybase Enterprise Application Suite Data modeling, business logic modeling
Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 57
Entidad-Relación extendido (EER) Modelo (en el capítulo siguiente)
El modelo de entidad-relación en su forma original no se adhirió a las abstracciones de la especialización y la generalización
El siguiente capítulo muestra cómo el modelo ER se puede ampliar con Tipo y subtipo relaciones subconjunto de
configuración Especialización / jerarquías de generalización Notación para mostrarlas en los diagramas EER
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 58
Resumen de Capitulo.
Conceptos del modelo ER: entidades, atributos, relaciones.
Restricciones en el modelo ER. ER uso en el diseño conceptual paso a paso el
esquema de la base de datos EMPRESA. Diagramas ER – Notación. Notaciones alternativas - diagramas de clases
UML, otros.