SICI-4030

Base 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
• Atribute
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
• 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.
 Ejemplo - 1
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 - 2
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 - 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
• SDLC
and IS Development
– 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

Logical Design

Physical Design

Implementation

Maintenance
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Planning
Planning Purpose–preliminary understanding
Deliverable–request for study
Analysis

Logical Design

Physical Design

Database activity– Implementation

enterprise modeling and
early conceptual data
Maintenance
modeling
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Purpose–thorough requirements analysis
Planning and structuring
Deliverable–functional system specifications
Analysis
Analysis

Logical Design

Physical Design

Database activity – Thorough Implementation

and integrated conceptual data
modeling
Maintenance
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Purpose–information requirements elicitation
Planning and structure
Deliverable–detailed design specifications
Analysis

Logical
Logical Design
Design

Physical Design

Database activity– Implementation

logical database design
(transactions, forms,
Maintenance
displays, views, data
integrity and security)
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Purpose–develop technology and
Planning organizational specifications
Deliverable–program/data
Analysis structures, technology purchases,
organization redesigns
Logical Design

Physical Design
Physical Design

Database activity– Implementation

physical database design (define
database to DBMS, physical data
Maintenance
organization, database processing
programs)
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Purpose–programming, testing, training,
Planning installation, documenting
Deliverable–operational programs,
Analysis documentation, training materials

Logical Design

Physical Design

Database activity–
database implementation, Implementation
Implementation
including coded programs,
documentation, installation Maintenance
and conversion
 Systems Development Life Cycle
(see also Figures 2.4, 2.5) (cont.)
Planning Purpose–monitor, repair, enhance
Deliverable–periodic audits
Analysis

Logical Design

Physical Design

Database activity–
database maintenance, Implementation
performance analysis and
tuning, error corrections Maintenance
Maintenance
Prototyping Database Methodology
Prototyping Database Methodology (Fig. 2.6)

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)

Pág. 47
Prototyping Database Methodology (Figure 2.6)

Pág. 47
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

BASE DE DATOS
TRADICIONAL BASE 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)
Figure 3-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

Pág. 97
 Entities
“something that users track”

Page 49
Figure 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
• 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
Pág. 100
 EJEMPLOS DE ATRIBUTOS
ENTIDAD CLIENTE ENTIDAD ESTUDIANTE
• número • número
• nombre • nombre
• dirección • edad
• teléfono • genero
• crédito • departamento
• e-mail • 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

l eje mplo
Ma
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

ple
m
Si
ite
os
mp
Co

Figure 3-7 A composite attribute Págs. 101 - 102

 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
 Atributos multivalued & derived -
Ejemplos

Multivalued
an employee can have
more than one skill Derived
from date
employed and
Figure 3-8 Entity with multivalued attribute (Skill) current date
and derived attribute (Years_Employed)

Págs. 101 - 102

 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

Simple Identifier

r
tifie
id en
s ite
po
m
Co

Pág. 103
Ejemplo de un atributo multivalued
y composite

This attribute
that is both
multivalued and
composite

Figure 3-19 Simple example of time-stamping

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 UID
CLIENTE
El número del cliente es muy
número
buen candidato para un UID
nombre
ya que su valor es único
seguro social
dirección
El seguro social también
teléfono
podría ser un buen candidato
crédito
para un UID.
e-mail

ESTADIO
(PARQUE)
id En el caso de un estadio,
nombre necesitamos crear un atributo
dirección artificial que posea un valor único
teléfono para que identifique cada instancia
capacidad sillas de la entidad.
capacidad carros
 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
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
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, 7th 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

CARRO posee MOTOR

tablilla número
marca descripción
modelo está asignado

1 1
UNO A MUCHOS - EJEMPLOS

DEPARTAMENTO habitado por EMPLEADO

id numero
localización estar asignado nombre
descripción seguro social

1 M
∞
MUCHOS A MUCHOS - EJEMPLOS

ESTUDIANTE tomar CURSO

número código
nombre tomado por semestre
seguro social M M descripción

∞ ∞
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
Relación entre una entidad fuerte y otra débil
Identifying relationship

Strong entity Weak entity

Pág. 98
 Relación con Cardinalidad Mandatoria

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and at least one history, and can
only one patient have many

Figure 3-17 Examples of cardinality constraints

Pág. 116
Relación con una Cardinalidad Mandatoria y otra
Opcional

b) One optional, one mandatory

A project must be An employee can be assigned

assigned to at least one to any number of projects, or
employee, and may be may not be assigned to any
assigned to many at all

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

Pág. 116
Tipos de Relaciones y Relaciones de Instancias

a) Relationship type

b) Relationship
instances

Figure 3-10 Relationship types and instances

Pág. 106
 Relación con Cardinalidad Opcional

a) Optional cardinalities

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

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

Pág. 116
 Ejemplo de Múltiples Relaciones

a) Employees and departments

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

Figure 3-21 Examples of multiple relationships Pág. 120
 Ejemplo de Múltiples Relaciones (cont.)

b) Professors and courses (fixed lower limit constraint)

Here, min cardinality constraint is 2

Figure 3-21 Examples of multiple relationships (cont.) Pág. 120
 Atributos Multivalorados que pueden ser
Representados como Relaciones

simple

composite
Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships
Pág. 114
Ejemplo de Relación Binaria que Contiene un
Atributo

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship
Figure 3-11a A binary relationship with an attribute Pág. 108
 Ejemplo de Relación con Entidad Asociativa

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.
Pág. 108
Figure 3-11b An associative entity (CERTIFICATE)
Otro Ejemplo de Relación con Entidad Asociativa

This could just be a relationship with

attributes…it’s a judgment call
Figure 3-13c An associative entity – bill of materials structure
Pág. 111
 Ejemplo de Relación Ternaria con una Entidad
Asociativa

Pág. 112
Figure 3-18 Ternary relationship as an associative entity
 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