unidad ii esp parte 2

58
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 1

Upload: titiushko-jazz

Post on 15-Aug-2015

40 views

Category:

Documents


1 download

TRANSCRIPT

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 3- 1

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

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- 14

Ejemplo de Atributo Compuesto

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Entities and Attributes (cont’d.)

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- 33

Relación Muchos a uno (N:1)

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- 51

Ejemplo de una Relación Ternaria

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.