SICI-4030Base de Datos

Prof. Nelliud D. Torres

Análisis/Diseño y Data Modeling - Introducción

OBJETIVOS (Parte 1)• Enterprise Data Model• Information Systems Architecture (ISA)• Dos enfoques (aproach) en las bases de datos

– Systems Development Life Cycle (SDLC)– Prototyping Database Methodology

• Uso del CASE en las bases de datos• Normas del negocio (Business Rules)• Data names (Nombre de los datos)• Modelación

– Modelo Conceptual– Modelo Lógico– Modelo Físico

• Terminología de Datos

OBJECTIVOS (Parte 2)

• Definiciones base de datos– Entidades

• Definición• Ejemplo de Entidades• Entity Type vs Entity Instance• Strong Entity vs Weak Entity• Reglas para nombres de

Entidades

– Atributos• Definición• Ejemplos de Atributos• Required Atribute vs Optional

Atribute• Simple Atribute vs Composite

Atribute

• Single-Value Atribute vs Multivalued Atribute

• Stored Atribute vs Derived Atribute

• Simple Identifier vs Composite Identifier

• Ejemplos de UID• Reglas para nombrar y definir

Atributos• Información adicional sobre

Atributos

– Relaciones• Definición• Grado (degree) de relaciones• Tipos de relaciones

– Temas adicionales de Relaciones

ENTERPRISE DATA MODEL

Volver a los

Objetivos

Enterprise Data Model• Es el primer paso en el desarrollo de la base de Datos• Se especifica el alcance (scope) y el contenido en

general. Este paso de planificación ocurre durante el análisis del sistema.

• Es una imagen general (Overall picture) de la data de la organización a un alto nivel de abstración

• Trabaja con los diagramas Entity-relationship• Describe los tipos de entidades y las relaciones entre las

entidades• Se estudian las políticas del negocio (Business rules) para

poder diseñar apropiadamente las relaciones.

Págs. 37 - 38

INFORMATION SYSTEMS ARCHITECTURE

(ISA)

Volver a los

Objetivos

Information Systems Architecture (ISA)• Plano conceptual (conceptual blueprint) que contiene la

estructura deseada de su sistema de información• Consiste de:

– Data - (ejemplo; Enterprise Data Model–simplified ER Diagram)– Processes – Que manipulan datos. Ejemplo: Processes– data flow

diagrams, process decomposition, etc.– Networks - Transportan data por la organización y entre sus

asociados. Se utilizan diagramas tipo Data Network–topology como el ejemplo de la: Fig 1-9.

– People - Gerencia de proyectos y recursos. (People–people management) utilizando herramientas de gerencia de proyectos como por ejemplo el uso de Gantt charts.

– Events and points in time - Cuando los procesos se ejecutan.– Reasons - Razones para eventos y reglas (ejemplo, decision tables)

Págs. 38 - 39

Ejemplos

A continuación se muestran algunos ejemplos de algunos diagramas que se utilizan bajo la arquitectura de Sistemas de Información. Como este curso sólo se enfoca en el diseño e implementación de las Bases de Datos, no vamos a profundizar en estos tópicos.

Figure 2-1 Segment from enterprise data model

Enterprise data model - Describe entidades de alto nivel en una organización y las relaciones entre las entidades.

Pág. 38

Ejemplo - 1

Figure 2-2 Example of process decomposition of an order fulfillment function (Pine Valley Furniture)

Decomposition = breaking large tasks into smaller tasks in a hierarchical structure chart

Pág. 41

Ejemplo - 2

Ejemplo - 3 Planning Matrixes• Describen relaciones entre diferentes

objetos en la organización• Tipos de matrices: (no se van a discutir)

– Function-to-data entity– Location-to-function– Unit-to-function– IS-to-data entity– Supporting function-to-data entity– IS-to-business objective

Pág. 42

Ejemplo - 3 Example business function-to-data entity matrix (Fig. 2-3)

Pág. 42

DOS ENFOQUES (APROACH) EN LAS BASES DE DATOS

Volver a los

Objetivos

Two Approaches to Database and IS Development

• SDLC– System Development Life Cycle– Es un proceso detallado y bien planificado del desarrollo de

un Sistema de Información o en este caso de una Base de Datos

– Consume mucho tiempo, pero se entienden todos sus componentes.

– Es un ciclo de desarrollo largo (toma mucho tiempo)• Prototyping

– Rapid Application Development (RAD)– Define la Base de Datos durante el desarrollo inicial del

prototipo– Repite las actividades de implementación y mantenimiento

con nuevas versiones de prototipos hasta completar una versión aceptable.

Pág. 43

Systems Development Life Cycle

Systems Development Life Cycle(see also Figures 2.4, 2.5 Pags. 43-47)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Planning Purpose––preliminary understandingDeliverable––request for study

Database activity–– enterprise modeling and early conceptual data modeling

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Analysis

Purpose–thorough requirements analysis and structuringDeliverable–functional system specifications

Database activity – Thorough and integrated conceptual data modeling

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical DesignLogical Design

Purpose–information requirements elicitation and structureDeliverable–detailed design specifications

Database activity– logical database design (transactions, forms, displays, views, data integrity and security)

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Physical Design

Purpose–develop technology and organizational specificationsDeliverable–program/data structures, technology purchases, organization redesigns

Database activity– physical database design (define database to DBMS, physical data organization, database processing programs)

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Implementation

Purpose–programming, testing, training, installation, documentingDeliverable–operational programs, documentation, training materials

Database activity– database implementation, including coded programs, documentation, installation and conversion

Systems Development Life Cycle(see also Figures 2.4, 2.5) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Maintenance

Purpose–monitor, repair, enhanceDeliverable–periodic audits

Database activity– database maintenance, performance analysis and tuning, error corrections

Prototyping Database Methodology

Prototyping Database Methodology (Fig. 2.6)

Pág. 47

Prototyping Database Methodology (Figure 2.6)

Pág. 47

Pág. 47

Prototyping Database Methodology (Figure 2.6)

Pág. 47

Prototyping Database Methodology (Figure 2.6)

Pág. 47

Prototyping Database Methodology (Figure 2.6)

USO DEL CASE EN LAS BASES DE DATOS

Volver a los

Objetivos

The Role of CASE• Computer-Aided Software Engineering (CASE)–

Herramientas de software que proveen un apoyo automatizado en el desarrollo de los sistemas de información.

• Tres herramientas para las Bases de Datos:– Data modeling – Dibuja o crea los diagramas de entidad - relación– Code generation – Genera código en SQL para la creación de

tablas.– Repositories – Base de conocimientos para la información de la

empresa.

Pág. 49

NORMAS DEL NEGOCIO (Business Rules)

Volver a los

Objetivos

NORMAS DEL NEGOCIO (Business Rules)

• Declaraciones que definen o limitan algunos aspectos del negocio.

• Controla en influye en la conducta del negocio.

• Expresado en términos familiares para los end users.

• Se automatiza con el DBMS software.

• Influye en el diagrama ERD.

Pág. 87

UNA BUENA REGLA (NORMA) DE NEGOCIO

• Debe ser declarativa. Que diga el que, no el como

• Precisa y clara, que tenga significado.• Que sea Atomic. Que se pueda definir en

una sola oración.• Consistente. Interna y externamente• Expresable, estructurada y en lenguaje

natural.• No debe ser redundante.• Debe ser entendible por los usuarios de

negocios.Pág. 89

CARACTERÍSTICAS DE UNA BUENA REGLA DE NEGOCIO

Pág. 89

DATA NAMES (NOMBRE DE LOS DATOS)

Volver a los

Objetivos

UN BUEN DATA NAME DEBE:

• Estar relacionado al negocio, no a características técnicas.

• Tener significado y auto documentada.

• Legible

• Compuesto de palabras de una lista previamente aprobada.

• Repetible

Pág. 91

MODELACIÓN (MODELING)

Volver a los

Objetivos

MODELACIÓN (MODEL)

• Herramienta útil para comunicar y organizar ideas.

• Debe ser lo más estándar posible y debe evitar ambigüedades

• Los flujogramas, PAC, diagramas jerárquicos, diagrama estructurado, etc. son ejemplos de modelación.

• El modelo que nos interesa es el modelo entidad-relación.

MODELACIÓN - 2

• Es una forma de recolectar la información sobre la organización.

• Presenta la información de una forma clara y precisa.

• Debe ser fácil de desarrollar y modificar.• Minimiza cambios en el sistema y en caso

de haberlos, facilita la evaluación.• Facilita el trabajo en equipo al mejorar la

comunicación de las ideas.

TIPOS DE MODELOS

Los modelos tienen diferentes niveles de abstracción. En este caso los niveles son Conceptual, lógico y físico. Cada uno tiene su propósito y se van a discutir en los próximos slides. No existe un acuerdo estándar que indique en donde termina un nivel y comienza el otro, pero si existen unos conceptos que más o menos indican las peculiaridades de cada nivel.

MODELO CONCEPTUAL

• Muestra las necesidades de la Base de Datos a nivel general. Sólo se muestran los conceptos más básicos. No se especifican todos los atributos de las tablas, ni se resuelven las relaciones muchos a muchos. Tampoco hay que poner todos los UID (Unique ID o primary key) de las tablas. El propósito es dar una idea general de la Base de Datos.

MODELO LÓGICO

Se ajusta al modelo de Base de Datos en particular. En el caso del modelo relacional, se resuelven las relaciones muchos a muchos, se identifican todos los atributos, UID y campos foráneos. La Base de Datos debe estar normalizada y preparada para poder implementarse físicamente.

MODELO FÍSICO

La Base de Datos se implementa en una computadora utilizando el software apropiado. Por ejemplo Oracle, SQL server, MySql, DB2, Informix, etc. Aquí se debe tomar en cuenta las llaves foráneas (foreign keys), los índices, las vistas (views), integridad referencial, restricciones (constraints) entre otras cosas.

TERMINOLOGÍA DE DATOS

Volver a los

Objetivos

TERMINOLOGÍA DE DATOS

TRADICIONAL

BASE DE DATOSBASE DE DATOS

RELACIONAL

Archivo Entidad Tabla

Record Instancia, tuplo

Fila

Campo Atributo Columna

DEFINICIONES BASE DE DATOS

Volver a los

Objetivos

BASE DE DATOS - Definiciones

• Entidades – Algo importante que deseamos almacenar. Por ejemplo: Una persona, evento, lugar, categoría o cualquier otra cosa que se le pueda nombrar.

• Atributos – Datos que describen a la entidad y por lo tanto necesitamos almacenarlas.

• Relaciones – Define como las entidades se relacionan entre si.

ENTIDADES

Volver a los

Objetivos

ENTIDADES

Una ENTIDAD representa una persona, lugar, objeto , evento o concepto dentro del ambiente de Sistemas de información. Por lo tanto a cada entidad se le asigna un nombre propio. Deseamos guardar datos dentro de una entidad. A continuación mostramos ejemplos de entidades.

Pág. 96

EJEMPLO DE ENTIDADES

• PERSONA: ESTUDIANTE, EMPLEADO, PACIENTE• LUGAR: ALMACEN, WAREHOUSE, ESTADO,

PUEBLO• OBJETO: MAQUINA, EDIFICIO, AUTOMOVIL, LIBRO• EVENTO: VENTA, MATRICULA, RENOVACION,

QUEJA, COBRO, PAGO, TRASLADO, TAREA, TRANSFERENCIA, ASIGNACION, CONTACTO

• CONCEPTO: CUENTA, CURSO, CENTRO DE TRABAJO

Pág. 96

UNA ENTIDAD• DEBE SER:

– Un objeto que tenga muchas instancias en la Base de Datos.

– Un objeto que se componga de múltiples atributos– Un objeto que se pueda diseñar y representar

(model).

• NO DEBE SER:– Un usuario del sistema de Base de Datos– Un resultado (output) de la Base de Datos (ejemplo;

un reporte)

Inappropriate entities

System System useruser

System System outputoutput

Figure 3-4 Example of inappropriate entities

Appropriate entities

Pág. 97

Entities“something that users track”

Page 49Figure 3-1 © 2000 Prentice Hall

Yufei Yuan Course Web Site

ENTITY TYPE VS ENTITY INSTANCE

• Un entitity type es una colección de entidades que comparten propiedades o características comunes.

• Un entity instance es una sola ocurrencia de un entity type.

• Hay que tener cuidado en no confundir ambos términos.

Pág. 96

ENTITY TYPE VS ENTITY INSTANCE - EJEMPLO

Pág. 96

STRONG VS WEAK ENTITY

• Strong Entity - Una entidad que existe independientemente de cualquier otra entidad.

• Weak Entity - Una entidad cuya existencia depende de alguna otra entidad.

• Identifying Owner - El tipo de entidad en el cual el tipo de entidad débil (weak) depende.

• Identifying Relationship - Relación entre una entidad débil y su owner.

Págs. 97 - 98

STRONG VS WEAK ENTITY (CONT.)

• Strong entities – Existen independientemente de otros tipos de

entidades– Tienen su propio identificador único (unique

identifier, campo clave)

• Weak entity– Depende de una entidad fuerte (strong), no

puede existir por cuenta propia– No tiene un identificador único, solo uno parcial

Págs. 97 - 98

EJEMPLO DE LA RELACIÓN ENTRE UNA ENTIDAD FUERTE (STRONG) Y

OTRA DÉBIL (WEAK)

Pág. 98

REGLAS PARA DAR NOMBRE A LAS ENTIDADES

• Una entidad debe tener un nombre singular. (ejemplo CLIENTE, ESTUDIANTE, etc.)

• Debe ser específico para la organización. (ejemplo; una organización puede utilizar el nombre CUSTOMER y otra CLIENT o CLIENTE vs CONSUMIDOR)

• Debe ser conciso ya que debe utilizar la menor cantidad de palabras posible (preferiblemente una).

Págs. 98 - 99

REGLAS PARA DAR NOMBRE A LAS ENTIDADES (CONT.) - 1

• Si se utiliza abreviaciones, también deben ser específicas y descriptivas.

• Se debe mantener el mismo nombre en toda la base de datos. No duplicados.

• El nombre a utilizarse puede ser el resultado de un evento. Por ejemplo si se va a registrar los proyectos asignados a un empleado ASIGNACION puede ser un nombre. Si un estudiante esta contactando a un profesor y ese proceso se quiere registrar, se puede llamar CONTACTO.

Págs. 98 - 99

ATRIBUTOS

Volver a los

Objetivos

ATRIBUTOS

Pág. 100

• Attribute – Propiedad o característica de una entidad o de un tipo de relación.

• Tipos de atributos: (se discuten más adelante)– Required versus Optional Attributes– Simple versus Composite Attribute– Single-Valued versus Multivalued Attribute– Stored versus Derived Attributes– Identifier Attributes

EJEMPLOS DE ATRIBUTOS

ENTIDAD CLIENTE• número• nombre• dirección• teléfono• crédito• e-mail

ENTIDAD ESTUDIANTE• número• nombre• edad• genero• departamento• igs• escuela procedencia

ATRIBUTOS - Required versus Optional

• Required attribute - Necesita tener un valor por cada instancia que tenga la entidad.– Ejemplo: nombre, género, seguro social, etc.

• Optional attribute - No es necesario que toda instancia de una entidad tenga un valor en ese atributo en particular.– Ejemplo: teléfono, celular, etc.

Pág. 100

Required versus Optional - EJEMPLO

Mal ejemplo

Pág. 101

ATRIBUTOS - Simple versus Composite Attribute

• Simple (or atomic) Attribute - Un atributo que no se puede descomponer en sub-componentes que sean significativos para la organización. – Ejemplo; edad, género, peso, etc.

• Composite Attribute - Un atributo que tiene componentes significativos (sub-componentes). – Ejemplo; nombre, dirección, etc.

Pág. 101

Simple versus Composite Attribute - EJEMPLO

Págs. 101 - 102

Com

posi

te Simple

Figure 3-7 A composite attribute

ATRIBUTOS - Single-Valued versus Multivalued Attribute

• Single-Valued Attribute - Atributo que sólo puede tomar un valor en cualquier instancia de una entidad.– Ejemplo: género, fecha de nacimiento, etc.

• Multivalued Attribute - Atributo que puede tomar más de un valor para cualquier instancia de una entidad. – Ejemplo; en la figura del slide anterior, el atributo skill de la

entidad EMPLOYEE tiene más de un valor. Otros ejemplos podrían ser: fecha de contacto, puesto, tareas, etc.

Pág. 102

ATRIBUTOS - Stored versus Derived Attributes

• Stored Attributes - Su valor no se deriva ni se calcula utilizando otros valores.– Ejemplo: salario por hora, horas trabajadas, etc.

• Derived Attributes - Atributos cuyos valores pueden ser calculados de otros atributos relacionados. También pueden ser creados por data fuera del sistema como lo son la fecha y la hora o algún código entrado por un usuario. Ejemplo; el tiempo que lleva trabajando un empleado en la empresa.– Ejemplo: Sueldo bruto, edad actual, total de ventas, años en

la empresa

Pág. 102

Multivaluedan employee can have more than one skill Derived

from date employed and current date

Págs. 101 - 102

Figure 3-8 Entity with multivalued attribute (Skill) and derived attribute (Years_Employed)

Atributos multivalued & derived - Ejemplos

ATRIBUTOS - Identifier Attributes• Identifier - Atributo (o combinación de atributos)

que distingue cada instancia de la entidad haciéndola única. Debe ser un atributo cuyo valor nunca se repita.

• Simple identifier - Su valor no está sub-dividido en más de un atributo.– Ejemplo: Seguro social, número de empleado

• Composite identifier - Un identifier que tiene valores de más de un atributo.– Ejemplo: numero de cliente + número de orden

Pág. 103

Identifier Attributes (simple vs composite)- Ejemplos

Composite id

entifier

Simple Identifier

Pág. 103

Figure 3-19 Simple example of time-stamping

This attribute that is both multivalued and composite

Ejemplo de un atributo multivalued y composite

Características de los Identifiers (Primary Key)

• No cambiará de valor• No será Nulo (null)• No pueden ser “inteligentes”. Por ejemplo no

pueden tener valores que puedan cambiar como una dirección, nombre, edad o algún código que represente un valor que sea variable.

• Trate de utilizar identifiers simples (de un solo atributo) siempre que se pueda.

• A los identifiers se les conoce también como UID (Unique Identifier) y primary key.

Pág. 103

Ejemplos de UIDCLIENTE

númeronombreseguro socialdirecciónteléfonocréditoe-mail

ESTADIO(PARQUE)

idnombredirecciónteléfonocapacidad sillascapacidad carros

El número del cliente es muy buen candidato para un UID ya que su valor es único

El seguro social también podría ser un buen candidato para un UID.

En el caso de un estadio, necesitamos crear un atributo artificial que posea un valor único para que identifique cada instancia de la entidad.

REGLAS PARA NOMBRAR Y DEFINIR ATRIBUTOS

• Un atributo debe llevar un nombre o frase singular. Ejemplo; cliente, precio del producto

• Deben ser únicos. No pueden existir dos atributos de la misma entidad con el mismo nombre.

• Para lograr que un atributo sea único, se sugiere el uso de alguna regla estándar. Por ejemplo el uso de prefijos.

Pág. 104

REGLAS PARA NOMBRAR ATRIBUTOS (GUÍAS)

• Su nombre establece lo que es el atributo y porque es importante.

• También establece claramente que incluye o no.

• El alias (aliases) o nombre alterno del atributo, puede ser especificado.

• Es deseable que el nombre establezca la fuente del valor del atributo (de donde proviene).

Pág. 105

INFORMACIÓN ADICIONAL SOBRE ATRIBUTOS

• Los atributos deben describir a una entidad en una de las siguientes formas:– Identificándola– Calificándola– Clasificándola– Cuantificándola– Expresando su estado

Pág. 105

INFORMACIÓN ADICIONAL SOBRE ATRIBUTOS - Cont.

• Ejemplo, en la ENTIDA EMPLEADO:– El número lo identifica– El nombre lo califica– El puesto lo clasifica– La edad lo cuantifica– El estado (status) expresa su estado. (activo,

con licencia, retirado, etc.)

Pág. 105

RELACIONES

Volver a los

Objetivos

RELACIONES

• Es una asociación bidireccional (ambas direcciones) e imprescindible entre dos o tres entidades o entre una entidad y ella misma.

• La relación entre las entidades se conoce como Degree.

Degree of Relationships

• Indica el número de tipos de entidades que participan en la relación–Unary Relationship - Entre la misma

entidad.–Binary Relationship - Entre dos

entidades.–Ternary Relationship - Entre tres

entidades.

Pág. 109 - 112

Degree of relationships – from Figure 3-2

Entities of two different types related to each other Entities of three

different types related to each other

One entity related to another of the same entity type

Pág. 95

Figure 3-12 Examples of relationships of different degrees

a) Unary relationships

Pág. 110

Figure 3-12 Examples of relationships of different degrees (cont.)

b) Binary relationships

Pág. 110

Figure 3-12 Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note: a relationship can have attributes of its own

Pág. 110

OTRO EJEMPLO DEL GRADO DE RELACIONES

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

Tipos de Relaciones

• One-to-One (uno a uno)– Cada entidad en la relación va a tener exactamente

una relación en sus instancias.

• One-to-Many (uno a muchos)– La entidad de una parte tiene relación con muchas

instancias de la otra entidad, pero cada instancia de la otra entidad sólo puede tener relación con una instancia de la primera entidad.

• Many-to-Many (muchos a muchos)– En ambas entidades en la relación, existen relaciones

de muchos a muchos.

UNO A UNO - EJEMPLOS

11

CARRO

tablillamarcamodelo

MOTOR

númerodescripción

posee

está asignado

UNO A MUCHOS - EJEMPLOS

DEPARTAMENTO

idlocalizacióndescripción

EMPLEADO

numeronombreseguro social

habitado por

estar asignado

M∞

1

MUCHOS A MUCHOS - EJEMPLOS

M

∞

M

∞

ESTUDIANTE

númeronombreseguro social

CURSO

códigosemestredescripción

tomar

tomado por

TEMAS ADICIONALES DE RELACIONES

Volver a los

Objetivos

Temas adicionales de Relaciones• Relationship Types vs. Relationship Instances

– Relationship Types - El tipo de relación se modela como líneas entre los tipos de entidades.

– Relationship Instances - La instancia se refiere a instancias específicas de la relación

• Las relaciones pueden tener atributos– Estos describen capacidades pertinentes a la asociación entre las

entidades en la relación.

• Dos entidades pueden tener más de un tipo de relación entre ellos (multiple relationships)

• Associative Entity – Combinación de relaciones y entidad

Pág. 107

Strong entity Weak entity

Identifying relationship

Pág. 98

Relación entre una entidad fuerte y otra débil

a) Mandatory cardinalities

A patient must have recorded at least one history, and can have many

A patient history is recorded for one and only one patient

Pág. 116

Figure 3-17 Examples of cardinality constraints

Relación con Cardinalidad Mandatoria

b) One optional, one mandatory

An employee can be assigned to any number of projects, or may not be assigned to any at all

A project must be assigned to at least one employee, and may be assigned to many

Pág. 116 Figure 3-17 Examples of cardinality constraints (cont.)

Relación con una Cardinalidad Mandatoria y otra Opcional

Figure 3-10 Relationship types and instances

a) Relationship type

b) Relationship instances

Pág. 106

Tipos de Relaciones y Relaciones de Instancias

a) Optional cardinalities

A person is married to at most one other person, or may not be married at all

Pág. 116

Figure 3-17 Examples of cardinality constraints (cont.)

Relación con Cardinalidad Opcional

Entities can be related to one another in more than one way

a) Employees and departments

Pág. 120 Figure 3-21 Examples of multiple relationships

Ejemplo de Múltiples Relaciones

b) Professors and courses (fixed lower limit constraint)

Here, min cardinality constraint is 2

Pág. 120 Figure 3-21 Examples of multiple relationships (cont.)

Ejemplo de Múltiples Relaciones (cont.)

simple

composite

Pág. 114 Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships

Atributos Multivalorados que pueden ser Representados como Relaciones

Figure 3-11a A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship

Pág. 108

Ejemplo de Relación Binaria que Contiene un Atributo

Figure 3-11b An associative entity (CERTIFICATE) Pág. 108

Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in Figure 3-11a has been replaced by two one-to-many relationships with the associative entity.

Ejemplo de Relación con Entidad Asociativa

Figure 3-13c An associative entity – bill of materials structure

This could just be a relationship with attributes…it’s a judgment call

Pág. 111

Otro Ejemplo de Relación con Entidad Asociativa

Figure 3-18 Ternary relationship as an associative entityPág. 112

Ejemplo de Relación Ternaria con una Entidad Asociativa

REFERENCIAS

• Modern Database Management 8th Edition, Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden

• Yufei Yuan Course Web Site

• Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel