Unidad ii esp parte 2

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
UNIDAD II (CAP 3)
Modelando Datos utilizando El
Modelo Entidad-Relación(ER)

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 Atributos
Tipos de entidad, conjuntos de valores y atributos clave
Las relaciones y los tipos de relaciones
Entidad 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

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

Visión general del proceso de diseño de
base de datos

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

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

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

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

 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

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

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.

Ejemplo de Atributo Compuesto

Entities and Attributes (cont’d.)

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.

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

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.

Entidad Tipo Vehiculo, con dos llaves y
atributos.

Tipo Entidad, Conjunto Entidad
 Tipo Entidad
 Coleccion ( o conjunto) de entidades que tienen
los mismos atributos.

Diseño Inicial Tipo Entidad:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

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

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.

Instancia de relación WORKS_FOR N:1 Relación
entre EMPLOYEE y DEPARTMENT

Instancias de Relación de M:N WORKS_ON
relación entre EMPLOYEE y PROJECT

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

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
.

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)

DIAGRAMA ER – Tipos de Relación son:
WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF

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

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

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)

Relación Muchos a uno (N:1)

Relación de Muchos a Muchos
(M:N)

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.

Una relación recursiva supervisión

Tipo de relación recursiva es: SUPERVISION
(Nombre de rol participante se muestra)

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

Ejemplo Atributo de un tipo de Relación:
Horas de WORKS_ON

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.

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 minmax, min0, 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

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

ESQUEMA COMPAÑIA Digrama ER usando
notación (min, max)

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

Resumen de Notaciones para Diagramas
ER

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

Diagrama de Clases UML para Esquema
de Base de Datos COMPAÑIA

Otra notación alternativa diagramatica.

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

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)

Ejemplo de una Relación Ternaria

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 redundante
Por 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)

Otro ejemplo de una relación ternaria.

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

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

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

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

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.

Unidad ii esp parte 2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Unidad ii esp parte 2

Ähnlich wie Unidad ii esp parte 2 (20)

Mehr von Titiushko Jazz

Mehr von Titiushko Jazz (20)

Unidad ii esp parte 2