UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL

DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

MODELAMIENTO DE DATOS [IS - 381]

1. DATOS GENERALES
Facultad : Ingeniería de Minas, Geología y Civil
Escuela Profesional : Ingeniería de Sistemas
Departamento Académico : Matemática y Física
Currículo : 2018
Sigla : IS – 381
Grupo : Grupo A, B y C
Semestre : 2025-I
Créditos : 4.0
: 2.0 HT, 2.0 HP, 2.0 HL
Horas Semanales

Docentes Teoría : Ing. Karel Peralta Sotomayor

Ing. Javier Portillo Quispe

Docentes Práctica : Ing. Javier Portillo Quispe

Ing. Gladys Huarcaya Vicente

Docentes Laboratorio : I n g . Javier Portillo Quispe

Ing. Richar Zapata Casaverde
Ing. Karel Peralta Sotomayor
Ing. José Guerrero Hinostroza
Ing. Elvira Fernández Jeri
2. SUMILLA
Introducción al análisis de datos. Fases del diseño conceptual y entidades. Relaciones y
atributos. Cardinalidad. Metodología para diseño conceptual de base de datos.
Criterios para elección de conceptos. Diseño de vistas. Análisis estructurado de procesos.
Análisis funcional del diseño de base de datos. Análisis conjunto de datos y funciones.
Diseño lógico de alto nivel. Diseño lógico para el modelo relacional. Diseño Físico de la
Base de Datos. Bases de datos no relacionales.

3. COMPETENCIA GENÉRICA
Analizar los requerimientos de información del negocio, modelarlos y traducirlos en un
diseño físico de la base de datos.

4. COMPETENCIA DE LA ASIGNATURA
Uso de herramientas para el diseño conceptual de bases de datos, aplicando
principios teóricos a un caso de estudio de un negocio.
Emplear metodologías de diseño conceptual y análisis funcional para diseñar
las bases de datos.
Transformar el modelo conceptual de base de datos como modelo lógico
relacional de la base de datos y posteriormente en el modelo físico relacional.
Página 1 de 6
 UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL
DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

5. PROGRAMA DE CONTENIDOS

UNIDAD DE APRENDIZAJE: MODELOS DE DATOS RELACIONALES

CONTENIDOS
SEMANAS

CONCEPTUAL (Saber) PROCEDIMIENTAL (Hacer) ACTITUDINAL (Querer)

Explica los fundamentos

Introducción al
01 del modelamiento y la
modelamiento de datos
base de datos.
Identifica los beneficios
Modelado de Datos
02 del modelado orientado a
Orientado a Objetos
objetos.
Describe la importancia
del uso de identificadores
03 Identificadores para las entidades y su
aplicación en el modelo
de datos. Demuestra interés
Comprende la asistiendo puntualmente y
redundancia de datos en participando activamente
04 Redundancia el mundo real y lo evita
en cada una de las
mediante el proceso de
abstracción. sesiones.
Comprende el uso del Demuestra responsabilidad
modelo conceptual e y creatividad cuando
identifica las entidades trabaja individualmente o
importantes y sus en equipo.
05 Modelo Conceptual relaciones en el concepto Tiene un punto de vista
de dominio que definen el
crítico y fundamenta sus
ámbito del problema que
tratará la solución del ideas con argumentos
sistema. científicos.
Comprende que el
modelo relacional
proporciona una forma
06 Modelo Relacional estándar de representar y
consultar datos que
cualquier aplicación
podría utilizar
Comprende y aplica el
proceso de normalización
07 Normalización
con el objeto de
minimizar la redundancia

Página 2 de 6
 UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL
DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

UNIDAD DE APRENDIZAJE: MODELOS DE DATOS RELACIONALES

CONTENIDOS
SEMANAS

CONCEPTUAL (Saber) PROCEDIMIENTAL (Hacer) ACTITUDINAL (Querer)

de datos facilitando su
gestión posterior.
08 EXAMEN PARCIAL
Comprende los lenguajes
relacionales en la
realización de consultas,
09 Lenguaje Relacional
realización de cálculos, el
álgebra relacional y el
SQL.
Comprende que datos
Diseño de Base de deben almacenarse y
10
Datos como se relacionan los
elementos de datos.
Integra el uso de índices
11 Indexamiento como lista de elementos y
números de referencia.

UNIDAD DE APRENDIZAJE: MODELOS DE DATOS NO RELACIONALES

CONTENIDOS
SEMANAS

CONCEPTUAL (Saber) PROCEDIMIENTAL (Hacer) ACTITUDINAL (Querer)

Explica la diferencia entre

los modelos de datos
relacionales y los modelos
Introducción a las BD
12 no relacionales.
no relacionales
Identifica los pros y
contras de cada uno de Demuestra interés
estos paradigmas. asistiendo puntualmente y
participando activamente
en cada una de las
sesiones.
Demuestra responsabilidad
y creatividad cuando

Página 3 de 6
 UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL
DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

UNIDAD DE APRENDIZAJE: MODELOS DE DATOS NO RELACIONALES

CONTENIDOS
SEMANAS

CONCEPTUAL (Saber) PROCEDIMIENTAL (Hacer) ACTITUDINAL (Querer)

Comprende la generación trabaja individualmente o

y manejo de grandes en equipo.
Manejo de grandes volúmenes de datos, las Tiene un punto de vista
13
volúmenes de datos estrategias de
crítico y fundamenta sus
almacenamiento y
recuperación. ideas con argumentos
científicos.
Explica el desarrollo de un
trabajo semestral
14 Revisión de trabajo final
aplicando los conceptos
aprendidos
15 EXAMEN FINAL

6. ESTRATEGIAS METODOLOGICAS
El curso es de naturaleza teórico-práctico, por lo mismo que se desarrollará
con guías de laboratorio entregadas por el profesor antes de cada laboratorio.
Se dejará prácticas de laboratorio para la presentación de los mismos en cada
sesión de laboratorio.
Asistencia y asesoramiento del docente durante los laboratorios y en los
horarios de atención establecidos fuera de hora de clases.
Fomentar en los estudiantes el desarrollo de habilidades y técnicas a través del
planteamiento de problemas y casos prácticos.

7. MATERIALES EDUCATIVOS
Presentaciones de las clases
Libros digitales
Recursos de la web

8. CRITERIOS DE EVALUACIÓN

a) ASPECTOS GENERALES
Las evaluaciones se regirán en la escala vigesimal, con notas de cero a
veinte.

Página 4 de 6
 UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL
DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

Las evaluaciones y sus respectivas notas serán entregadas a los

estudiantes para su revisión y firma, luego del cual no habrá lugar a
reclamo.
No rendir exámenes ni presentar trabajos se calificarán con CERO (00).

b) REQUISITOS DE APROBACIÓN
La nota mínima de aprobación de la asignatura es de ONCE (11).
Asistencia no menor al 80% del total de clases de laboratorio.

c) EVALUACIONES
Examen de Parcial (EP) 25%
Examen Final (EF) 25%
Promedio de Laboratorio (PL) 30%
Trabajo Final (TF) 20%

d) PROMEDIO FINAL (PF)

El promedio final del curso se obtiene aplicando la siguiente fórmula:

PF = 0.25*(EP) + 0.25*(EF) + 0.30*(PL) + 0.20*(TF)

9. PROGRAMA DE CONTENIDO DE LABORATORIOS

LAB. CONTENIDO

01 ERwin Data Modeler

Diagramación del DER y elaboración del Diccionario de Datos.
Lenguaje de Manipulación de Datos (DML) – Parte I
02 Uso de la sentencia SELECT de una tabla. Operadores Aritméticos, de
Asignación, de Comparación, Lógico, operadores BETWEEN y Operadores
LIKES
03 Lenguaje de Manipulación de Datos (DML) – Parte II
Uso del INSERT, de registro único o múltiples registros.
04 Lenguaje de Manipulación de Datos (DML) – Parte III
Uso de funciones UPDATE y DELETE.
05 Lenguaje de Manipulación de Datos (DML) – Parte IV
Uso de la sentencia SELECT en tablas cruzadas, condicionales, y uso de alias.
Creación de tablas temporales haciendo uso de las sentencias SELECT e
INSERT.
06 Data Definition Language (DDL).
Uso de sentencias: CREATE, ALTER, DROP, TRUNCATE

Página 5 de 6
 UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL
DEPARTAMENTO ACADÉMICO DE MATEMÁTICA Y FÍSICA
AREA DE INFORMÁTICA

LAB. CONTENIDO

07 PRIMER EXAMEN PRÁCTICO

08 Recuperación Avanzada de Consulta de Datos
Uso de JOIN.
09 Recuperación Avanzada de Consulta de Datos
Uso de GROUP BY, HAVING, ORDER BY, UNION y Funciones Agregadas.
10 Transact-SQL Programación
Uso de variables, condicionales, bucles.
11 Creación de Base de Datos y Grupos de Archivos
12 Procedimientos almacenados
13 Vistas y Triggers
14 Tareas planificadas (Jobs)
16 SEGUNDO EXAMEN PRÁCTICO

10. BIBLIOGRAFÍA
DE MIGUEL Adoración; PIATTINI Mario. “Fundamentos y Modelos de Bases de
Datos. Editorial RAMA. 1999.
DE MIGUEL Adoración; PIATTINI Mario. “Diseño de Bases de Datos
Relacionales”. Editorial RAMA. 1999.
PIATTINI, Mario, GARCIA Félix. “Calidad en el Desarrollo y Mantenimiento de
Software”. Editorial Alfaomega Ra-Ma. 2003.
HANSEN Gary; HANSEN James. “Diseño y Administración de Base de Datos”.
Editorial Prentice Hall. 1998.
LUCAS GOMEZ, Angel. “Diseño y Gestión de Sistemas de Bases de Datos”.
Editorial Paraninfo. 1993.
MARTIN James. “Organización de las Bases de Datos”. Editorial Prentice Hall
Internacional. 1977.

Ayacucho, 17 de marzo del 2025

Página 6 de 6
Modelamiento de Datos (IS-348) Primera Semana

MODELAMIENTO DE DATOS (IS-348)

SESIÓN Nº 01: Introducción

Presentación del Docente

Presentación de alumnos

Presentación del Silabo

Docente: Javier Portillo

Correo: [email protected]
Celular: 983681689

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

Que es un modelo?

Un modelo es una representación simplificada de la realidad, de manera

gráfica, física o matemática con el único propósito de analizar, explicar, y
describir procesos o fenómenos. Digno de imitarse, es un patrón o guía de
acción, idealización de la realidad. Construimos y usamos modelos para resolver
problemas. Así, decimos que un plano o una mapa es una representación
bidimensional de la estructura geográfica de una cierta área.

Los modelos se clasifican como icónicos, análogos y simbólicos. Los modelos

icónicos son la representación física, a escala reducida o aumentada de un
sistema real. Por ejemplo, un barco de juguete, es un modelo icónico de uno
real. Los modelos análogos esencialmente requieren la sustitución de una
propiedad por otra con el fin de permitir la manipulación del modelo. Después
de resolver el problema, la solución sé reinterpreta de acuerdo al sistema original.
Por ejemplo, un modelo de redes eléctricas puede utilizarse como un modelo
análogo para el estudio de flujos en un sistema de transporte. En el campo de la
psicología, la conducta de aprendizaje de los animales (ratas, perros, monos,
etc.), ha servido como modelo analógico para estudiar las leyes del aprendizaje
humano.

El modelo simbólico o matemático es una representación de la realidad a través

de símbolos, los que tienen generalmente un carácter matemático o lógico. Un
tipo de modelo simbólico es una ecuación. Una ecuación es fácil de
comprender y de manejar, prestándose además para procesos
computacionales.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

BASE DE DATOS

Las bases de datos son exactamente lo que dice su nombre, un almacén de

información perteneciente a un mismo contexto y almacenado
sistemáticamente para su posterior uso. Que se administra mediante un motor o
gestor de base de datos abreviado SGBD (del inglés Database Management
System o DBMS) que permiten almacenar y posteriormente acceder a los datos
de forma rápida y estructurada. Los sistemas de gestión de base de datos son
un tipo de software muy específico, que sirve de interfaz entre la base de datos,
el usuario y las aplicaciones que la utilizan.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

Cada base de datos se compone de una o más tablas que guardan un conjunto
de datos. Éstas se dividen en columnas y filas:

Columnas: guardan una parte de la información sobre cada elemento que

queramos guardar en la tabla

Fila: cada una conforma un registro o tupla.

En este sentido; una biblioteca puede considerarse una base de datos

compuesta en su mayoría por documentos y textos impresos en papel e
indexados para su consulta. Actualmente, y debido al desarrollo tecnológico de
campos como la informática y la electrónica, la mayoría de las bases de datos
están en formato digital, siendo este un componente electrónico, por tanto se
ha desarrollado y se ofrece un amplio rango de soluciones al problema del
almacenamiento de datos.

Características:
Entre las principales características de los sistemas de base de datos podemos
mencionar:

a. Independencia lógica y física de los datos.

b. Redundancia mínima.
c. Acceso concurrente por parte de múltiples usuarios.
d. Integridad de los datos.
e. Consultas complejas optimizadas.
f. Seguridad de acceso y auditoría.
g. Respaldo y recuperación.
h. Acceso a través de lenguajes de programación estándar.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

DIFERENCIA ENTRE DATO E INFORMACIÓN

Dato
Los datos son la mínima unidad semántica, y se corresponden con elementos
primarios de información que por sí solos son irrelevantes como apoyo a la toma
de decisiones. También se pueden ver como un conjunto discreto de valores,
que no dicen nada sobre el porqué de las cosas y no son orientativos para la
acción.

Un número telefónico o un nombre de una persona, por ejemplo, son datos que,
sin un propósito, una utilidad o un contexto no sirven como base para apoyar la
toma de una decisión. Los datos pueden ser una colección de hechos
almacenados en algún lugar físico como un papel, un dispositivo electrónico
(CD, DVD, disco duro...), o la mente de una persona. En este sentido las
tecnologías de la información han aportado mucho a recopilación de datos.

Como cabe suponer, los datos pueden provenir de fuentes externas o internas a
la organización, pudiendo ser de carácter objetivo o subjetivo, o de tipo
cualitativo o cuantitativo, etc.

Información
La información se puede definir como un conjunto de datos procesados y que
tienen un significado (relevancia, propósito y contexto), y que por lo tanto son
de utilidad para quién debe tomar decisiones, al disminuir su incertidumbre.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Primera Semana

Diseño de Base de Datos de Ventas

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Segunda Semana

INTRODUCCIÓN AL MODELADO DE DATOS

Base de datos
Llamado también banco de datos, es un conjunto, colección o depósito de
datos almacenados en un soporte informático como es un Gestor de Bases de
Datos(SGBD). Los datos deben estar interrelacionados y estructurados de
acuerdo con un modelo capaz de recoger el máximo contenido semántico.

una base de datos es un conjunto de datos estructurados que pertenecen a un

mismo contexto y, en cuanto a su función, se utiliza para administrar de forma
electrónica grandes cantidades de información; para su posterior recuperación,
análisis o transmisión.

Sistema Gestor de Bases de Datos

Es un conjunto coordinado de programas, procedimientos, lenguajes, etc.. que
suministra tanto a los usuarios como al administrador de la base de datos, los
medios necesarios para describir, manipular y utilizar los datos almacenados en
la base, manteniendo confidencialidad, integridad, disponibilidad (CID) y
seguridad. Su objetivo principal es simplificar y facilitar el acceso a datos.

Modelado de datos

Es el conjunto de conceptos, reglas y convenciones que permiten describir y

manipular los datos del mundo real que constituye nuestra visión del mundo real
relevante para nuestro sistema. El modelo de datos es un “dispositivo de
abstracción” para la interpretación de la realidad con el objetivo de captar su
semántica. Al aplicar el modelo de datos se obtiene una estructura de datos
llamada esquema.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Segunda Semana

• Muchos autores distinguen dos tipos de modelos lógicos de

datos: Conceptuales (Modelo Entidad- relación (E/R)) y convencionales (Modelo
Relacional).

Tipos de Modelado de Datos

Modelo Conceptual: Representa una vista general de los datos, sin enfocarse en
detalles técnicos. Se usa para entender la estructura y las relaciones entre las
entidades principales.
Modelo Lógico: Es una versión más detallada del modelo conceptual, donde se
definen las claves primarias, claves foráneas y otros atributos sin considerar
detalles específicos del sistema de gestión de bases de datos (DBMS).

Vista en Modo Diseño de la tabla Cliente.

Clave Primaria o Primary Key.- Toda tabla debe contener para poder ser
representada una clave primaria o candidata. Esta clave identifica de forma
unívoca cada fila de una entidad. Debe ser elegida adecuadamente de forma
tal que no pueda repetirse. Por ej: en la imagen vemos que se eligió el atributo
codCliente como clave primaria. De este modo nos garantizamos de que no van
a existir dos clientes con el mismo código.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Segunda Semana

Clave Secundaria o Foreign Key.- Es una columna o combinación de columnas

en una tabla, cuyo/s valor/es es/son el valor de una clave primaria para otra otra
tabla. La clave foránea debe ser del mismo tipo de dato que la clave primaria
de la tabla con la cual se relaciona. En el ejemplo de la tabla Cliente tenemos
como clave foránea codZona quien es clave primaria en la tabla Zona. Se
pueden relacionar únicamente si se dá esta paridad de vincular clave primaria
con clave foránea del mismo tipo de datos.

Vista Entidad-Relación de las Tablas Cliente & Zona.

Modelo Físico: Es la implementación del modelo lógico en un sistema de base

de datos específico, definiendo estructuras como tablas, índices y restricciones.

Beneficios del Modelado de Datos

a. Facilita la comprensión y documentación del sistema de datos.
b. Optimiza el rendimiento de consultas y almacenamiento de la base de
datos.
c. Reduce la redundancia y mejora la integridad de los datos.
d. Ayuda en la comunicación entre desarrolladores, analistas y usuarios.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Segunda Semana

Arquitectura ANSI a tres niveles

1. Modelo conceptual

El modelo conceptual de bases de datos es una representación abstracta de los

datos y sus relaciones dentro de un sistema, sin entrar en detalles técnicos sobre
cómo se almacenarán físicamente. Su principal objetivo es describir la estructura
de la información de manera clara y entendible para los interesados, como
analistas, diseñadores y usuarios del sistema.

Modelo entidad -Relación

 Modelo elaborado por PETER CHEN (1976). Sirve para establecer una visión
global de los datos de una organización o de un sistema de información,
en un nivel de
 abstracción próxima al usuario e independiente de las características
físicas del equipo donde se vaya a instrumentar el sistema.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-348) Segunda Semana

 Constituye el Nivel Conceptual de la arquitectura ANSI

 Consiste en describir la información de la organización mediante la
definición de entidades y asociaciones o interrelaciones entre ellas.
Entidad
Cualquier objeto real o abstracto sobre el cual queremos tener información
que tiene existencia por sí mismo y se puede identificar de manera clara y
precisa (empleado, artículo, cliente, planificaciones,estándares…).
• Una entidad se representará mediante un rectángulo con un nombre.
• Para poner nombre a la entidad, normalmente se utiliza la forma
singular. (y mayúsculas).
• Las entidades pueden ser regulares o débiles. Las primeras tienen existencia
por sí mismas mientras que las débiles dependen de otra entidad.

Atributos
Cada una de las propiedades, características o unidades de información
básicas de una entidad o interrelación.
• Aquel o aquellos atributos que identifican unívocamente cada una de las
ocurrencias de la entidad se denomina identificador principal.
• Ejemplo
• Entidad : CLIENTE
• Atributos: DNI, Nombre, dirección, teléfono, etc...
• Identificador Principal: DNI

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Modelamiento de Datos

Al igual que los arquitectos realizan sus planos para construir casas, los diseñadores de
base de datos necesitan realizar modelos para construir sus bases de datos. Los modelos
facilitan la comunicación entre el diseñador de base de datos y los usuarios finales. Los
modelos son fáciles de utilizar y cambiar, ya que son sólo una imagen muy simplificada
del sistema de información que se desea desarrollar.
El modelado de datos; también conocido como “Modelamiento de datos”, es el proceso
que se aplica para crear una representación gráfica de la visión que tienen los usuarios
de los datos, de esto se desprende que es la tarea más importante en el desarrollo de
eficaces aplicaciones de bases de datos.
El modelo Entidad-Relación (E-R).- es un modelo conceptual utilizado en el diseño
de bases de datos. Su propósito es representar de manera gráfica y estructurada los
datos y sus relaciones antes de implementarlos en un sistema gestor de bases de datos
(SGBD), fue desarrollado por Peter Chen en 1976.
Los elementos básicos de MER se presentan en un diagrama simple que permite
establecer en forma general un modelo de datos. Los elementos fundamentales se
presentan en la Figura 3.1.

Figura 3.1: Elementos de diagrama de CHEN.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Entidad .-Es cualquier objeto o evento acerca del cual podemos recolectar datos.
Puede ser una persona, lugar o cosa.

Ejemplo: puede ser un cliente, un trabajador o un artículo. También son entidades los
eventos o acontecimientos que ocurren en el tiempo; por ejemplo, una venta, un
requerimiento de artículos de almacén o la matrícula de un alumno.

Figura 3.2: Entidad y atributos. Siendo rut atributo “clave” o “identificador”.

Figura 3.3: Entidad y atributos. Siendo Cod_prof atributo “clave” o “identificador”

o llave primaria (pk).

Figura 3.4: Ejemplo de transformación de un tipo de entidad y sus atributos

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Atributo.- Son las propiedades que describen las características de una Entidad.

Ejemplo: En la Entidad PACIENTE, registraremos los atributos: DNI, Nombre, Dirección,

Fecha de su última consulta y los detalles de la consulta, diagnóstico y receta.

Tipos de atributos

a) Atributo compuesto.- Un atributo compuesto en una base de datos es un atributo

que puede dividirse en varios subatributos más simples y significativos. Es decir, un
atributo compuesto está formado por múltiples valores relacionados que pueden
representarse de manera separada (atributo atómico).

Por ejemplo Dirección (puede dividirse en: calle, número, localidad, provincia y código
postal.)

b) Atributo multivaluado o compuesto.- atributo que puede tener varios valores para
cada instancia de una entidad. Por ejemplo, un empleado puede tener varios números de
teléfono.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

c) Atributo derivado.- Un atributo derivado es aquel cuyo valor se calcula a partir de

otros atributos de la misma entidad o de entidades relacionadas.
Por ejemplo Edad. (se puede calcular a partir de la fecha de nacimiento).

Relaciones (Interrelaciones)

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un
nombre que describe su función. Las relaciones se representan gráficamente mediante
rombos y su nombre aparece en el interior (Generalmente con frases cortas).

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Las relaciones se expresan mediante un verbo, procurando así formar frases que
expresan un proceso de gestión, considerando que las entidades son sustantivos que
actúan como sujeto y complemento cuando se asocian. En la figura 3.4 se muestra la
relación sujeto-verbo-complemento, en este ejemplo, la ocurrencia de la relación: “Juan
García estudia programación” en sentido inverso se lee “Programación es estudiada por
Juan García”.

Figura 3.4: Ejemplo de relación bajo el modelo E/R

Las entidades en su mayoría no suelen quedar aisladas, sino que necesitan de otras
entidades para cumplir su propósito; por ejemplo, si estamos creando una base de datos
para un colegio y contamos con la entidad Matrícula, es necesario que esta se relacione

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

con una entidad Alumno, ya que no puede existir una matrícula que no tenga alumno;
también necesitaría relacionarse con una entidad Asistente académico (para conocer
quién realizó la matrícula). Si trasladamos este ejemplo a un esquema gráfico, tendríamos
algo similar a la figura siguiente:

Tipo de relaciones

1) Relaciones binarias o de grado 2.- cuando la relación se establece entre dos

entidades diferentes. En un sistema de bases de datos, estas relaciones son las más
frecuentes. Ejemplo:

2) Relaciones unitarias o recursivas.- se establece entre entidades de la misma

clase. Participa solo una entidad. Por ejemplo, un empleado supervisa a otros empleados.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

3) Relaciones ternarias o de grado 3.- Participan 3 entidades diferentes.

Relaciones de especialización.- Relaciones que se establecen en un diagrama E/R

entre un supertipo y sus subtipos. Las relaciones de generalización en un modelo entidad-
relación son relaciones de contención entre entidades de alto y bajo nivel. Se utilizan para
agrupar entidades con características comunes en una entidad generalizada. La
estructura permite a la información que se repite y usa relaciones padre/Hijo: cada padre
puede tener muchos hijos pero cada hijo sólo tiene un padre.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Atributos de una relación

Cabe mencionar que en algunos casos las relaciones pueden tener atributos y así se
pueden convertir en una tabla en el modelo lógico y/o físico. Una relación puede tener
sus propios atributos similares a los que se manejan en las entidades. Por ejemplo, si se
requiere registrar las fechas en las que un vehículo fue utilizado por una determinada

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

persona, se incluye el atributo Fecha a la relación CONDUCE, como se muestra en la

Figura 3.5.
Los atributos de una relación se representan gráficamente mediante un óvalo, de manera
análoga a los utilizados en una entidad.

Figura 3.5: Relación con atributo

En la Figura 3.6 se observa que a cada instancia de la relación CONDUCE se le asigna un

valor del atributo, que corresponde a la fecha en la que una persona utilizó un
determinado vehículo.

Figura 3.6: Instancias del atributo Fecha de la relación CONDUCE

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Otro ejemplo:

Cardinalidad

En el modelo entidad-relación, la cardinalidad es el número de veces que una entidad se

puede relacionar con otra. Cantidad de relaciones que tiene una entidad con otra.
Cantidad de elementos que le corresponden a una entidad de otra. La cardinalidad con
la que una entidad participa en una relación especifica el número mínimo y el número
máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha
entidad. Es una restricción de integridad.

Cardinalidad mínima.- Indica el número mínimo de veces que una entidad debe
participar en una relación.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Cardinalidad máxima.- Indica el número máximo de veces que una entidad puede
participar en una relación.

Tipos de cardinalidades

1) Uno a uno (1:1) : Cada instancia de una entidad se asocia con una única instancia
de otra entidad.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

En el mundo real es posible suponer que una persona conduce un vehículo y un

vehículo es conducido por una sola persona. Ejemplo:

Supongamos que estamos elaborando una base de datos para un colegio y contamos
con las entidades Docente y Tutor.

Notemos que ambas entidades tienen atributos en común; para no tener redundancias
de datos, podemos agrupar los atributos comunes en una nueva entidad llamada Persona
y luego relacionar Docente con Persona de uno a uno, porque a un docente le
corresponde una persona (y viceversa); lo mismo sucede con Tutor, a un tutor le
corresponde una Persona (y viceversa).

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

2) Uno a muchos (1:N) : Una instancia de la entidad A puede estar relacionada con
muchas instancias de la entidad B, pero cada instancia de B solo se asocia con una única
instancia de la entidad A. El concepto es similar cuando se analiza la cardinalidad muchos
a uno.

Para analizar la cardinalidad uno a muchos se supone que un vehículo puede ser
conducido por varias personas. Ejemplo:

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

3) muchos a muchos (N:M) : se produce cuando varios registros de una tabla se

asocian a varios registros de otra tabla. Por ejemplo, existe una relación de muchos a
muchos entre los clientes y los productos: los clientes pueden comprar varios productos
y los productos pueden ser comprados por muchos clientes.

Para la cardinalidad N:M se supone que una persona puede conducir varios vehículos y
que un vehículo es conducido por varias personas. Ejemplo:

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Comencemos definiendo dos entidades con algunos atributos: Colaborador y

Profesión.

Si realizamos el análisis de derecha a izquierda, detectaremos que una profesión puede

englobar a varios colaboradores.

De izquierda a derecha notaremos que un colaborador podría tener varias profesiones.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

El resultado de nuestro análisis queda de la siguiente forma:

Cuando tenemos un resultado similar a la imagen anterior, podemos concluir que se

trata de una relación de varios a varios (muchos a muchos).

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

DIFERENCIA ENTRE LLAVE (CLAVE, ÍNDICE) PRIMARIA Y LLAVE

UNICA(UNIQUE)

LLAVE PRIMARIA

Es una restricción en una tabla de base de datos que garantiza que cada fila tenga un
identificador único. Sirve para identificar de manera única cada registro en la tabla y no
puede contener valores duplicados ni NULL.
Una clave primaria es una columna o una combinación de columnas (Llave primaria
compuesta) que se establecen para identificar de manera única cada registro en una
tabla. Una clave primaria tiene restricciones de unicidad y no permite valores NULL, lo
que garantiza que no haya valores duplicados y que siempre se asigne un valor.

Características de una llave primaria:

❖ Única: No puede haber dos filas con el mismo valor en la clave primaria.
❖ No nula: No puede contener valores NULL.
❖ Inmutable: No debería cambiar con el tiempo.
❖ Índexada automáticamente: Mejora el rendimiento en búsquedas.

Ejemplo:

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Llave primaria compuesta

Una llave compuesta en una base de datos es una clave primaria que está formada por
dos o más columnas en una tabla. Se usa cuando ninguna columna por sí sola puede
identificar de manera única una fila, pero la combinación de varias sí lo hace.

Las llaves compuestas en bases de datos relacionales son claves primarias formadas por
dos o más columnas. Se utilizan cuando una sola columna no es suficiente para identificar
de manera única una fila en una tabla. Aquí tienes algunos ejemplos de su uso:

1. Relación entre Estudiantes y Cursos (M:N)

Escenario:
En una universidad, los estudiantes pueden inscribirse en varios cursos, y cada curso
puede tener varios estudiantes. Se usa una tabla intermedia Inscripciones con una clave
compuesta.

Uso de tablas intermedias en las relaciones de mucho a muchos (M:N)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Volviendo al ejemplo de la universidad en la que los alumnos se inscriben a varios cursos.

Tablas:
Estudiante (id_estudiante, nombre, apellido)
Curso (id_curso, nombre_curso)
Inscripción (id_estudiante, id_curso, fecha_inscripcion)

Clave compuesta en la tabla Inscripciones:

La clave primaria estará formada por (id_estudiante, id_curso), asegurando que un
estudiante no se inscriba dos veces en el mismo curso.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

CREATE TABLE Inscripción(

id_estudiante INT,
id_curso INT,
fecha_inscripcion DATE,
PRIMARY KEY (id_estudiante, id_curso),
FOREIGN KEY (id_estudiante) REFERENCES Estudiante(id_estudiante),
FOREIGN KEY (id_curso) REFERENCES Curso(id_curso)
);

Aquí, ni id_estudiante ni id_curso son únicos por sí solos, ya que un estudiante puede
inscribirse en varios cursos y un curso puede tener varios estudiantes. Sin embargo, la
combinación de id_estudiante y id_curso es única para cada inscripción.

LLAVE UNICA
En bases de datos, una llave única (UNIQUE KEY) es una restricción que asegura que los
valores en una columna (o combinación de columnas) sean únicos en toda la tabla. A
diferencia de la clave primaria (PRIMARY KEY), una clave única permite valores NULL
(aunque en algunas bases de datos solo permite un NULL).

Ejemplo.
CREATE TABLE Empleado (
DNI INT PRIMARY KEY,
nombre VARCHAR(100),
correo VARCHAR(100),
Celular CHAR(9),
UNIQUE(correo,Celular)-- Garantiza que no haya correos duplicados y que no haya
números de celulares duplicados
);

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Diferencias entre Clave Primaria y Clave Única:

Instancia y Esquema
Instancia
En el modelo entidad-relación (E-R) de bases de datos, una instancia se refiere a un
conjunto de datos específicos que existen en un momento determinado en la base de
datos. Es decir, es el conjunto de valores almacenados en las tablas (relaciones) en un
instante de tiempo. Es el contenido real de la base de datos en un momento dado. Puede
cambiar con el tiempo a medida que los datos se actualizan.

Ejemplo:
Supongamos que tenemos la siguiente entidad en un modelo E-R.

Aquí, la tabla con estos registros representa una instancia de la entidad "Estudiante" en
un instante específico. Si mañana agregamos un nuevo estudiante o eliminamos uno, la
instancia cambiará.
Esquema
Es la estructura o diseño de la base de datos, que define entidades, atributos y relaciones.
Es estático y no cambia con los datos. Ejemplo:

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Tercera Semana

Docente: Mg. Ing. Javier Portillo Quispe

PRACTICA
EJERCICIO 1
A partir del siguiente enunciado se desea realiza el modelo entidad-relación.
“Una empresa vende productos a varios clientes. Se necesita conocer los datos personales
de los clientes (nombre, apellidos, dni, 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 clients. 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 RUC, nombre y dirección”.
EJERCICIO 2
A partir del siguiente enunciado se desea realizar el modelo entidad-relación.
“Se desea informatizar la gestión de una empresa de transportes que reparte paquetes por
toda España. Los encargados de llevar los paquetes son los camioneros, de los que se
quiere guardar el dni, nombre, teléfono, dirección, salario y población en la que vive. De
los paquetes transportados interesa conocer el código de paquete, descripción,
destinatario y dirección del destinatario. Un camionero distribuye muchos paquetes, y un
paquete sólo puede ser distribuido por un camionero.De las provincias a las que llegan los
paquetes interesa guardar el código de provincia y el nombre. Un paquete sólo puede
llegar a una provincia. Sin embargo, a una provincia pueden llegar varios paquetes.De los
camiones que llevan los camioneros, interesa conocer la matrícula, modelo, tipo y
potencia. Un camionero puede conducir diferentes camiones en fechas diferentes, y un
camión puede ser conducido por varios camioneros”.
EJERCICIO 3
A partir del siguiente enunciado diseñar el modelo entidad-relación.
“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 (DNI, nombre, dirección y teléfono). Los
profesores imparten módulos, y cada módulo tiene un código y un nombre. Cada alumno
está matriculado en uno o varios módulos. De cada alumno se desea guardar el nº de
expediente, nombre, apellidos y fecha de nacimiento. Los profesores pueden impartir
varios módulos, pero un módulo sólo puede ser impartido por un profesor. Cada curso
tiene un grupo de alumnos, uno de los cuales es el delegado del grupo”.
EJERCICIO 4
A partir del siguiente supuesto diseñar el modelo entidad-relación.
“Se desea diseñar una base de datos para almacenar y gestionar la información empleada
por una empresa dedicada a la venta de automóviles, teniendo en cuenta los siguientes
aspectos:La empresa dispone de una serie de coches para su venta. Se necesita conocer la
matrícula, marca y modelo, el color y el precio de venta de cada coche.Los datos que
interesa conocer de cada cliente son el NIF, nombre, dirección, ciudad y número de
teléfono: además, los clientes se diferencian por un código interno de la empresa que se
incrementa automáticamente cuando un cliente se da de alta en ella. Un cliente puede
comprar tantos coches como desee a la empresa. Un coche determinado solo puede ser
comprado por un único cliente.El concesionario también se encarga de llevar a cabo las
revisiones que se realizan a cada coche. Cada revisión tiene asociado un código que se
incrementa automáticamente por cada revisión que se haga. De cada revisión se desea
saber si se ha hecho cambio de filtro, si se ha hecho cambio de aceite, si se ha hecho
cambio de frenos u otros. Los coches pueden pasar varias revisiones en el concesionario”.
EJERCICIO 5
A partir del siguiente supuesto diseñar el modelo entidad-relación.
“La clínica “SAN PATRÁS” 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, població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”.
Modelamiento de Datos (IS-381) Semana 4

Relación 1:1, 1:N, M:N

1:1

Muy probable que se puede unir en una sola tabla.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1:N

M:N

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Del modelo conceptual al modelo relacional

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Fases a seguir en el Diseño de Bases de Datos

Transformación del Modelo conceptual al modelo relacional

➢ Se aplica el sentido común.

➢ El cual da lugar a unas reglas fáciles de deducir e implementar.

1) Las entidades pasan a ser tablas(=Relaciones)

➢ Los atributos pasan a ser columnas

➢ El ID pasa a ser PK

1) Las interrelaciones (rombos) pasan a ser:

FKs (Las 1:1, 1:N): Que pasan a una de las tablas

O Crean una nueva table nueva (las N:M o ternarias)

Dependiendo de las cardinalidades

Los atributos de interrelación(“rombo”) se van con la FK, o la nueva tabla.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1:1

1:N

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

N:M

Doble relación

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.1 Entidades (Fuertes y Débiles)

Cada una de las entidades (fuertes y débiles) del diagrama E/R genera una tabla, donde cada uno de los atribu‑
tos de la entidad pasa a ser una columna de la tabla.
Ejemplo:

Figura 1.1: Entidad Fuerte

En este ejemplo las entidades fuertes Alumno y Examen Teórico generan una tabla en el modelo relacional
con las siguientes columnas.

• ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)

• EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)

1.2 Relaciones con cardinalidad 1:1

Como norma general, las relaciones con cardinalidad 1:1 no generan una tabla, lo que haremos será que la clave
primaria de una entidad pasará a formar parte de la tabla de la otra entidad, y pasará como un atributo.

La participación de cada una de las entidades será lo que nos ayude a decidir cuál será la entidad que pasará
su clave primaria a la otra entidad.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Excepción: Sólo existe un caso donde una relación con cardinalidad 1:1 genera una nueva tabla, y será cuando
la participación de las dos entidades sea de tipo (0,1)..(0..1).

Veamos los casos que pueden existir:

1.2.1 Participación (1,1)..(0,1)

Figura 1.2: Relación uno a uno

Como la participación de Usuario es de (1,1) y la de Canal YouTube es de (0,1), la clave primaria de Usuario
se almacena en la tabla de Canal YouTube como un atributo. Se dice que el atributo id_usuario que se añade
en la tabla Canal_YouTube es una clave ajena o foreign key (FK) de la tabla Usuario.

Las tablas del modelo relacional quedarían así:

• USUARIO(id, email, password, nombre, apellido1, apellido2)

• CANAL_YOUTUBE(id, nombre, descripción, fecha_creación, id_usuario)
– id_usuario: FOREIGN KEY de USUARIO(id)

1.2.2 Participación (1,1)..(1,1)

Figura 1.3: Relación uno a uno

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso, como la participación de las dos entidades es de (1,1) podemos resolverlo de tres formas.

1. La clave primaria de Presidente se almacena en la tabla País como un atributo (id_presidente). Se dice
que id_presidente es una clave ajena o foreign key (FK) de la tabla Presidente.

• PRESIDENTE(id, nombre, apellido1, apellido2)

• PAÍS(id, nombre, id_presidente)
– id_presidente: FOREIGN KEY de PRESIDENTE(id)

2. La clave primaria de País se almacena en la tabla Presidente como un atributo (id_pais). Se dice que
id_pais es una clave ajena o foreign key (FK) de la tabla País.

• PAÍS(id, nombre)
• PRESIDENTE(id, nombre, apellido1, apellido2, id_país)
– id_país: FOREIGN KEY de PAÍS(id)

3. Las claves primarias de ambas entidades se guardan en la tabla de la otra entidad. Es decir, la tabla Pre‑
sidente guardaría la clave primaria de País y la tabla País guardaría también la clave primaria de Pre‑
sidente. Esta solución puede presentar redundancia, pero puede ser interesante en algunas ocasiones,
dependiendo de las consultas que se vayan a realizar sobre estas tablas a nivel de aplicación. En este caso
los atributos id_país y id_presidente serían claves_ajenas o foreign key (FK).

• PRESIDENTE(id, nombre, apellido1, apellido2, id_país)

– id_país: FOREIGN KEY de PAÍS(id)
• PAÍS(id, nombre, id_presidente)
– id_presidente: FOREIGN KEY de PRESIDENTE(id)

1.2.3 Participación (0,1)..(0,1)

Figura 1.4: Relación uno a uno

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Cuando la participación de las dos entidades es de (0,1), se puede crear una nueva tabla donde se almacenan
las claves primarias de las dos entidades que participan en la relación. La clave primaria de la nueva tabla será
una de las dos claves ajenas que se reciben.

En este ejemplo tendríamos:

• ALQUILER(id, fecha_inicio, fecha_fin, importe, fianza)

• ALQUILER_RENUEVA_ALQUILER(id_alquiler, id_alquiler_anterior)
– id_alquiler: FOREIGN KEY de ALQUILER(id)
– id_alquiler_anterior: FOREIGN KEY de ALQUILER(id)

1.3 Relaciones con cardinalidad 1:N

Las relaciones con cardinalidad 1:N no generan una tabla, lo que haremos será que la clave primaria de la enti‑
dad que participa con cardinalidad 1 pasará a formar parte de la tabla de entidad que participa con cardinalidad
N, y además pasará como un atributo.

Ejemplo:

Figura 1.5: Relación uno a muchos

En este caso la clave primaria de la entidad que participa en la relación con cardinalidad 1 se guarda en la tabla
de la entidad que participa con cardinalidad N.

• USUSARIO(id, email, password, nombre, apellido1, apellido2)

• VÍDEO(id, nombre, descripción, duración, id_usuario)
– id_usuario: FOREIGN KEY de USUARIO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.3.1 Relaciones reflexivas con cardinalidad 1:N

Figura 1.6: Relación uno a muchos reflexiva

En este caso la clave primaria se almacena en la misma tabla como atributo.

La tabla Empleado vuelve a guardar su clave primaria como atributo haciendo referencia al id del jefe, le lla‑
maremos id_jefe.

• EMPLEADO(id, nombre, apellido1, apellido2, id_jefe)

– id_jefe: FOREIGN KEY de EMPLEADO(id)

1.4 Relaciones con cardinalidad N:N

Las relaciones con cardinalidad N:N son las únicas que van a generar una nueva tabla.
Ejemplo:

Figura 1.7: Relación muchos a muchos

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso se crea una nueva tabla donde se almacenan las claves primarias de las dos entidades que parti‑
cipan en la relación. Las claves primarias de las entidades también serán claves primarias de la nueva tabla. Si
la relación contiene algún atributo, se deberán añadir a la nueva tabla.

• ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)

• EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)
• ALUMNO_HACE_EXAMEN_TEÓRICO(id_alumno, id_examen, nota)
– id_alumno: FOREIGN KEY de ALUMNO(id)
– id_examen: FOREIGN KEY de EXAMEN(id)

NOTA: Habrá casos donde los atributos de la relación también formarán parte de la clave primaria de la nueva
tabla. Estos casos aparecerán cuando en la relación existan atributos de tipo fecha y sea necesario almacenar
un histórico de las relaciones entre las dos entidades en función de las fechas. Estos casos también pueden
resolverse añadiendo un nuevo identificador de tipo entero con autoincremento en lugar de utilizar una clave
primaria compuesta por varias columnas.

Ejemplo:

Figura 1.8: Relación muchos a muchos

Las reglas de transformación de E/R al modelo relacional nos dicen que la relación Suministra genera una
nueva tabla porque es una relación de cardinalidad N:N. Esta nueva tabla recibe las claves primarias de las
dos entidades que participan en la relación y además participan como clave primaria. La solución teórica sería
la siguiente:

• PROVEEDOR(id, dirección, ciudad, provincia)

• PIEZA(id, nombre, color, precio)
• PROVEEDOR_SUMINISTRA_PIEZA(id_proveedor, id_pieza, fecha, cantidad)
– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Con esta solución podemos tener un problema en el caso de que un proveedor nos suministre piezas con el
mismo id en fechas diferentes. En este caso no podríamos almacenar esta información en la tabla porque se
produciría un error de claves primarias duplicadas.

#id_proveedor #id_pieza fecha cantidad

1 1 01/01/2018 100
1 1 20/01/2018 100

Para solucionarlo podemos incluir el atributo fecha como parte de la clave primaria de la tabla, de modo que
la clave primaria estaría compuesta por id_proveedor, id_pieza y fecha. La solución sería la siguiente:

• PROVEEDOR_SUMINISTRA_PIEZA(id_proveedor, id_pieza, fecha, cantidad)

– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

En este caso ya no habría ningún problema para almacenar que un proveedor nos suministra piezas con el
mismo id en fechas diferentes.

#id_proveedor #id_pieza #fecha cantidad

1 1 01/01/2018 100
1 1 20/01/2018 100

Si fuese necesario registrar que el mismo proveedor puede suministrar piezas con el mismo código en diferentes
horas del mismo día, habría que reemplazar la columna fecha por fecha_hora.

#id_proveedor #id_pieza #fecha_hora cantidad

1 1 01/01/2018 08:00:00 100

1 1 20/01/2018 10:00:00 100
1 1 20/01/2018 17:00:00 100

Otra forma de resolver este problema puede ser creando un nuevo atributo id que sea un valor numérico con
autoincremento y que éste sea la única clave primara de la tabla. La solución sería la siguiente:

• PROVEEDOR_SUMINISTRA_PIEZA(id, id_proveedor, id_pieza, fecha_hora, cantidad)

– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso tampoco habría ningún problema para almacenar que un proveedor nos suministra piezas con el
mismo id en fechas diferentes.

#id id_proveedor id_pieza fecha_hora cantidad

1 1 1 1/01/2018 08:00:00 100

2 1 1 20/01/2018 10:00:00 100
3 1 1 20/01/2018 17:00:00 100

1.4.1 Relaciones reflexivas con cardinalidad N:N

Figura 1.9: Relación muchos a muchos reflexiva

En este caso tendremos dos tablas en el modelo relacional:

• VÍDEO(id, título, descripción, reproducciones)

• VÍDEOS_RELACIONADOS(id_video, id_video_relacionado)
– id_video: FOREIGN KEY de VÍDEO(id)
– id_video_relacionado: FOREIGN KEY de VÍDEO(id)

1.5 Relaciones grado 3

Siempre que sea posible se recomienda convertir las relaciones de grado 3 en dos relaciones de grado 2.

Las relaciones de grado 3 pueden generar una nueva tabla dependiendo de la cardinalidad de la relación.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.5.1 Cardinalidad N:N:N

En este caso creamos una tabla. La clave primaria de la nueva tabla estará formada por las tres claves de las
entidades que participan en la relación.

Figura 1.10: Relación grado 3

1.5.2 Cardinalidad 1:N:N

En este caso creamos una tabla. La clave primaria de la nueva tabla estará formada por las dos claves de las
entidades que participan como N en la relación.

1.5.3 Cardinalidad 1:1:N

En este caso no es necesario crear una tabla. La entidad que participa como N recibe las claves de las dos
entidades que participan como 1.

1.6 Generalización y Especialización (Relaciones ISA)

Existen varias soluciones para realizar el el paso a tablas de una especialización. La solución que se elija en cada
caso dependerá del tipo de especialización que estemos resolviendo: total, parcial, inclusiva o exclusiva.

Las 3 soluciones posibles que podemos aplicar son las siguientes:

1. Crear una única tabla para la superclase. En este caso todos los atributos de las subclases se guardarían
en la superclase

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

2. Crear una tabla sólo para las subclases. En este caso los atributos de la superclase habría que guardarlos
en cada una de las subclases.

3. Crear una tabla para cada una de las entidades, tanto para la superclase como las subclases. En este caso
las subclases tendrían que guardar la clave de la primaria de la superclase.

Ejemplo de especialización exclusiva/total

En este caso sería adecuado utilizar la solución 2 o 3. También sería posible utilizar la solución 1, pero al tratarse
de una especialización exlusiva, tendríamos muchas columnas con valores NULL.

Solución 2: Crear una tabla sólo para las subclases.

• EPISODIO(id, título, sinopsis, imagen, archivo_vídeo, duración temporada, número)

• PELÍCULA(id, título, sinopsis, imagen, archivo_vídeo, duración puntuación_imdb, director)

Solución 3: Crear una tabla para cada una de las entidades.

• VÍDEO(id, título, sinopsis, imagen, archivo_vídeo, duración, tipo)

• EPISODIO(id, temporada, número)

– id: FK de VÍDEO(id)

• PELÍCULA(id, puntuación_imdb, director

– id: FK de VÍDEO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Ejemplo de especialización inclusiva/total

En este caso podríamos utilizar cualquiera de las tres soluciones, dependerá del contexto del ejercicio y de
cómo se relacionen estas entidades con el resto de entidades del diagrama.

Solución 1. Crear una única tabla para la superclase.

• LIBRO(id, título, isbn, año_publicación, descripción, tipo, lugar_impresión, fecha_impresión, pre‑

cio_papel, tamaño_archivo, precio_ebook)

Solución 2: Crear una tabla sólo para las subclases.

• LIBRO_PAPEL(id, título, isbn, año_publicación, descripción, lugar_impresión, fecha_impresión, precio)

• LIBRO_EBOOK(id, título, isbn, año_publicación, descripción, tamaño_archivo, precio)

Solución 3: Crear una tabla para cada una de las entidades.

• LIBRO(id, título, isbn, año_publicación, descripción, tipo)

• LIBRO_PAPEL(id, fecha_impresión, precio)

– id: FK de LIBRO(id)
• LIBRO_EBOOK(id, tamaño_archivo, precio)
– id: FK de LIBRO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Relación 1:1, 1:N, M:N

1:1

Muy probable que se puede unir en una sola tabla.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1:N

M:N

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Del modelo conceptual al modelo relacional

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Fases a seguir en el Diseño de Bases de Datos

Transformación del Modelo conceptual al modelo relacional

➢ Se aplica el sentido común.

➢ El cual da lugar a unas reglas fáciles de deducir e implementar.

1) Las entidades pasan a ser tablas(=Relaciones)

➢ Los atributos pasan a ser columnas

➢ El ID pasa a ser PK

1) Las interrelaciones (rombos) pasan a ser:

FKs (Las 1:1, 1:N): Que pasan a una de las tablas

O Crean una nueva table nueva (las N:M o ternarias)

Dependiendo de las cardinalidades

Los atributos de interrelación(“rombo”) se van con la FK, o la nueva tabla.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1:1

1:N

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

N:M

Doble relación

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.1 Entidades (Fuertes y Débiles)

Cada una de las entidades (fuertes y débiles) del diagrama E/R genera una tabla, donde cada uno de los atribu‑
tos de la entidad pasa a ser una columna de la tabla.
Ejemplo:

Figura 1.1: Entidad Fuerte

En este ejemplo las entidades fuertes Alumno y Examen Teórico generan una tabla en el modelo relacional
con las siguientes columnas.

• ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)

• EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)

1.2 Relaciones con cardinalidad 1:1

Como norma general, las relaciones con cardinalidad 1:1 no generan una tabla, lo que haremos será que la clave
primaria de una entidad pasará a formar parte de la tabla de la otra entidad, y pasará como un atributo.

La participación de cada una de las entidades será lo que nos ayude a decidir cuál será la entidad que pasará
su clave primaria a la otra entidad.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Excepción: Sólo existe un caso donde una relación con cardinalidad 1:1 genera una nueva tabla, y será cuando
la participación de las dos entidades sea de tipo (0,1)..(0..1).

Veamos los casos que pueden existir:

1.2.1 Participación (1,1)..(0,1)

Figura 1.2: Relación uno a uno

Como la participación de Usuario es de (1,1) y la de Canal YouTube es de (0,1), la clave primaria de Usuario
se almacena en la tabla de Canal YouTube como un atributo. Se dice que el atributo id_usuario que se añade
en la tabla Canal_YouTube es una clave ajena o foreign key (FK) de la tabla Usuario.

Las tablas del modelo relacional quedarían así:

• USUARIO(id, email, password, nombre, apellido1, apellido2)

• CANAL_YOUTUBE(id, nombre, descripción, fecha_creación, id_usuario)
– id_usuario: FOREIGN KEY de USUARIO(id)

1.2.2 Participación (1,1)..(1,1)

Figura 1.3: Relación uno a uno

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso, como la participación de las dos entidades es de (1,1) podemos resolverlo de tres formas.

1. La clave primaria de Presidente se almacena en la tabla País como un atributo (id_presidente). Se dice
que id_presidente es una clave ajena o foreign key (FK) de la tabla Presidente.

• PRESIDENTE(id, nombre, apellido1, apellido2)

• PAÍS(id, nombre, id_presidente)
– id_presidente: FOREIGN KEY de PRESIDENTE(id)

2. La clave primaria de País se almacena en la tabla Presidente como un atributo (id_pais). Se dice que
id_pais es una clave ajena o foreign key (FK) de la tabla País.

• PAÍS(id, nombre)
• PRESIDENTE(id, nombre, apellido1, apellido2, id_país)
– id_país: FOREIGN KEY de PAÍS(id)

3. Las claves primarias de ambas entidades se guardan en la tabla de la otra entidad. Es decir, la tabla Pre‑
sidente guardaría la clave primaria de País y la tabla País guardaría también la clave primaria de Pre‑
sidente. Esta solución puede presentar redundancia, pero puede ser interesante en algunas ocasiones,
dependiendo de las consultas que se vayan a realizar sobre estas tablas a nivel de aplicación. En este caso
los atributos id_país y id_presidente serían claves_ajenas o foreign key (FK).

• PRESIDENTE(id, nombre, apellido1, apellido2, id_país)

– id_país: FOREIGN KEY de PAÍS(id)
• PAÍS(id, nombre, id_presidente)
– id_presidente: FOREIGN KEY de PRESIDENTE(id)

1.2.3 Participación (0,1)..(0,1)

Figura 1.4: Relación uno a uno

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Cuando la participación de las dos entidades es de (0,1), se puede crear una nueva tabla donde se almacenan
las claves primarias de las dos entidades que participan en la relación. La clave primaria de la nueva tabla será
una de las dos claves ajenas que se reciben.

En este ejemplo tendríamos:

• ALQUILER(id, fecha_inicio, fecha_fin, importe, fianza)

• ALQUILER_RENUEVA_ALQUILER(id_alquiler, id_alquiler_anterior)
– id_alquiler: FOREIGN KEY de ALQUILER(id)
– id_alquiler_anterior: FOREIGN KEY de ALQUILER(id)

1.3 Relaciones con cardinalidad 1:N

Las relaciones con cardinalidad 1:N no generan una tabla, lo que haremos será que la clave primaria de la enti‑
dad que participa con cardinalidad 1 pasará a formar parte de la tabla de entidad que participa con cardinalidad
N, y además pasará como un atributo.

Ejemplo:

Figura 1.5: Relación uno a muchos

En este caso la clave primaria de la entidad que participa en la relación con cardinalidad 1 se guarda en la tabla
de la entidad que participa con cardinalidad N.

• USUSARIO(id, email, password, nombre, apellido1, apellido2)

• VÍDEO(id, nombre, descripción, duración, id_usuario)
– id_usuario: FOREIGN KEY de USUARIO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.3.1 Relaciones reflexivas con cardinalidad 1:N

Figura 1.6: Relación uno a muchos reflexiva

En este caso la clave primaria se almacena en la misma tabla como atributo.

La tabla Empleado vuelve a guardar su clave primaria como atributo haciendo referencia al id del jefe, le lla‑
maremos id_jefe.

• EMPLEADO(id, nombre, apellido1, apellido2, id_jefe)

– id_jefe: FOREIGN KEY de EMPLEADO(id)

1.4 Relaciones con cardinalidad N:N

Las relaciones con cardinalidad N:N son las únicas que van a generar una nueva tabla.
Ejemplo:

Figura 1.7: Relación muchos a muchos

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso se crea una nueva tabla donde se almacenan las claves primarias de las dos entidades que parti‑
cipan en la relación. Las claves primarias de las entidades también serán claves primarias de la nueva tabla. Si
la relación contiene algún atributo, se deberán añadir a la nueva tabla.

• ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)

• EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)
• ALUMNO_HACE_EXAMEN_TEÓRICO(id_alumno, id_examen, nota)
– id_alumno: FOREIGN KEY de ALUMNO(id)
– id_examen: FOREIGN KEY de EXAMEN(id)

NOTA: Habrá casos donde los atributos de la relación también formarán parte de la clave primaria de la nueva
tabla. Estos casos aparecerán cuando en la relación existan atributos de tipo fecha y sea necesario almacenar
un histórico de las relaciones entre las dos entidades en función de las fechas. Estos casos también pueden
resolverse añadiendo un nuevo identificador de tipo entero con autoincremento en lugar de utilizar una clave
primaria compuesta por varias columnas.

Ejemplo:

Figura 1.8: Relación muchos a muchos

Las reglas de transformación de E/R al modelo relacional nos dicen que la relación Suministra genera una
nueva tabla porque es una relación de cardinalidad N:N. Esta nueva tabla recibe las claves primarias de las
dos entidades que participan en la relación y además participan como clave primaria. La solución teórica sería
la siguiente:

• PROVEEDOR(id, dirección, ciudad, provincia)

• PIEZA(id, nombre, color, precio)
• PROVEEDOR_SUMINISTRA_PIEZA(id_proveedor, id_pieza, fecha, cantidad)
– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Con esta solución podemos tener un problema en el caso de que un proveedor nos suministre piezas con el
mismo id en fechas diferentes. En este caso no podríamos almacenar esta información en la tabla porque se
produciría un error de claves primarias duplicadas.

#id_proveedor #id_pieza fecha cantidad

1 1 01/01/2018 100
1 1 20/01/2018 100

Para solucionarlo podemos incluir el atributo fecha como parte de la clave primaria de la tabla, de modo que
la clave primaria estaría compuesta por id_proveedor, id_pieza y fecha. La solución sería la siguiente:

• PROVEEDOR_SUMINISTRA_PIEZA(id_proveedor, id_pieza, fecha, cantidad)

– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

En este caso ya no habría ningún problema para almacenar que un proveedor nos suministra piezas con el
mismo id en fechas diferentes.

#id_proveedor #id_pieza #fecha cantidad

1 1 01/01/2018 100
1 1 20/01/2018 100

Si fuese necesario registrar que el mismo proveedor puede suministrar piezas con el mismo código en diferentes
horas del mismo día, habría que reemplazar la columna fecha por fecha_hora.

#id_proveedor #id_pieza #fecha_hora cantidad

1 1 01/01/2018 08:00:00 100

1 1 20/01/2018 10:00:00 100
1 1 20/01/2018 17:00:00 100

Otra forma de resolver este problema puede ser creando un nuevo atributo id que sea un valor numérico con
autoincremento y que éste sea la única clave primara de la tabla. La solución sería la siguiente:

• PROVEEDOR_SUMINISTRA_PIEZA(id, id_proveedor, id_pieza, fecha_hora, cantidad)

– id_proveedor: FOREIGN KEY de PROVEEDOR(id)
– id_pieza: FOREIGN KEY de PIEZA(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

En este caso tampoco habría ningún problema para almacenar que un proveedor nos suministra piezas con el
mismo id en fechas diferentes.

#id id_proveedor id_pieza fecha_hora cantidad

1 1 1 1/01/2018 08:00:00 100

2 1 1 20/01/2018 10:00:00 100
3 1 1 20/01/2018 17:00:00 100

1.4.1 Relaciones reflexivas con cardinalidad N:N

Figura 1.9: Relación muchos a muchos reflexiva

En este caso tendremos dos tablas en el modelo relacional:

• VÍDEO(id, título, descripción, reproducciones)

• VÍDEOS_RELACIONADOS(id_video, id_video_relacionado)
– id_video: FOREIGN KEY de VÍDEO(id)
– id_video_relacionado: FOREIGN KEY de VÍDEO(id)

1.5 Relaciones grado 3

Siempre que sea posible se recomienda convertir las relaciones de grado 3 en dos relaciones de grado 2.

Las relaciones de grado 3 pueden generar una nueva tabla dependiendo de la cardinalidad de la relación.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

1.5.1 Cardinalidad N:N:N

En este caso creamos una tabla. La clave primaria de la nueva tabla estará formada por las tres claves de las
entidades que participan en la relación.

Figura 1.10: Relación grado 3

1.5.2 Cardinalidad 1:N:N

En este caso creamos una tabla. La clave primaria de la nueva tabla estará formada por las dos claves de las
entidades que participan como N en la relación.

1.5.3 Cardinalidad 1:1:N

En este caso no es necesario crear una tabla. La entidad que participa como N recibe las claves de las dos
entidades que participan como 1.

1.6 Generalización y Especialización (Relaciones ISA)

Existen varias soluciones para realizar el el paso a tablas de una especialización. La solución que se elija en cada
caso dependerá del tipo de especialización que estemos resolviendo: total, parcial, inclusiva o exclusiva.

Las 3 soluciones posibles que podemos aplicar son las siguientes:

1. Crear una única tabla para la superclase. En este caso todos los atributos de las subclases se guardarían
en la superclase

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

2. Crear una tabla sólo para las subclases. En este caso los atributos de la superclase habría que guardarlos
en cada una de las subclases.

3. Crear una tabla para cada una de las entidades, tanto para la superclase como las subclases. En este caso
las subclases tendrían que guardar la clave de la primaria de la superclase.

Ejemplo de especialización exclusiva/total

En este caso sería adecuado utilizar la solución 2 o 3. También sería posible utilizar la solución 1, pero al tratarse
de una especialización exlusiva, tendríamos muchas columnas con valores NULL.

Solución 2: Crear una tabla sólo para las subclases.

• EPISODIO(id, título, sinopsis, imagen, archivo_vídeo, duración temporada, número)

• PELÍCULA(id, título, sinopsis, imagen, archivo_vídeo, duración puntuación_imdb, director)

Solución 3: Crear una tabla para cada una de las entidades.

• VÍDEO(id, título, sinopsis, imagen, archivo_vídeo, duración, tipo)

• EPISODIO(id, temporada, número)

– id: FK de VÍDEO(id)

• PELÍCULA(id, puntuación_imdb, director

– id: FK de VÍDEO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 4

Ejemplo de especialización inclusiva/total

En este caso podríamos utilizar cualquiera de las tres soluciones, dependerá del contexto del ejercicio y de
cómo se relacionen estas entidades con el resto de entidades del diagrama.

Solución 1. Crear una única tabla para la superclase.

• LIBRO(id, título, isbn, año_publicación, descripción, tipo, lugar_impresión, fecha_impresión, pre‑

cio_papel, tamaño_archivo, precio_ebook)

Solución 2: Crear una tabla sólo para las subclases.

• LIBRO_PAPEL(id, título, isbn, año_publicación, descripción, lugar_impresión, fecha_impresión, precio)

• LIBRO_EBOOK(id, título, isbn, año_publicación, descripción, tamaño_archivo, precio)

Solución 3: Crear una tabla para cada una de las entidades.

• LIBRO(id, título, isbn, año_publicación, descripción, tipo)

• LIBRO_PAPEL(id, fecha_impresión, precio)

– id: FK de LIBRO(id)
• LIBRO_EBOOK(id, tamaño_archivo, precio)
– id: FK de LIBRO(id)

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 6

NORMALIZACIÓN DE DATOS

La normalización de bases de datos es un proceso que consiste en aplicar una serie de

reglas (reglas que se basan en la clave primaria y las dependencias funcionales) a las
relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional, con el
fin de pulir el modelo relacional. Este proceso se realiza dividiendo una tabla grande en
tablas más pequeñas y definiendo relaciones entre ellas. La normalización también es el
proceso por el cual se redistribuyen adecuadamente los atributos entre entidades.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
Las anomalías que se evitan al normalizar una base de datos son:
Anomalías de inserción.
Anomalía de borrado.
Anomalía de actualización.
La normalización garantiza que el esquema resultante se encuentra más próximo al
modelo de la organización.
En el modelo relacional es frecuente llamar table a una relación, aunque para que una
tabla sea considerada relación tiene que cumplir con algunas restricciones:
Cada tabla debe tener su nombre único.
No puede haber dos registros iguales (no se permiten duplicados)
Todos los datos en una columna deben ser del mismo tipo.
La teoría del modelo relacional y el proceso de normalización de las Base de Datos, fue
desarrollado por Edgar Frank Codd (1970 y 1972). Con el fin de corregir algunas
redundancias y anomalías, Codd (1972) propuso tres formas normales , 1FN, 2FN, y 3FN.

Existen 6 formas normales. las primeras tres formas normales son suficientes para
cubrir las necesidades de la mayoría de las bases de datos.

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 6

Primera forma normal (1 FN)

Una tabla está en Primera Forma Normal si:
Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio
son indivisibles, mínimos.
Una tabla no puede tener múltiples valores en cada columna (No hay filas duplicadas, no
posee grupos repetidos). Todos los valores en una columna deben ser del mismo tipo.

Segunda forma normal (2 FN)

Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna
clave dependen de forma completa de la clave principal. Es decir que no existen
dependencias parciales. Todos los atributos que no son clave principal deben depender
únicamente de la clave principal (dependencia funcional).

Dependencia funcional
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se
conoce el valor de DNI tiene una conexión con Apellido o Nombre .
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la
siguiente manera:
FechaDeNacimiento Edad

Docente: Mg. Ing. Javier Portillo Quispe

Modelamiento de Datos (IS-381) Semana 6

De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener

éstas dependencias funcionales para lograr la eficiencia en las tablas.

B es funcionalmente dependiente de A.
Tercera forma normal (3 FN)
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional
transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema
de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es
un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Docente: Mg. Ing. Javier Portillo Quispe

 NORMALIZACIÓN
Matrícula Nombre Dirección Teléfono Materia Num Materia Cód_Carrera Carrera
1 Sergio Perez Lopez Puebla 22 565656 Base de Datos 123 27 Ing. Sistemas
1 Sergio Perez Lopez Puebla 22 565656 Programación Web 234 27 Ing. Sistemas
1 Sergio Perez Lopez Puebla 22 565656 Programación Visual 235 27 Ing. Sistemas
2 Ana Vargas Portal Reforma 1 232323 Base de Datos 123 27 Ing. Sistemas

Se observa repetición de datos y atributo no atómico.

PRIMERA FORMA NORMAL

Remover grupos repetitivos, y que los campos estén a nivel atómico

Matrícula Nombre Ap. Paterno Ap. Materno Dirección Teléfono Cód_Carrera Carrera
1 Sergio Perez Lopez Puebla 22 565656 27 Ing. Sistemas
2 Ana Vargas Portal Reforma 1 232323 27 Ing. Sistemas

Matrícula Materia Num.Materia

1 Base de Datos 123
1 Programación Web 234
1 Programación visual 235
2 Base de Datos 123

SEGUNDA FORMA NORMAL

Remover dependencias parciales
Solo dependencia funcional
Materia no tiene una dependencia funcional con matrícula
Tabla (entidad) Fuerte
Matrícula Nombre Ap. Paterno Ap. Materno Dirección Teléfono Cód_Carrera Carrera
1 Sergio Perez Lopez Puebla 22 565656 27 Ing. Sistemas
2 Ana Vargas Portal Reforma 1 232323 27 Ing. Sistemas

Tabla (entidad) Débil

Tabla (entidad) Fuerte

Num.Materia Materia
123 Base de Datos
234 Programación Web
235 Programación visual
123 Base de Datos

TERCERA FORMA NORMAL

Remover dependencias transitivas
Matrícula Nombre Ap. Paterno Ap. Materno Dirección Teléfono Cód_Carrera
1 Sergio Perez Lopez Puebla 22 565656 27
2 Ana Vargas Portal Reforma 1 232323 27

Cód_Carrera Carrera
27 Ing. Sistemas
28 Mecatrónica

Matrícula Num.Materia
1 123
1 234
1 235
2 123

Num.Materia Materia
123 Base de Datos
234 Programación Web
235 Programación visual
123 Base de Datos
Guía de Ejercicios de Normalización de Base de Datos (IS381)

Guía de Ejercicios
Aplicar las reglas de normalización los siguientes ejercicios.

1. Un dato sin normalizar no cumple con ninguna regla de normalización. Para explicar con un ejemplo en qué
consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla.

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado Num_art nom_art cant Precio
2301 23/02/11 101 Martin Caracas 3786 Red 3 35,00
2301 23/02/11 101 Martin Caracas 4011 Raqueta 6 65,00
2301 23/02/11 101 Martin Caracas 9132 Paq-3 8 4,75
2302 25/02/11 107 Herman Coro 5794 Paq-6 4 5,00
2303 27/02/11 110 Pedro Maracay 4011 Raqueta 2 65,00
2303 27/02/11 110 Pedro Maracay 3141 Funda 2 10,00

PRIMERA FORMAL NORMAL (1FN)

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para
NUM_ART, NOM_ART, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto
tenemos que convertir a la primera forma normal. Los pasos a seguir son:
• Tenemos que eliminar los grupos repetidos.
• Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y
ARTICULOS_ORDENES

ordenes (Id_orden, Fecha, Id_cliente, Nom_cliente, Estado)

Articulos_ordenes (id_orden, num_art, nom_art, cant, precio)

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado
2301 23/02/11 101 Martin Caracas
2302 25/02/11 107 Herman Coro
2303 27/02/11 110 Pedro Maracay

Articulos_ordenes
Id_orden Num_art nom_art cant Precio
2301 3786 Red 3 35,00
2301 4011 Raqueta 6 65,00
2301 9132 Paq-3 8 4,75
2302 5794 Paq-6 4 5,00
2303 4011 Raqueta 2 65,00
2303 3141 Funda 2 10,00

1/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

SEGUNDA FORMAL NORMAL (2FN)

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier
columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son:
• Determinar cuáles columnas que no son llave no dependen de la llave primaria de la tabla.
• Sacar esas columnas de la tabla base para llevar a otra tabla (segunda tabla).
• Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen.

La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor
para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria
ID_ORDEN.

Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas

PRECIO y NOM_ART son dependientes de NUM_ART, pero no son dependientes de
ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla
ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria
de la que dependen.

Las tablas quedan ahora de la siguiente manera.

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado
2301 23/02/11 101 Martin Caracas
2302 25/02/11 107 Herman Coro
2303 27/02/11 110 Pedro Maracay

Articulos_ordenes (id_orden, num_art, cant)

Articulos_ordenes
Id_orden Num_art cant
2301 3786 3
2301 4011 6
2301 9132 8
2302 5794 4
2303 4011 2
2303 3141 2

Articulos ( num_art, nom_art, precio)

Articulos
Num_art nom_art Precio
3786 Red 35,00
4011 Raqueta 65,00
9132 Paq-3 4,75
5794 Paq-6 5,00
3141 Funda 10,00

2/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

TERCERA FORMAL NORMAL (3FN)

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea
dependiente de otra columna no llave (dependencia transitiva). Los pasos a seguir son:
• Determinar las columnas que son dependientes de otra columna no llave.
• Eliminar esas columnas de la tabla base.
• Crear una segunda tabla con esas columnas y con la columna no llave de la cual son
dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como
la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo
está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es
la llave primaria.

Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual
dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se
muestran a continuación.

ordenes (id_orden, fecha, id_cliente)

Ordenes
Id_orden Fecha Id_cliente
2301 23/02/11 101
2302 25/02/11 107
2303 27/02/11 110

Clientes (id_cliente, nom_cliente, estado)

Clientes
Id_cliente Nom_cliente Estado
101 Martin Caracas
107 Herman Coro
110 Pedro Maracay

Por lo tanto la base de datos queda de la siguiente manera:

ordenes (id_orden, fecha, id_cliente)

Clientes (id_cliente, nom_cliente, estado)
Articulos ( num_art, nom_art, precio)
Articulos_ordenes (id_orden, num_art, cant)

2. FACTURA DE COMPRA VENTA: La empresa COLOMBIAN SYSTEMS lo ha contratado como el

“Ingeniero Encargado” para sistematizar la facturación. En la siguiente FACTURA DE COMPRA VENTA,
usted debe analizar toda la información disponible y aplique el proceso de normalización, hasta llegar a la
Tercera Forma Normal.

3/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

Se pide realizar la respectiva justificación detallada de cada uno de los pasos que conduzcan al resultado
final.

Factura(NUM_FAC, FECHA_FAC, NOM_CLIENTE, DIR_CLIENTE, RIF_CLIENTE,

CIUDAD_CLIENTE, TELEF_CLIENTE, CATEGORIA, COD_PROD, DESP_PROD, VAL_UNIT,
CANT_PROD)

Donde:

NUM_FAC: Número de la factura de compra venta

FECHA_FAC: Fecha de la factura de compra venta
NOM_CLIENTE: Nombre del cliente
DIR_CLIENTE: Dirección del cliente
RIF_CLIENTE: Rif del cliente
CIUDAD_CLIENTE: Ciudad del cliente
TELEF_CLIENTE: Teléfono del cliente
CATEGORIA: Categoría del producto
COD_PROD: Código del producto
DESCRIPCION: Descripción del producto
VAL_UNIT: Valor unitario del producto
CANT_PROD: Cantidad de productos q compra el cliente
La llave primaria es Número de Factura de venta: NUM_FAC

3. EMPRESA DE ENVIO DE MERCANCIA: a continuación se agrupan todos los atributos que hacen parte
de la base de datos para aplicarle las reglas de normalización. Donde se incluyen los nombres de los
atributos con su significado
* GUIA_NO = Numero de Guia
* GUIA_FECHA= Fecha de la Guia
* GUIA_HORA= Hora de la Guia
* ORGN_RIF = Identificacion de Empresa Origen
* ORGN_NOM = Nombre de Empresa Origen
* ORGN_ACT = Actividad Comercial de Empresa Origen
* ORGN_CIUDAD= Ciudad de Empresa Origen
* ORGN_DIR = Direccion de Empresa Origen
* ORGN_TEL = Telefono de Empresa Origen
* ORGN_CEL = Celular de Empresa Origen
* DEST_ID = Identificacion del destinatario
* DEST_NOM = Nombre del destinatario
* DEST_COD_CIUDAD = Codigo de la ciudad del destinatario
* DEST_CIUDAD= Ciudad del destinatario
* DEST_DIR = Direccion del destinatario
* DEST_TEL = Telefono del destinatario
* DEST_KM = Distancia kilometraje de Ciudad origen a ciudad del destinatario
* CODIGO = Codigo del paquete
* TIPO = Tipo de paquete
* NOMBRE = Nombre del paquete
* DESCRIPCION = Descripción del paquete

4/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

* VALR_ FLETE = Valor del flete

4. Video club: En una tienda de video se necesita mantener información de alrededor de 3000 casetas cada uno
de los casetes tiene asignado un número por cada `película se necesita conocer un titulo y categoría por
ejemplo: comedia, suspenso, drama, acción, ciencia ficción, etc. Se mantienen algunas copias de muchas
películas. Se le da a cada película una identificación y se mantiene seguimiento de lo que contiene cada
casete.
Un casete puede venir en varios formatos y una película es grabada en un solo casete; frecuentemente las
películas son pedidas de acuerdo a un actor especifico Tom Cruise y Demi More son los más populares es
por esto que se debe mantener información de los actores que pertenecen a cada película.
No en todas las películas actúan artistas famosos, a los clientes de la tienda le gusta conocer datos como el
nombre real del actor, y su fecha de nacimiento.
En la tienda se mantienen información solo de los actores que aparecen en las películas y que se tiene a
disposición. Solo se alquila videos a aquellos que pertenecen al club de videos. Para pertenecer al club se
debe tener un buen crédito. Por cada miembro del club se mantiene una ficha con su nombre, teléfono y
dirección, cada miembro del club tiene asignado un número de membresía. Se desea mantener información
de todos los casetes que un cliente alquila, cuando un cliente alquila un casete se debería conocer el nombre
de la película, la fecha en la que se alquila y la fecha de devolución.

Se pide aplicar las reglas de normalización hasta la tercera forma normal, teniendo las siguientes entidades
con sus respectivos atributos:

Alquiler (cod_alquiler, num_membresia, cod_cliente, nom_cliente, dir_cliente, telef_cliente, cod_cassette,

fecha_alquiler, fecha_dev, valor_alquiler, cantidad)

Cassettte (cod_cassette, num_copias, formato, cod_pelicula, titulo, categoría, cod_actor, nom_actor,

fechanac_actor, cod_tipo)

Donde:

cod_alquiler = Codigo del alquiler

num_membresia = Numero de membresia
cod_cliente = código del cliente
nom_cliente = nombre del cliente
dir_cliente = dirección del cliente
telef_cliente = teléfono del cliente
cod_cassette = código del cassette
fecha_alquiler = fecha del alquiler del al película
fecha_dev = fecha de devolución de la pelicula
valor_alquiler = valor del alquiler de la película
cantidad = cantidad de película alquilada
num_copias = números de copias de cassette
formato = formato del cassette
titulo = nombre de la película
categoría = categoría de la película
cod_actor = código del actor
nom_actor = nombre del actor
fechanac_actor = fecha de nacimiento del actor
cod_tipo = código del tipo de película.

5/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

5. Dada la siguiente relación PRESTAMO_LIBROS (Colegio, profesor, asignatura/ habilidad, aula, curso,
libro, editorial, fecha_prestamo) que contiene información relativa a los préstamos que realizan las
editoriales a los profesores de primaria de los colegios para su evaluación en alguna de las
asignaturas/habilidades que imparten. Se pide aplicar las reglas de normalización y obtener su modelo
relacional, indicar sus claves, atributos principales.

Asignatura/
Colegio Profesor Aula Curso Libro Editorial Fecha_prestamo
habilidad
Aprender y
Pensamiento enseñar en
C.P Cervantes Juan Pérez 1.A01 1er Grado Graó 09/09/2010
Lógico educación
infantil
Preescolar Técnicas
C.P Cervantes Juan Pérez Escritura 1.A01 1er Grado 05/05/2010
Rubio,N56 Rubio
Aprender y
Pensamiento Enseñar en
C.P Cervantes Juan Pérez 1.A01 1er Grado Graó 05/05/2010
Numérico educación
infantil
Pensamiento
Alicia Espacial, Educación Prentice
C.P Cervantes 1.B01 1er Grado 06/05/2010
García Temporal y Infantil N9 Hall
causal
Aprender y
Alicia Pensamiento enseñar en
C.P Cervantes 1.B01 1er Grado Graó 06/05/2010
García Numérico educación
infantil
Aprender y
Andrés enseñar en
C.P Cervantes Escritura 1.A01 2do Grado Graó 09/09/2010
Fernández educación
infantil
Saber
educar: guía
Andrés Temas de
C.P Cervantes Ingles 1.A01 2do Grado para Padres 05/05/2010
Fernández Hoy
y
Profesores
Saber
educar: guía
Juan Pensamiento Temas de
C.P Quevedo 2.B01 1er Grado para Padres 18/12/2010
Méndez Lógico Hoy
y
Profesores
Aprender y
Juan Pensamiento enseñar en
C.P Quevedo 2.B01 1er Grado Graó 06/05/2010
Méndez Numérico educación
infantil

6. Se tiene una relación del REPORTE_MATRICULA (código_alumno, nombre_alumno, especialidad,

código_curso, nombre_curso, nombre_docente, oficina, sección) se pide aplicar las reglas de normalización
llegando hasta las 3FN.

Código/ Nombre/ Código/ Nombre/

Especialidad Nombre_curso Oficina curso
alumno alumno curso docente

6/7
Guía de Ejercicios de Normalización de Base de Datos (IS381)

Luis Carlos
382145A Industrial MA123 Matemática 2 CB-214 U
Zuloaga Arambulo
Luis
382145A Industrial QU514 Física Química Petra Rondinel CB-110 U
Zuloaga
Luis Víctor
382145A Industrial AU521 Descriptiva CB-120 W
Zuloaga Moncada
Cesar
360247k Raúl Rojas Sistemas PA714 Investigación 1 SC-220 V
Fernadez
Carlos
360247k Raúl Rojas Sistemas MA123 Matemática 2 CB-214 V
Arambulo
Víctor
360247k Raúl Rojas Sistemas AU511 Dibujo CB-120 U
Moncada

7. Se presenta una base de datos de una biblioteca, aplicar las reglas de normalización simplificando hasta la
tercera forma normal.

Prestamos_libro (codLibro, Titulo, Autor, Editorial, NombreLector, Fechadev)

codLibro Titulo Autor Editorial nombreLector Fechadev

1001 Variable compleja Murray Spiegel McGraw Hill Pérez Gómez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán, Ana 17/04/2005
1005 Estadística Murray Spiegel McGraw Hill Roca, René 16/04/2005
1006 Oracle University Nancy Greenberg y Priya Nathan Oracle Corp. García Roque, Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Pérez Gómez, Juan 18/04/2005

7/7
 NORMALIZACIÓN PRÉSTAMO LIBRO EN UNA BIBLIOTECA
A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con
un ejemplo simplificado de una base de datos para una pequeña biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev

Variable Murray Pérez Gómez,

1001 McGraw Hill 15/04/2005
compleja Spiegel Juan
Visual E.
1004 Anaya Ríos Terán, Ana 17/04/2005
Basic Petroustsos
Murray Roca Vargas,
1005 Estadística McGraw Hill 16/04/2005
Spiegel René
Nancy
Oracle Greenberg García Roque,
1006 Oracle Corp. 20/04/2005
University y Priya Luis
Nathan
Clipper Pérez Gómez,
1007 Ramalho McGraw Hill 18/04/2005
5.01 Juan

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) ya que no tiene campos
atómicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en
apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla.

1NF
CodLibro CodAutor Titulo Autor Editorial Paterno Materno Nombres FechaDev
Variable Murray
1001 801 McGraw Pérez Gómez Juan 15/04/2005
compleja Spiegel
Visual E.
1004 802 Petroustsos
Anaya Ríos Terán Ana 17/04/2005
Basic
Murray McGraw
1005 801 Estadística Spiegel Hill
Roca Vargas René 16/04/2005
Nancy Oracle
1006 803 Oracle DB García Roque Luis 20/04/2005
Greenberg Corp.
Priya Oracle
1006 804 Oracle DB Nathan Corp.
García Roque Luis 20/04/2005
Clipper
1007 806 Ramalho McGraw Pérez Gómez Juan 18/04/2005
5.01

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra
manera, todos los atributos no clave deben depender por completo(dependencia funcional) de la
clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si
consideramos como atributo clave el código del libro.

Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre
del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser
trasladados a otra tabla.
 2NF
LIBRO

CodLibro Titulo Autor Editorial PRÉSTAMO

Variable Murray
1001 McGraw
compleja Spiegel CodLibro CodLector FechaDev
E.
1004 Visual Basic Anaya 1001 501 15/04/2005
Petroustsos
1004 502 17/04/2005
Murray
1005 Estadística McGraw Hill
Spiegel 1005 503 16/04/2005
Oracle Nancy Oracle
1006 1006 504 20/04/2005
University Greenberg Corp.
1007 501 18/04/2005
1006 Oracle DB Priya Nathan Oracle Corp.

1007 Clipper 5.01 Ramalho McGraw Hill

La nueva tabla sólo contendrá datos del lector.

LECTOR

CodLibro CodLector Paterno Materno Nombres

1001 501 Pérez Gómez Juan
1004 502 Ríos Terán Ana

503 Roca Vargas René

1005
1006 504 García Roque Luis
1007 501 Pérez Gómez Juan
Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la
columna CodLector para identificar unívocamente a cada uno.

2NF Mejorado
Cabe mencionar que cada columna no clave tiene una dependencia funcional de la llave
primaria. Como se puede observer las tablas yo no tienen anomalias y ya no tienen
dependencia transitiva por lo que ya no es necesario realizar la 3FN.
LECTOR PRÉSTAMO

CodLibro CodLector Paterno Materno Nombres CodLibro CodLector FechaDev

1001 501 Pérez Gómez Juan 1001 501 15/04/2005
1004 502 Ríos Terán Ana 1004 502 17/04/2005
1005 503 Roca Vargas René 1005 503 16/04/2005
1006 504 García Roque Luis 1006 504 20/04/2005
1007 501 Pérez Gómez Juan 1007 501 18/04/2005

LIBRO AUTOR EDITORIAL

CodLibro Titulo CodAutor Autor CodEditorial Editorial

Variable Murray
1001 801 901 McGraw Hill
compleja Spiegel
Visual Basic E.
1004 802 902 Anaya
5 Petroustsos
Nancy
1005 Estadística 803 903 Oracle Corp.
Greenberg
Oracle
1006 804 Priya Nathan
University
1007 Clipper 5.01 806 Ramalho
 Álgebra Relacional
El álgebra relacional es un lenguaje de consulta procedimental.
Posee un conjunto de operadores que toman como parámetros
una o dos relaciones y devuelven otra, estos operadores los
podemos clasificar en:
Operadores Básicos Operadores Derivados

• Selección • Intersección
• Proyección • Join
• Unión • División
• Diferencia • Join
• Producto Cartesiano • Asignación
• Renombramiento
Se forman combinando los
operadores básicos
Modelamiento de datos (IS-381)
 Notación
• Las letras mayúsculas R,S,T, … denotan
esquemas de relaciones (estructura)

• Las letras minúsculas r,s,t,… denotan instancias

(datos concretos) de las relaciones cuyos
esquemas son R,S,T,… respectivamente.
 Selección
σpredicado (r)
Es un operador unario.
• Define una relación con los mismos atributos que R y que
contiene solo aquellas filas de r que satisfacen la condición
especificada (predicado).

Ejemplo: Consideremos la siguiente tabla

ingeniero
#Emp Nombre Edad
12 Juan 26
21 Manuel 40
233 Maria 50
a) Dar los ingenieros de mas de 35 años

σ Edad>=35 (ingeniero)
#Emp Nombre Edad
21 Manuel 40
233 Maria 50

b) Dar los datos del ingeniero cuyo número de empleado es 21

σ #Emp=21 (ingeniero)
#Emp Nombre Edad
21 Manuel 40

c) Devolver los ingenieros menores de 21 Años

σ Edad<21 (ingeniero)
#Emp Nombre Edad
 Proyección
∏Atr1, . . . , Atrn (r)
• Es un operador unario.
•Define una relación que contiene un subconjunto de la
columnas de R con los valores de los atributos especificados,
eliminando filas duplicadas en el resultado.

Ejemplo: Dada la siguiente relación

ingeniero
#Emp Nombre Edad
12 Juan 26
21 Manuel 40
233 Maria 50
455 Juan 42
 a) Dar nombre y edad de los ingenieros
∏ Nombre,Edad (ingeniero)

Nombre Edad
Juan 26
Manuel 40
Maria 50
Juan 42

b) Dar el nombre de los ingenieros

∏ Nombre (ingeniero)
Nombre
Juan
Manuel
Maria
Propiedad de Unión Compatible
Dos relaciones R y S tienen la propiedad de unión
compatible si:
•R y S tienen el mismo número de atributos (aridad).
•Los dominios de los i-esimos atributos de R y S son
iguales para todo i.
 Unión
r∪s
• La unión de dos relaciones r y s, es otra relación que
contiene todas las tuplas que están en r, o en s, o en
ambas, eliminándose las tuplas duplicadas.
• R y S deben ser unión-compatible, es decir, definidas
sobre el mismo conjunto de atributos.
Ejemplo: Dada las siguiente relaciones:
ingeniero jefe
#Emp Nombre Edad #Emp Nombre Edad
12 Juan 26 12 Juan 26
21 Manuel 40 245 Marcos 45
233 Maria 50
a) Devolver todo el personal, es decir, ingenieros y jefes.
ingeniero ∪ jefe

#Emp Nombre Edad

12 Juan 26
21 Manuel 40
233 Maria 50
245 Marcos 45
 Diferencia
r-s
• La diferencia de dos relaciones r y s, es otra relación
que contiene las tuplas que están en la relación r,
pero no están en s.
• R y S deben ser unión-compatible.

Ej.: Dada las siguiente relaciones:

ingeniero jefe
#Emp Nombre Edad #Emp Nombre Edad
12 Juan 26 12 Juan 26
21 Manuel 40 245 Marcos 45
233 Maria 50
 a) Devolver los Ingenieros que no son jefes.
ingeniero - jefe

#Emp Nombre Edad

21 Manuel 40
233 Maria 50

b) Devolver los Jefes que no son Ingenieros.

jefe - ingeniero

#Emp Nombre Edad

245 Marcos 45
 Producto Cartesiano
rxs
• Define una relación que es la concatenación de cada
una de las tuplas (filas) de la relación r con cada una
de las tuplas (filas) de la relación s.
Ejemplo: Dada las siguientes relaciones:
departamento
ingeniero #Dep Nombre
1001 Electricidad
#Emp Nombre #Dep 1002 Mecanica
201 Juan 1001
202 Manuel 1002 proyecto
203 Carlos 1001 #Pro Descripcion
501 Motor Hibrido
502 Transformador
a) Devolver los ingenieros junto a todos los departamentos de la empresa:

ingeniero X departamento
#Emp Ing.Nombre Ing.#Dep Depa.#Dep Depa.Nombre
201 Juan 1001 1001 Electricidad
201 Juan 1001 1002 Mecánica
202 Manuel 1002 1001 Electricidad
202 Manuel 1002 1002 Mecánica
203 Carlos 1001 1001 Electricidad
203 Carlos 1001 1002 Mecánica

b) Devolver los departamentos junto a todos proyectos de la empresa.

departamento X proyecto
#Dep Nombre #Pro Descripcion
1001 Electricidad 501 Motor Hibrido
1001 Electricidad 502 Transformador
1002 Mecanica 501 Motor Hibrido
1002 Mecanica 502 Transformador