Módulo 1: Introducción a las

bases de datos
1.2 Modelo Entidad Relación

1
 Ciclo de vida de una DB
Contexto
específico

Recopilación y análisis
de requisitos
Requisitos funcionales Requisitos de datos
Diseño Conceptual
Análisis funcional Esquema conceptual de alto
nivel de los datos y para
cualquier tipo de DBMS.
• MySQL – Relacional
• Oracle – Relacional
• MongoDB – Documentos
• DynamoDB – Documentos/Clave
valor
• Redis – Clave Valor
• Cassandra – Columna
• Neo4j - Grafo

• MySQL – Relacional
Diseño Lógico • Oracle – Relacional
Diseño de la Esquela Lógico para un tipo de • SQLServer - Relacional
DBMS
aplicación
Diseño Físico
• MySQL – Relacional
Esquema Físico para un DBMS
específico
Implementación de
las operaciones

Aplicaciones 2
 Modelo entidad relación
❖ Es el modelo conceptual más utilizado para el diseño
conceptual de bases de datos. Fue introducido por Peter
Chen en 1976.
❖ Se basa en una percepción de un contexto específico del
mundo real.
❖ En el modelo ER existen 3 conceptos básicos principales:
entidades, atributos y relaciones.

3
 Entidad (Sustantivo)
❖ Una entidad representa un una cosa u objeto, real o
abstracto de contexto que queremos modelar.

❖ Es un sustantivo común que nos clasificar cosas u objetos del

mismo tipo. En el contexto de una universidad contramos
alumno, curso, profesor, etc.
alumno curso profesor

❖ La entidad curso nos permite representar a todos los cursos

de una universidad.

4
 Atributo (adjetivo)
❖ Los atributos son las características o propiedades de
una entidad o relación.
❖ Nos entregan más información de de la entidad o
relación.

❖ Por ejemplo, la entidad alumno tiene los atributos RUT,

DV, nombre, peso, etc.

5
 Atributo (adjetivo)
❖ Para cada atributo hay un conjunto de valores permitidos
(dominio). Por ejemplo, la entidad alumno:
• RUT: Puede ser cualquier número entero positivo.
• DV: un número desde el 0 al 9 ó la letra K.
• Nombre: Texto de largo máximo 250.
• Peso: Número entero positivo que representa kilos.
❖ Un alumno en particular tiene los valores:
• RUT: 11.111.111
• DV: 1
• Nombre: Juan Perez
• Peso: 70 6
 Relación (verbo)
❖ Una relación es una asociación entre entidades.

❖ Las entidades involucradas en una relación son

participantes en esa relación.

❖ Una relación puede tener dirección. Es opcional y la

usamos cuando tenemos certeza de la dirección en que
se lee la relación.

7
 Relación (verbo)
❖ Al número de participantes en la relación se le llama
grado de la relación

• Relación unaria o grado 1.

• Relación binaria o grado 2.

• Relación ternaria o grado 3. Etc.

8
 Modelo ER: Ejemplo 1
❖ Entidades alumno y curso.
❖ Atributos de un alumno: RUT DV, nombre y Peso.
❖ Atributos de un curso: codigo y nombre.
❖ Atributos de la relación: año y semestre.
❖ Rut e código son llaves, es decir, atributos con valores únicos.
❖ Relación (binaria): un alumno inscribe 0 o M (0 o muchos) cursos.
Un curso es inscrito por 0 o M (0 o muchos) alumno.

9
 Tipos de atributos
❖ Atributo clave: Es cuando los valores de uno o más
atributos identifican en forma única a una entidad.

(*) Si es que no claridad del tipo de atributo, se

recomienda dejar como un atributo simple.

10
 Tipos de atributos
❖ Simple o compuesto:
❖ Simple: no se divide en subpartes
❖ Compuesto: se divide en subpartes. Se compone de dos o más
atributos simples.

❖ Monovaluado / Multivaluado
❖ Monovaluado: tiene un sólo valor para una entidad específica.
❖ Multivaluado: tiene un conjunto de valores para una entidad
específica. Ejemplo. Correo electrónico

11
 Tipos de atributos
❖ Almacenado / Derivado:
❖ Almacenado: se guarda en la base de datos
❖ Derivado: Su valor se obtiene a partir del valor de otros
atributos o entidades relacionados. Se representa con un
óvalo punteado. Ejemplo Edad, que se deriva del año de
nacimiento y la fecha actual.

❖ Valor Nulo: Un atributo toma un valor nulo cuando una

entidad no tiene un valor para el. El valor nulo puede
indicar que el valor no existe para la entidad o que es
desconocido. Por ejemplo segundo nombre.
12
Modelo ER: Ejemplo 2

13
 Cardinalidad
❖ Expresa el número de entidades a las que otra entidad puede estar
asociada vía un conjunto de relaciones.
❖ Para un conjunto de relaciones binarias R entre los conjuntos de
entidades A y B, la cardinalidad es:

uno a uno uno a muchos muchos a uno muchos a muchos

14
 Restricciones
❖ Participación total / Parcial:
❖ Total: Cada entidad de un conjunto de entidades participa al
menos en una relación del conjunto de relaciones.

❖ Participación parcial: Sólo algunas entidades de un conjunto

de entidades participan en relaciones del conjunto de
relaciones.

15
 Restricciones
❖ Dependencia de existencia: Cuando la entidad débil no
puede existir sin la existencia de la entidad fuerte de la
cual depende.

Ejemplo:
• Ambas entidades tienen identificador único.
• Un cliente puede tener 0 o más pedidos.
• No puede existir un pedido si no se conoce el cliente.
• Un pedido puede ser realizado por sólo un cliente.
• Si se elimina el cliente, se elimina el pedido.

16
 Restricciones
❖ Dependencia en Identificación: Cuando, además de la
dependencia en existencia, la entidad débil no se puede
identificar con sus propios atributos, y debe incluir en su
clave la clave de la entidad.

Ejmeplo:http://www.sinim.gov.cl/archivos/centro_descargas/modificacion_instructivo_pres_codigos.pdf

17
Restricciones

18
Modelo entidad relación – Lenguaje (1/2)

19
Modelo entidad relación – Lenguaje (2/2)

20
 Modelo ER – Flexibilidad
❖ El modelo ER es muy flexible. En este curso usaremos la
cardinalidad (N,M).
❖ Si es posible usaremos relaciones dirigidas -->

21
 Modelo ER – Recomendaciones
❖ Leer/observar el contexto específico del problema.
● Identificar los puntos de entrada y salida de los datos.
● Analizar interfaces de usuario existentes
● Reportes que se generan actualmente en la compañía
● Formularios actuales que se usan para recolectar información
● Conversar con las personas que usarán la base de datos.

❖ Identificar entidades.
❖ Identificar relaciones entre entidades.
❖ Agregar atributos.
❖ Mejorar el modelo:
● Agregar restricciones, tipos de atributos, cardinalidad, llaves, etc.
● Valida el modelo a través de un ejemplo.
● Si es necesario repite los pasos desde el inicio.

22
 Modelo ER – Ejercicio 1 – Venta de productos
❖ Una empresa vende productos a varios clientes. Se necesita conocer los
datos personales de los clientes (nombre, apellidos, RUT, dirección y
fecha de nacimiento). Cada producto tiene un nombre y un código, así
como un precio unitario. Un cliente puede comprar varios productos a
la empresa, y un mismo producto puede ser comprado por varios
clientes.
❖ Los productos son suministrados por diferentes proveedores. Se debe
tener en cuenta que un producto sólo puede ser suministrado por un
proveedor, y que un proveedor puede suministrar diferentes productos.
De cada proveedor se desea conocer el RUT, nombre y dirección

23
Modelo ER – Ejercicio 1 – Venta de productos

24
 Modelo ER – Ejercicio 1 – Venta de productos

Esta segunda solución es menos óptima, ya que no es necesario modelar

la entidad empresa. 25
 Modelo ER – Ejercicio 2 – Despacho de
encomiendas
❖ Se desea automatizar la gestión de una empresa de transportes que
reparte encomiendas por todo Chile. Los encargados de llevar las
encomiendas son los choferes, de los que se quiere guardar el RUT,
nombre, teléfono, dirección, salario y comuna en la que vive.
❖ De las encomiendas transportadas interesa conocer el código de
encomienda, descripción, destinatario y dirección del destinatario. Un
chofer distribuye muchas encomienda, y una encomienda sólo puede ser
distribuido por un chofer.
❖ De las comunas a las que llegan las encomiendas interesa guardar el
código de comuna y el nombre. Una encomienda sólo puede llegar a una
comuna. Sin embargo, a una comuna pueden llegar varias encomiendas.
❖ De los camiones que llevan los choferes, interesa conocer la patente,
modelo, tipo y potencia. Un chofer puede conducir diferentes camiones
en fechas diferentes, y un camión puede ser conducido por varios
choferes.

26
Modelo ER – Ejercicio 2 – Despacho de
encomiendas

27
Modelo ER – Ejercicio 2 – Despacho de
encomiendas

28
Módulo 1: Introducción a las
bases de datos
1.3 Modelo Entidad Relación Extendido

29
 Modelo Entidad Relación Extendido
❖ El Modelo Entidad Relación Extendido (Modelo EER,
enhanced entity–relationship), contiene todos los
conceptos del Modelo ER, y los extiende para
representar requisitos de bases de datos más complejas.
❖ El Modelo EER agrega los conceptos de:
❖ Súper Entidad/Sub Entidad (Súper Clase /Sub Clase).
❖ Especialización/Generalización.
❖ Herencia de atributos y relaciones.

30
 Súper Entidad / Sub Entidad
❖ Una súper entidad es la entidad general sobre las que
derivan las otras entidades, que se llaman sub
entidades.
❖ En la súper entidad se indican los atributos comunes a
todas las sub entidades, se sobreentiende que las sub
entidades también tienen esos atributos, pero no se
indican de nuevo esos atributos en el diagrama.

31
 Súper Entidad / Sub Entidad
❖ Súper entidad VEHÍCULO. Sub entidades AUTOMÓVIL y
CAMIÓN.

32
 Especialización / Generalización.
❖ Generalización: el proceso de definir la súper entidad, a
partir de entidades especializadas (sub entidades).
❖ Especialización: es el proceso inverso de la
generalización, dado que define sub entidades a partir
de una entidad general (Super entidad).

33
Generalización

34
Especialización

35
 Herencia.
❖ Las sub entidades heredan los valores de todos los
atributos de la super entidad.
❖ Un elemento de la sub entidad también se clasifica
como un elemento súper entidad. Un automóvil
también es un vehículo. Entonces, hereda las relaciones
también.

36
Módulo 1: Introducción a las
bases de datos
1.4 Buenas prácticas

37
 Convenciones
❖ Cuando identificamos datos es importante seguir estándares para los
nombres de los elementos que estamos modelando.
❖ Existen muchos estándares. lo importante es seguir uno de ellos.
❖ Debemos definir:
• Idioma: ¿En qué idioma nombraremos la entidades, relaciones y
atributos? por ejemplo en español.
• En inglés debemos omitir cualquier carácter específico para ese
idioma, tal como “ñ” o la tilde en el idioma español. Por ejemplo,
debemos usar “descripcion” en lugar de descripción, y “anho” en
lugar de año.
• Singular o Plural: Definir si una entidad o atributo se escribirá en
plural o singular.
• Usar Prefijos: Si se quiere algún prefijo para los elementos. Ejemplo:
doctor_nombre, noctor_RUT, noctor_genero, etc.
38
 Convenciones
• Separador de palabra
• PascalCase: La primera letra de cada palabra comenzará
con mayúsculas. Por ejemplo:Persona,
FechaDeNacimiento.
• camelCase: La primera palabra comienza por minúscula. La
primera letra de cada palabra restante comenzará con
mayúsculas. Por ejemplo: persona, fechaDeNacimiento
• snake_case: Todas las letras en minúscula. Si es un
elemento formado por más de una palabra, estas palabras
se separarán por guion bajo `_`. Por ejemplo: persona,
fecha_de_nacimiento
• UPPERCASE: Todo en mayúscula sin importar la cantidad de
palabras. Por ejemplo:PERSONA, FECHADENACIMIENTO
39
 Convenciones
Por ejemplo si usamos esta elección:
• En español sin caracteres especiales.
• Entidades en singular, atributos en singular.
• Sin prefijos.
• snake_case para separar las palabras.
• Sólo abreviar palabras ampliamente usadas, como rut, dv, dni, etc.

Este es el resultado:
• Entidad: persona.
• Atributos: rut, dv, nombre, apellido_paterno, apellido_materno.

40
 Diccionario de datos
❖ Un diccionario de datos es un conjunto de definiciones que
contiene las características lógicas y puntuales de los datos que se
van a utilizar en el sistema que se programa, incluyendo nombre,
descripción, alias, contenido y organización.
❖ El diccionario de datos es la definición de todos los datos que
pertenecen a un sistema.
❖ El objetivo de un diccionario de datos es dar precisión sobre los
datos que se manejan en un sistema, evitando así malas
interpretaciones o ambigüedades.
❖ Los diccionarios de datos son buenos complementos a los
diagramas de flujo de datos , los diagramas entidad-relación, etc.

41
 Diccionario de datos
❖ Para cada campo se indica:
• Un nombre: para distinguir campo dato de otro.
• Tipo de datos: dominio de valores que puede tomar el campo.
• Clave primaria: indica si es parte de la clave primaria o no.
• Obligatorio: indica si el campo debe tener un valor.
• Valor por defecto: indica si hay un valor que se debe considerar
para el campo, cuando no se asigna un valor.
• Descripción: indica lo que representa en el sistema.

42
 Diccionario de datos
❖ Ejemplo para la entidad persona. Para cada entidad se debe
escribir esta información.

43
Ejercicios Modelo ER

44
 Modelamiento ER con www.draw.io
❖ Ingresar a www.draw.io y seleccionar “Google Drive”:

45
 Modelamiento EER con www.draw.io
❖ Seleccionar correo UC ya logeado o ingresarlo.
❖ Confirmar acceso:

46
 Modelamiento EER con www.draw.io
❖ Seleccionar correo UC ya logeado o ingresarlo:

47
 Modelo ER – Ejercicio 3 – Instituto educacional
❖ Se desea diseñar la base de datos de un Instituto. En la base de datos se
desea guardar los datos de los profesores del Instituto (RUT, nombre,
dirección y teléfono).
❖ Los profesores imparten cursos, y cada curso tiene un código de curso,
año, semestre y un nombre.
❖ Cada alumno está matriculado en uno o varios cursos.
❖ De cada alumno se desea guardar el nº de alumno, rut, nombre,
apellidos y fecha de nacimiento.
❖ Los profesores pueden impartir varios cursos, pero un curso sólo puede
ser impartido por un profesor. Cada curso tiene un grupo de alumnos,
uno de los cuales es el delegado del grupo.

48
 Modelo ER – Ejercicio 3 – Instituto educacional
❖ No queda claro cómo leer la relación DELEGADO cuando
no hay dirección.

49
 Modelo ER – Ejercicio 3 – Instituto educacional
❖ Se pueda una fecha indicando el sentido de la relación,
cuando sea necesario.

50
 Modelo ER – Ejercicio 4 – Clínica
❖ La clínica “SAN PEDRO” necesita llevar un control informatizado de su
gestión de pacientes y médicos.
❖ De cada paciente se desea guardar el código, nombre, apellidos,
dirección, provincia, código postal, teléfono y fecha de nacimiento. De
cada médico se desea guardar el código, nombre, apellidos, teléfono y
especialidad.
❖ Se desea llevar el control de cada uno de los ingresos que el paciente
hace en el hospital. Cada ingreso que realiza el paciente queda
registrado en la base de datos. De cada ingreso se guarda el código de
ingreso (que se incrementará automáticamente cada vez que el
paciente realice un ingreso), el número de habitación y cama en la que
el paciente realiza el ingreso y la fecha de ingreso.
❖ Un médico puede atender varios ingresos, pero el ingreso de un
paciente solo puede ser atendido por un único médico. Un paciente
puede realizar varios ingresos en el hospital. 51
Modelo ER – Ejercicio 4 – Clínica

52
 Modelo ER – Ejercicio 5 – Proyectos
Una empresa que realiza proyectos informáticos para sus clientes, y necesita diseñar el modelo
ER, para mejorar la administración de sus proyectos:
❖ De cada uno de los proyectos realizados tiene código, descripción, presupuesto, fecha de
inicio y fecha de fin. Los proyectos son solicitados por clientes, de los que se desea guardar
el RUT, teléfono, domicilio y razón social. Un cliente puede solicitar varios proyectos, pero
un proyecto es solicitado por un único cliente.
❖ En los proyectos participa un equipo de profesionales, de los que se dispone la siguiente
información: RUT, nombre, domicilio, teléfono y especialidad. La especialidad puede ser
jefe de proyectos, programador, analista funcional. Un profesional puede participar en
varios proyectos. Los proyectos son realizados por uno o más profesionales. Para los
programadores se necesita almacenar lenguaje de programación que domina, si está
certificado en ese lenguaje y el año de certificación. Para los analistas se requiere saber
que tipos análisis domina.
❖ Los profesionales que participan en los proyectos reciben pagos. De los pagos realizados se
quiere guardar el número de pago, concepto, cantidad y fecha de pago. También interesa
almacenar los diferentes tipos de pagos que puede realizar la empresa. De cada uno de los
tipos de pagos se desea guardar el código y descripción. Un tipo de pago puede pertenecer
a varios pagos. 53
Modelo ER – Ejercicio 5 – Proyectos

54
 Modelo ER – Ejercicio 6 – Agencia
❖ Una agencia de viajes desea informatizar toda la gestión de los viajeros
que acuden a esta agencia y los viajes que estos realizan. La agencia
proporciona la siguiente información:
❖ La agencia desea guardar la siguiente información de los viajeros: RUT,
nombre, dirección y teléfono. De cada uno de los viajes que maneja la
agencia interesa guardar el código de viaje, número de plazas, fecha en
la que se realiza el viaje y otros datos. Un viajero puede realizar tantos
viajes como desee con la agencia. Un viaje determinado sólo puede ser
cubierto por un viajero.
❖ Cada viaje realizado tiene un lugar destino y un lugar de origen. De cada
uno de ellos se quiere almacenar el código y nombre. Un viaje tiene un
único lugar de destino y un único lugar de origen.
55
Modelo ER – Ejercicio 6 – Agencia

56