Estructuras de Almacenamiento

de Datos

Clase 1:
Introducción
Modelo de Entidades y Relaciones

Cursada 2014

Facultad de Ciencias Exactas Universidad Nac. Centro de la Pcia. de Bs. As.

Introducción
Introducción a la Materia

Objetivo:
 Realizar una introducción al diseño de los aspectos
esenciales de los datos de un sistema de
información y al almacenamiento y administración de
los mismos en memoria secundaria.
 Se pretende que los alumnos:
 (Parte I) Adquieran conocimientos del modelado
conceptual de datos y su importante rol dentro del ciclo
de desarrollo de software.
 (Parte II) Se adquieran conceptos teóricos necesarios
para comprender las estrategias para estructurar y
acceder eficientemente de manera estándar a grandes
volúmenes de datos almacenados en forma persistente,
como preámbulo al manejo de Bases de Datos.
Introducción a la Materia

• Raramente un usuario pide construir una base de datos para

utilizarla solamente para almacenar y recuperar datos. En
casi todas las situaciones, pedirá crear una aplicación.

• Una aplicación se utiliza para realizar tareas específicas.

Puede que en el proceso, se utilice una base de datos para
almacenar y recuperar los datos, pero la construcción de ésta
es más que eso, es una parte crucial de la solución al
problema del usuario.
Contexto
Actualmente, para organizar y procesar los datos:

 Bases de Datos (BD)

 Sistemas de Archivos + DBMS

SGBD - Sistema de Gestión de Bases de Datos

(DBMS - Database Management System )

conjunto de tipo de datos abstractos que son implementados para el

almacenamiento, la organización jerárquica, manipulación, acceso,
direccionamiento y recuperación de datos (mucho en común con la
tecnología de BD )  Estructuras de Almacenamiento de Datos
específicas
 Un poco de historia …
 Las primeras aplicaciones
 manejo de datos simples (sueldos, stock, etc)
 Actualmente
 sistemas de archivos para grandes volúmenes de datos
 necesidad de software específico para administrarlos
(sistemas de BD, DBMS)

 Sin embargo…
 … el estudio de los sistemas de archivos permite:
◦ Conocer su perspectiva histórica  evolución

◦ Conocer los problemas y fallas que ocurren  evitarlos o

prevenirlos

◦ Conocer las características de archivos simples  facilitan el

entendimiento del funcionamiento de las BD (cómo los administra el
DBMS?)
Historia más reciente …

•Hoy en día, la tecnología de BD es parte de casi todos los sistemas de

información. Esto no es sorprendente si se tiene en cuenta que cada
sistema de información necesita almacenar datos y las relaciones entre
ellos. Aún así, la gran variedad de aplicaciones que utilizan esta tecnología
es asombrosa.

•Variedad de aplicaciones dato-intensivas (incluyendo BD, cálculos

científicos, gráficos, entretenimiento, multimedia, sensores, aplicaciones
web y correo electrónico)

• Un profundo cambio cuantitativo y cualitativo llegó muy

imperceptiblemente alrededor del año 2000: el precio de almacenamiento
de información se redujo a un punto donde se volvió más barato almacenar
datos en discos de computadora que en papel !!

• 2.000 años de civilización han almacenado datos en texto escrito (en

pergamino, papiro o papel). Actualmente (y apaciblemente) ese paradigma
ha comenzado su ocaso  la digitalización de texto no sólo es
imprescindible para compartir y analizar, sino que también es más
económica !!
 Parte I

Diseño Conceptual
Modelo de Entidades y Relaciones
Representación simbólica de la información

Conocimiento  entendimiento de la naturaleza, cualidades y

relaciones de las cosas. La observación o percepción de un hecho
se traduce en una porción incremental de conocimiento.

Información  estos incrementos de conocimiento.

La información valiosa debe ser registrada en una forma simbólica

inteligible para que pueda ser comunicada a otras personas 
adecuada representación simbólica de la información.

La pieza más elemental de información es el dato  aunque no es

de utilidad por sí mismo, sino vinculado con otros datos  el
almacenamiento y la comunicación de información requieren la
estructuración de datos.
 Representación simbólica de la información
o Que es un dato?  una pieza atómica de dato es la siguiente tupla:

< nombre de objeto, propiedad del obj., valor de la prop. del obj., instante >

o Un hecho o idea, usualmente se refiere a un objeto y a algún aspecto

del objeto, el cual captura un determinado valor en un cierto momento.

o El tiempo real implica cierta sincronización entre los hechos que no es

del todo representable  es más útil el tiempo relativo del hecho, que
puede ser capturado, ordenando los hechos, en lugar de registrar su
tiempo real  ignorar la noción de tiempo y reemplazarla por otras
propiedades explícitas que permitan establecer el ordenamiento entre
objetos.

dato elemental se convertiría en la terna:

< nombre de objeto, propiedad del objeto, valor de la prop. del objeto >
Representación simbólica de la información

La estructura y el contexto le dan significado a los datos

posibilitando su entendimiento.

El lenguaje natural es nuestra forma primaria de representación y

comunicación de información pero NO es el mejor medio.

En muchas situaciones resulta más útil establecer formas

especializadas de representación de la información. Las fórmulas
matemáticas, los mapas carreteros y las partituras musicales,
constituyen ejemplos de modelos especializados de
representación simbólica de la información.

Fuente: Apuntes de Cátedra. Bases de Datos. Prof. J. Ale y G. Dejean. Fac. Ingeniería UBA.
Diseño de un Modelo de Datos
MODELO DE DATOS
o Es una herramienta intelectual que permite plasmar una
interpretación de un conjunto de aspectos del mundo real:
o poder expresivo para ayudar a entender cómo están
relacionados los datos
o abstracta, para ser mínimamente perturbable ante los
cambios concernientes al aspecto evolutivo del mundo real.

o Es un mecanismo de abstracción, que permite ver el contenido

de información de los datos, en lugar de sus valores individuales.

o Los modelos son usados extensivamente en muchas disciplinas

para mejorar la comprensión y abstraer los detalles (modelos
físicos, matemáticos, económicos, etc.)

o En nuestra disciplina interesa comprender y elaborar MODELOS

DE DATOS, que puedan ser codificados y manipulados
computacionalmente.
Diseño de un Modelo de Datos
o Modelado de Datos  organización los datos de manera que
representen con la mayor fidelidad una situación del mundo real,
con el objetivo de poder manejarla computacionalmente …

o No es posible tener un conocimiento completo del mundo real

 centrar la atención en la información relevante, ocultando o
ignorando otra que no sea relevante o que resulte inadecuada
para el propósito requerido.

o Comprensión de las características de la información que es

relevante para resolver cómo van a ser organizados y
procesados los datos  pueden ser descriptas a través de
enunciaciones generales.

o Un conjunto formal y consistente de tales enunciaciones define

un modelo conceptual de datos.
Diseño de un Modelo de Datos
Las etapas para encontrar una forma eficaz de representar la
información en el mundo computacional incluyen las siguientes:

identificación de los datos de la realidad: actores,

recursos, objetos, etc. del mundo real de los cuales interesa
guardar información

identificación de relaciones entre datos: detección de los

vínculos significativos que se dan entre los elemntos de las
etapas anteriores.

abstracción de datos y relaciones: representación

simbólica de los elementos detectados en las etapas
anteriores

DISEÑO
CONCEPTUAL
 Etapas en el Diseño

ESQUEMA
LÓGICO ESQUEMA
ESQUEMA
GENÉRICO LÓGICO
ESQUEMA FÍSICO
ESPECÍFICO
CONCEPTUAL
Base
Sin DBMS Con DBMS De
Diseño Lógico
Datos
UdeD Diseño Conceptual
Temprano Tardío Almacenamiento

Ingeniería de Normalización
Requisitos y Depuración Sistema de
Archivos

Contenido de la Contenido parcial de la

asignatura: Estructuras asignatura: Bases de
de Almanamiento de Datos I
Datos
Etapas en el Diseño

Análisis de los Requisitos:

+ estudiar las reglas de la organización mediante entrevistas a
usuarios, etc.
+ determinar qué modelar
+ obtener un esquema descriptivo de la realidad
+ puede requerir realimentación y refinamientos

Diseño Conceptual:
 Modelo Conceptual de Datos
◦ Para describirlo  + objetos del mundo real
+ vínculos semánticos entre ellos
+ descripción de ambos
 Metodologías más difundidas:
Modelo de Entidades y Relaciones Extendido –MERE
Unified Modeling Language – UML
Object-Role Modeling – ORM
otras ….
Etapas en el Diseño

Diseño Lógico (DL)

DL Temprano: mediante reglas de transformación se obtiene un
diseño de los datos sobre una plataforma específica
(transformación del modelo conceptual de datos a una
especificación formal)
Refinamiento del Esquema: analizar y depurar la colección de
relaciones  buscar una representación normalizada 
Teoría+Herramientas de Normalización
DL Tardío: BD relacional ?

Sistema de Archivos+Indices (SA+I)?

Diseño Físico: se especifican las estructuras de almacenamiento

de datos internas y la organización de los archivos de índices y
de datos en un SA+I o en una BD
Etapas de Modelado Conceptual de Datos

UCLM, España (F.Ruiz)

Modelo Conceptual de Datos

 Se destaca el Modelo de Entidades y Relaciones

(Modelo E/R - MER), propuesto por Chen en dos
artículos ya icónicos, 1976 y 1977.

 Según Chen, “El Modelo E/R puede ser usado como

una base para una vista unificada de los datos”,
adoptando “el enfoque más natural del mundo real que
consiste en entidades e interrelaciones (relaciones )”.

 Posteriormente otros autores lo han extendido con

importantes aportes, lo que ha dado lugar a una
familia de Modelos de Datos (MER Extendido –
MERE).
Modelo de Entidades y Relaciones
Extendido (MERE)

• Es un modelo de datos conceptual (o semántico),

capaz de describir los requerimientos de datos para
un sistema de información de forma directa, con una
notación gráfica fácil de entender.

• Los requisitos de datos son descriptos en términos

de un esquema conceptual.

• Es una extensión de la propuesta original de

Chen.
Modelo de Entidades y Relaciones Extendido
(MERE)
 El MERE ha tenido una gran difusión en la comunidad
informática dedicada al desarrollo de aplicaciones generales
sobre bases de datos  ha sido el modelo más extendido en
las herramientas CASE de ayuda al diseño de BD.
 Es simple y poderoso para modelar abstracciones del mundo
real.
 Es una representación gráfica de un modelo de datos,
fácilmente traducible a un esquema de BD:
Reglas de transformación  esquema relacional esquema
lógico
 Se ha convertido en un estándar ‘de facto’, incluso muchas
herramientas de diseño de BD utilizan sus conceptos.
 Los esquemas ER son comparables a los obtenidos en
diagramas de clases UML.
Conceptos Básicos

El Modelo E/R (MER), tal como fue propuesto por Chen,

distinguía los siguientes elementos estáticos:

◦ Entidad (entity)
◦ Relación (o Interrelación) (relationship)
◦ Dominio (domain)
◦ Atributo (atribute)
Diferentes tipos de interrelaciones, entidades y
características de los atributos conducen al MERE.
Representación de elementos básicos del
MER

Diagrama de Entidades y Relaciones

Entidades nombre entidad

Nombre atributo (con variaciones en

Atributos la gráfica de acuerdo a su tipo)

Relaciones entre entidades nombre relación

Entidades
Definiciones de Entidad:

 “Cualquier objeto (real o abstracto) que existe en la

realidad y acerca del cual queremos almacenar
información en la base de datos”.

 “Algo con realidad objetiva que existe o puede ser

pensado”.

 “Una persona, lugar, cosa, concepto o suceso, real o

abstracto, de interés para la empresa”.

 “ Objetos (hechos, cosas, personas,...) que tienen

propiedades en común y una existencia autónoma.”
 Conjunto Entidad

Abstrayendo las características comunes de un conjunto de

entidades se obtiene:

 Conjunto Entidad: Representa el tipo de entidades o la estructura

genérica que describe un conjunto de entidades. Se lo identifica
con un nombre (en singular por lo general) que caracteriza el
conjunto entidad (aunque generalmente es mencionado
simplemente como entidad).

 Ejemplo: todos los Alumnos  Entidad ALUMNO

◦ Todas las entidades de un conjunto tienen el mismo conjunto de
atributos que interesa modelar. Ej. Todos los ejemplares de
ALUMNO, tendrán LU, Nombre, Apellido.
◦ Cada atributo tiene un dominio de definición.
◦ Cada conjunto entidad necesita un identificador o clave: atributo
o conjunto de ellos que permita identificar a cada uno de los
ejemplares que componen el conjunto entidad (K). La Entidad
ALUMNO tiene como atributo identificador de los ejemplares a
LU.
 Conjunto Entidad

Está formado por ejemplares o instancias, que son

 entidades, cada una representa simbólicamente a
 Un objeto del mundo real, distinguible entre otros del mismo.
Se describe por medio de sus propios atributos.
Los objetos individuales son instancias de la entidad

Instancias o entidades
(individuales)
(Conjunto) Entidad
123, Carlos, Sánchez
124, Miguel, Rodríguez
ALUMNO
125, José, González
126, Agustín, García
LU …....
Nombre
Apellido
Entidades
Existen dos categorías de tipos de entidades:
 Regulares o fuertes, que son aquellas cuyos
ejemplares tienen existencia por sí mismos (ej. Los
ejemplares de ALUMNO)

 Débiles, en las cuales la identificación y existencia de

un ejemplar dependen de la identificación y existencia
de un ejemplar de otro tipo de entidad, por ejemplo:
◦ la existencia e identificación de una COPIA_LIBRO depende de la
identificación y existencia de un ORIGINAL_LIBRO;
◦ el REGLON_REMITO depende de la identificación y existencia de un
ejemplar de REMITO;
◦ la identificación y existencia de una PROVINCIA depende de la
identificación y existencia del PAÍS al cual pertenece…..
Identificación de Entidades
…problema para identificarlas
 Uno de los problemas que existirán en el diseño del MER es la decisión
de si un determinado objeto o concepto se modela como una entidad o
no.

 Por ejemplo, el color es habitualmente una propiedad de una entidad

(como es el caso del color de un auto), pero en una fábrica de pinturas
probablemente sería apropiado modelar el color como una entidad con
sus propias propiedades.

Las tres propiedades inherentes de las entidades:

1. Tiene que tener existencia propia,

2. Cada ejemplar de un tipo de entidad debe poder
distinguirse de los demás,
3. Todos los ejemplares de un tipo de entidad deben
tener las mismas propiedades.
Identificación de Entidades
Pero ...
 La primera de estas reglas no sería aplicable a las
entidades débiles  que significa ‘existencia’?.
 La segunda supone la obligación de un identificador
que permita distinguir los distintos ejemplares de un
tipo de entidad, lo que tampoco es universalmente
aceptado (ni por algunos autores, ni por los modelos,
ni por los productos)  que hacer con ejemplares
‘iguales’?.
 La tercera es relativa: ¿exactamente las mismas?,
¿las mismas entre las que nos interesan?  cómo
determinar el conjunto de propiedades?

Respuestas … experiencia en el diseño, astucia en la definición

de identificadores, y otras destrezas…
Atributos
 Son los datos relativos a una entidad o relación
 Es una característica (adjetivo) que puede identificar o describir
una entidad, o las relaciones que pueden existir entre dos o más
de ellas.
 Cada atributo tiene asociado un Dominio de definición (entero,
cadena de caracteres, fechas, etc.) y puede tomar un cierto
valor dentro del dominio
 Un atributo puede ser:
◦ simple (ej. Nombre, nro.de documento, etc.)
◦ compuesto: se pueden dividir en componentes más
pequeños, su valor es la concatenación de los valores de los
atributos simples (ej. Dirección: calle, número, piso, dpto.)
◦ univaluado (ej. Edad)
◦ multivaluado: puede tener un conjunto de valores para una
misma instancia (ej. Teléfono, pueden ser varios números)
Atributos (cont.)

 Todas las instancias de una entidad se describen mediante el

mismo conjunto de atributos … (3a. Propiedad de Entidades)
 (Casi) Siempre hay un atributo cuyo valor siempre es distinto
para cada instancia de una entidad  atributo clave o atributo
identificador principal (ej. Número de libreta de un Alumno,
patente de un Automóvil) … (2a. Propiedad de Entidades)
 Algunas entidades pueden tener más un atributo clave  clave
alternativa o atributo identificador alternativo (ej. documento del
Alumno) … (2a. Propiedad de Entidades)
 Los atributos de una entidad pueden ser obligatorios (deben
tener un valor) u opcionales, inclusive pueden ser nulos (es
decir no contener valor).
Atributos (cont.)
Los atributos se colocan junto a las entidades.
◦ Con simbología específica según su tipo.
◦ Hay otras formas de notación aceptables.
Atributos (cont.)
Atributos (cont.) Cada conjunto de
entidades debe
tener al menos un
identificador o
clave.
ALUMNO

nro_libreta Esa clave podría

documento
nombre
ser un atributo
telefonos compuesto.
tutor
mails
calle
¿Podría ser un
direccion
numero atributo multivalor?
Relaciones (o Interrelaciones)
Una relación (interrelación) es una asociación, vinculación
o correspondencia entre conjuntos de entidades, y se
materializa en un conjunto de asociaciones entre dos o
más instancias del mismo o diferente tipo.

Igual que en el caso de las entidades, distinguiremos entre:

 Conjunto Relación: el tipo de relación o estructura genérica

que describe un conjunto de relaciones, y

 Cada relación, o instancia de relación es decir, cada uno de

los ejemplares concretos.

 CURSA es un tipo de relación que vincula los tipos de

entidad ALUMNO y MATERIA; un ejemplar del tipo de
relación CURSA es la vinculación entre el alumno “Carlos
Sánchez” y el curso “Estructuras de Datos” dado que
satisface la frase “Carlos Sánchez cursa la materia
Estructuras de Datos”.
Relaciones

Elementos de un tipo de relación

 Nombre (único en el esquema )

 Grado u orden (número de tipos de entidades
participantes)
 Tipo de correspondencia o cardinalidad o
multiplicidad (1 a 1, 1 a muchos, muchos a
muchos, …)
 Puede tener atributos propios

Subrayados los términos más usuales

Relaciones - Grado

◦ Una interrelación de orden n (n-aria) R relaciona n

conjuntos de entidades E1 ... En.

◦ Cada tupla en R involucra las entidades e1E1, ..., en

 En

◦ Entonces si:
 n=1 la relación se denomina unaria;
 n=2 la relación se denomina binaria;
 n=3 la relación se denomina ternaria;
 ...
Relaciones – Tipos de correspondencia

Uno a uno – 1 : 1

Uno a muchos – 1 : N

Muchos a muchos – N : N
Relaciones – Cardinalidades
 Es el nro. máximo y mínimo de ejemplares de una entidad que
pueden estar relacionadas con ejemplares de otra u otras
entidades.
 Esta información se coloca sobre los vínculos (líneas), en el
ejemplo encerrado entre paréntesis.
 Lectura Look-Across (LA) o Chen-Style: se lee sobre la línea de
la ‘entidad destino’
 La cardinalidad máxima representa el máximo número de
ejemplares de una entidad con los que se puede relacionar otra
entidad: al menos 1, como máximo N (muchos o varios, es variable)
 La cardinalidad mínima también representa información valiosa:
◦ Un ejemplar de una entidad puede estar relacionado con otro:
Cardinalidad mínima 0
◦ Un ejemplar de una entidad debe estar relacionado al menos con un
ejemplar Cardinalidad mínima 1

(0,N) (1,1)
Relaciones Unarias (reflexivas, recursivas)

#Pieza Forma
PIEZA -parte
Nombre
Precio N

Cual es la semántica de esta relación y de sus

cardinalidades máximas?
Cada pieza forma-parte de otra u otras piezas
Cada pieza esta-formada-por otra u otras piezas
Notar que se describe con hechos afirmativos
 Relaciones Binarias (1:N)

N 1
Id-Carr Id-Depto
Nombre
CARRERA  DEPTO NombreD

Cual es la semántica de esta relación y de sus

cardinalidades máximas?
Cada carrera pertenece a un único departamento
Cada departamento posee muchas carreras
 Relaciones Binarias (N : N )

LU IdDeporte
Apellido NbreDep
N N
Nombre
ALUMNO PRACTICA DEPORTE

Cual es la semántica de esta relación y de sus

cardinalidades máximas?
Cada alumno practica varios deportes
Cada deporte es practicado por varios alumnos
 Relaciones Opcionales vs. Obligatorias
LU
Cardinalidadades mínimas
IdDeporte
Apellido
NbreDep
Nombre N N
ALUMNO PRACTICA DEPORTE

Cual debería ser la semántica ‘COMPLETA’ de esta

relación, interpretada en el mundo real?
Un alumno practica al menos un deporte? O podría no
practicar ninguno?
Un deporte es practicado por al menos un alumno? O
podría ocurrir que nadie lo practicara?
Hasta ahora sólo se ha indicado que un deporte podría ser
practicado por varios alumnos y que un alumno podría
practicar varios deportes… los casos más restrictivos no
están representados.
 Relaciones Opcionales vs. Obligatorias
LU
Cardinalidadades mínimas
IdDeporte
Apellido
NbreDep
Nombre *, N *, N
ALUMNO PRACTICA DEPORTE

los casos más restrictivos se indican donde figura el *

Si un alumno practica al menos un deporte?
*, N 1, N

O podría no practicar ninguno?

*, N 0, N

Un deporte es practicado por al menos un alumno?

1, N *, N

O podría ocurrir que nadie lo practicara?

0, N *, N
 Relaciones Opcionales vs. Obligatorias

LU
Cardinalidadades mínimas
IdDeporte
Apellido
NbreDep
Nombre 0, N 1, N
ALUMNO PRACTICA DEPORTE

Este diagrama expresa que

Un alumno practica al menos un deporte y podría practicar
varios;
Un deporte podría no ser practicado por ningún alumno, pero
puede ser practicado por alguie, es decir uno o más alumnos.

0 en la cardinalidad mínima indica OPCIONALIDAD

1 en la cardinalidad mínima indica OBLIGATORIEDAD
(relación mandatoria)
Relaciones Ternarias

PROVEEDOR PARTE
R

PROYECTO
Cual es la semántica de esta relación y de sus
cardinalidades máximas?
¿Cual es el nro. máximo de ejemplares de cada entidad
que está vinculado con un par de ejemplares de la otra
entidad?
Por ejemplo: un proveedor, ¿cuantas partes provee para
cada proyecto (una o muchas)?

Alternativas Diferentes: N:N:N 1:1:N 1:N:N 1:1:1

 Relaciones Ternarias

Cardinalidad N:N:N
Proveedor Parte Proyecto
◦ Un proveedor provee Prov NroP Proy
cada parte a muchos P1 PA Pr1
proyectos. P2 PB Pr2
◦ Un proveedor provee P3 PC Pr3
para cada proyecto R
muchas partes. Prov NroP Proy

◦ Una parte, para cada P1 PA Pr1

proyecto es provista P1 PB Pr1
P1 PA Pr2
por muchos
P2 PA Pr1
proveedores.
 Relaciones Ternarias

Cardinalidad 1:N:N Proveedor Parte Proyecto

◦ Un proveedor provee Prov NroP Proy
cada parte a muchos
proyectos. P1 PA Pr1
◦ Un proveedor a cada P2 PB Pr2
proyecto le provee P3 PC Pr3
muchas partes.
◦ Cada parte provista a un R
proyecto lo hace sólo UN Prov NroP Proy
proveedor. P1 PA Pr1
?? P1 PB Pr1
Este par de tuplas no P1 PA Pr2
corresponde, la relación
P2 PA Pr1
es 1:N:N: sólo una de
las tuplas es correcta
 Relaciones Ternarias

Cardinalidad 1:1:N
Proveedor Parte Proyecto
◦ Un proveedor provee Prov NroP Proy
cada parte a muchos
P1 PA Pr1
proyectos.
P2 PB Pr2
◦ Un proveedor a cada
P3 PC Pr3
proyecto le provee UNA
única parte. R
◦ Cada parte provista a un ?? Prov NroP Proy
proyecto lo hace sólo UN P1 PA Pr1
proveedor. ??
P1 PB Pr1
Hay tuplas que no P1 PA Pr2
corresponden, la P2 PA Pr1
relación, sólo una de
cada par es correcta…
 Relaciones Ternarias

Cardinalidad 1:1:1
◦ Un proveedor provee Proveedor Parte Proyecto
cada parte a UN solo Prov NroP Proy
proyecto.
◦ Un proveedor a cada P1 PA Pr1
proyecto le provee UNA ?? P2 PB Pr2
única parte. P3 PC Pr3
◦ Cada parte es provista a??
R
un proyecto por sólo UN
proveedor. Prov NroP Proy
?? P1 PA Pr1
P1 PB Pr1
Algunas de estas tuplas P1 PA Pr2
no corresponden, la P2 PA Pr1
relación es 1:1:1
Relación Entidad Débil - Entidad Fuerte

 Una entidad débil puede ser unívocamente identificada

sólo en el contexto de otra entidad fuerte o propietaria.
 Fuerte y débil están vinculadas por una relación
binaria (1,1):(*,N). Siempre la cardinalidad del lado 1
es 1. (Porqué?)
 La entidad débil tiene una dependencia de existencia y
de identificación respecto de la entidad fuerte.
Entidad débil
Entidad fuerte
1,1 0,N
PAIS R PROVINCIA
IdPais IdPcia
NombrePais NombrePcia

……….. ………..

¿Cómo indicar la dependencia de existencia y de identificación?  esquema lógico

Agregación
 Es una extensión propuesta para
modelar, además, interrelaciones
entre entidades y relaciones, o
entre relaciones  MERE Producto

Fabrica

Agregación 1

N N
Proyecto Desarrolla PlantaFabril

La interrelación se trata como si fuese otra entidad con el

objetivo de su participación en otras relaciones. Esto significa
que el producto es fabricado para un único proyecto de una
planta fabril
¿Cómo indicar la relación Fabrica, entre entidades y relaciones?  esquema lógico
 Jerarquías (Relaciones ES-UN o ISA)
Subtipos y Supertipos

DNI ESTUDIANTE
ApNom <tipo>

Fecha-Gr
Fecha-Inscrip NO_GRADUADO GRADUADO

Curricula MAESTRÍA DOCTORADO

F.inicio

• Exclusivas y compartidas
• De participación total y parcial

¿Cómo representar los distintos casos?  esquema lógico

Construcción del MERE
No existen reglas que indiquen cómo construir un modelo de
datos, sólo principios generales a aplicar junto al criterio del
diseñador experimentado
◦ Interpretar las frases expresadas en lenguaje natural (en el relevamiento),
identificando cuáles son las entidades (datos) y cuales las relaciones
(entre los datos) en la organización.
◦ Chen propuso las siguientes heurísticas:
− En general un sustantivo es una entidad, aunque también podría ser un
atributo (Ej: “los ALUMNOS cursan MATERIAS”)
− Un verbo o frase verbal puede indicar una relación entre entidades (Ej:
“los alumnos CURSAN materias”). Asociaciones entre los datos.
◦ Que información acerca de las entidades y relaciones deberían
registrarse?  determinar los atributos (de entidades y relaciones).
◦ Respecto de relaciones más complejas (ternarias, agregaciones, etc.) la
experiencia del diseñador, las herramientas computacionales que maneje y
el conocimiento de las transformaciones en esquemas equivalentes
constituyen un recurso fundamental.
Decisiones de diseño
 Cuándo un concepto debería modelarse como entidad? O
como atributo?
 Cuándo un concepto debería modelarse como una entidad?
O una relación?
DEPENDE DE LOS REQUERIMIENTOS DEL CLIENTE !!
 Cómo definir correctamente el grado de una relación? Es
binaria? Es ternaria o de orden >3? Son varias o es una?
ANÁLISIS DE TIEMPOS Y ACTORES
 Es equivalente una relación ternaria a dos o más binarias
entre las entidades involucradas?
 Es equivalente una relación ternaria a una agregación?
NO SIEMPRE !!
 EXPERIENCIA Y PRÁCTICA SON INDISPENSABLES PARA
RESOLVER ESTOS INTERROGANTES 
 Sumario: Diseño Conceptual
 El diseño conceptual se guía por el análisis de los
requisitos
◦ Permite obtener una descripción de alto nivel de los
datos que finalmente serán almacenados
 MERE es uno de los modelos más populares para el
diseño conceptual.
◦ Construcciones expresivas, cercanas a la forma en que
los usuarios piensan acerca de sus aplicaciones.
◦ Numerosas herramientas CASE (que generalmente
siguen el modelo binario).
◦ En actual evolución, mismo estilo que MER: UML
 Mecanismos de derivación casi automática desde el
esquema conceptual al esquema lógico temprano.
… continuará …
 Lectura Obligatoria
Diseño de Bases de Datos Relacionales
De Miguel, A.; Piattini, M.; Marcos, E.
AlfaOmega RaMa editores, 2000.
(Capítulos 1 y 2)

Database Modeling and Design.

Teorey, T.; Lighstone, S.; Nadeau, T.; Jagadish, H.
Morgan Kaufmann. 5ta. Edición. 2011
(Capítulo 2)