6 Version Electronica de Una Revista

Fundamentos de bases
de datos
Zea Ordoñez Mariuxi, Honores Tapia Joofre, Rivas Asanza Wilmer
Universidad Técnica de Machala

Fundamentos de base de datos
Ing. César Quezada Abad, MBA
Rector
Ing. Amarilis Borja Herrera, Mg. Sc.

Vicerrectora Académica
Soc. Ramiro Ordóñez Morejón, Mg. Sc.

Vicerrector Administrativo
COORDINACIÓN EDITORIAL
VICERRECTORADO ACADÉMICO
Tomás Fontaines-Ruiz, PhD.

Investigador Becario Prometeo-Utmach
Asesor Del Programa De Reingeniería
Ing. Karina Lozano Zambrano

Coordinadora Editorial
Ing. Jorge Maza Córdova, Ms.

Ing. Cyndi Aguilar
Equipo de Publicaciones
Mariuxi Zea Ordoñez

Joofre Honores Tapia
Wilmer Rivas Asanza
UNIVERSIDAD TÉCNICA DE MACHALA

2015
Primera edición 2015
ISBN: 978-9942-24-074-3
D.R. © 2015, universidad técnica de machala

Ediciones utmach
Km. 5 1/2 Vía Machala Pasaje
www.utmachala.edu.ec
Este texto ha sido sometido a un proceso de evaluación por pares externos

con base en la normativa editorial de la utmach.
Portada:
Concepto editorial
Samanta Cabezas (est. Comunicación Social)
Fotografía: Dir. de Comunicación UTMACH
Diseño, montaje y producción editorial: UTMACH
Impreso y hecho en Ecuador

Printed and made in Ecuador
Advertencia: “Se prohíbe la reproducción, el re-

gistro o la transmisión parcial o total de esta
obra por cualquier sistema de recuperación de
información, sea mecánico, fotoquímico, elec-
trónico, magnético, electroóptico, por fotocopia
o cualquier otro, existente o por existir, sin el
permiso previo por escrito del titular de los de-
rechos correspondientes”.
Índice
PREFACIO........................................................................... 17
PRÓLOGO............................................................................ 19
DEDICATORIA..................................................................... 21
INTRODUCCIÓN.................................................................. 23
1. BASE DE DATOS RELACIONALES................................... 25
1.1. Generalidades de bases de datos................................... 26
1.2. Ejemplificación.............................................................. 27
1.3. Concepto de modelos de datos. Funciones y
sublenguajes........................................................................ 29
1.3.1. Diseño de los sistemas de bases de datos................... 31
1.3.2. Funciones de un SGBD.............................................. 31
1.4. Clasificación de los varios tipos de diseño de datos de
acuerdo al nivel de abstracción............................................ 33
1.4.1. Modelos de datos conceptuales................................... 33
1.4.2. Modelos de datos lógicos............................................ 35
1.4.3. Modelos de datos físicos............................................. 37
1.5. Enumeración de las reglas de Codd para un sistema
relacional..............................................................................38
2. DESCRIPCIÓN Y APLICACIÓN DEL MODELO
ENTIDAD-RELACIÓN PARA EL MODELADO DE DATOS....... 43
2.1. Proceso de realización de modelo entidad - relación....... 44
2.2. Elementos..................................................................... 44
2.2.1. Entidad...................................................................... 44
2.2.2. Relación..................................................................... 45
8 Segura M, Lam A, García C
2.2.3. Atributo y dominio..................................................... 47

2.3. Diagramas entidad-relación extendidos como
elementos para resolver las carencias de los diagramas
entidad-relación simples...................................................... 49
2.3.1. Cardinalidad de las relaciones.................................... 49
2.3.2. Entidades fuertes y frágiles........................................ 50
2.3.3. Atributos en relaciones............................................... 52
2.3.4. Herencia................................................................... 52
2.3.5. Agregación................................................................ 54
2.4. Diseño lógico a partir de diagramas entidad - relación... 54
2.4.1. Reglas concernientes al modelo entidad - relación
básico.................................................................................. 55
2.4.2. Reglas concernientes al modelo entidad – relación
extendido............................................................................. 60
2.5. Desarrollo de diversos supuestos prácticos de
modelización mediante diagramas Entidad-Relación............. 63
3. ANÁLISIS DEL MODELO RELACIONAL Y DE LOS
ELEMENTOS QUE LO INTEGRAN........................................ 67
3.1. Concepto de relaciones y sus propiedades..................... 68
3.2. Concepto de claves en el modelo relacional.................... 70
3.3. Las restricciones en el modelo relacional....................... 73
3.3.1. Restricciones inherentes............................................. 73
3.3.2. Restricciones semánticas o de usuario....................... 73
3.4. Nociones de álgebra relacional....................................... 76
3.4.1. Operadores tradicionales de la teoría de conjuntos..... 76
3.4.2 Operadores relacionales específicos............................. 79
3.5. Nociones de Cálculo relacional de filas para resolver
ejercicios prácticos esenciales.............................................. 83
3.6. Nociones de Cálculo relacional de Dominios.................. 87
2.7. Teoría de la normalización y sus objetos........................ 88
3.7.1. Concepto de dependencias funcionales....................... 92
3.7.2. Análisis y aplicación de las diferentes formas normales:
forma normal y la forma normal de Boyce/Codd.................. 98
3.7.3 Ventajas e inconvenientes que justifican una
desnormalización de las tablas. Valoración en diferentes
supuestos prácticos........................................................... 107
Índice 9
3.7.4. Desarrollo de diferentes supuestos prácticos de

normalización de datos incluyendo propuestas de
desnormalización de datos................................................. 114
4. MODELO ORIENTADO A OBJETOS............................... 117
4.1. Contextualización del modelo orientado a objeto
dentro del modelado UML.................................................. 117
4.2. Modelo de datos orientado a objetos............................ 120
4.2.1. Conceptos de objeto, clase, método y mensaje.......... 120
4.2.2. Representación de clases en UML............................. 121
4.2.3. Relaciones entre clases en UML................................ 123
4.3. Comparación del modelo de clases con el modelo
Entidad-Relación............................................................... 130
EJERCICIOS PROPUESTOS Y RESUELTOS....................... 135
Índice de figuras
Figura. 1: Relación empleados con sus campos y registros..28

Figura. 2: Esquema entidad relación de una biblioteca........ 34
Figura. 3: Diagrama de clases para una biblioteca............... 35
Figura. 4: Esquema de una base de datos jerárquica........... 36
Figura. 5: Esquema de una base de datos en red................. 37
Figura. 6: Diseño de una base de datos relacional con
datos.................................................................................... 37
Figura. 7: Representación gráfica de una entidad................ 44
Figura. 8: Representación gráfica de una relación............... 45
Figura. 9: Relación reflexiva................................................ 45
Figura. 10: Relación ternaria............................................... 45
Figura. 11: Relación 1:1 binaria.......................................... 46
Figura. 12: Relación 1:1 reflexiva........................................ 46
Figura. 13: Relación 1:N binaria.......................................... 47
Figura. 14: Relación 1:N reflexiva........................................ 47
Figura. 15: Relación N:M binaria......................................... 47
Figura. 16: Relación N:M reflexiva....................................... 48
Figura. 17: Representación de atributos.............................. 48
Figura. 18: Representación de atributos alternativa............ 48
Figura. 19: Representación de cardinalidades en una
relación binaria N:M............................................................. 44
relación reflexiva N:M........................................................... 49
relación ternaria.................................................................. 50
Figura. 22: Representación gráfica de una entidad frágil..... 50
Figura. 23: Dependencia en identificación........................... 51
Figura. 24: Dependencia en existencia................................ 51
Figura. 25: Relación N:M con atributo................................. 52
Figura. 26: Relación 1:1 con atributo.................................. 52
Figura. 27: Representación de Herencia.............................. 53
Figura. 28: Jerarquía de tipos subtipos total y exclusiva..... 53
Figura. 29: Representación de agregación............................ 54
Figura. 30: Esquema ejemplo de ER.................................... 55
Figura. 31: Esquema ER con relación reflexiva N:M............. 56
Figura. 32: Esquema ER con relación 1:N........................... 58
Figura. 33: Esquema ER con relación 1:N........................... 58
Figura. 34: Esquema ER con relación 1:1............................ 59
Figura. 35: Esquema ER con relación ternaria M:N:P.......... 60
Figura. 36: Esquema ER con una dependencia en
existencia............................................................................. 60
Figura. 37: Esquema ER con una jerarquía de tipos y
subtipos............................................................................... 62
Figura. 38: Esquema relacional........................................... 73
Figura. 39: Diseño de modelo relacional.............................. 91
Figura. 40: Representación de las formas normales............. 92
Figura. 41: Diagrama de dependencias funcionales............. 93
Figura. 42: Diagrama de dependencias funcionales............. 96
Figura. 43: Comprobación de dependencia de reunión........ 98
Figura. 44: Diseño Relacional.............................................. 99
Figura. 45: Diagrama de dependencias funcionales........... 102
Figura. 46: Esquema relacional......................................... 103
Figura. 47: Relación de uno a uno (1:1)............................. 109
Figura. 48: Relación Instituto............................................ 109
Figura. 49: Relación de uno a muchos (1:n)....................... 109
Figura. 50: Tabla Empleados............................................. 110
Figura. 51: Relación de muchos a muchos........................ 110
Figura. 52: Partición vertical............................................. 111
Figura. 53: Partición horizontal......................................... 112
Figura. 54: Relación Universidad....................................... 113
Figura. 55: Relación en primera forma Normal.................. 113
Figura. 56: Diagrama de Estructuras................................ 118
Figura. 57: Dos representaciones de la clase libro............. 123
Figura. 58: Asociación binaria sin nombre......................... 124
Figura. 59: Asociación reflexiva con nombres y con
valores............................................................................... 124
Figura. 60. Asociación Ternaria......................................... 125
Figura. 61: Clase Asociativa.............................................. 125
Figura. 62. Agregación...................................................... 126
Figura. 63: Composición................................................... 127
Figura. 64: Generalización................................................ 127
Figura. 65: Generalización de dos niveles.......................... 128
Figura. 66: Especialización disjunta, total y dinámica....... 129
Figura. 67: Herencia Múltiple............................................ 129
Figura. 68: Relación de Dependencia................................. 129
Figura. 69: Objeto de la clase cliente................................. 131
Figura. 70: Representación detallada de un objeto de
la clase cliente................................................................... 131
Figura. 71: Diagrama de objetos........................................ 132
Índice de tablas
Tabla 1: Definición matemática de relacion.......................... 68

Tabla 2: Relación Artículos................................................... 69
Tabla 3: Relación Pedidos..................................................... 71
Tabla 4: Tabla Linea_pedidos............................................... 72
Tabla 5: Esquema relacional con datos................................. 74
Tabla 6: Ejemplo de relaciones para el álgebra relacional..... 76
Tabla 7: Unión de dos relaciones.......................................... 76
Tabla 8: Intersección de dos relaciones................................. 76
Tabla 9: Diferencia entre dos relaciones.............................. 76
Tabla 10: Relaciones para ejemplos posteriores.................... 78
Tabla 11: Producto cartesiano de dos relaciones................... 78
Tabla 12: Selección sobre una relación................................. 79
Tabla 13: Proyección sobre una relación............................... 79
Tabla 14: Selección y proyección sobre una relación............. 79
Tabla 15: Relaciones a utilizar en la división........................ 80
Tabla 16: División de las relaciones...................................... 80
Tabla 17: Relaciones de ejemplo para la combinación........... 81
Tabla 18: Producto cartesiano.............................................. 81
Tabla 19: Combinación o reunión......................................... 82
Tabla 20: Combinación Natural............................................ 83
Tabla 21: Ejemplo de relaciones para el cálculo relacional
de filas:................................................................................ 83
Tabla 22: Ejemplo de relaciones para el cálculo relacional
de fila................................................................................... 84
Tabla 23: Relación Pedidos................................................... 90
Tabla 24: Reacio Libro.......................................................... 94
Tabla 25: Relación Coche..................................................... 95
Tabla 26 : Relación Con Dependencias Multivaluadas.......... 97
Tabla 27: Relación Alumnos............................................... 100
Tabla 30: Relación Postal................................................... 105
Tabla 31: Relaciones en Cuarta Forma normal................... 106
Tabla 32: Datos de un Directorio........................................ 135
Tabla 33: Código de Provincia............................................ 135
Tabla 34 Registro de Directorio.......................................... 136
Tabla 35: Nombre - Fecha de un Directorio........................ 136
Tabla 36: Tabla Ciudad...................................................... 136
Tabla 37: Datos de un Encargo.......................................... 137
Tabla 38: Tabla pedido..................................................... 1146
Tabla 39: Tabla línea de pedido.......................................... 147
Prefacio
En la actualidad, se considera a las bases de datos como un elemento

indispensable en las empresas, instituciones u organizaciones que uti-
lizan sistemas computarizados, ya que éstas permiten operar datos de
manera organizada, segura, confiable y en grandes cantidades.
Cada vez se necesita más recursos en tecnología, es por ellos que
como avanzan las generaciones de las computadoras, las bases de da-
tos de igual manera avanzan en conjunto con los leguajes de progra-
mación.
Resulta impresionante poder visualizar como se procesa los datos
en microsegundos, mientras se realizan otras transacciones, al mis-
mo tiempo en la misma base de datos en lugares y estados diferentes;
definitivamente la tecnología avanza a pasos agigantados es por eso
que debemos arriesgarnos con el pasar de los años a las nuevas tec-
nologías que harán más fácil ciertas acciones como la administración y
seguridad de la información.
Existen dos razones por las cuales se ha realizado el presente libro,
la primera es dar a conocer los acontecimientos, por los cuales surgen
las bases de datos relacionales, el sistema gestor de base de datos,
Aplicación del Modelo Entidad-Relación para el modelado de datos y
modelos orientados a objetos.
[17]
Prólogo
Hoy en día las bases de datos han tomado gran importancia mundial,
es totalmente indispensable para las organizaciones puesto que brinda
mucha facilidad en el acceso a la información y una gran capacidad de
almacenaje de datos.
Es por este motivo que resulta muy grato dar a conocer este libro
que se titula “FUNDAMENTOS DE BASES DE DATOS”, el mismo que
ha sido creado para orientar a cualquier persona: desde un estudiante
en sus primeros pasos en el aprendizaje del mundo de la base de datos,
hasta un profesional ávido de nuevos conocimientos.
Con este libro se pretende que el lector pueda despejar toda clase de
interrogantes acerca de bases de datos y le permita familiarizarse rá-
pidamente con su contenido, no solo teórico sino también práctico me-
diante una serie de ejercicios.
La estructura de este libro está sujeta a un sinnúmero de temas,
los mismos que se encuentran organizados en 4 capítulos, cuyo con-
tenido se presenta de manera clara y precisa. Cada capítulo es suma-
mente importante en el proceso de aprendizaje de las bases de datos.
Los temas de este libro versan sobre las bases de datos relacionales y el
modelado de datos, cada uno con definiciones claras y entendibles, así
mismo reglas de transformación totalmente necesarias para crear un
modelado relacional y además el modelo orientado a objetos.
El objetivo del libro es lograr que cada lector enriquezca sus co-
nocimientos con los temas plasmados en cada capítulo, y servir como
ayuda didáctica a cientos de docentes en el área de bases de datos.
[19]
Dedicatoria
Dedico la realización de este libro a mis padres por el apoyo que me

han brindado a lo largo de toda mi vida ya que con su ayuda y consejos
han sabido guiarme para ser una persona de bien tanto en el aspecto
humano como en el profesional. Ellos han sido mi ejemplo a seguir
para lograr ser una persona correcta, honesta y con objetivos claros
[21]
Introducción
Con base a las investigaciones se ha comprobado que en la actualidad

el usuario tiene un acceso a la información más rápido que en el siglo
XXIII. Además, solo los ordenadores poseen la capacidad de almace-
nar, gestionar y trasmitir una amplia gama de datos. Los mismos que
pueden ser manipulados en momento por usuarios autorizados, ya sea
para realizar una inserción, modificación, eliminación o búsqueda.
El libro que se presenta a continuación pretende fortalecer los conoci-
mientos de los lectores empezando por conceptos básicos sobre bases
de datos relacionales, gestores de bases de datos, diseñar un diagrama
entidad – relación hasta llegar a una serie de ejercidos propuestos so-
bre cada uno de los temas.
Se divide en cuatro capítulos, los cuales están distribuidos de la si-
guiente manera:
Capítulo 1: Este capítulo trata sobre los conceptos de base de da-
tos relaciones, ejemplos, modelos de datos, funciones y sublenguajes,
clasificación de los modelos y las reglas de Codd.
Capítulo 2: Este capítulo trata sobre el análisis del modelo relacio-
nal y de los elementos que lo integran, conceptos de relaciones, claves
en el modelo relacional, restricciones, nociones de algebra relacional,
nociones de cálculo de tuplas para poder resolver ejercicios prácticos
básicos, nociones de cálculo relacional de dominios y teoría de la nor-
malización y sus objetivos.
Capítulo 3: En este capítulo se hablará sobre la Descripción y
Aplicación del Modelo Entidad-Relación para el modelado de datos,
el proceso de realización de diagramas Entidad-Relación, elementos,
diagramas Entidad-Relación extendidos, diseño lógico a partir de dia-
[23]
24 Zea M, Honores J, Rivas W
gramas Entidad-Relación y desarrollo de diversos supuestos prácticos

de modelización mediante diagramas Entidad-Relación.
Capítulo 4: Este capítulo trata sobre la contextualización del Mo-
delo orientado a objetos dentro del modelado UML, modelo de datos
orientado a objetos, comparaciones del modelo de clases con el modelo
Entidad- Relación, diagrama de objetos como caso especial del diagra-
ma de clases, modelo Distribuido y los enfoques para realizar el diseño.
Además, consta de una sección únicamente de ejercicios propuestos
que ayudaran al lector a enriquecer de manera práctica los conoci-
mientos adquiridos.
Base de datos relacionales
Descripción del capítulo
A continuación, se presentará los objetivos principales de cada aparta-

do del capítulo 1, sobre las Bases de Datos Relacionales:
El objetivo principal del apartado 1.1, es el de presentar una definición
coherente de lo que representa una base de datos relacional.
En el apartado 1.2 tiene por objetivo ejemplificar de forma clara y preci-
sa el diseño de una base de datos relacional, tomando en consideración
varios aspectos que se ven involucrados en la misma como son, las
claves candidatas, principales, alternativas, externas, y secundarias.
El apartado 1.3, tiene por objetivo exponer un concepto de modelos y
los tipos de segmentos que surgen ya sean estos estáticos o dinámicos.
Además, se expone los siguientes puntos:
Diseño de los sistemas de bases de datos
• Funciones de un SGBD
• Función de definición
• Función de manipulación.
• Función de control
En el apartado 1.4 se tiene por objetivo exponer la clasificación de los
diversos tipos de diseño de datos que existen de acuerdo al nivel de
abstracción, tomando así en cuenta los siguientes:
• Modelos de datos conceptuales
• Modelos de datos lógicos
• Modelos de datos físicos
El apartado 1.5 tiene por objetivo tratar sobre la enumeración de las
reglas de codd, para un sistema relacional, y se describirá de forma
breve cada una de ellas.
[25]
1.1. Generalidades de bases de datos
• Base datos relacional: Es aquella que está compuesta por un con-

junto de datos almacenados y relacionados entre sí, permitiendo
manipular los datos de una empresa. La función principal de una
base de datos es mantener la integridad y seguridad de los datos
ante cualquier incidente. [1], además es considerada como un sis-
tema de datos integrados los cuales pueden ser manipulados direc-
tamente por una serie de aplicaciones. [2]
• Sistema gestor de bases de datos (SGBD): También denomina-
do por sus siglas en inglés como Data Base Management System
(DBMS), es una herramienta que sirve como interfaz entre la base
de datos, el usuario y las aplicaciones. Además, permite definir,
construir, almacenar y manejar una base de datos, permitiendo el
control de los tipos de datos y restricciones sobre la información.
[3]
• Personas en el entorno de bases de datos: Dentro del entorno de
una base de datos intervienen cuatro grupos de personas que son
las siguientes:
Administrador de la base de datos: Es la persona encargada

de establecer las políticas de seguridad y del acceso concu-
rrente.
Diseñadores de la base de datos: Aquellos que diseñan la

base de datos, identificando datos, relaciones entre ellos, res-
tricciones sobre los datos y sobre las relaciones. También de-
ben tener conocimientos sobre los datos de la empresa y sus
reglas de negocio.
Programadores de aplicaciones: Encargados de implementar

los programas de aplicación que servirán a los usuarios fina-
les. Los mismos que permitirán insertar, modificar, eliminar y
consultar datos. [4]
A continuación, se definen los elementos de una base de datos relacio-

nal:
• Tabla: Es aquella que se encarga de alojar datos de la base de datos
y esta compuestas por:
Base de datos relacionales 27
Tupla: Se considera tupla a cada una de las filas de una tabla.
Atributo: Son las columnas de una tabla.
Grado: Número de atributos por los que está compuesta una

tabla.
Cardinalidad: Corresponde al número de tuplas de una tabla.
Dominio: Permite especificar los posibles valores válidos para

un atributo. Los dominios
Valor nulo: Indican contenidos de atributos que no tienen nin-

gún valor. Cuando hablamos de un valor nulo dentro claves
secundarias este indica que el registro actual no está relacio-
nado con ninguno. En cambio, para otros atributos indica que
no se puede rellenar ese valor por alguna razón.
Relaciones: Son aquellas que permiten evitar los datos redun-

dantes.
• Formularios: Se utilizan para actualizar los datos.

• Consultas: Permiten ver, modificar y analizar datos.
• Informes: Utilizados para mostrar datos en formato impreso. [5]
1.2. Ejemplificación
En una base de datos relacional los datos se obtienen en relaciones

y una relación se puede personalizar por medio de una tabla. Toda
relación tiene un nombre y está compuesta por un conjunto de filas
y columnas. Las columnas pertenecen a los atributos de la relación.
Por lo tanto las filas poseen una serie de valores para cada uno de los
atributos de la relación.
Al diseñar nuestra base de datos indicamos las tablas con sus res-
pectivos campos y el tipo de dato que le corresponde a cada uno de
ellos, como, por ejemplo, al definir el código debe ser de tipo string
(cadena) con un tamaño de caracteres asignado por el administrador
según las políticas del negocio, el nombre con un tamaño de treinta
caracteres, el género con un tamaño de nueve caracteres y el cargo con
un tamaño de cuarenta caracteres.
Una base de datos relacional debe garantizar la integridad y calidad
de los datos, por lo cual se debe cumplir con las reglas de negocio que
establece la empresa. Además, un aspecto importante a considerar
es la privacidad de la base de datos, al hablar de privacidad estamos
hablando de los permisos o privilegios que se le otorgan a cada uno de
los empleados de una empresa, ya que eso depende las acciones u ope-
raciones que ellos puedan realizar dentro de la base de datos.
La disponibilidad también es un elemento fundamental de la base
de datos, ya que permite a los usuarios y aplicaciones manipular per-
FUNDAMENTOS
manentemente la información DE BASE DE DATOS
de una organización. 2015

Tabla Empleados
e:] Andrea Pineda ::'vfasculino Gerente de operaciones

Cristhian Durán Femenino Director técnico Dominios
1 1 1 1
1
codi&o mombre 1eaero carso
- -+ Atributos
}
1000 Andrea Pineda Femenino Gerente de operaciones
1001 Cri sthian Durán Masculino Director técnico

Tuplas
1002 Daniel Flores Masculino Jefe de área
1003 Roció Ruiz Femenino Analista

'
-~ Grado =4
~~

Figura. 1: Relación empleados con sus campos y registros.
Claves
Uno nuestra
Al diseñar de losbaseelementos primordiales
de datos indicamos de con
las tablas lassus
tablas son las
respectivos claves,
campos unade dato
y el tipo
que leclave
corresponde a cada
aspirante deuno
una derelación
ellos, como, por conjunto
es un ejemplo, al de
definir el código
atributos que debe ser de tipo
repre-
string sentan
(cadena) uncon valor
un tamaño
único de de
caracteres
cada filaasignado
de lapor el administrador
relación, lo cualsegún
quiere las decir
políticas del
negocio,
queelnonombre
podrácon un tamaño
haber en unade treinta caracteres,
relación más de una el género
fila concon
el un tamaño
mismo de nueve
valor
caracteres y
único. el cargo con un tamaño de cuarenta caracteres.
Una base de datos relacional debe garantizar la integridad y calidad de los datos, por lo cual se
Una relación posee más de una clave aspirante o candidata, las
debe cumplir con las reglas de negocio que establece la empresa. Además, un aspecto importante a
cuales pueden ser clave principal y claves alternativas, o denominadas
considerar es la privacidad de la base de datos, al hablar de privacidad estamos hablando de los
porootros
permisos autores
privilegios como:
que se candidata,
le otorgan externa
a cada uno o secundaria.
de los empleados de una empresa, ya que eso
depende las acciones u operaciones que ellos puedan realizar dentro de la base de datos.
La disponibilidad también es un elemento fundamental de la base de datos, ya que permite a los
usuarios y aplicaciones manipular permanentemente la información de una organización.
Claves
Uno de los elementos primordiales de las tablas son las claves, una clave aspirante de una relación
• Clave candidata: Es el conjunto de atributos de una tabla por los

cuales se logra identificar unívocamente cada tupla de la tabla.
• Clave principal o primaria: Es la clave designada que permite
identificar únicamente las filas de la relación, es decir esta será la
clave principal. Por ejemplo, en la relación Empleado definimos al
atributo codigo como la clave principal.
• Claves alternativas: Son aquellos atributos o claves candidatas
que no han sido seleccionados como clave principal. Por ejemplo,
en la relación Empleado, los atributos como: nombre, genero, cargo
serían claves alternativas.
• Clave externa o secundaria: Es aquel atributo de una tabla que se
encuentra relacionado con una clave de otra tabla. [5]
Si un atributo ya permite identificar a cada fila, no tiene sentido que
la clave alternativa esté formada por ese atributo o quizás por algún
otro, como podemos ver en la relación de la figura 1 el atributo código
vendría hacer la clave principal ya que no puede haber dos empleados
con el mismo valor para este atributo, pero en caso de definir el atri-
buto nombre como clave principal no tendría que repetirse el nombre o
apellido del empleado, lo cual suele pasar porque pueden existir varios
empleados con el mismo nombre o con el mismo apellido por eso es
recomendable usar el atributo codigo como clave principal por ser un
campo único para cada persona. [6]
1.3. Concepto de modelos de datos. Funciones y sublenguajes
Un modelo de datos es un instrumento usado para crear una base de

datos, además está compuesto por símbolos, conocimientos y normas
que nos permiten representar los datos que se van a recopilar en una
base de datos, es decir, por medio de estos modelos se puede reprodu-
cir la información. [7]
El esquema dentro de un modelo de datos es una descripción es-
pecífica que permite representar a la base de datos. Existen diferentes
modelos de datos que se ajustan en el transcurso de la creación de la
base de datos, empezando por un esquema conceptual creado al inicio,
pasando por esquemas intermedios hasta llegar al esquema interno
que representa las características físicas que posee la base de datos.
Dentro de los modelos de datos existen dos tipos de segmentos: un
segmento estático y dinámico.

Segmento estático: Se clasifica en elementos autorizados y elemen-
tos no autorizados. Los elementos autorizados no son elementos simi-
lares para todos los modelos, pero están compuestos por entidades,
atributos, dominios y relaciones. Estos elementos son personificados
en manera de grafos.
En cuanto a los elementos no autorizados existen algunos valores
que no se deben almacenar en una base de datos. Existen dos tipos de
restricciones:
• Condiciones inherentes: Se define como condición inherente
del modelo relacional a una relación en la que no debe tener
dos filas idénticas.
• Condiciones semánticas: Estas condiciones suelen afectar al
conjunto de valores que posee un atributo. Sin embargo, tiene
como objetivo mostrar de la mejor forma posible el mundo real.
La condición semántica en caso de usar un atributo llamado
sueldo, sería que el sueldo solo puede adquirir valores enteros
mayores a cero.
Segmento dinámico: Este segmento establece que unos conjuntos de
operadores precisen sobre la estructura del modelo. Se llama ocurren-
cia del esquema o estado de la base de datos a los valores de los datos
almacenados. Entonces la aplicación de una operación de una ocu-
rrencia del diseño convierte a esta en otra ocurrencia.
0 (BDi)= BDj
Por ejemplo, si guardamos información de cinco empleados en una ta-

bla que pertenece a la base de datos, eso forma una ocurrencia del
esquema. Si ingresamos un nuevo empleado estamos efectuando la
operación de introducción, obteniendo otra ocurrencia del diseño de la
base de datos, en el que ya no tendríamos cinco empleados guardados
sino seis.
Al momento de crear una base de datos se deben seguir los siguientes
pasos secuenciales:
• Diseño conceptual: Estos diseños son altamente semánticos
y autónomos del tipo de base de datos que se va a usar pos-
teriormente, independientemente del Sistema Gestor de Bases
de Datos (SGBD). Hoy en día el diseño de datos usado para la
elaboración de esta tarea es el Modelo Entidad Relación.

• Diseño lógico: Parte del diseño conceptual elaborado anterior-
mente y convertirlo en el diseño lógico utilizando una serie de
reglas de innovación dependientes del diseño lógico. Existen
diversos tipos de diseños lógicos como son el diseño jerárquico,
el diseño en red y el diseño relacional.
• Diseño físico: Convierte el diseño lógico en diseño físico a tra-
vés de la herramienta SGBD, usando todos los elementos que
contiene la base de datos como: dominios, tablas, prohibicio-
nes, índices, etc.
1.3.1. Diseño de los sistemas de bases de datos

El objetivo de un SGBD es impedir a los usuarios las referencias sobre
como los datos son almacenados y conservados, por lo cual el admi-
nistrador de la base de datos tiene que representar la estructura de
los datos en diferentes niveles; por lo cual el resto de usuarios pueden
acceder, a esto se le conoce como diseño de los sistemas de bases de
datos. Debido a la normativa ANS/X3/SPARC, el diseño de una base
de datos debe tener tres niveles de abstracción:
• Nivel físico: Es el nivel más bajo de abstracción en el que se re-
presenta cómo se almacenan físicamente la información: la ca-
pacidad de los bloques de datos, procesos de direccionamiento,
los índices, etc.
• Nivel lógico: En este nivel se describen los datos que se están
siendo almacenados en la base de datos y que tipo de relacio-
nes existen entre los datos.
• Nivel externo: Este nivel es el más cercano al usuario, ya que
se describe lo que más le interesa al grupo de usuarios sobre la
base de datos ocultándole el resto de la base de datos.
1.3.2. Funciones de un SGBD

Las funciones principales de un Sistema Gestor de Base de Datos son
la función de definición, manipulación y de control:
1.3.2.1. Función de definición

Esta función permite al diseñador de la base de datos definir los ele-
mentos, estructura y las relaciones, normas de integridad y de confiabi-
lidad, así mismo la definir las particularidades de tipo físico y las vistas
de los usuarios. Por lo que se da el uso de un lenguaje de definición de
datos (DDL) el cual provee precisar las estructuras físicas, lógica global
y externas, proporcionados a cada uno de los niveles del diseño.
1.3.2.2. Función de manipulación.

Esta función permite a los usuarios realizar búsquedas y poder reem-
plazar la información que se encuentra guardada en la base de datos.
Para la actualización de la base de datos se involucra tres tipos de
operaciones que son:
• Inserción: Consiste en aumentar los datos, por ejemplo: inser-
tar los datos de un producto nuevo que se comercializa en una
empresa.
• Eliminación: Consiste en disminuir la información de la base
de datos, por ejemplo: eliminar o borrar los datos de un pro-
ducto que se dejó de comercializar en una empresa.
• Modificación: Consiste en editar la información de la base de
datos, por ejemplo: modificar el precio de un producto.
La función de manipulación se producirá a cabo por la interminación
de un lenguaje de manipulación de datos (DML), es decir que estos len-
guajes consiguen catalogar varios criterios:
A través de la forma independiente que maneja el DML, se ha lo-
grado conocer a los lenguajes huésped, autocontenidos o duales. DML
huésped estos lenguajes se tienen que infiltrar en otro lenguaje de pro-
gramación. Los DML autocontenidos son aquellos lenguajes utilizados
por los usuarios que poseen escasos conocimientos en cuanto a la pro-
gramación. Los lenguajes como el SQL, son manipulados como lengua-
jes huéspedes, y son denominados como lenguajes duales.
De acuerdo al detalle se puede especificar el procedimiento debido
para permitir los datos y consultarlos, ya que existen dos tipos de len-
guajes: Los de tipo procedimentales permiten al usuario proporcionar
instrucciones al sistema para que realice una serie de operaciones en la
base de datos y los poco procedimentales en cambio permiten al usua-
rio describir la información deseada sin un procedimiento específico
con el fin de obtener esa información.
Los lenguajes de especificación y lenguajes navegacionales se di-
ferencian en su forma de cómo recuperar o actualizar los datos. Los
lenguajes de especificación por medio de cada sentencia del DML logra

recuperar un conjunto de registros, mientras que los lenguajes navega-
cionales recuperan un solo registro.
1.3.2.3. Función de control

Esta función está compuesta por una serie de herramientas las mis-
mas que preparan la tarea del administrador de la base de datos. La
administración del sistema es quien se encarga de la administración
de usuarios. Debemos tomar en cuenta que los administradores tienen
que monitorizar el trabajo de la base de datos, así mismo respaldar y
realizar copias de seguridad de la base de datos en caso de algún inci-
dente, etc.
1.4. Clasificación de los varios tipos de diseño de datos de acuerdo

al nivel de abstracción.
Existen diferentes tipos de diseño de datos que se adaptan a lo largo del

proceso de la elaboración de la base de datos, es decir, estos diseños
son utilizados en las etapas del diseño de bases de datos como por el
ejemplo el diseño conceptual, diseño lógico y diseño físico.
1.4.1. Modelos de datos conceptuales

Estos modelos son diseños semánticos y autónomos independiente-
mente del tipo de base de datos que se procura crear, los mismos que
reciben el nombre de diseños lógicos.
Hoy en día el modelo Entidad Interrelación es el modelo de datos más
usado, mientras que otros autores definen que el modelo propuesto por
Chen, conocido como el modelo extendido Entidad Relación es el más
utilizado en la actualidad.
1.4.1.1. Modelos Entidad Relación

Chen plantea como elementos básicos del Modelo Entidad Relación a
las entidades, relaciones y atributos:
• Entidad: Una entidad es como un objeto del cual se desea
almacenar información en la base de datos. Por ejemplo, si
deseamos crear una base de datos para una biblioteca, las enti-
dades vendrían a ser los usuarios, libros, autores de los libros,
ejemplares, etc. Las entidades son representadas a través de

rectángulos.
• Relación: Es la correspondencia entre entidades. Las relacio-
FUNDAMENTOS DE BASE DE DATOS
nes se representan por medio de un rombo con el respectivo 2015
nombre en su interior.

• Atributo: Los atributos son las características de una entidad.
• Atributo: Los
Los atributos
atributos son
son representados
las características de una
de varias entidad.conLos
maneras; un atributos son
representados
óvalo y el nombre del respectivo atributo en su interior puedeatributo en su
de varias maneras; con un óvalo y el nombre del respectivo
interior puede
ser ser incorporado
incorporado directamentecon
directamente conlalaentidad
entidadoo con
con la
la relación.
relación.
~y AUTOR ~
M•~Y~ LIBRO ~
~(1.1)~
DI
~
(l.m) /~
e
EJEMPLAR
Figura. 2: Esquema entidad relación de una biblioteca
1.4.1.2. Diseño orientado a objetos

1.4.1.2. Diseño
A raízorientado a objetos nuevos métodos de análisis y diseño orien-
de que se formaron
tado a objetos esto
A raíz de que se formaron nuevos diométodos de análisisde
paso al Lenguaje Modelado
y diseño Unificado
orientado (UML),
a objetos esto dio paso al
el mismo que constituye una serie de reglas empleadas al momento de
Lenguaje de Modelado Unificado (UML), el mismo que constituye una serie de reglas empleadas
crear cualquier tipo de diagrama.
al momento de crear cualquier tipo de diagrama.
El modelo orientado a objetos está constituido por los siguientes ele-
El modelo orientado a objetos está constituido por los siguientes elementos:
mentos:
• Clase: • Se Clase:
considera clase a un
Se considera objeto
clase cualquiera
a un objeto sobre sobre
cualquiera el queel se
quedesea
se almacenar
informacióndesea
en la almacenar
base de datos.
información en la base de datos.
• Atributo: Los atributos vienen hacer las características de una clase, es decir la
información que se espera guardar sobre ella.
• Método: Los métodos son las operaciones que se van a aplicar sobre una clase. Por
ejemplo, para la clase libro tendríamos como métodos: solicitar y devolver un libro por
• Atributo: Los atributos vienen hacer las características de una

clase, es decir la información que se espera guardar sobre ella.
• Método: Los métodos son las operaciones que se van a aplicar
sobre una clase. Por ejemplo, para la clase libro tendríamos
como métodos: solicitar y devolver un libro por parte del usua-
rio a la biblioteca.
• Relación: Las relaciones son las respectivas agrupaciones que
se dan entre las clases. Existen varios tipos de relaciones en el
lenguaje de modelado unificado como son: asociación, jerar-
quía o generalización, agregación y composición, cada una de
FUNDAMENTOS
ellas se representa DE BASE DE DATOS
de forma distinta.
A continuación, se muestra un ejemplo de un diagrama de clases sobre
2015
una biblioteca.
Autor Libro
M N
Códioo ~
Nombre lítulo
ISBN
1 Editolial
Páginas
SolicitarPrestamo()
.M 1 OevOlución()
Detalle .
Fech_dev
Fech_Pres 1
N • -
-
1
Usuario -• M
M N
Código ~~ Ejemplar
Nombre ' Códjgo
Teléfono Localización
Dirección
Figura. 3: Diagrama de clases para una biblioteca.
1.4.2. Modelos deModelos

1.4.2. datos lógicos
de datos lógicos
Estos modelosEstos
son modelos soncrear
usados para usados para crear
un diseño unque
lógico diseño lógico la
represente que represente
estructura la base de datos
la estructura la base de datos que se va a diseñar. Un diseño lógico
que se va a diseñar. Un diseño lógico parte del diseño conceptual. Existen tres modelos de datos
parte del diseño conceptual. Existen tres modelos de datos lógicos: el
lógicos: el modelo jerárquico, modelo en red y el más usado en la actualidad el modelo relacional.
modelo jerárquico, modelo en red y el más usado en la actualidad el
1.4.2.1. Modelo jerárquico
Este modelo usa una estructura en forma de árbol, en la cual el padre puede poseer cualquier
número de hijos, pero un hijo solo puede tener un padre.
A continuación, se mostrará el ejemplo de un diagrama de estructura de árbol con dos ejemplos de
registros: sucursal y empleados, en donde varios empleados pueden tener muchos hijos.
modelo relacional.
Figura. 3: Diagrama de clases para una biblioteca.
1.4.2. Modelos de datos lógicos
Este modelo usasonuna
Estos modelos estructura
usados en forma
para crear un diseño lógico quede árbol,
represente en la cual
la estructura la baseel
de padre
datos
puede que se va a diseñar. Un diseño lógico parte del diseño conceptual. Existen tres modelos de datos
poseer cualquier número de hijos, pero un hijo solo puede tener
lógicos: el modelo jerárquico, modelo en red y el más usado en la actualidad el modelo relacional.
un padre.
Este modelo usa una se
A continuación, estructura
mostraráen formael
de ejemplo
árbol, en la de
cual un
el padre puede poseer
diagrama decualquier
estruc-
número de hijos, pero un hijo solo puede tener un padre.
tura deA continuación,
árbol conse dos ejemplos de registros: sucursal y empleados,
mostrará el ejemplo de un diagrama de estructura de árbol con dos ejemplos de
en
donde registros:
variossucursal
empleados pueden
y empleados, tener
en donde varios muchos
empleados puedenhijos.
tener muchos hijos.
Sucursal
Santa Rosa Ing. Miguel Albán
Oficina Empleado
Eloy Alfaro Fernando Morán
¡
/Hijos~
1-Lu-is-Mo-rán~l
-1M-1-l-O1 Ana Morán 1 20 1 F 1
Figura. 4: Esquema de una base de datos jerárquica.
1.4.2.2. Modelo en red

1.4.2.2. Modelo en red
Este modelo maneja una estructura no lineal en la que cada registro hijo puede tener más un nodo
Este modelo manejade una
padre. La simbología estructura
las entidades son nodos deno lineal
un grafo y las en la quemediante
asociaciones, cadalosregistro
arcos.
hijo puede tener más un nodo padre. La simbología de las entidades
FUNDAMENTOS DE BASE DE DATOS 2015
son nodos de un grafo y las asociaciones, mediante los arcos.

Codasyl se considera como el modelo en red más extenso. En la22
Codasyl se considera como el modelo en red más extenso. En la figura 5 se observa un ejemplo de

figura 5 lase observa
forma un ejemplo
de la información en este diseñode la forma de la información en este
de datos.
diseño de datos.
Santa Rosa Ing. Miguel Albán
Oficina -----------;Emplead~
1 1
1 EloyAlfaro ~ lt <,
1-~1-~A~le~x~R~a~m~ó~n-~1~1~1
1 2 1 Fernando Morán 11 11 1 Lethy Blacio
t
1 Hijos
1 Lis Ramón 1 40 1 F 1 1 Luis Morán 1 10 1 M 1 1 Ana Morán 1 20 1 F 1
Figura. 5: Esquema de una base de datos en red.
1.4.2.3 Modelo relacional

En este modelo se hace uso de las tablas para la forma lógica de los datos y sus relaciones, este
modelo es creado por Codd en el año de 1970. Se denomina tupla a cada fila de la tabla y atributo
o campo a cada columna de la tabla. El campo principal de una tabla que marca la diferencia entre
otros campos es la clave.
En la siguiente figura 6 se mostrará la información que se desea almacenar en la base de datos.
Ésta manejará información sobre la sucursal de una empresa y sus empleados.

En este modelo se hace uso de las tablas para la forma lógica de los
datos y sus relaciones, este modelo es creado por Codd en el año de
Figura. 5: Esquema de una base de datos en red.
1970. Se denomina tupla a cada fila de la tabla y atributo o campo a
cada columna de la tabla. El campo principal de una tabla que marca
En este modelo se hace uso de las tablas para la forma lógica de los datos y sus relaciones, este
la diferencia entre
modelo es creado otros
por Codd en elcampos
año de 1970.esSeladenomina
clave. tupla a cada fila de la tabla y atributo
o En
campola siguiente figura 6 se mostrarádelaunainformación
a cada columna de la tabla. El campo principal tabla que marca laque
diferencia entre
se desea
otros campos es la clave.
almacenar en la base de datos. Ésta manejará información sobre la
En la siguiente figura 6 se mostrará la información que se desea almacenar en la base de datos.
sucursal de una
Ésta manejará empresa
información sobre laysucursal
sus empleados.
de una empresa y sus empleados.
Localldad_Dtp
osa
:-ium_Emp :-iombre_Emp Saeldo_Emp :-ium_Dep

4
41
Figura. 6: Diseño de una base de datos relacional con datos.
1.4.3.Modelos
1.4.3. Modelos de de datos físicos físicos
datos
El diseño físico es la última etapa del diseño de una base de datos el cual consiste en crear en un
El SGBD
diseño los físico
elementosesque
laformarán
últimaparte etapa
de la del
base diseño deeluna
de datos. En caso base de datos
de una base de datos el
cual consiste en crear en un SGBD los elementos que formarán parte
relacional se debería crear tablas, disparadores, vistas, índices, etc.
de la base de datos. En el caso de una base de datos relacional se de-
bería crear tablas, disparadores, vistas, índices, etc.
Una base de datos relacional está compuesta por una o varias ta- 23

blas. Para la creación de una tabla mediante el lenguaje de definición
de datos se utiliza la instrucción CREATE TABLE. Es necesario definir
los atributos por los que estará compuesta una tabla como son: nom-
bre, tipo de datos y restricciones asociadas al atributo.
A continuación, veremos un ejemplo de cómo crear en el SGBD
Oracle la base de datos relacional, utilizando el mismo diseño lógico
que se muestra en la figura 2, para lo cual se utilizarían las siguientes
instrucciones CREATE TABLE:
create table Autor
(Código char (5) primary key,
Nombre varchar2 (30));

create table Libro
(Código char (7) primary key,
Título varchar2(60) not null,
ISBN char (10) unique,
Editorial varchar2(0),
Paginas number (5,0) check (Paginas >0));
create table Ejemplar
(Codlibro char (7) references Libro (Código),
Localización varchar2(60) references Autor (Nombre),
primary key (CodLibro, Localización));
create table Usuario
(Código number (7) primary key check (Codigo >0),
Nombre varchar2(40) not null,
Teléfono char(9) not null),
Dirección varchar2(60));
create table Prestamo
(Codlibro char(8) references Libro (Código),
Código number(6) references Usuario (Código),
Fech_Pres date,
Fech_dev date,
primary key (CodLibro, Código, Fech_Pres, Fech_dev));
1.5. Enumeración de las reglas de Codd para un sistema relacio-

nal
A continuación, se detallan las doce reglas definidas por Codd en 1984

las cuales deben cumplirse al desarrollar un sistema relacional. Aun-
que resulta difícil que un sistema relacional llegue a efectuar algunas
de estas normas, a continuación, se detallaran las reglas de Codd:
Regla 1: Se debe representar toda la información de la base de datos
en el esquema lógico, es decir que todos los datos están en las tablas.
Regla 2: Regla del acceso garantizado: Todos los datos de una base
de datos relacional deben ser accesibles al nivel lógico usando el nom-
bre de tabla, valor de la clave principal y nombre de columna.
Regla 3: Tratamiento sistemático de valores nulos: A través de los va-
lores nulos es posible representar información inédita o no aplicable,
independientemente del tipo de datos.

Regla 4: Catálogo dinámico en línea basado en el modelo relacio-
nal: Solo los usuarios autorizados pueden realizar consultar y modificar
datos. Así mismo los usuarios pueden tener acceso a la estructura de
la base de datos.
Regla 5: Regla del sublenguaje de datos completo: Debe por lo me-
nos haber un lenguaje con una sintaxis bien definida que permita la
administración de la base de datos.
Regla 6: Regla de actualización de vistas: Aquellas vistas que se
pueden modificar deben también permitir la modificación por parte del
sistema.
Regla 7: Inserción, modificación y eliminación de alto nivel: En el
momento en que se realice una inserción, modificación o eliminación el
sistema deberá ser capaz de proporcionar datos. El lenguaje de manejo
de datos puede ser de declaración, es decir, debe permitir, por ejemplo,
cambiar algunas filas de una tabla de forma conjunta.
Regla 8: Independencia física de datos: No interviene el usuario y
está enfocada a que las modificaciones que se realicen en la base de
datos no alteren el método de acceso. Por ejemplo, organización de ar-
chivos para mejorar el rendimiento (“separación física de aplicaciones y
estructura de almacenamiento”).
Regla 9: Independencia lógica de datos: Las aplicaciones no deben
verse afectadas por las modificaciones que se realizan en las tablas de
la base de datos, ya que ambas funcionan diferente. Ejemplo: Eclipse
– Mysql.
Regla 10: Independencia de integridad: Se debe especificar las limi-
taciones de integridad para una base de datos relacional por separado
de los programas de aplicación y almacenar en la base de datos.
Regla 11: Independencia de distribución: La distribución de una
base de datos es independiente, ya sea cuando se trabaja con una base
de datos compartida en diferentes ordenadores o cuando se trabaje con
una base de datos centralizada.
Regla 12: Regla de la no subversión: Si en un sistema relacional
cuenta con un lenguaje de bajo nivel, esto le impide que pueda saltarse
las normas de integridad y las limitaciones mencionadas en los lengua-
jes relacionales de más alto nivel. Ejemplo: búsqueda del apellido de un
empleado, resultado el número de teléfono. [5]
Resumen
• Una base de datos relacional está compuesta por un conjunto de

datos almacenados y relacionados entre sí, permitiendo manipular
la información de una empresa
• En una base de datos relacional la información se recopila en base
al contenido de las tablas y las relaciones que existe entre ellas
• Un modelo de datos es un instrumento usado para crear una base
de datos, además está compuesto por símbolos, conocimientos y
normas que nos permiten personificar los datos que se van a reco-
pilar en una base de datos.
• El objetivo de un SGBD es impedir a los usuarios las referencias
sobre como la información es almacenada y conservada,
• Las funciones principales de un Sistema Gestor de Base de Datos
son la función de definición, manipulación y de control
• Existen diferentes tipos de diseño de datos que se adaptan a lo lar-
go del proceso de la elaboración de la base de datos, los cuales son:
Modelos de datos conceptuales, Modelos de datos lógicos, Modelos
de datos físicos
[41]
Descripción y aplicación del modelo
entidad-relación para el modelado de
datos
A continuación, se detalla cada contenido del capítulo 2, acerca de la

descripción y aplicación del modelo Entidad - Relación para el mode-
lado de datos.
En el apartado 2.1, tiene por objetivo conocer el origen del modelo en-
tidad – relación.
En el apartado 2.2, tiene por objetivo conocer cada uno de los elemen-
tos que forman parte de un modelo entidad - relación, siendo estos:
• Entidad.
• Relación.
• Atributo.
• Dominio.
En el apartado 2.3, tiene por objetivo analizar el modelo entidad – rela-
ción extendido, el mismo que detalla puntos importantes como:
• Cardinalidad.
• Entidad frágil y fuerte.
• Atributos en entidades.
• Herencia.
• Agregación
• Generalización.
En el apartado 2.4, tiene por objetivo determinar la forma más opcional
de pasar de un modelo entidad – relación a un modelo relacional.
En el apartado 2.5, tiene por objetivo plantear una serie de prácti-
cas para diagramar modelos de entidad - relación y su correcta trans-
formación a un modelo de datos mediante reglas definidas.
[43]
2.1. Proceso de realización de modelo entidad - relación
Actualmente para diseñar o modelar conceptualmente una base de da-

tos se utiliza el modelo de datos llamado modelo entidad – interrelación,
conocido también como modelo entidad – relación (ER); fue presentado
por Peter Chen en el año de 1976, el mismo DEque estuvoDEsujeto a varias
FUNDAMENTOS BASE
contribuciones por diferentes autores creando así el modelo entidad -
DATOS 2015
relación extendido. [5]
2.1. Proceso
Comode realizaciónbásicos
elementos de modelo
del entidad
modeloentidad-
relación relación tenemos: en-
Actualmente para diseñar o modelar conceptualmente
tidad, atributo, dominio y relación o interrelación, una base de datosseseexpli-
los cuales utiliza el
modelo
carándemásdatosadelante.
llamado modelo entidad – interrelación, conocido también como modelo
entidad – relación (ER); fue presentado por Peter Chen en el año de 1976, el mismo que
estuvo
2.2. sujeto a varias contribuciones por diferentes autores creando así el modelo entidad -
Elementos
relación extendido. [5]
Como elementos básicos del modelo entidad- relación tenemos: entidad, atributo, dominio
El modelo entidad – relación se compone de varios elementos, los mis-
y relación o interrelación, los cuales se explicarán más adelante.
mos que se detallan a continuación.
2.2. Elementos
El modelo entidad – relación se compone de varios elementos, los mismos que se detallan
2.2.1. Entidad
a continuación.
Se define
2.2.1. Entidadcomo entidad al objeto sobre el cual se desea guardar in-
Se define comoen
formación una al
entidad base desobre
objeto datos. Porseejemplo,
el cual al diseñar
desea guardar una en
información base
una de
base de
datos. Por ejemplo, al diseñar una base de datos para gestionar el inventarioque
datos para gestionar el inventario de una empresa, las entidades de una
formarían
empresa, el modelo
las entidades queserían almacén,
formarían departamento,
el modelo serían almacén,producto, etc. producto,
departamento, [8]
etc. [8]Dentro de una entidad tenemos las llamadas ocurrencias de una
entidad, que son aquellos valores determinados que toman cada uno
Dentro de una entidad tenemos las llamadas ocurrencias de una entidad, que son aquellos
de los atributos de una entidad. En este caso un ejemplo de ocurrencia
valores determinados que toman cada uno de los atributos de una entidad. En este caso un
de una entidad Producto seria el producto “Televisor Oled Curvo De
ejemplo de ocurrencia de una entidad Producto seria el producto “Televisor Oled Curvo
55’’ EC9300”.
De 55'' EC9300”.
La representación gráfica de una entidad, es por medio de un rec-
Latángulo
representación gráfica
en el cual se de una entidad,
coloca es por
el nombre de medio de un Ejemplo,
la entidad. rectángulo entidad
en el cual se
coloca el nombre de la entidad. Ejemplo, entidad Producto.
Producto.
Conjunto de Entidades
Entidad Producto PRODUCTO
Figura. 7: Representación gráfica de una entidad
2.2.2. Relación
Se entiende por relación a la asociación o vínculo entre dos o más entidades, estableciendo
alguna interacción entre ellas. En el caso de un Curso y Alumno se establecería como
relación tiene para mostrar que los cursos tienen alumnos.
La representación gráfica de una relación es por medio de un rombo en el cual va el
coloca el nombre de la entidad. Ejemplo, entidad Producto.
Descripción y aplicación del modelo entidad-relación para el modelado de datos 45
2.2.2. Relación
Se entiende por relación a la asociación o vínculo entre dos o más en-
Figura. 7: Representación gráfica de una entidad
tidades, estableciendo alguna interacción entre ellas. En el caso de un
2.2.2. Relación
Curso y Alumno se establecería como relación tiene para mostrar que
Se entiende por relación a la asociación o vínculo entre dos o más entidades, estableciendo
los cursos tienen alumnos.
alguna interacción entre ellas. En el caso de un Curso y Alumno se establecería como
La representación gráfica de una relación es por medio de un rom-
relación tiene para mostrar que los cursos tienen alumnos.
bo en el cual va el nombre de la relación, asociadas de las entidades
La representación gráfica de una relación es por medio de un rombo en el cual va el
que forman parte de la relación. Para demostrar la representación
nombre de la relación, asociadas de las entidades que forman parte de la relación. Para
de la relación
demostrar se usará
la representación de el
la ejemplo
relación se dado
usaráanteriormente
el ejemplo dadoentre Curso yentre
anteriormente
Alumno. [5]
Curso y Alumno. [5]
CURSO ALUMNO
Figura. 8: Representación gráfica de una relación

FUNDAMENTOS
Las relaciones poseen las siguientes características:DE BASE DE DATOS 2015

• Nombre:
Las relaciones
Cada relación poseerá un nombre que las distinguirá de
poseen las siguientes características: 29
las demás.
• Las relaciones
Nombre: poseen
Cada las siguientes
relación poseerá uncaracterísticas:
nombre que las distinguirá de las demás.
• Grado: Número de entidades que son parte de una relación. Se
• Nombre:
• Grado: Número de entidades que son un
Cada relación poseerá nombre
parte de unaque las distinguirá
relación. de lasen:
Se clasifican demás.
clasifican en:
• üGrado: Número
Relaciones de entidades
binarias que son
o de grado parte de una
2: Relaciones relación.
que asocianSea clasifican en:
dos entidades
• Relaciones binarias o de grado 2: Relaciones que asocian a dos
ü Relaciones binarias o de grado 2: Relaciones que asocian a dos entidades
distintas.
entidades distintas.
distintas.
ü Relaciones reflexivas o de grado 1: Relaciones que solo relacionan una
• ü
Relaciones
Relaciones reflexivas
reflexivas oode
degrado
grado 1:
1: Relaciones
Relaciones quequesolo
solorelacionan
relacio- una
entidad consigo misma.
nanentidad
una entidad consigo misma.
consigo misma.
PERSONA
Figura. 9: Relación reflexiva

Figura. 9: Relación reflexiva
ü Relaciones ternarias, cuaternarias, o de grado 3,4: Relaciones que asocian más de
• dosü
Relaciones
Relaciones ternarias,
entidades. cuaternarias,
ternarias, cuaternarias, o de
o de grado 3,4:grado 3,4: que
Relaciones Relaciones
asocian más de
quedos asocian más de dos entidades.
entidades.
CURSO ALUMNO
AULA
Figura. 10: Relación ternaria
Figura. 10: Relación ternaria
ü Las relaciones poco usuales son las relaciones de grado 2, a diferencia de las
ü Las binarias
relaciones relaciones
quepoco usuales
son las son las relaciones
más utilizadas, de relaciones
le siguen las grado 2, areflexivas.
diferencia de las
• relaciones binarias que son las más utilizadas, le siguen
Tipo de correspondencia: Es el número de entidades en la que se puede asociar las relaciones reflexivas.
otra
Tipo de correspondencia: Es el número de entidades
entidad a través del conjunto de relaciones. Se clasifican en:
• en la que se puede asociar otra
ü entidad a través
1:1: Se del conjunto
da cuando de relaciones.
un registro de cada Se clasifican
entidad estáen:
relacionado con un único
ü Relaciones ternarias, cuaternarias, o de grado 3,4: Relaciones que asocian más de
dos entidades.
• Las relaciones poco usuales son las relaciones de grado 2, a

diferencia de las relaciones binarias que son las más utilizadas,
le siguen las relaciones reflexivas.
Tipo de correspondencia: Figura.Es
10:el número
Relación de entidades en la que se puede
ternaria
asociar otra entidad a través del conjunto de relaciones. Se clasifican
ü Las relaciones poco usuales son las relaciones de grado 2, a diferencia de las
en: relaciones binarias que son las más utilizadas, le siguen las relaciones reflexivas.
• Tipo de1:1: Se da cuandoEsun
correspondencia: el registro
número dede cada entidad
entidades en la queestá relacionado
se puede con
asociar otra
entidadun único
a través del registro
conjunto dederelaciones.
otra entidad. Ejemplo:
Se clasifican en:
1:1: Persona
ü Una Se da cuandotieneununregistro
usuariode cada
y un entidad está le
Usuario relacionado
pertenececona un
unaúnico
sola
registro
persona. de otra entidad. Ejemplo:
Una Persona tiene un usuario y un Usuario le pertenece a una sola persona.
PERSONA USUARIO
Figura. 11: Relación 1:1 binaria
Una Persona está casada con una sola Persona.

FUNDAMENTOS
Una Persona está casada con una sola Persona.
DE BASE DE DATOS 2015

PERSONA

Figura. 12: Relación 1:1 reflexiva.

30
ü 1:N: Se da cuando un registro de una entidad A solo está relacionado con
• 1:N: Se da cuando unRelación
registro de una entidad A solo está rela-
un único registro deFigura. 12:
la entidad B, y un1:1 reflexiva.
registro de la entidad B tiene más de
cionado con un único registro de la entidad B, y un registro de
un registro relacionado con la entidad A. Ejemplo:
ü 1:N: Se da cuando un registro de una entidad A solo Cliente
Un está tiene varias
relacionado con
la entidad
facturas, B tiene
Facturamás de un registro relacionado con la entidad
un único pero unade
registro le pertenece
la entidad a un solo
B, y un registro decliente.
la entidad B tiene más de
A. Ejemplo:
un registro Un Cliente
relacionado tiene varias
con la entidad facturas,
A. Ejemplo: pero una
Un Cliente tieneFactura
varias
le pertenece a un solo cliente.
facturas, pero una Factura le pertenece a un solo cliente.
Figura. 13: Relación 1:N binaria

CLIENTE FACTURA
Un Trabajador puede ser jefe de varios trabajadores, pero un trabajador
solo puede tener un jefe.
Un Trabajador puede
Un Trabajador puede serserjefe
jefede
devarios
variostrabajadores, peropero
trabajadores, un trabajador
un traba-
jador solo puede tener un jefe.
Figura. 14: Relación 1:N reflexiva

facturas, pero una Factura le pertenece a un solo cliente.
Un Trabajador puedeFigura.ser jefe de varios

13: Relación trabajadores, pero un trabajador
1:N binaria
Un Trabajador puede ser jefe de varios trabajadores, pero un trabajador
TRABAJADOR~~~~~
• N:M: Se da cuando un14:

Figura. registro
Relaciónde
1:Nuna entidad puede estar re-
reflexiva
lacionado con más de un registro de otra entidad, en este caso
ü N:M: Se da cuando un registro de una entidad puede estar relacionado con
de correspondencia Figura.
es 14: Relación 1:N
necesario reflexiva
crear una nueva tabla que in-
más de un registro de otra entidad, en este caso de correspondencia es
ü N:M:cluya loscuando
Se da registros relacionados
un registro entre sí. Ejemplo: Una Factura
necesario crear una nueva tabla de
queuna entidad
incluya los puede estar
registros relacionado
relacionados con
entre
puede
másEjemplo: incluir
de un registro varios productos,
de otrapuede
entidad, y un
en varios Producto
este caso puede estar
de correspondencia en
es
sí. Una Factura incluir productos, y un Producto
varias
necesario facturas.
puede estarcrear una nueva
en varias tabla que incluya los registros relacionados entre
facturas.
sí. Ejemplo: Una Factura puede incluir varios productos, y un Producto
puede estar en varias facturas.
FACTURA PRODUCTO
Figura. 15: Relación N:M binaria.
Un Menú puede contener varios menús.

Figura. 15: Relación N:M binaria.
MENÚ
Figura. 16: Relación N:M reflexiva
Figura. 16: Relación N:M reflexiva
2.2.3. Atributo y dominio

Un atributo se define como las propiedades o características que es- 31
tán asociadas a una entidad o relación. En una entidad Producto sus

atributos serían código, nombre, descripción, valor, etc. Un dominio es 31
el valor permitido para cada atributo de una entidad, en el caso de un
atributo código, su dominio sería una cadena de cinco caracteres.
Una manera de representar los dominios es a través de un círculo,
el mismo que deberá contener su nombre y en la línea que se relaciona
con la entidad se colocará el nombre del atributo; esta representación
es muy poco factible debido a que el modelo entidad – relación resultan
muy pesados y confusos. [9]
Es por aquella razón que la representación del modelo entidad - re-
2.2.3. Atributo y dominio
lación
Un
tuvo
atributo seun pequeño
define como cambio,
las propiedades se oomitiría el
características nombre
que están del atributo
asociadas a unaen
entidad
la2.2.3.
línea o relación.
de asociación
Atributo En una entidad Producto sus atributos
y dominio con la entidad y solo se colocaría el nombre del serían código, nombre,
descripción,
Un atributo
atributo envalor,
seeldefineetc. como
círculo Un dominio
prescindiendoes el valor opermitido
las propiedades del para cada
características
nombre queatributo
del de una entidad,
están asociadas
dominio. a una
en el caso de
entidad diferentes un atributo
o relación. En código,
una de su dominio
entidad sería
Producto una cadena
sus ellos
atributosde cinco caracteres.
serían código, nombre,
Existen
Una manera valor,
de representar tipos atributos
los dominios entre
es a permitido
través de para tenemos:
un círculo, el mismo queentidad,
deberá
descripción, etc. Un dominio es el valor cada atributo de una
• contener
Atributosu identificador
nombre y en la línea principal
que se [AIP):
relaciona con Atributo
la entidad que
se permite
colocará el identifi-
nombre del
en el caso de un atributo código, su dominio sería una cadena de cinco caracteres.
atributo;
Una manera de representar los dominios es a través de un círculo, el mismo que deberá–
car esta
cada representación
registro de es
la muy
entidad poco factible
adecuada, debido por a que el
ejemplo, modelo
en entidad
la entidad
relación
contener resultan
productosu nombre muy
el y pesados
atributo
en la línea y identificador
confusos. [9]
que se relaciona principal
con la entidadsería el código
se colocará el nombredebido
del
Es por
atributo; aquella razón que la representación pocodel modelodebido
entidada -que relación tuvo unentidad
pequeño
a queesta norepresentación
existirán dos es muy o más factible
productos registrados el modelo
con el mismo –
cambio, se
relación omitiría
resultan muy el pesados
nombre del atributo en
y confusos. [9] la línea de asociación con la entidad y solo se
código.
colocaría el nombre
Es por aquella razóndel queatributo en el círculodel
la representación prescindiendo
modelo entidad del nombre
- relacióndeltuvo
dominio.
un pequeño
• ExistenAtributo identificador
diferentes tipos de atributos candidato
entre ellos (AIC]: Si existe más de un atributo
tenemos:
cambio, se omitiría el nombre del atributo en la línea de asociación con la entidad y solo se
§ Atributo
que
colocaría cumpla
el nombre identificador
con la condición
del atributo principal
en de
el círculo [AIP):
ser un Atributo
prescindiendo atributoque
del permite
AIP,
nombre delaidentificar
los atributos
dominio. cada
Existen registro
no seleccionados de la entidad
diferentes tipos de atributos adecuada,
se los denominarán por ejemplo, en la entidad producto
entre ellos tenemos:atributo identificador candi- el atributo
§ identificador
dato.
principal sería
Atributo identificador el código
principal [AIP):debido
Atributo a queque no existirán
permite dos o cada
identificar más
productos
registro deregistrados
la entidadcon el mismopor
adecuada, código.
ejemplo, en la entidad producto el atributo
• Atributo
§ Atributo identificador
identificador alternativo (AIA): Esmás el atributo identificador
identificador principal candidato
sería el código(AIC]: Si existe
debido a que de nounexistirán
atributo que cumpla
dos o más
candidato
con la no
condición designado
de ser un
productos registrados con el mismo código.
como
atributo atributo
AIP, a los identificador
atributos no principal.
seleccionados se [10]
los
Otra§ forma denominarán
de atributo
representar identificador
un candidato.
modelo de entidad
Atributo identificador candidato (AIC]: Si existe más de un atributo que cumpla – relación, es colo-
cando Atributo
§ dentro identificador
de
con la condición losdeóvalosser alternativo (AIA):
o círculos
un atributo AIP, aelEs elatributos
losnombre atributono identificador
de candidato
los atributos
seleccionados se losde
no designado atributo
denominarán como atributo identificador
identificador principal. [10]
candidato.
determinada entidad. El atributo identificador principal se lo resalta
Otra§ forma de representar
Atributo identificador un modelo de entidad
alternativo (AIA):– Es relación, es colocando
el atributo dentro
identificador de los
candidato
mediante
óvalos no una línea
o designado
círculos elcomo de subrayado,
nombre de los mientras
atributos de que los atributos
determinada entidad. El alterna-
atributo
atributo identificador principal. [10]
tivos
Otra no
identificador
formase desubrayan.
principal
representar se lounresalta
modelomediante
de entidaduna–línea de subrayado,
relación, es colocando mientras
dentroque de los
los
____
atributos alternativos no se subrayan.
óvalos o círculos el nombre de los atributos de determinada entidad. El atributo
identificador principal se lo resalta mediante una línea de subrayado, mientras que los
atributos alternativos no se subrayan. ~/
Fecha
Nombre
PRODUCTO
Figura. 17: Representación de atributos
También se puede representar colocando un círculo para cada atributo, el círculo rellenado
También se para
de negro será puede representar
el atributo colocando
identificador
Figura. principal,dey un
17: Representación círculo
el círculo
atributos vacíopara cada
será para atribu-
el atributo
identificador
to,También
el círculo alternativo.
rellenado
se puede decolocando
representar negro será parapara
un círculo el atributo identificador
cada atributo, prin-
el círculo rellenado
de negro
cipal, y elserá para el atributo
círculo identificador
vacío será para principal, y el círculo
el atributo vacío será para
identificador el atributo
alternativo.
identificador alternativo.
Fecha
Figura. 18: Representación de atributos alternativa
FACTURA
l:M O Nombre
Figura. 18: Representación de atributos alternativa
32

32

2.3. Diagramas entidad-relación extendidos como elementos para

resolver las carencias de los diagramas entidad-relación simples.
Luego que Peter Chen haga la presentación de su modelo entidad – re-

lación extendido, varios autores han creado diversos modelos atracti-
vos basándose en el modelo entidad – relación. deDE
Chen.
FUNDAMENTOS DE BASE DATOS 2015

2.3.1. Cardinalidad deFUNDAMENTOS las relaciones. DE BASE DE DATOS 2015
2.3. Diagramas entidad-relación extendidos como elementos para resolver las
Se define como cardinalidad al número de veces en que se asocia una
carencias de los diagramas entidad-relación simples.
entidad
2.3. con
LuegoDiagramas
que otra,
Peter Chencuando
entidad-relaciónhablamos
extendidos
haga la presentación desucardinalidad
de como
modelo entidad máxima
elementos – para y mínima
resolver
relación las
extendido,
carencias
hacemos de los diagramas
referencia al entidad-relación
máximo y mínimosimples.
de ocurrencias
varios autores han creado diversos modelos atractivos basándose en el modelo entidad –de una entidad
Luego
relación.
asociada que
deaPeter
otraChen
Chen. haga lapor
entidad presentación
medio de de una
su modelo entidadLas
relación. – relación extendido,
cardinalidades
varios
2.3.1. autores han creado
Cardinalidad de lasdiversos
relaciones.modelos atractivos basándose en el modelo entidad –
se clasifican en: uno a uno, uno a muchos y muchos a muchos, cada
relación.
Se definedecomo Chen.cardinalidad al número de veces en que se asocia una entidad con otra,
una
2.3.1. deCardinalidad
estas cardinalidades poseen las etiquetas de (1,1), (1,N) y (N,M).
cuando hablamos dedecardinalidad
las relaciones.
máxima y mínima hacemos referencia al máximo y
[8]Se
mínimodefinedecomo cardinalidad
ocurrencias de unaalentidad
númeroasociada
de veces en que
a otra se asocia
entidad una entidad
por medio de una con otra,
relación.
cuando
LasPara hablamos
cardinalidades de
representar cardinalidad
unaen:
se clasifican máxima
etiqueta
uno y uno
N,
a uno, mínima
Maes hacemos
necesario
muchos referencia
y muchos definir al el
a muchos, máximo
máximo
cada unay
mínimo
de estas de ocurrencias
cardinalidades de una
poseen entidad
las asociada
etiquetas de a otra
(1,1), entidad
(1,N)
y mínimo de la cardinalidad. En este caso tenemos la entidad Factu- y por
(N,M). medio
[8] de una relación.
Las cardinalidades se clasifican
etiqueta en: uno a uno, uno a muchos yelmuchos a muchos, cadadeuna
raPara representar una
y Producto, se entiende N, que
M es necesario
una definirincluye
factura máximocomoy mínimo
mínimo la
un
de estas cardinalidades poseen las etiquetas de (1,1), (1,N) y (N,M). [8]
cardinalidad. En este caso tenemos la entidad Factura y Producto, se entiende que una
producto y
Para representar como máximo
una mínimo
etiquetaunN,varios productos;
M es necesario así mismo
definirvarios
el máximo un producto
y mínimo lano
de un
factura incluye como producto y como máximo productos; así mismo
podrá
producto estar
cardinalidad. eneste
En
no podrá ninguna
caso
estar factura
tenemos
en ninguna o opertenecer
la entidad
factura pertenecer aProducto,
Facturaaymuchasmuchas se facturas.
facturas.entiende que una
factura incluye como mínimo un producto y como máximo varios productos; así mismo un
producto no podrá estar en ninguna factura o pertenecer a muchas facturas.
Figura. 19: Representación de cardinalidades en una relación binaria N:M.
En una relación reflexiva, decimos que muchos trabajadores tienen un solo jefe o no, y que
En una relaciónFigura. reflexiva, decimos
19: Representación que muchos
de cardinalidades trabajadores
en una relación binaria N:M. tienen un
un trabajador puede o no ser jefe de un trabajador.
solo jeferelación
En una o no, reflexiva,
y que un trabajador
decimos que muchos puede o no ser
trabajadores jefe
tienen un de
soloun
jefetrabajador.
o no, y que
un trabajador puede o no ser jefe de un trabajador.
Figura. 20: Representación de cardinalidades en una relación reflexiva N:M
Las relaciones ternarias o también conocidas como relaciones con grado mayor que 2,
Figura. 20: Representación de cardinalidades en una relación reflexiva N:M
representan la cardinalidad de manera diferente. En este caso tenemos la entidad: Curso,
Las relaciones
Aula y Alumnoternarias o también
las relaciones serían conocidas como relaciones con grado mayor que 2,
las siguientes:
representan la cardinalidad
§ Un Curso puede tenerdecomo
manera diferente.
mínimo En este caso
una impartición tenemos la entidad: Curso,
o varias.
Aula Alumno
§ y Un Aula las relaciones
puede albergarserían
variaslas siguientes: o una.
imparticiones
UnaCurso
§§ Un puede puede
impartición tener como mínimo
tener un unaalumnos.
o varios impartición o varias.
§ Un Aula puede albergar varias imparticiones o una.
§ Una impartición puede tener un o varios alumnos.
Las relaciones ternarias o también conocidas como relaciones con gra-

do mayor que 2, representan la cardinalidad de manera diferente. En
este caso tenemos la entidad: Curso, Aula y Alumno las relaciones se-
rían las siguientes:
• Un Curso puede tener como mínimo una impartición o varias.
• Un Aula puede albergar varias imparticiones o una.
• Una imparticiónFUNDAMENTOS
puede tener un DE DE DATOS 2015
BASEalumnos.
o varios

CURSO FUNDAMENTOS DE BASE DE DATOS

ALUMNO
2015

n n
AULA
Figura. 21: Representación de cardinalidades en una relación ternaria
2.3.2. Entidades
2.3.2. Entidades fuertes
fuertes y frágiles
y frágiles
Existen dos
Existen dostipos de
tipos entidades
de y estas
entidades
Figura. 21: Representación de son:
y estas son:
cardinalidades en una relación ternaria
• Entidades fuertes:
• Entidades fuertes: Se representa Se representa con uncon rectángulo dentro del dentro
un rectángulo cual se coloca el
del cual
nombre de la entidad. También conocida como entidad regular la cual es posible
2.3.2.se colocafuertes
Entidades el nombre de la entidad. También conocida como entidad
y frágiles
identificarla unívocamente por cada uno de sus atributos.
Existen dos
regular tipos de entidades
la cual y estas
es posible son:
• Entidades frágiles: Este tipoidentificarla unívocamente
de entidad se caracteriza por no serporidentificada
cada uno
• deEntidades
sus fuertes:
atributos. Se representa con un rectángulo dentro del cual se coloca el
unívocamente por sus atributos y que no puede existir sin ser parte de una relación.
nombre de la entidad. También conocida como entidad regular la cual es posible
• EntidadesSe la representa gráficamente
frágiles: Este tipomediante un doble rectángulo
de entidad y dentro depor
se caracteriza él nombre
no ser
identificarla unívocamente por cada uno de sus atributos.
de la entidad. [10]
• identificada unívocamente
Entidades frágiles: Este tipo depor susseatributos
entidad caracteriza yporque no no
ser puede existir
identificada
sin ser partepordesusuna
unívocamente relación.
atributos y que noSepuedela existir
representa gráficamente
sin ser parte de una relación.me-
Se la representa
diante un doble gráficamente
rectángulo mediante un doble
y dentro de rectángulo
él nombre y dentro
de ladeentidad.
él nombre[10]
1
de la entidad. [10]
Figura. 22: Representación gráfica de una entidad frágil.
De igual manera podemos encontrar tipos de relaciones dependiendo de las entidades que
[PRÉSTAMO
se asocien, tenemos a las relaciones habituales y frágiles.
• Relaciones Figura.
habituales:
22: Representación gráficaentidades
Relaciones entre habituales.
de una entidad frágil.
• Relaciones frágiles: Relaciones entre entidades frágiles y habituales. Se
De igual manera podemos encontrar tipos de relaciones dependiendo de las entidades que
De igual subdividen
manera en:podemos encontrar tipos de relaciones dependiendo
se asocien, tenemos a las relaciones habituales y frágiles.
ü Dependencia
de •lasRelaciones
entidades en identificar:
que seRelaciones
asocien, Se da cuando
tenemos lassolo es posible habituales
identificar las y
habituales: entre entidadesa habituales.
relaciones
ocurrencias de entidades frágiles con el atributo identificador principal de
frágiles.
• Relaciones frágiles: Relaciones entre entidades frágiles y habituales. Se
una entidad habitual. Ejemplo: Préstamo – Pago, la entidad Pago es una
subdividen en:
entidad habitual y no permitirá realizar un pago sino se cuenta con el
ü Dependencia en identificar: Se da cuando solo es posible identificar las
identificador principal de la entidad Préstamo.
ocurrencias de entidades frágiles con el atributo identificador principal de
una entidad habitual. Ejemplo: Préstamo – Pago, la entidad Pago es una
entidad habitual y no permitirá realizar un pago sino se cuenta con el
identificador principal de la entidad Préstamo.
• Relaciones habituales: Relaciones entre entidades habituales.

• Relaciones frágiles: Relaciones entre entidades frágiles y habitua-
les. Se subdividen en:
• Dependencia en identificar: Se da cuando solo es posible
identificar las ocurrencias de entidades frágiles con el atribu-
to identificador principal de una entidad habitual. Ejemplo:
Préstamo – Pago, la entidad Pago es una entidad habitual y no
permitirá realizar un pago sino se cuenta con el identificador
principal de la entidad Préstamo.

PRÉSTAMO
PAGO
Figura. 23: Dependencia en identificación.

• Dependencia en existencia:
ü Dependencia en existencia: Se
Figura. da
Se23:da cuando
Dependencia
cuando existe una
en identificación
existe una asociación
. asociación
entre una
entidad
entre unaü entidadfuerte
Dependencia y
fuerteuna entidad frágil,
y una entidad
en existencia: de tal manera
frágil,existe
Se da cuando que
de tal un
unamaneraregistro
asociaciónque de laun
entre una
entidad
registro de la frágil
entidad no exista
fuerte frágil
entidad sin
y una entidadun
no existaregistro
frágil,sinde
de un la entidad
tal manera
registro fuerte
quede del
un la cual
registro es
entidadde la
dependiente.
entidad Ejemplo: Cliente –un Préstamo, dedecimos un fuerte
clientedelpuede
fuerte del cual es frágil no exista
dependiente. sinEjemplo:
registroCliente la entidad
– Préstamo, cual es
deci-
poseer o no un préstamo,
dependiente. Ejemplo:y varios
Cliente préstamos
– Préstamo,puedendecimos
pertenecer una un cliente.
cliente puede
mos un cliente
Si un puede
cliente noun poseer
existe, o no los
tampoco un préstamo, y varios préstamos
poseer o no préstamo, y variospréstamos
préstamosdebidopuedenapertenecer
la dependencia un
a un cliente.
pueden pertenecer
préstamo soloaesun
Si un cliente cliente.
generado
no existe, por Siun un
tampoco loscliente
cliente. Dentro
préstamos node existe, a latampoco
la relación
debido se colocó
dependencia losun
una E
préstamos debido que representa
préstamo asolo la es la existencia.
dependencia
generado por unun préstamo
cliente. Dentro de solo es generado
la relación se colocó
una EDentro
por un cliente. que representa
de la la existencia.se colocó una E que representa
relación
la existencia.
CLIENTE
PRÉSTAMO
Figura. 24: Dependencia en existencia
Figura. 24: Dependencia en existencia
Atributos en relaciones
2.3.3.
Un 2.3.3.
atributo puede serenparte
Atributos tanto de una entidad como de una relación. Su representación
relaciones
es igual a la representación
Un atributo puede ser parte de tanto
los atributos de las entidades,
de una entidad como de una cada relaciónSupuede
relación. tener
representación
atributos
es igualasociados. Por ejemplo,deenlos
a la representación el caso que se
atributos de desee la cantidad
las entidades, de productos
cada de unatener
relación puede
factura de unasociados.
atributos cliente, el Por
atributo cantidad
ejemplo, de laque
en el caso factura debería
se desee colocarse
la cantidad de en la relación
productos de una
2.3.3. Atributos en relaciones

Un atributo puede ser parte tanto de una entidad como de una rela-
ción. Su representación es igual a la representación de los atributos
de las entidades, cada relación puede tener atributos asociados. Por
ejemplo, en el caso que se desee la cantidad de productos de una fac-
tura de un cliente, el atributo cantidad de la factura debería colocarse
en la relación “agrupa”.

__
PRODUCTO
~
/~
~
Figura. 25: Relación N:M con atributo.

Figura. 25: Relación N:M con atributo.
Se
Se puede fijar
puede fijar atributos
atributos a relaciones
a relaciones 1,1 o 1,N, a1,1 o 1,N,dea las
cualquiera cualquiera
entidades quedeselas en-

encuentren asociadas. En la relación “tiene”, la entidad Curso
tidades que se encuentren asociadas. En la relación “tiene”, la el y Alumno se agregará entidad
Se puede
atributo fijar atributos
dirigente a relaciones
en la relación “tiene”,1,1 o 1,N,
ya que cadaacurso
cualquiera de las entidades
tiene designado que se
un dirigente.
Curso y Alumno se agregará el atributo dirigente en la relación “tiene”,
encuentren asociadas. En la relación “tiene”, la entidad Curso y Alumno se agregará el
[8]
ya que dirigente
atributo cada curso tiene designado
en la relación “tiene”, ya que uncada
dirigente.
curso tiene[8]
designado un dirigente.
[8]
Dirigente
Figura. 26: Relación 1:1 con atributo

Nombre
ALUMNO

Figura. 26: Relación 1:1 con atributo
2.3.4. Herencia
ciertos casos hemos encontrado entidades parecidas, es por esta razón que la herencia
En
es un tipo de asociación entre una entidad padre y una entidad hijo. La entidad hijo hereda
2.3.4. Herencia
2.3.4. Herencia
todos los atributos de la entidad padre, omitiendo la representación de una de ellas.
En ciertos casos hemos encontrado entidades parecidas, es por esta razón que la herencia
En ciertos casos
Se representan mediantehemos encontrado
un triángulo inverso que seentidades parecidas,
conecta con las es por esta
entidades mediante
una
razón línea. En el siguiente ejemplo se muestre la herencia de las entidades Estudiante,
todos losque la herencia
atributos espadre,
de la entidad un tipo de asociación
omitiendo entre
la representación una
de una de entidad
ellas. padre
Docente, Representante y Usuario a una Entidad Persona.
ySeuna entidad
representan hijo. un
mediante Latriángulo
entidad hijo que
inverso hereda todos
se conecta conlos
las atributos de la en-
entidades mediante
una línea.
tidad En el omitiendo
padre, siguiente ejemplo se muestre la herencia
la representación de unade lasde ellas. Estudiante,
entidades
Se representan mediante un triángulo inverso que se conecta con las
entidades mediante una línea. En el siguiente ejemplo se muestre la
herencia de las entidades Estudiante, Docente, Representante y Usua-
rio a una Entidad Persona.
Figura. 27: Representación de Herencia
Las generalizaciones podrán ser de varios tipos:

todos los atributos de la entidad padre, omitiendo la representación de una de ellas.
Se representan mediante un triángulo inverso que se conecta con las entidades mediante
una línea. En el siguiente ejemplo se muestre la herencia de las entidades Estudiante,
EMPLEADO
ESTUDIANTE DOCENTE REPRESENTANTE USUARIO
1 1 1
doc_codigo
~ ~ ~
Las generalizaciones podrán ser de varios tipos:

Generalización
Las generalizaciones integral:
podrán ser deSe da cuando
varios tipos: no existen ocurrencias que no
pertenezcan a ninguna de las entidades que heredan.
Generalización Parcial: Se da cuando si existen ocurrencias que no

pertenezcan a ninguna de las entidades que heredan
Generalización integral: Se da cuando no existen ocurrencias que no pertenezcan a
Generalización Exclusiva: Se da cuando una entidad que hereda con-
ninguna de las entidades que heredan.
sigue ser parteParcial:
de una entidad
36
Generalización Se da cuando sisupertipo (tipoque
existen ocurrencias genérico que apuede
no pertenezcan ninguna di-
vidirse
de las en subtipos,
entidades contiene atributos comunes), su representación se
que heredan
Generalización
realiza mediante Exclusiva:
un arcoSe da cuando
que una entidad
contiene lasque hereda de
líneas consigue ser parte de
asociación una las
con
entidad supertipo (tipo genérico que puede dividirse en subtipos, contiene atributos
demás entidades.
comunes), su representación se realiza mediante un arco que contiene las líneas de
Si la entidad
asociación Empleado
con las demás entidades. formara parte de una de sus entidades
subtipos (entidad
Si la entidad Empleadocuyas instancias
formara parte de unaheredan algunos
de sus entidades atributos
subtipos (entidad de una
cuyas
instancias heredan algunos atributos de una entidad supertipo), se
entidad supertipo), se señalaría este suceso con un arco [11]. Se repre- señalaría este suceso con
un arco [11]. Se representaría de la siguiente manera:
sentaría de la siguiente manera:
ESTUDIANTE DOCENTE REPRESENTANTE USUARIO
1 1 1 1
~ ~ ~ ~
Figura. 28: Jerarquía de tipos subtipos total y exclusiva
2.3.5. Agregación
El modelo entidad – relación no permite crear relaciones entre relaciones, es decir no admite crear
relación entre relación y entidad, es por esta razón que recibe el concepto de agregación.
La agregación permite crear a partir de más de dos entidades y una relación que las asocia entre sí,
3.5. Agregación
El modelo entidad – relación no permite crear relaciones entre relacio-
nes, es decir no admite crear relación entre relación y entidad, es por
esta razón que recibe el concepto de agregación.
La agregación permite crear a partir de más de dos entidades y una
relación que las asocia entre sí, una entidad de nivel mucho más alto.
Logrando a partir de objetos elementos, crear objetos compuestos. [12]
Un ejemplo de relación N,M tenemos las entidades Estudiante,
Curso y Acta de Notas, las cuales muestran que algunos estudiantes
se han matriculado en un curso y muestra en qué fecha y en qué esta-
do se encuentra la matrícula. Para relacionar las entidades Estudiante
y Curso se instaura la relación se matricula y la relación se registra que
asociará a la entidad Acta de Notas.
Una manera de representar este diagrama es envolviendo en un
rectángulo las entidades y relaciones que deseamos asociar (Estudian-
te, Curso, se matricula) FUNDAMENTOS
a través de una DE BASE
nueva que la2015
DE DATOS
relación llamare-
mos matrícula.
Matricula
l:M O:N
ESTUDIANTE CURSO
ACTA DE NOTAS
Figura. 29: Representación de agregación.

2.4.
2.4.Diseño lógico
Diseño lógico a partir
a partir de diagramas
de diagramas entidad - relación
entidad - relación
Para diseñar un esquema lógico relacional de una base de datos se mostrarán algunas de las
formas
Para posibles.un
diseñar Puntualmente
esquemase lógico
estudiará relacional
la forma de transformar
de una elbase
modelodeEntidad
datos– se
Relación a un modelo relacional. Lo primero en analizar serán las reglas dadas para
mostrarán algunas de las formas posibles. Puntualmente se estudiará
convertir el modelo Entidad – Relación en un modelo relacional.
la forma
El modelodeejemplo
transformar el modelo
de Entidad Relación será elEntidad
siguiente: – Relación a un modelo re-
lacional. Lo primero en analizar serán las reglas dadas para convertir
el modelo Entidad – Relación en un modelo relacional.
El modelo ejemplo de Entidad Relación será el siguiente:
2.4. Diseño lógico a partir de diagramas entidad - relación
Para diseñar un esquema lógico relacional de una base de datos se mostrarán algunas de las
formas posibles. Puntualmente se estudiará la forma de transformar el modelo Entidad –
Relación a un modelo relacional. Lo primero en analizar serán las reglas dadas para
Descripción
convertir y aplicación
el modelo del–modelo
Entidad entidad-relación
Relación en un modelopara el modelado de datos
relacional. 55
El modelo ejemplo de Entidad Relación será el siguiente:
Figura. 30:
2.4.1. Reglas concernientes alEsquema
modelo ejemplo de ER
entidad - relación básico
2.4.1.1. Transformación de entidades
Para transformar una entidad del modelo entidad – relación al modelo
relacional, cada una de las entidades pasarán como relaciones al mo-
delo relacional. 38

2.4.1.2. Transformación de atributos

Al transformar las entidades del modelo entidad - relación al modelo
relacional pasan como relación, y los atributos de estas entidades pa-
sarán como atributos de la relación en el esquema relacional. Los atri-
butos identificadores principales pasarán como la clave principal de la
relación. En la mayoría de sistemas gestores de base de datos ya no es
prescindible detallar los atributos con la restricción Not Null debido a
que las claves principales nunca tomarán un valor nulo. [13]
En el ejemplo de modelo entidad - relación dado anteriormente las re-
laciones y sus atributos quedarían de la siguiente manera:
Cliente CI (Cédula de Identidad), nombre, dirección, teléfono.
Z Z
Venta ID (Identificación), fecha precio_total, detalle.

Producto ID (Identificación), descripción, precio_venta, stock.
Z
Para los atributos identificadores alternativos si es prescindible la res-

tricción Not Null, ya que cada uno de esos atributos serán necesarios
al momento de insertarlos.
como relación, y los atributos de estas entidades pasarán como atributos de la relación en el
esquema relacional. Los atributos identificadores principales pasarán como la clave
principal de la relación. En la mayoría de sistemas gestores de base de datos ya no es
prescindible detallar los atributos con la restricción Not Null debido a que las claves
56 principales Zeanunca tomarán
M, Honores un valor
J, Rivas W nulo. [13]
En el ejemplo de modelo entidad - relación dado anteriormente las relaciones y sus
2.4.1.3. Transformación
atributos de interrelaciones
quedarían de la siguiente manera: binarias y reflexivas
Cliente à CI (Cédula de Identidad), nombre,
Para transformar las interrelaciones binarias y reflexivas dirección, teléfono.
al modelo re-
Venta à ID (Identificación), fecha precio_total, detalle.
lacional, es necesario conocer el grado y la conectividad, para que así
Producto àID (Identificación), descripción, precio_venta, stock.
su transformación sea la más adecuada.
Para los atributos identificadores alternativos si es prescindible la restricción Not Null, ya
Interrelaciones NM
que cada uno de esos atributos serán necesarios al momento de insertarlos.
Toda interrelación
2.4.1.3. TransformaciónN, Mdeseinterrelaciones
transformabinariasen una relación, la misma que
y reflexivas
posee
Paracomo claves
transformar lassecundarias a caday una
interrelaciones binarias de las
reflexivas clavesrelacional,
al modelo principales de
es necesario
las conocer
entidades el grado y la conectividad, paraLa
interrelacionadas. quenueva
así su transformación
relación tendrá sea la más
comoadecuada.
clave
Interrelaciones
principal NM
a la agrupación de las claves secundarias, los atributos de la
Toda interrelación N, M se transforma en una relación, la misma que posee como claves
entidad pasarán a la nueva relación.
secundarias a cada una de las claves principales de las entidades interrelacionadas. La
Considerando el ejemplo del modelo entidad – relación de la figura
nueva relación tendrá como clave principal a la agrupación de las claves secundarias, los
30 con la asociación
atributos entre alas
de la entidad pasarán entidades
la nueva relación. Producto y Venta, se creará
unaConsiderando
nueva tabla que tendrá
el ejemplo del modelocomo atributos
entidad – relaciónlasde claves
la figuraprincipales de
30 con la asociación
cadaentre las entidades
tabla asociada Producto y Venta, se creará
y los atributos de launa nueva tabla
relación queque tendrá como
serían atributos
cantidad
las claves principales de cada tabla asociada y los atributos de la relación que serían
y precio.
cantidad y precio.
Venta ID, fecha precio_total, detalle
Z
Venta à ID, fecha precio_total, detalle Producto àID, descripción, precio_venta,

Producto ID, descripción, precio_venta, stock
stock
Z
Detalle_venta à Id_venta, Id_producto, cantidad, precio
En En
el el
caso
casodede una relación
una relación reflexiva,
reflexiva, demanera
de igual igualsemanera
creará unasenueva
creará
tablauna
con las
nueva tabla con las claves principales de cada entidad asociada. Enque
claves principales de cada entidad asociada. En el siguiente ejemplo se muestra el un
menú puede dividirse en algunos submenús y dicho submenú puede constar en varios
siguiente ejemplo se muestra
menús. [14]
FUNDAMENTOS
que un menú DEpuede
BASE dividirse
DE DATOS 2015
en algunos
submenús y dicho submenú puede constar en varios menús. [14]

--------. l:M
39
MENÚ
Figura. 31: Esquema ER con relación reflexiva N:M

La
La nueva tabla
nueva tabla creada
creada constará constará de claves
de claves secundarias secundarias
Cod_Menu, Cod_Menu, Cod_
Cod_Submenu.
Menú à
Submenu. Cod_Menu, Contenido
Menú Cod_Menu, Contenido
Z
Contiene à Cod_Menu, Cod_SubMenu)
Interrelaciones 1: N
Las entidades que forman parte de una interrelación 1, N se transforman en relaciones cada


Descripción y aplicación
La nueva tabla del modelo
creada constará entidad-relación
de claves para el modelado
secundarias Cod_Menu, de datos
Cod_Submenu. 57
Menú à Cod_Menu, Contenido

Contiene à Cod_Menu, Cod_SubMenu)

Interrelaciones
Interrelaciones
La nueva 1:
1:NN de claves secundarias Cod_Menu, Cod_Submenu.
tabla creada constará
Las entidades
Menúentidades
Las à Cod_Menu, que
que forman
Contenido
forman parteparte
de unade interrelación 1, N se transforman
una interrelación 1, N seen transfor-
relaciones cada
una con sus correspondientes atributos.
man en relaciones cada una con sus correspondientes atributos.
Para este tipo de interrelación es necesario solamente colocar del lado de la relación que
Para este tipo de interrelación es necesario solamente colocar del lado
corresponde a N, la clave secundaria que haga referencia a la otra relación.
de la Si relación queContiene
la cardinalidad escorresponde a N,la
Cod_Menu,
de 1,1,àcolocaremos laclave
clave
Cod_SubMenu) secundaria
secundaria que haga
con la restricción Notrefe-
Null, ya
rencia a laatributo
que este otra relación.
será necesario al momento de su inserción.
Interrelaciones
Si 1: N es 0,1, indica que los atributos de la clave secundaria si pueden recibir un
Silalacardinalidad
cardinalidad es de 1,1, colocaremos la clave secundaria con
Las valor
entidades que
nulo. [13]forman
[14] parte de una interrelación 1, N se transforman en relaciones cada
la restricción Not Null, ya que este atributo será necesario al momento
una Como
con susejemplo
correspondientes
nos guiamos atributos.
del modelo entidad – relación de la figura 30, en donde se
de
Parasu inserción.
establecerá un vínculo entreeslas
este tipo de interrelación necesario
entidadessolamente
Venta y colocar
Cliente,del
en lado de la relación
la relación Venta iráque
como
Si la cardinalidad
corresponde es secundaria
a N, la clave 0,1, indica queque
haga los atributos
referencia derelación.
la clave secundaria
clave secundaria el atributo CI. Este atributo tomaráa la
la restricción
otra Not Null, ya que toda
Si pueden
si laventa
cardinalidad es deun
recibir
se la realiza a 1,1, colocaremos
unvalor
cliente.nulo. la clave
[13] secundaria con la restricción Not Null, ya
[14]
que este atributo será necesario al
Como ejemplo nos guiamos del modelo momento de su inserción.
entidad – relación de la fi-
Si laCliente
cardinalidad
à CI, es 0,1,
nombre, indica que los atributos de la clave secundaria si pueden recibir un
gura 30, en donde sedirección, ciudad un vínculo
establecerá entre las entidades Venta
valor nulo. [13] [14]
y Cliente, en la relación Venta irá como clave secundaria el atributo CI.
Como ejemplo nos guiamos del modelo entidad – relación de la figura 30, en donde se
Este atributo
establecerá tomará
un vínculo entrelalasrestricción
entidades Venta Not Null, ya
y Cliente, que
en la todaVenta
relación ventairá se la
como
realiza a un cliente.
clave secundaria el atributo CI. Este atributo tomará la restricción Not Null, ya que toda
Venta à ID, fecha precio_total, detalle, Ci_cli Producto àID, descripción, precio_venta, stock
venta se la realiza
Cliente a un cliente.dirección, ciudad
CI, nombre,
Z
Cliente à CI, nombre, dirección, ciudad
Detalle_venta à Id_venta, Id_producto, cantidad, precio
Si encontramos un caso de interrelación en donde esta posea atributos propios, estos

Venta à ID, fecha precio_total, detalle, Ci_cli Producto àID, descripción, precio_venta, stock
atributos podrán ser colocados en otra entidad además de la clave secundaria.
Detalle_venta à Id_venta, Id_producto, cantidad, precio 40

Si encontramos
Si encontramos un uncasocaso
de interrelación en dondeenesta
de interrelación poseaesta
donde atributos
poseapropios, estos
atributos
atributos podrán ser colocados en otra entidad además de la clave secundaria.
propios, estos atributos podrán ser colocados en otra entidad además
de la clave secundaria.
A estos casos de interrelación también es posible aplicar el mismo
40
proceso
de una interrelación N, M, en la cual se crearía una nueva
tabla con las claves secundarias y los atributos propios de la relación;
pero solo bajo las siguientes condiciones:

• Si la cardinalidadFUNDAMENTOS 0,1, la clave DE
esFUNDAMENTOS BASE
DE BASE
secundaria DE DATOS
DE DATOS
tomará 2015
valor 2015
nulo.
• Si se desea conservar la semántica de la interrelación con sus atri-
A estos butos casos propios.
de interrelación también es posible aplicar el mismo proceso de una
A estos casos de interrelación también es posible aplicar el mismo proceso de una
interrelación
• interrelación N, M, en la cual se crearía una
Si la interrelación nueva tabla con lasen claves secundarias y los
N, M, en la cualpueda transformarse
se crearía una nueva tabla con una
las correspondencia
claves secundarias y los
atributos propios de la relación; pero solo bajo las siguientes condiciones:
atributosN:M.propios
[13] de la relación; pero solo bajo las siguientes condiciones:
§ Si la cardinalidad es 0,1, la clave secundaria tomará valor nulo.
En §el Siseladesea
siguiente
§ Si cardinalidad
modelo
conservaresla0,1, la clave
entidad-
semántica de secundaria
larelación tomará
como
interrelación valor
mejor
con sus nulo.
opción
atributos propios. resultaría
conservar §§ SiSilaseinterrelación
desea
la conservar
semántica la semánticadel
pueda transformarse
original de la interrelación
en una conN:M.
correspondencia
modelo y guardar sus el
atributos
[13] propios.
atributo propio
En §
el Si la
siguiente interrelación
modelo pueda
entidad- transformarse
relación
de la relación entre las entidades Comerciante y Pedido. como en una
mejor correspondencia
opción resultaría N:M. [13]
conservar la
En el siguiente
semántica modelo
original del modeloentidad-
y guardarrelación
el atributocomo
propiomejor opciónentre
de la relación resultaría conservar la
las entidades
Comerciante y Pedido.
semántica original del modelo y guardar el atributo propio de la relación entre las entidades
___
Comerciante y Pedido.
~ ~
/~
~ COMERCIANTE PEDIDO ~
Figura. 32: Esquema ER con relación 1:N.

En una relación reflexiva, Figura. el
32:método
Esquema ERmás común
con relación 1:N. es el primero, lo que
En una relación reflexiva, el método más común es el primero, lo que generaría una
generaría
una relación correspondiente a la misma entidad, con clave
relación correspondiente a la misma entidad, con clave secundaria que haga relación con la
secundaria
clave principal que
de hagaentidad.
lareflexiva,
misma relación con la clave principal de la misma enti-
En una relación el método más común es el primero, lo que generaría una
dad.
En el siguiente ejemplo se muestra que todo estudiante tiene un delegado y que un
relación correspondiente a la misma entidad, con clave secundaria que haga relación con la
estudiante
En es delegado
el siguiente de 0,ejemplo
1 o varios estudiantes.
clave principal de la misma entidad. se muestra que todo estudiante tiene un
En el siguiente
delegado y queejemplo se muestra es
un estudiante quedelegado
todo estudiante
de 0, tiene un delegado
1 o varios y que un
estudiantes.
estudiante es delegado de 0, 1 o varios estudiantes.
O:M
ESTUDIANTE
Figura. 33: Esquema ER con relación 1:N
Figura. 33: Esquema ER con relación 1:N

Estudiante (Num_Mat, nombre, Num_Mat_Del)
Interrelaciones 1:1
Este tipo de interrelaciones pasan del modelo entidad – relación al modelo relacional con la
transformación de sus entidades
Estudiante (Num_Mat, nombre,enNum_Mat_Del)
relaciones y con sus atributos correspondientes.
Interrelaciones 1:1
Este tipo de interrelaciones pasan del modelo entidad – relación al modelo relacional con la
41
transformación de sus entidades en relaciones y con sus atributos correspondientes.
41
Interrelaciones 1:1
Este tipo de interrelaciones pasan del modelo entidad – relación al mo-
delo relacional con la transformación de sus entidades en relaciones y
con sus atributos correspondientes.
FUNDAMENTOS
Para representar esta interrelación DE BASE
solo bastaría DE DATOS
añadir 2015
en cualquiera
de
las dos relaciones una clave secundaria que haga referencia a la otra
relación. [14] esta interrelación solo bastaría añadir en cualquiera de las dos relaciones
Para representar
Para la transformación
una clave secundaria que hagadereferencia
esta interrelación hay
a la otra relación. dos opciones:
[14]
Para la transformación de esta interrelación hay dos opciones:
Primera
Primera
Delegación Nombre_del, nombre_ciu
Z
Delegación à Nombre_del, nombre_ciu

Ciudad Nombre_ciu
Ciudad à Nombre_ciu
Z
Segunda
Segunda
Delegación à Nombre_del
Delegación Nombre_del
Z
Ciudad à Nombre_ciu, Nombre_del

Ciudad Nombre_ciu, Nombre_del
Z
DELEGACIÓN
CIUDAD
Figura. 34: Esquema ER con relación 1:1.
Delegación à Nombre_del, Nombre_ciu
Ciudad à Nombre_ciu
2.4.1.3. Transformación de interrelaciones de grado superior
de interrelaciones a 2 superior a 2
de grado
Una relación ternaria genera la creación de una nueva tabla que contiene los atributos
Una relación ternaria genera la creación de una nueva tabla que contie-
propios de la relación, juntos con las claves principales de las tablas que se encuentran
ne los atributos
relacionadas. propios
La nueva tablade la relación,
creada juntos
tendrá como clavecon las claves
principal principales
la vinculación de las
de las tablas que se encuentran relacionadas. La nueva
claves secundarias de las entidades que forman parte de la relación. tabla creada
tendrá
Tenemoscomo clavemodelo
el siguiente principal la vinculación
entidad de las una
– relación que muestra claves secundarias
interrelación ternariade
.
las entidades que forman parte de la relación.
Tenemos el siguiente modelo entidad – relación que muestra una
interrelación ternaria.

ESTUDIANTE
SEMESTRE

ASIGNATURA
Figura. 35: Esquema ER con relación ternaria M:N:P
Cada unaCadadeuna
lasde
entidades deldelmodelo
las entidades modelo entidad - relación
entidad - relación se transforma-
se transformará en tablas y se
crearáy una
rá en tablas nueva tabla
se creará unacon las tres
nueva claves
tabla consecundarias que referencian
las tres claves a las claves
secundarias
principales adelas
que referencian lasclaves
entidades asociadas, en
principales delalas
cual con la vinculación
entidades de las
asociadas, enclaves
secundarias se tendrá la clave principal de la nueva tabla creada. [15]
la cual con la vinculación de las claves secundarias se tendrá la clave
principal2.4.2.
de la nueva
Reglas tabla creada.
concernientes al modelo[15]
entidad – relación extendido
2.4.2.1. Transformación de dependencias en existencia y en identificación
Figura. 35: Esquema ER con relación ternaria M:N:P
En primer
2.4.2. Reglas lugar, tenemos la dependencia
concernientes al modelo en entidad
existencia que son relaciones
– relación con cardinalidad
extendido
Cada 1,
2.4.2.1. unaN,deeslas
decir que la del
entidades
Transformación entidad
modelo
de queentidad
posee -larelación
dependencias cardinalidad
en N, es una en
se existencia
transformará entidad
en débil.
ytablas y se Lo que
iden-
crearáindica
una nueva
que notabla
podráconhaberlas registros
tres claves
si nosecundarias que referencian
existen registros a las
en la entidad clavesde la cual
regular
tificación
principales de las entidades asociadas, en la cual con la vinculación de las claves
depende.
En primer Así lugar,
secundarias se tendrá
mismo tenemos la dependencia
la clavelaprincipal
tenemos de la nueva
dependencia tabla en existencia
creada.
en identificación [15] quemanera
que de igual son re- como la
lacionesdependencia
con cardinalidad
en existencia son relaciones con cardinalidad 1, N, pero la diferencialaes que
1, N, es decir que la entidad que posee
2.4.2.para
cardinalidadReglas concernientes
poder
N, esidentificar al
cada
una entidad modelo entidad
registro
débil. la–entidad
de Lo relación extendido
frágil
que indica esque
necesario el AIP haber
no podrá de la entidad
frágil y de la entidaddefuerte.
dependencias
[16] en existencia y en identificación
registros si no
En primer lugar,existen registros en la entidad regular de la cual depen-
Tenemos eltenemos
siguientela esquema
dependencia ER:en existencia que son relaciones con cardinalidad
de. 1, N, es decir que la entidad que posee la cardinalidad N, es una entidad débil. Lo que
indicamismo
Así que no podrá
tenemoshaber registros si no existen registros
la dependencia en la entidad regular
en identificación quededela cual
igual
depende.
manera como la dependencia en existencia son relaciones con cardina-
Así mismo tenemos la dependencia en identificación que de igual manera como la
lidaddependencia
1, N, pero la diferencia
en existencia es quecon
son relaciones para poder 1,identificar
cardinalidad cada registro
N, pero la diferencia es que
de lapara
entidad
poder identificar cada registro de la entidad frágil es necesario el AIPydede
frágil es necesario el AIP de la entidad frágil la enti-
la entidad
dad frágil y de [16]
fuerte. la entidad fuerte. [16]
Tenemos el siguiente esquema ER:
Tenemos el siguiente esquema ER:
CLIENTE
Figura. 36: Esquema ER con una dependencia en existencia
El esquema relacional es el que se presenta a continuación:

Cliente (CI, Nombre, Dirección)
Préstamo (Num_pres, CI_cliente)
PRÉSTAMO
Figura. 36: Esquema ER con una dependencia en existencia

43


2.4.2.2. Transformación de jerarquías de tipos y subtipos

Existen varias soluciones para la transformación de un modelo entidad
- relación con entidades tipo y subtipos, entre las cuales tenemos:
• Agrupar los atributos de la entidad tipo y sus subtipos en una úni-
ca relación. Las condiciones para esta solución son:
1. Subtipos se diferencian entre sí en pocos atributos.
2. Las interrelaciones que las vinculen sean las mismas para cada
subtipo.
3. La jerarquía es total o casi total.
4. Prestaciones, mejor opción en cuanto a mayor velocidad en el
acceso a los datos de un objeto.
• La segunda opción sería crear una relación para el supertipo y otra
relación que agrupe todos los subtipos. Con esto es posible crear
una única relación que abarque todos los atributos de las entida-
des subtipo y siendo la clave principal la misma de la entidad su-
pertipo. Si tenemos una jerarquía que no es total, debemos dividir
al menos en dos tablas la entidad supertipo y los subtipos. Si no
se realiza dicha división tendremos problemas con valores nulos. Si
deseamos mantener la semántica esta solución no es muy factible.
• La tercera opción será crear una relación para un supertipo y una
relación para cada subtipo. Esta solución es la más adecuada
cuando ninguno de los parámetros de la primera opción se cumple.
Esta solución permite mantener la originalidad de la semántica.
Para recuperar datos se deben crear varias tablas por lo que ofre-
cen menor velocidad en el acceso a datos en comparación con la
segunda opción.
• La cuarta opción es crear una relación para cada subtipo que con-
tenga tanto atributos propios como atributos comunes. Es muy
adecuada ya que posee casi los mismos términos de la tercera op-
ción, en cuanto acceso a datos suelen afectar a los atributos co-
munes.

CI fecha
TÉCNICO INGENIERO
Figura. 37: Esquema ER con una jerarquía de tipos y subtipos
Opciones de paso al modelo relacional:

Opción A: Empleado (CI, nombre, fecha, dirección, nivel, tipo)
Opción B: Empleado (CI, nombre, fecha, dirección)
Datos Persona (CI, nivel, tipo)
Opción c: Empleado (CI, nombre, fecha, dirección]
Técnico (CI, nivel] Ingeniero (CI, tipo)

Opción D: Técnico (CI, Nombre, nivel)
Ingeniero (CI, Nombre, Tipo)

2.4.2.3. Transformación de agregaciones
Las agregaciones del modelo entidad – relación al modelo relacional, se transforman como
Las agregaciones
entidades. del modelo
En el siguiente entidad
ejemplo tenemos – relación
las entidades al modelo
Estudiante, Cursorelacional,
y Acta de
seNotas,
transforman como
las relaciones entidades.
matrícula y registraEn
haneldado
siguiente ejemplo
lugar a nuevas tenemos
tablas las
que estarán
formadas por
entidades las claves secundarias.
Estudiante, Curso [15]
y Acta de Notas, las relaciones matrícula
y registra han dado lugar a nuevas tablas que estarán formadas por las
claves secundarias. [15]
Estudiante (Cod_est, nombre, dirección] Matricula (Cod_est, fecha, estado)
45

Ingeniero (CI, Nombre, Tipo)
Las agregaciones del modelo entidad – relación al modelo relacional, se transforman como
entidades. En el siguiente ejemplo tenemos las entidades Estudiante, Curso y Acta de
Notas, las relaciones
Descripción matrícula
y aplicación y registra
del modelo han dado
entidad-relación lugar
para datosque estarán63
a nuevasdetablas
el modelado
formadas por las claves secundarias. [15]

Estudiante (Cod_est, nombre, dirección] Matricula (Cod_est, fecha, estado)

45

Registra( Cod_est, CodAct)
Acta de Notas (CodAct)

Curso (Número, descripción)
2.5.Desarrollo
2.5. Desarrollo de diversos supuestossupuestos
de diversos prácticos de modelización
prácticosmediante diagramas
de modelización
Entidad-Relación
mediante diagramas Entidad-Relación
Dentro del planteamiento de ejercicios a resolver del tema, se proponen varias prácticas de
Dentro del planteamiento de ejercicios a resolver del tema, se proponen
modelado de ER. Se ha elaborado una transformación para cada diagrama de la entidad. Se
varias prácticas
encuentran de modelado
varias suposiciones en los de ER. Se
ejercicios ha elaborado una transforma-
propuestos.
ción para cada diagrama de la entidad. Se encuentran varias suposi-
ciones en los ejercicios propuestos.
46

Resumen
• Como elementos básicos del modelo entidad- relación podemos

nombrar a las entidades, dominios, atributos y las relaciones o
interrelaciones.
• Se define como entidad al objeto sobre el cual se desea guardar
información en una base de datos.
• Se entiende por relación a la asociación o vínculo entre dos o más
entidades.
• Un atributo se define como las propiedades o características que
están asociadas a una entidad.
• Un dominio es el valor permitido para cada atributo de una enti-
dad.
• Se define como Cardinalidad al número de veces en que se asocia
una entidad con otra.
• Para transformar una entidad del modelo entidad – relación al mo-
delo relacional, cada una de las entidades pasaran como relaciones
al modelo relacional.
[65]
Análisis del modelo relacional y de
los elementos que lo integran
A continuación, se detalla el objetivo principal de cada contenido del

capítulo 3, Análisis del modelo relacional y de los elementos que lo
integran
El apartado 3.1 tiene por objetivo exponer de forma clara un con-
cepto en lo que se refiere a una base de datos relacional y sus propie-
dades
El objetivo del apartado 3.2 es el de describir las de funciones de las
claves que se ven presentes en un modelo relacional.
El apartado 3.3 tiene como objetivo general, exponer de forma clara las
restricciones que se ven presentes en el diseño de un modelo relacional
de las cuales son consideras dos tipos que son:
• Restricciones Inherentes
• Restricción semántica o de usuario
En el apartado 3.4 se tiene por objetivo el hablar sobre las nociones
del álgebra relacional dando una descripción de la misma y sobre los
distintos operadores que son utilizados:
• Los operadores tradicionales de la teoría de conjuntos
• Los operadores relacionales específicos
El objetivo principal del apartado 3.5 es precisamente el de dar a cono-
cer las nociones de cálculo relacional por filas utilizando la ejemplifica-
ción mediante ejercicios prácticos esenciales.
El objetivo del apartado 3.6 consiste en exponer las nociones de cálculo
relacional de dominio.
El apartado 3.7 tiene como objetivo explicar de forma clara la teoría
[67]
de la normalización y sus objetos, de lo cual se realizará una concep-

tualización de las dependencias funcionales, así como un análisis de
las ventajas e inconvenientes que resultan de la aplicación tanto de la
normalización como de la desnormalización mediante el uso de dife-
rentes supuestos prácticos.
3.1. Concepto de relaciones y sus propiedades

3.1. ConceptoEndeuna base de datos
relaciones y sus relacional,
propiedades los datos son recolectados mediante
relaciones, y estas a su vez son generalmente representadas mediante
En una base de datos relacional, los datos son recolectados mediante relaciones, y estas a
tablas. En las cuales vemos involucrados conceptos de elementos que
su vez son generalmente representadas mediante tablas. En las cuales vemos involucrados
ya han sido mencionados en el capítulo anterior, tales como, tuplas
conceptos de (filas),
elementos que ya
atributos han sido grado
(columnas), mencionados
(número ende el capítulodeanterior,
atributos una rela- tales como,
tuplas (filas),ción),
atributos (columnas),
y cardinalidad grado
(número (número
de filas de unade atributos de una relación), y
relación).
cardinalidad (número de filas
En síntesis, de una
se puede relación).
afirmar que una base de datos relacional es un
conjunto de tablas o relaciones
En síntesis, se puede afirmar que una base de identificadas por nombres
datos relacional únicos en
es un conjunto de tablas o
las cuales las filas representan hechos (tupla) y las columnas represen-
relaciones identificadas por nombres únicos en las cuales las filas representan hechos
tan las propiedades (atributos).
(tupla) y las columnas representan las propiedades (atributos).
En esta sección se va a explicar un concepto de relación, visto des-
En esta secciónde se
unva a explicar
punto unmás
de vista concepto de relación,
matemático vistoSiendo
y flexible. desde un
así punto
que unade vista más
matemático yrelación
flexible.R Siendo
basado así
en unqueconjunto
una relación R basado
determinado de en un conjunto
dominios determinado
(D1, D2,
de dominios (D1, D2, …Dn), es combinada en dos partes que comprenden una ycabecera y
…Dn), es combinada en dos partes que comprenden una cabecera
un cuerpo. un cuerpo.
Cabecera: Comprende un conjunto de n pares de atributo-dominio, en
Cabecera: Comprende un conjunto de n pares de atributo-dominio, en el cual n representa
el cual n representa el grado y A representa los atributos, de tal manera
el grado y Aquerepresenta los atributos, de tal manera que cada atributo A, pertenece
cada atributo A, pertenece únicamente a uno de los dominios D.
únicamente aCuerpo:
uno de los dominiosun
Comprende D.conjunto de m filas de las cuales cada fila re-
Cuerpo: Comprende
presenta aun unconjunto
conjunto dede nmpares
filasatributo-valor:
de las cuales(A1:V1),
cada fila representa
(A2:V2) ..., a un
conjunto de n pares atributo-valor: (A1:V1), (A2:V2) ..., (An: Vn) (i=1...m).
(An: Vn) (i=1...m).
D1 D2 D3 (…) Dn
A1 A2 A3 (…) An
Tabla 1: Definición matemática de relacion
El esquema representativo de una relación es R y su cabecera será la siguiente:

R {(A¡: D¡ )} ¡=1..n
Además, el estado de una relación, se encuentra conformado por el esquema y el cuerpo de
la misma, donde el cuerpo de una relación está comprendido por un conjunto determinado
Análisis del modelo relacional y de los elementos que lo integran 69
El esquema representativo de una relación es R y su cabecera será la

siguiente:
R {(A¡: D¡ )} ¡=1..n
Además, el estado de una relación, se encuentra conformado por el
esquema y el cuerpo de la misma, donde el cuerpo de una relación
está comprendido por un conjunto determinado de filas que en su
momento llegan a satisfacer un adecuado esquema de relación.
Por ejemplo, considerando una relación Artículos, de la cual su ca-
becera cuenta con tres atributos definidos en sus respectivos dominios
de la siguiente manera:
• A1 (codigo_art), establecido sobre el primer dominio D1, el cual
es una cadena con una longitud máxima de cinco caracteres.
• A2 (descrip_art), establecido sobre el segundo dominio D2, el
cual es una cadena con una longitud máxima de cincuenta
caracteres.
• A3 (pvp_art), establecido sobre el tercer dominio D3, el cual es
un número con una longitud máxima de cuatro cifras, donde 2015
las dos últimas son decimales.
Articulos
codigo_art descrip_art pvp_art
A0025 Teclado 8.00
A0026 Mouse Inalámbrico 13.5
A0027 Disco Duro Samsung 85.00
A0028 Impresora Canon 300.50
A0029 Monitor Samsung 375.50
A0030 Portátil HP 800.00
Tabla 2: Relación Artículos

De la relación Artículos, se puede observar que el cuerpo, está deter-
De la relación Artículos,
minado por seissefilas,
puede
de observar
las cualesque
cadael una
cuerpo, estádedeterminado
cuenta tres pares depor seis filas,
de las cuales cada una cuenta
atributo-valor. Tomando de tres
como pares de atributo-valor.
ejemplo Tomando
la primera fila de como
la relación Ar- ejemplo la
ticulos se tiene la siguiente estructura: {(A1:V11), (A2:V12), (A3:V13)},
primera fila de la relación Articulos se tiene la siguiente estructura: {(A1:V11), (A2:V12),
la cual hace referencia a los siguientes datos: {codigo_art: ´A0025´.],
(A3:V13)}, la cual hace referencia a los siguientes datos: {codigo_art: ´A0025´.],
(descrip_art: “Teclado”), (pvp_art:8,00)}
(descrip_art: “Teclado”), (pvp_art:8,00)}
Propiedades de una relación:
• Toda relación está identificada por un nombre que es único dentro de la base de
datos relacional a la que pertenece.
• Es indispensable el valor de un atributo en una relación, además en la intersección
Propiedades de una relación:

• Toda relación está identificada por un nombre que es único
dentro de la base de datos relacional a la que pertenece.
• Es indispensable el valor de un atributo en una relación, ade-
más en la intersección de una fila y una columna se encuentra
un solo valor.
• En una tabla los atributos tienen, y deben llevar nombres di-
ferentes, más sin embargo es posible que en tablas diferentes
dentro de una misma base de datos se encuentren atributos
con nombres similares.
• En una relación los atributos no se suelen encontrar en orden.
• No es posible que en una tabla puedan existir dos filas idénticas
• Las filas en una relación no se suelen encontrar en orden.
Generalmente una relación es representada mediante su nombre, se-
guido de sus atributos entre paréntesis y estos a su vez separados por
comas. De tal manera que la relación Artículos quedaría representada
de siguiente forma:
Artículos (codigo_art, descrip_art, pvp_art)
3.2. Concepto de claves en el modelo relacional
Una clave candidata, consiste en una agrupación de atributos que iden-

tifican de manera única a cada fila perteneciente a la relación. Dicho de
otra forma, en una relación no debe existir más de una fila identifica-
da con el mismo valor de su clave aspirante. Considerando la relación
Articulos de la Tabla 2, el atributo codigo_art vendría siendo la clave
candidata, ya que no se podría asignar el mismo valor de este atributo
a dos artículos diferentes.
Realmente en una relación es posible que exista más de una clave
candidata, de las cuales es necesario reconocer entre la clave principal
y las claves alternativas.
Clave principal: Es aquella que está destinada a identificar cada fila
de una relación. En situaciones en las que solo existe una clave aspi-
rante, esta es tomada directamente como una clave principal.
Una clave principal se la presenta subrayada o anteponiendo ante su
nombre el símbolo “#”.
Así se puede representar la relación Artículo de estas dos maneras:

Clave principal: Es aquella que está destinada a identificar cada fila de una relación. En
situaciones en las que solo existe una clave aspirante, esta es tomada directamente como
una clave principal. Análisis del modelo relacional y de los elementos que lo integran 71
Una clave principal se la presenta subrayada o anteponiendo ante su nombre el símbolo
Articulo (#codigo_art, descrip_art, pvp_art)
“#”.
Articulo (codigo_art, descrip_art, pvp_art)
Así se puede Claves
representar la relación
alternativas: Son Artículo de estasclaves
todas aquellas dos maneras:
candidatas que no
Articulo (#codigo_art,
han sido seleccionadas como clave descrip_art,
principal, porpvp_art)
ejemplo, en la rela-
ción Artículos, Articulo
si en esta(codigo_art,
relación se descrip_art,
supiera que pvp_art)
no van a existir dos
Claves alternativas: Son todas aquellas claves candidatas que no han
artículos con una misma descripción, se podría considerar sido seleccionadas
el campo
descrip_art como otra clave candidata teniendo así al atributo codi-
como clave principal, por ejemplo, en la relación Artículos, si en esta relación se supiera
go_art como clave principal y el atributo descrip_art como una clave
que no van a existir dos artículos con una misma descripción, se podría considerar el
alternativa.
campo descrip_art comotipos
Existen otros otra de clave candidata
claves en un modelo teniendo así al atributo
relacional, tales como codigo_art
las como
clave principal
claves atributo descrip_art
y el foráneas, como una clave
las cuales corresponden a unalternativa.
conjunto de atributos
Existen otrosnotipos
nulosdedeclaves en un modelo
una relación relacional,
cuyos valores debentalestenercomo las clavescon
concordancia foráneas, las
cuales corresponden a un conjunto de atributos no nulos de una relación cuyos valores
los valores de una clave candidata, que generalmente es una clave
principal de otra relación, las cuales además deben de estar definidas
deben tener concordancia con los valores de una clave candidata, que generalmente es una
en un mismo dominio.
clave principal de otra relación, las cuales además deben de estar definidas en un mismo
Si además de la relación Artículos, se considera una relación Pedidos,
dominio. la misma que contiene datos referentes a los pedidos propiamente,
Si además de que lahan
relación Artículos,
sido realizados porselosconsidera
clientes deuna empresa,Pedidos,
unarelación para lo cualla misma que
contiene datos referentes a los pedidos propiamente, que han sido realizados
por cada pedido realizado se almacenará un código (referencia_ped) y por los
clientes de una empresa, para lo cual por cada pedido realizado se almacenará un código
la fecha en la que se ha efectuado el pedido (fecha_ped).
Teniendo en cuenta que la clave principal será el atributo referencia_
(referencia_ped) y la fecha en la que se ha efectuado el pedido (fecha_ped).
ped, la representación de la relación Pedidos quedaría de la siguiente
Teniendo en cuenta que la clave principal será el atributo referencia_ped, la
manera:
Pedidos(#referencia_ped,
representación de la relación Pedidos quedaría de la siguientefecha_ped) manera:
Pedidos
Pedidos (#referencia_ped,
(referencia_ped, fecha_ped)
fecha_ped)
Pedidos (referencia_ped,
Representado mediante un ejemplo, los datos fecha_ped)
que se podría almacenar
Representadoenmediante
la tabla deunlaejemplo, los datos que se podría almacenar en la tabla de la
relación Pedidos.
relación Pedidos.
Pedidos
referencia_ped fecha_ped
P011 10/09/2015
P012 11/10/2015
P013 12/11/2015
P014 13/12/2015
Tabla 3: Relación Pedidos
Continuando con el ejemplo anterior, se considerará una relación llamada Linea_pedidos,

la misma que contendrá las líneas de pedidos de los encargados desarrollados por los
clientes. En esta relación además se almacenará un tercer atributo denominado
cantidad_art, el cual representará la cantidad de unidades por cada artículo considerado
Continuando con el ejemplo anterior, se considerará una relación lla-

mada Linea_pedidos, la misma que contendrá las líneas de pedidos de
los encargados desarrollados por los clientes. En esta relación además
se almacenará un tercer atributo denominado cantidad_art, el cual
representará la cantidad de unidades por cada artículo considerado en 2015
el pedido. Además, esta nueva relación constara de una clave principal
que está compuesta de los atributos referencia_ped y codigo_art. El
Linea_pedidos
cual se puede representar(referencia_ped,
de la siguiente codigo_art,
manera. cantidad_art)
Linea_pedidos (#referencia_ped,
Linea_pedidos (referencia_ped, #codigo_art,
codigo_art, cantidad_art)
cantidad_art)
Representado mediante un ejemplo,
Linea_pedidos los datos#codigo_art,
(#referencia_ped, que se podría almacenar en la
cantidad_art) tabla de
relación Linea_pedidos.
Representado mediante un ejemplo, los datos que se podría almacenar
en la tabla de la relación Linea_pedidos.
Linea_pedidos
referencia_ped codigo_art cantidad_art
P010 A0025 4
P011 A0026 12
P012 A0027 17
P013 A0028 20
P014 A0029 10
P014 A0030 5
P014 A0025 15
Tabla 4: Tabla Linea_pedidos
En la tabla Linea_pedidos, el atributo referencia_ped, es una clave foránea que hac

En la tabla Linea_pedidos, el atributo referencia_ped, es una clave fo-
referencia al atributo referencia_ped de la tabla Pedidos. Por tal motivo el valor que s
ránea que hace referencia al atributo referencia_ped de la tabla Pedi-
asigne a este
dos. atributo en la tabla
Por tal motivo Linea_pedidos,
el valor que se asignedeberá
a este tener concordancia
atributo en la tablacon uno de lo
valores que contenga el deberá
Linea_pedidos, referencia_ped
atributotener concordanciadecon la tabla
uno de Pedidos.
los valores que
La mismacontenga
situación se repitereferencia_ped
el atributo con el atributo decodigo_art, el cual vendría siendo una calv
la tabla Pedidos.
foránea de la tabla Artículos, por tal motivo, cada valor que
La misma situación se repite con el atributo tome elelatributo
codigo_art, cual codigo_a
vendría siendo una calve foránea de la tabla Artículos, por tal motivo,
en la tabla Linea_pedidos, deberá tener concordancia con uno de los valores qu
cada valor que tome el atributo codigo_art en la tabla Linea_pedidos,
corresponden al atributo codigo_Art de la tabla Articulo.
deberá tener concordancia con uno de los valores que corresponden al
La representación de una clave
atributo codigo_Art foránea
de la tabla se la realiza mediante flechas, que van desde
Articulo.
clave foránea,Lahasta la cave principal
representación de una correspondiente.
clave foránea se la Por lo tanto,
realiza la base
mediante fle-de datos que s
ha creadochas,
mediante
que vanlas desde
tres tablas utilizadas
la clave foránea,hasta
hastael la
momento, quedaría
cave principal representada de
corres-
siguiente manera:
valores que contenga el atributo referencia_ped de la tabla Pedidos.
La misma situación se repite con el atributo codigo_art, el cual vendría siendo una calve
foránea de la tabla Artículos, por tal motivo, cada valor que tome el atributo codigo_art
en la tabla Linea_pedidos, deberá tener concordancia con uno de los valores que
corresponden al atributo codigo_Art
Análisis de la tabla
del modelo relacional y de Articulo.
los elementos que lo integran 73
La representación de una clave foránea se la realiza mediante flechas, que van desde la
pondiente. Por lo tanto, la base de datos que se ha creado mediante las
clave foránea, hasta la cave principal correspondiente. Por lo tanto, la base de datos que se
tres tablas utilizadas hasta el momento, quedaría representada de la
ha creado mediante las tres tablas utilizadas hasta el momento, quedaría representada de la
siguiente manera:
siguiente manera:
Artlculos linea_pedldos Pedidos

#codigo_an <.. 1 #referecla_ped ~ , .. referencta_ped
#codigo_art
- Figura. 38: Esquema relacional
-
3.3. Las restricciones en el modelo relacional
3.3. Las restricciones en el modelo relacional

Una restricción trata de aquellas ocurrencias no permitidas en un mo-
Una restricción trata de aquellas ocurrencias no permitidas en un modelo relacional de las
delo relacional de las cuales se pueden distinguir dos tipos, que son las
cuales se pueden distinguir dos tipos, que son las restricciones inherentes y las
restricciones inherentes y las restricciones semánticas.
restricciones semánticas.
3.3.1. Restricciones inherentes
3.3.1. Restricciones inherentes
Este tipo de restricciones son características que diversifican la relación de una tabla, las
Este tipo de restricciones son características que diversifican la rela-
cuales se describen a continuación:
ción de una tabla, las cuales se describen a continuación:
• No existen dos filas idénticas, por lo que es de carácter obliga-
torio contar con una clave principal.
• El orden tanto de las filas como de los atributos no tienen re- 53
levancia.
• Cada uno de los atributos solo pueden contar con un único va-
lor de domino, por lo tanto, no se permiten los grupos iterativos
o atributos multivaluados.
Por otro lado, existe otra limitación de este tipo que es justamente la
regla de la integridad de una entidad la cual dice que “Ningún atributo
que forme parte de la clave principal de una relación puede tomar un
valor nulo”.
3.3.2. Restricciones semánticas o de usuario

A continuación, se describirá las limitaciones semánticas o de usuario
más importantes en un modelo relacional.
Clave principal: En una relación es posible estipular uno o varios
atributos como clave principal para identificar cada fila de una tabla,
sabiendo que los valores asignados a estos atributos no podrán redun-
dar ni ser nulos.
Unicidad: Cuando se identifican atributos de los cuales sus valo-

res no consiguen repetirse en una relación, esta limitación permite la
definición de claves alternativas.
Obligatoriedad de uno o varios atributos: Con esta restricción
se sugiere que los atributos no contengan valores nulos o inexistentes.
Esta restricción no es realmente necesaria establecerse en cuanto a loa
atributos de las claves principales, ya que en su mayoría los sistemas
gestores de bases de datos ya cuentan con la restricción de integridad
para las entidades, la cual se explica en el apartado 3.3.1.
Integridad referencial: Esta restricción indica que, si una relación
consta de una clave foránea que hace referencia a la clave principal de
otra relación, esta clave foránea podrá almacenar ya sea un valor nulo
o únicamente alguno de los valores que estén contenidos en la clave
principal de la relación a la que se está haciendo la referencia.
De tal manera el atributo referencia_ped definido en la relación Linea_
pedidos siendo clave foránea de la relación Pedidos, contendrá o bien
un valor nulo o bien uno de los valores correspondientes al atributo
referencia_ped de la relación Pedidos y de igual manera ocurre con
el atributo codigo_art en la relación Linea_pedidos, siendo este, clave
foráneo de la relación FUNDAMENTOS
Artículos, deberáDEcontener
BASE DEvalores
DATOS que2015
coincidan
con
los valores establecidos en la clave principal que es el atributo co-
digo_art de la relación Artículos.
Linea_pedidos
referencia_ped codigo_art cantidad_art Articulos
P010 A0025 4 codigo_art descrip_art pvp_art
P011 A0026 12 A0025 Teclado 8.00
P012 A0027 17 A0026 Mouse Inalámbrico 13.5
P013 A0028 20 A0027 Disco Duro 85.00
P014 A0029 10 A0028 Impresora Canon 300.50
P014 A0030 5 A0029 Monitor Samsung 375.50
P014 A0025 15 A0030 Portátil HP 800.00

Pedidos
referencia_ped fecha_ped
P011 10/09/2015
P012 11/10/2015
P013 12/11/2015
P014 13/12/2015
Tabla 5: Esquema relacional con datos
Otra acción importante a más de definir las claves foráneas de una relación, es la de
determinar las consecuencias que conllevaría el hecho de borrar o editar las filas de una
relación referenciada para lo cual se ha definido las siguientes opciones:
Operación restringida: Esta indica que no es permitido tanto la edición como la
eliminación de una fila que esta referenciada a otra relación. Aplicando esta operación al
ejemplo anterior, esto implicaría que para eliminar un artículo de la relación Articulos, no
Otra acción importante a más de definir las claves foráneas de una re-
lación, es la de determinar las consecuencias que conllevaría el hecho
de borrar o editar las filas de una relación referenciada para lo cual se
ha definido las siguientes opciones:
Operación restringida: Esta indica que no es permitido tanto la
edición como la eliminación de una fila que esta referenciada a otra
relación. Aplicando esta operación al ejemplo anterior, esto implicaría
que para eliminar un artículo de la relación Articulos, no debería existir
ningún registro (fila) en la tabla Linea_pedidos que contenga el artículo
que se piensa eliminar, por otro lado, tampoco será posible modificar
el atributo codigo_art de la relación Articulos mientras se tuviese algún
registro en la relación Linea_pedidos que haga referencia a ese artículo.
Operación de transferencia en cascada: Esta operación indica
que tanto la eliminación o modificación de una fila en la relación que
contenga la clave principal, implicaría inmediatamente la eliminación o
modificación en cascada de todas aquellas filas que contengan la clave
foránea y que hacían referencia a la fila eliminada de la otra relación.
Por ejemplo, si de la relación Pedidos se llegara a modificar el atributo
referencia_ped, en la tabla Linea_pedidos, se deberá modificar todas las
líneas de pedidos que hacían referencia al pedido modificado.
Operación con puesta a nulos: Esta operación indicaría que en
caso de que se eliminara una fila de la relación que contiene la clave
principal, inmediatamente modificaría el valor de la clave foránea en
otra relación a un valor nulo. De tal manera en el ejemplo anterior, si
se llegara a eliminar un registro (fila) de la relación Artículos, se modi-
ficaría el valor a nulo del atributo codigo_art de la relación Linea_pe-
didos de todas aquellas filas cuyo valor del atributo codigo_art hacían
referencia a la fila del artículo eliminado. Sin embargo, esta operación
no es válida en este ejemplo debido a que el atributo codigo_art en la
relación Linea_pedidos no puede tomar un valor nulo o inexistente ya
que anteriormente ya se había establecido que dicho atributo formaría
parte de la clave principal de la relación Linea_pedidos.
Operación con puesta de valor por defecto: Esta operación tiene
un comportamiento similar a la operación anterior, con la diferencia
de que, en este caso en lugar de establecer un valor nulo o inexistente
para el campo de la clave foránea de una relación, se establece un valor
predeterminado o por defecto para tal atributo.

76 atributo
valor del Zea M, Honores J, Rivas W
codigo_art hacían referencia a la fila del artículo eliminado. Sin
embargo,
En esta operación
un modelo no es válida
relacional existen enotras
este ejemplo debido
limitaciones, a que
a las se pue-codigo_art
el atributo
cuales
en la derelación Linea_pedidos
llamar de comprobación o de rechazo y aserciones. En estas dos ya que
no puede tomar un valor nulo o inexistente
anteriormente ya seel había
limitaciones usuario establecido que dicho
debe determinar un atributo
predicado formaría
en basepartea uno de la clave
principal de la relación Linea_pedidos.
o varios atributos de una relación, de esta forma cada que se efectué
Operación con puesta
una operación de de valor por adefecto:
modificación través de Esta operación
la base tieneprimero
de datos, un comportamiento
se
verificará si se cumple con el predicado estipulado, y de
similar a la operación anterior, con la diferencia de que, en este caso en lugar de no ser así la establecer
ejecución
un valor de la operación
nulo o inexistente para elno será de
campo autorizada. Realmente
la clave foránea de una la relación,
diferencia se establece
entre estas dos limitaciones es que
un valor predeterminado o por defecto para tal atributo. en la de comprobación únicamente
se verá afectada una relación, mientras que en la de rechazo y asercio-
En un modelo relacional existen otras limitaciones, a las cuales se puede llamar de
nes se verán afectadas varias relaciones.
comprobación o de rechazo y aserciones. En estas dos limitaciones el usuario debe
determinar un predicado en base a uno o varios atributos de una relación, de esta forma
3.4. Nociones de álgebra relacional
cada que se efectué una operación de modificación a través de la base de datos, primero se
verificará si se cumple
El álgebra relacional coneselun predicado
lenguajeestipulado, y de no ser
formal de consultas así lade
a través ejecución
ba- de la
operación
ses deno datos
será autorizada.
relacionales Realmente
que compone la diferencia entre
la base del estas dos
lenguaje de limitaciones
consulta es que
en la de
SQL.comprobación únicamenteesseun
El álgebra relacional verá afectadadeuna
lenguaje relación,
consulta mientras que en la de
procedimental
rechazoque
y aserciones se verán afectadas varias relaciones.
está formada por un conjunto de operadores que retornan una o
3.4. Nociones de álgebra
más relaciones comorelacional
manejando y que causan otra relación como re-
El álgebra relacional es un lenguaje
sultado. Se dispone de dos grupos formal de consultas
de operadores queasontravés de bases de datos
los operado-
relacionales que compone
res tradicionales delalabase delde
teoría lenguaje
conjuntosde consulta SQL. El álgebra
y los operadores relacional es un
relacionales
concretos.
lenguaje de consulta procedimental que está formada por un conjunto de operadores que
retornan una o más relaciones como manejando y que causan otra relación como resultado.
3.4.1. Operadores tradicionales de la teoría de conjuntos
Se dispone de dos grupos de operadores que son los operadores tradicionales de la teoría
Generalmente todo par de tablas (relaciones), necesitan ser relaciona-
de conjuntos y los operadores relacionales concretos.
das con respecto a la unión, es decir que es necesario que sean de
3.4.1. Operadores tradicionales de la teoría de conjuntos
un mismo grado y que sus atributos deben corresponder a un mismo
Generalmente todo par de tablas (relaciones), necesitan ser relacionadas con respecto a la
dominio. En esta sección se utilizará las siguientes relaciones para los
unión, ejemplos
es decir que es necesario que sean de un mismo grado y que sus atributos deben
posteriores.
corresponder a un mismo dominio. En esta sección se utilizará las siguientes relaciones
para los ejemplos posteriores.
Empleados 1
codigo_emp nombre_emp Cargo
E001 Marlon Rodríguez Jefe
E002 Marcos Cevallos Director
E003 Jonathan Pereira Analista
E004 Andrés Flores Vendedor
Empleados 2
E010 Cristian Quezada Contador
E011 Oliver Añasco Vendedor
Empleados 1
Empleados 2
E004 FUNDAMENTOS
Andrés Flores DE BASE DE
Vendedor DATOS 2015
Tabla 6: Ejemplo de relaciones para el álgebra relacional

Operaciones de la teoría de conjuntos:
Operaciones de la
Operaciones
Unión: La unión deteoría
de lade conjuntos:
teoría
las relaciones
de conjuntos:
A y B (AUB) es una relación en la que se ven
Unión: La unión
Unión:
contenidas
La de las
filasrelaciones
unión
todas las
de las A y B (AUB)
relaciones
de las relaciones A y B.esy una
que relación
A y B (AUB) en existir
la que
es una relación
en caso de
ensela ven
que
redundancia se
se ven
contenidas
eliminan.
contenidas
todas las filas todas
de las las filas de
relaciones A las
y relaciones
B. y que en A y B.
caso de yexistir
que en caso
redundancia se 56
de existir redundancia se eliminan.
eliminan.
Empleados1 U Empleados 2
codigo_emp Empleados1 U Empleados
nombre_emp 2
Cargo
codigo_emp
E001 nombre_emp
Marlon Rodríguez Cargo Jefe
E001
E002 Marlon
Marcos Rodríguez
Cevallos Jefe
Director
E002
E003 Marcos Cevallos
Jonathan Pereira Director
Analista
E003
E004 JonathanFlores
Andrés Pereira Analista
Vendedor
E004
E010 Andrés Flores
Cristian Quezada Vendedor
Contador
E010
E011 Cristian Quezada
Oliver Añasco Contador
Vendedor
E011 Oliver
Tabla 7: UniónAñasco Vendedor
de dos relaciones
Tabla 7:
Intersección: Esta relación consiste enUnión de dostodas
contener relaciones
las filas que se encuentran tanto en
Intersección:
la relación Esta relación
A como en Esta
Intersección: consiste
la relación en contener
B aconsiste
relación todas
la vez. en contener las todas
filas que
las se encuentran
filas que se tanto en
la relación A como en
encuentran la relación
tanto B a la vez.
en la relación A como en la relación B a la vez.
Empleados 1 ∩ Empleados 2
Empleados
codigo_emp 1 ∩ Empleados
nombre_emp 2
Cargo
codigo_emp
E004 nombre_emp
Andrés Flores Cargo
Vendedor
E004 Tabla 8: Intersección
Andrés Flores Vendedor
de dos relaciones
Tabla 8: Intersección de dos relaciones
Diferencia: En una diferencia entre relaciones, (A - B) es una relación en la que se ven
Diferencia: En una
Diferencia:
contenidas todas diferencia
En
filasentre
una diferencia
aquellas que serelaciones, (A -enB)la(A
entre relaciones,
encuentran esrelación
-una relación
B) es en que
la que
una relación
A pero no se ven
tienen
contenidas
en latodas aquellas
que se filas
ven contenidas
correspondencia con la relación B. que se encuentran
todas aquellas en
filaslaque
relación A pero
se encuentran que
en no tienen
la relacióncon
correspondencia A pero que noB.tienen correspondencia con la relación B.
la relación
Empleados 1 - Empleados 2
Empleados
codigo_emp 1 - Empleados
nombre_emp 2
Cargo
codigo_emp
E001 nombre_emp
Marlon Rodríguez Jefe Cargo
E001
E002 Marlon Rodríguez
Marcos Cevallos Jefe
Director
E002
E003 Marcos Cevallos
Analista
Tabla 9: Diferencia entre dos relaciones
Tabla
Tabla 9:
9: Diferencia
Diferencia entre
entre dos
dos relaciones
relaciones
Producto cartesiano: Entre dos relaciones A y B, el producto cartesiano (AxB),
Producto
correspondecartesiano: Entre
a una relación en dos
la querelaciones A y B, eltodas
se ven involucrados producto cartesiano
las filas posibles (AxB),
que se
corresponde a una relación en la que se ven involucrados todas las filas posibles
obtengan de relacionar una fila de A con una fila de B. Considerando que si la relación que se
A
obtengan de relacionar
tiene un grado una filaBdetiene
m y la relación A con una fila
un grado n, de B. Considerando
la relación de (AxB)que si launrelación
tendrá A
grado de
Empleados 1 - Empleados 2
78 ZeaE002
M, Honores J, Rivas Marcos
W Cevallos Director
Producto cartesiano: Tabla 9: Diferencia
Entre entre dos relaciones
dos relaciones A y B, el producto carte-
Productosiano (AxB), corresponde
cartesiano: Entre dos arelaciones
una relaciónA en y B,la que se ven involucrados
el producto cartesiano (AxB),
todas las filas posibles que se obtengan de relacionar una fila de A con
corresponde a una relación en la que se ven involucrados todas las filas posibles que se
una fila de B. Considerando que si la relación A tiene un grado m y la
obtengan de relacionar una fila de A con una fila de B. Considerando que si la relación A
relación B tiene un grado n, la relación de (AxB) tendrá un grado de
tiene un grado m y la relación B tiene un grado n, la relación de (AxB) tendrá un grado de
(m+n). Mientras tanto si la cardinalidad de la relación A es p y la car-
(m+n). Mientras tanto si la cardinalidad de la relación A es p y la cardinalidad de la
dinalidad de la relación B es q, la cardinalidad de la relación de (AxB)
relación B es q,
será la cardinalidad de la relación de (AxB) será (pxq).
(pxq).
Empleados
codigo_emp nombre_emp Cargo codigo_dep
E001 Marlon Rodríguez Jefe 4
E002 Marcos Cevallos Director 6
E003 Jonathan Pereira Analista 6
DE BASE DE8DATOS
FUNDAMENTOS 2015

Departamentos
codigo_dep nombre_dep ciudad
4 Sistemas Machala 57
6 Financiero Arenillas
8 Ventas Santa Rosa
Tabla 10: Relaciones para ejemplos posteriores

Empleados x Departamentos
codigo_ nombre_emp cargo codigo_ codigo nombre_dep ciudad
emp dep _dep
E001 Marlon Rodríguez Jefe 4 4 Sistemas Machala
E001 Marlon Rodríguez Jefe 4 6 Financiero Arenillas
E001 Marlon Rodríguez Jefe 4 8 Ventas Santa Rosa
E002 Marcos Cevallos Director 6 4 Sistemas Machala
E002 Marcos Cevallos Director 6 6 Financiero Arenillas
E002 Marcos Cevallos Director 6 8 Ventas Santa Rosa
E003 Jonathan Pereira Analista 6 4 Sistemas Machala
E003 Jonathan Pereira Analista 6 6 Financiero Arenillas
E003 Jonathan Pereira Analista 6 8 Ventas Santa Rosa
E004 Andrés Flores Vendedor 8 4 Sistemas Machala
E004 Andrés Flores Vendedor 8 6 Financiero Arenillas
E004 Andrés Flores Vendedor 8 8 Ventas Santa Rosa
Tabla 11: Producto cartesiano de dos relaciones
3.4.2 Operadores relacionales específicos

En el álgebra relacional se defienden los siguientes operadores:
Operador de Selección o Restricción (G): Este operador algebraico, produce un
subconjunto horizontal de una relación existente, el mismo que comprende todas las filas
de la relación para las cuales se realiza un predicado detallado. Considerando las relaciones
del ejemplo anterior, si se requiere seleccionar todos los empleados que pertenecen al
Tabla 11: Producto cartesiano de dos relaciones
3.4.2 Operadores relacionales específicos
3.4.2
En el Operadores relacionalesseespecíficos
álgebra relacional defienden los siguientes operadores:
En el álgebra relacional se defienden los siguientes operadores:
Operador de Selección o Restricción (G): Este operador algebraico, pro-
Operador de Selección o Restricción (G): Este operador algebraico, produce un
duce un subconjunto
subconjunto horizontal de una horizontal de una
relación existente, relación
el mismo que existente, el mismo
comprende todas las filas
que comprende todas las filas de la relación para las cuales se realiza
de la relación para las cuales se realiza un predicado detallado. Considerando las relaciones
un
delpredicado detallado.
ejemplo anterior, Considerando
si se requiere seleccionar las relaciones
todos del que
los empleados ejemplo ante-
pertenecen al
departamento
rior, código es seleccionar
si se requiere 6, la expresión todos
es la siguiente:
los empleados que pertenecen al
departamento código es 6, σ codigo_dep=6
la expresión (Empleados)
es la siguiente:
σ codigo_dep=6 (Empleados)
YYsu
su resultado
resultado seráserá
el siguiente:
el siguiente:
Empleados
codigo_emp nombre_emp cargo codigo_dep
Tabla 12: Selección sobre una relación
Operador
Operador de deproyección
proyección (π): Este
(π): Este operador
operador produce produce un subconjunto
un subconjunto vertical de una
relación ya
vertical deexistente,
una relación FUNDAMENTOS
el mismoyaqueexistente, DE BASE
resulta de seleccionar
el mismo losque DE
atributos, DATOS
resulta 2015
especificados en un
de seleccio-
orden conveniente de FUNDAMENTOS
izquierda a derecha, para DEeliminar
luego BASElasDE DATOS
filas
nar los atributos, especificados en un orden conveniente de izquierda a copiadas. 2015

derecha, para luego eliminar las filas copiadas.
Por ejemplo, para conseguir los cargos de los empleados en la relación Empleados, el
Por Por ejemplo,
ejemplo, para para conseguir
conseguir los
los lacargos decargos de los empleados
los empleados enEmpleados,
en la relación la relaciónel
resultado de la proyección seria siguiente:
Empleados,
resultado el resultado
de la proyección de la proyección seria la siguiente:
seria la siguiente: 58

Empleados
Empleados
cargo
cargo
Jefe
Jefe
Director
Director
Analista
Analista
Vendedor
Tabla 13: Vendedor
Proyección sobre una relación
Tabla 13: Proyección sobre una relación
De igual
De igual maneramanera paralosobtener
para obtener nombreslos nombres
y los cargos deycada
los empleado
cargos deque cada em-
labora en el
De igual manera
pleado que
departamento para obtener
cuyolabora
código en los nombres y
el departamento
(codigo_dep) los cargos de cada
cuyo código
es 6, la expresión empleado que
(codigo_dep)
algebraica labora
es 6,en
será la siguiente:lael
departamento
expresióncuyoalgebraica
πcódigo (codigo_dep)
nombre_emp,
serácargo es
(σ6,codigo_dep=
la expresión6algebraica
la siguiente: será la siguiente:
(Empleados))
π nombre_emp,
De la cual se obtendrá cargo
como resultado
π nombre_emp,
(σ codigo_dep=
lo siguiente:
cargo
6 (Empleados))
(σ codigo_dep= 6 (Empleados))
De la cual se obtendrá como resultado lo siguiente:
Empleados
EmpleadosCargo
nombre_emp
nombre_emp
Marcos Cevallos Cargo
Director
Marcos Cevallos
Analista
TablaJonathan Pereira
14: Selección Analista
y proyección sobre una relación
Tabla 14: Selección y proyección sobre una relación
Operador división (/): Este operador se encarga de dividir una relación A con un grado m,
Operador
entre una división
relación (/): Estegrado
B con operador
n, deseloencarga
cual sedeobtiene
dividircomo
una relación A con
resultado una un grado m,
relación con
entre
gradouna relación B con grado n, de lo cual se obtiene como resultado una relación con mn
es decir, que si la relación A tiene un grado 2 y la relación B un grado 1, la relaciónmn
grado de
esdivisión
decir, A/B
que si la relación
dará A tiene un
como resultado un conjunto
grado 2 ydelaaquellas
relaciónfilas
B un<x>grado
que1,enlaelrelación
instantede
en
De igual manera para obtener los nombres y los cargos de cada empleado que labora en el
departamento cuyo código (codigo_dep) es 6, la expresión algebraica será la siguiente:
π nombre_emp, cargo (σ codigo_dep= 6 (Empleados))
Operador división (/): Este Empleados operador se encarga de dividir una rela-
nombre_emp Cargo
ción A con un grado m, entre una relación B con grado n, de lo cual
Marcos Cevallos Director
se obtiene como resultado Jonathanuna relación
Pereira con grado mn es decir, que si
Analista
la relación A tiene Tablaun14: grado
Selección2y proyección
y la relación B relación
sobre una un grado 1, la relación
de división A/B dará como resultado un conjunto
Operador división (/): Este operador se encarga de dividir una relación de aquellas
A confilas <x>m,
un grado
entre una relación B con grado n, de lo cual se obtiene como resultado una relaciónBcon
que en el instante en que se unan con las filas <y> de la relación
gradoproduzcan filas contenidas en A <x,y>. mn
Además, si se efectuara un producto cartesiano a la relación
es decir, que si la relación A tiene un grado 2 y la relación B un grado 1, la relación de A/B y la
relación
división A/B daráB secomo
obtendría
resultado como resultado
un conjunto un conjunto
de aquellas de filas
filas <x> que enque corres- en
el instante
que seponden
unan con a las filas <y> de
la relación A. la relación B produzcan filas contenidas en A <x,y>.
Además, si se efectuara un producto A/B cartesiano
x B aA la relación A/B y la relación B se
obtendría
Por como
ejemplo,resultado
si seunrealiza
conjuntoladedivisión
filas que entre
corresponden a la relación
la relación A.
Empleados, la
misma que tiene un grado 4, A/By xlaB relación
A Departamentos de grado
Por ejemplo, si se realiza
1. La relación la división entre la relación Empleados,
Empleados/Departamentos tendrá un grado la misma3, que tiene un
y estará
gradoconformada Departamentos
4, y la relaciónpor de grado 1. La relación Empleados/Departamentos
todos aquellos atributos que pertenecen a la relación
tendráEmpleados
un grado 3, menos
y estarálosconformada
atributos porpertenecientes
todos aquellos atributos que pertenecen
a la relación Departa-a la
relación Empleados
mentos y a su vez presentara únicamente las filas de empleados quey a
menos los atributos pertenecientes a la relación Departamentos
su vez presentara únicamente las filas de empleados que laboran en el departamento 6.
laboran en el departamento 6.
Departamentos
codigo_dep
6
Empleados
codigo_emp FUNDAMENTOS
nombre_emp DE BASEcodigo_dep
Cargo DE DATOS 2015
E001 Marlon Rodríguez Jefe 4

E004 Andrés Flores Vendedor 8
Tabla 15: Relaciones a utilizar en la división
59
Empleados/ Departamentos
Tabla 16: División de las relaciones
Operador de combinación
Operador (*): De la (*):
de combinación combinación entre una relación
De la combinación entreA una
y unarelación
relación B,
se obtiene
A y una relación B, se obtiene una relación en la que constanuna
una relación en la que constan todas las filas que resultan de enlazar fila de
todas
la relación
las filas que resultan de enlazar una fila de la relación A y otra fila deuna
A y otra fila de la relación B, con el objetivo de que estas desempeñen
condición específica para los valores correspondientes a un atributo de dominio habitual en
ambas relaciones. Es por esto que usualmente se realiza primero el producto cartesiano de
las dos relaciones para luego realizar una selección de aquellas filas que desempeñen la
condición establecida.
Empleados
codigo_emp nombre_emp cargo
Empleados/ Departamentos 2015
E002
E003 Marcos
Jonathan CevallosAnalista
Pereira Director 6 6
E003
E004 Jonathan
Andrés Flores Pereira Vendedor Analista 8 6
Tabla Tabla 16: División
15: Relaciones deenlas
a utilizar la relaciones
división
laOperador
relaciónde B,combinación Empleados/
con el objetivo(*): Dede laque Departamentos
combinación entre una relación
estas desempeñen A y una relación B,
una condición
se obtiene una
específica codigo_emp
pararelación
los valores nombre_emp
en la quecorrespondientes cargo
constan todas las filasa unque codigo_dep
resultan de
atributo de enlazar
dominio una fila de
la relaciónenAE002
habitual y otra fila
ambas deMarcos
relaciones.
Cevallos
la relación
Es porB, con Director
estoel que
objetivo 6
de que estas
usualmente se desempeñen
realiza una
condición específica para
primero el producto cartesiano los valores
Tabla 16:de correspondientes
las de
División dos a
las relaciones
relaciones un atributo de dominio
para luego realizar habitual en
ambas
una relaciones.
selección Es por
de aquellasesto que
filas usualmente se
que desempeñen realiza primero el producto cartesiano de
Operador de combinación (*): De la combinación entre una la condición
relación A y unaestable-
relación B,
las dos relaciones para luego realizar una selección de aquellas filas que desempeñen la
cida.
se obtiene una relación en la que constan todas las filas que resultan de enlazar una fila de
condición
la relación establecida.
A y otra fila de la relación B, con el objetivo de que estas desempeñen una
Empleadosa un atributo de dominio habitual en
condición específica para los valores correspondientes
codigo_emp
ambas relaciones. Es por nombre_emp
esto que usualmente cargo
se realiza primero el producto cartesiano de
E001 Marlon Rodríguez Jefe filas que desempeñen la
las dos relaciones para luego realizar una selección de aquellas
condición establecida. E002 Marcos Cevallos Director
Empleados
E004
codigo_emp
Andrés Flores cargoVendedor
nombre_emp
E002 Departamentos
Marcos Cevallos Director
E003 codigo_dep nombre_dep
Jonathan Pereira Ciudad
Analista
E004 4 AndrésSistemas
Flores Machala
Vendedor
8 Ventas
Departamentos Santa Rosa
Tabla 17: Relaciones
codigo_dep de ejemploCiudad
nombre_dep para la combinación
4 Sistemas Machala
Delas
De las relaciones
relaciones anteriores,
anteriores,
6 al al
efectuar
efectuarla combinación,
Financiero la Arenillas
combinación,quedaqueda
de tal de
manera
tal que el
manera codigo_dep
atributo que de
el atributo tabla Empleados,
8 lacodigo_dep tenga
Ventasde la tabla un
Santa Rosa mismo valor
Empleados, que un
tenga su atributo
correspondiente
mismo valor que ensulaTabla 17: Relaciones de ejemplo para la combinación
tabla
atributoDepartamentos,
correspondiente lo cualenquedaría
la tablaexpresado de la siguiente
Departamen-
forma:
De
tos, las relaciones
lo cual anteriores,
quedaría al efectuar
expresado de lala siguiente
combinación,forma:
queda de tal manera que el
atributo codigo_dep
(Empleados
(Empleados * de la tabla Empleados,
* Departamentos)
Departamentos) Empleados tenga un mismo
codigo_dep
Empleados valor que
=Departamentos
codigo_dep su codigo_dep
atributo
=Departa-
correspondiente
Cabe mencionar enque
la tabla
para Departamentos,
realizar esta lo cualesquedaría
operación expresado
necesario que de la siguiente
primeramente se efectúe
mentos codigo_dep
forma:
un producto cartesiano, de lo cual se obtiene como resultado lo siguiente:
Cabe mencionar que para realizar esta operación es necesario que pri-
(Empleados * Departamentos) Empleados codigo_dep =Departamentos codigo_dep
meramente
Cabe mencionarseque
efectúe un producto
para realizar cartesiano,
esta operación es necesariode
quelo cual se obtiene
primeramente se efectúe
como resultado lo siguiente: Empleados * Departamentos
un producto cartesiano, de lo cual se obtiene como resultado lo siguiente:
codigo_ nombre_emp Cargo codigo_ codigo_dep nombre_ ciudad
emp dep dep
E001 Marlon RodríguezEmpleados
Jefe * Departamentos
4 4 Sistemas Machala
codigo_
E002 nombre_emp
Marcos Cevallos Cargo
Director codigo_
6 codigo_dep
4 nombre_ ciudad Machala
Sistemas
emp
E003 Jonathan Pereira Analista dep 6 4 dep Sistemas Machala
Tabla 18: Producto cartesiano
Tabla 18: Producto cartesiano
60

60

82 Zea M, Honores J, FUNDAMENTOS
Rivas W DE BASE DE DATOS 2015

Empleados X Departamentos
codigo nombre_emp Cargo codigo_ codigo_ nombre_dep ciudad
_emp dep dep
E001 Marlon Rodríguez Jefe 4 6 Financiero Arenillas
E001 Marlon Rodríguez Jefe 4 8 Ventas Santa Rosa
E002 Marcos Cevallos Director 6 6 Financiero Arenillas
E002 Marcos Cevallos Director 6 8 Ventas Santa Rosa
Tabla 19: Combinación o reunión

Luego será necesario, tomar en cuenta únicamente aquellas filas que
Luego será necesario, tomar en cuenta únicamente aquellas filas que cumplen directamente
cumplen
con directamente
el predicado establecido,cones el predicado
decir, establecido,
que el atributo codigo_depes decir,
de la que el
relación
atributo codigo_dep
Empelados, tome el mismode la relación
valor queEmpelados,
el atributo tome el mismo
codigo_dep de valor que
la relación
Departamentos.
el atributo codigo_dep de la relación Departamentos.
En estaEnsituación se observase
esta situación queobserva
es una comparación
que es una equivalente,
comparaciónes decirequivalente,
se trata de una
combinación por igualdad. La combinación que se suele
es decir se trata de una combinación por igualdad. La combinación dar con mayor frecuencia entre
relaciones o tablas es la denominada join o también conocida como reunión natural, el cual
que se suele dar con mayor frecuencia entre relaciones o tablas es la
no es más que el resultado de la eliminación de los atributos duplicados de una
denominada join o también conocida como reunión natural, el cual no
combinación por igualdad.
esoperador
El más que que el resultado
representa de la eliminación
esta combinación es |x|, por de los atributos
lo tanto, duplicados
la reunión natural entre las
de una combinación por igualdad.
relaciones A y B se representa de la siguiente forma: AxB
Por
El lo tanto, de estas
operador que relaciones
representa se seleccionarán todas aquellas
esta combinación es filas
|x|,quepor
contengan
lo tanto,valores
la
equivalentes
reunión naturalen sus respectivas
entre lascolumnas de igual
relaciones A y dominio, es decir tanto
B se representa delalaclave foránea
siguiente
yforma:
la claveAxB
principal, y se suprimen las que se consideran iguales.
Por ejemplo, en una reunión natural dada entre las relaciones Empleados y
Por lo tanto, de estas relaciones se seleccionarán todas aquellas
Departamentos tendría que suprimir una de las columnas codigo_dep, tal como se
filas que contengan valores equivalentes en sus respectivas columnas
muestra a continuación.
de igual dominio, es decir tanto la clave foránea y la clave principal, y
se suprimen las que se Empleados
consideran iguales.
* Departamentos
Por ejemplo,
codigo_ en una reunión
nombre_emp cargo natural
codigo_dada entre nombre_
codigo_d las relaciones
ciudad Em-
emp
pleados y Departamentos tendríadep ep
que suprimir dep
una de las columnas
codigo_dep,
E002 tal como
Marcos Cevallosse muestra
Director a6 continuación.
4 Sistemas Machala
61

equivalentes en sus respectivas columnas de igual dominio, es decir tanto la clave foránea
y la clave principal, y se suprimen las que se consideran iguales.
Por ejemplo, en una reunión natural dada entre las relaciones Empleados y
Departamentos tendría que suprimir una de las columnas codigo_dep, tal como se
muestra a continuación.
Empleados * Departamentos
codigo_ nombre_emp cargo
codigo_ codigo_d nombre_ ciudad
emp dep ep dep
E001 Marlon Rodríguez FUNDAMENTOS
Jefe 4 DE
4 BASE DE DATOS
Sistemas Machala 2015

codigo_emp nombre_emp cargo codigo_ nombre_dep ciudad
FUNDAMENTOS dep
DE BASE DE DATOS 2015 61
E001 Marlon Rodríguez Jefe 4 Sistemas Machala

E002 Marcos Cevallos Director 6 Sistemas Machala
E003 Jonathan Pereira Analista 6 Sistemas Machala
E004 Andrés Flores Vendedor 8 Sistemas Machala
Tabla 20: Combinación Natural
codigo_emp nombre_emp cargo codigo_ nombre_dep ciudad
3.5. Nociones
3.5. Nociones de Cálculo relacional
de Cálculo de filas para
relacional resolver
de dep
filas ejercicios
para prácticos
resolver ejercicios
esenciales
prácticos
E001 esenciales
Marlon Rodríguez Jefe 4 Sistemas Machala
En el E002álgebra relacional se exponenDirector
Marcos Cevallos todos aquellos 6 procedimientos
Sistemas queMachala
son precisos
realizar
E003para obtener el resultado
Jonathan Pereira de Analista
una consulta. 6 Por otroSistemas
lado, en el caso del cálculo
Machala
En elE004 álgebra relacional se exponen todos aquellos procedimientos que
relacional de las Andrés filas seFlores
refiere a la Vendedor
utilización 8de un lenguaje Sistemas Machala en el
no procedimental
son precisos realizar paraTabla obtener el
20: Combinación resultado
Natural de una
que se muestra directamente la información deseada consulta. Porsin
otro
3.5. lado,deen
Nociones
necesidad de el caso
Cálculo
exponer del cálculo
el relacional
procedimiento relacional
de filas
que para ade
resolver
se lleva cabolas filas
ejercicios
para se refiere
prácticos
lograr a lade
la obtención
utilización
esenciales de unEste
dicha información. lenguaje
tipo de no procedimental
consultas en el cálculoen el deque
relacional se muestra
las filas se expresa o
En el álgebra
se enuncian
directamente de relacional
lalasiguiente semanera:
información exponen todos aquellos
deseada procedimientos
sin necesidad que sonelprecisos
de exponer pro-
cedimiento que se lleva a cabo para lograr la obtención de caso
realizar para obtener el resultado de una {tconsulta.
| P (t)} Por otro lado, en el dichadelinfor-
cálculo
relacional
Dada estaEste
mación. deestructura,
las tipo
filas de
sese refiere
entiende
consultas a laque
utilización
enel conjunto de un
el cálculo fila t al no
de lenguaje
relacional procedimental
igualdeque laselfilas enseel
predicado
propuesto P, es cierto para t. Deque se muestra
lo cual se muestra t.A o t|A| allavalor
directamente información deseada
del atributo A parasinla
expresa o se enuncian de la siguiente manera:
fila t y t є de
necesidad r para
exponer el que
indicar la fila t está que
procedimiento lleva ar.cabo para lograr la obtención de
en laserelación
dicha información.
Para demostrar Este tiporelacional
el cálculo de consultas{t las
de |enPfilas,
el(t)}
cálculo relacional de
se ejemplificará las filas las
utilizando se expresa
relacioneso
Dada estade
seEmpleados
enuncian estructura,
1 ylaEmpleados se entiende
2 indicadas
siguiente manera: yaque el conjunto
en ejemplos de fila t al igual que
anteriores.
el predicado propuesto P, es cierto {t | Ppara
(t)} t. De lo cual se muestra t.A o
Dada al
t|A| estavalor
estructura, se entiende
del atributo A paraqueEmpleados
el
la conjunto
fila t y1 tdeє rfila parat alindicar
igual que queel la
predicado
fila t
propuesto P, es
está en la relación r. cierto para t.
codigo_emp
De lo cual nombre_emp
se muestra t.A o t|A|cargo
al valor del atributo A para la
fila t y t є r para indicar E001
que la fila t estáMarlon
en la Rodríguez
relación r. Jefe
Para demostrar el cálculo E002
relacional de las filas, se ejemplificará utili-
Para demostrar el cálculo relacional deMarcoslas filas, Cevallos Directorutilizando las relaciones
se ejemplificará
zando las relacionesE003 EmpleadosJonathan 1 y EmpleadosPereira 2 indicadas ya en ejem-
Analista
Empleados 1 y Empleados 2 indicadas ya en ejemplos anteriores.
plos anteriores. E004 Andrés Flores Vendedor
Empleados
Empleados12
codigo_emp
codigo_emp nombre_emp nombre_emp cargo
cargo
Tabla 21: Ejemplo de relaciones para el cálculo relacional de filas:
Por lo tanto, si se desea conseguir los datos2 correspondientes tanto a la relación

Empleados
Empleados 1 y Empelados 2,
codigo_emp se utilizará el operador v(o).
nombre_emp cargoLo que se entiende como el
conjunto de filas que se encuentren
E010 tanto en la relación
Cristian Quezada Empleados
Contador 1 como en Empleados
2. E011 Oliver Añasco Vendedor
E004 Andrés1)
{t | (t є Empleados Flores Vendedor
v (t є Empleados2)}
Empleados 1
Empleados 2
Tabla 21: Ejemplo de relaciones para el cálculo relacional de filas:
Por lo tanto, si se desea conseguir los datos correspondientes tanto a la relación

Por lo tanto, si se desea conseguir los datos correspondientes tanto a
Empleados 1 y Empelados 2, se utilizará el operador v(o). Lo que se entiende como el
la relación Empleados 1 y Empelados 2, se utilizará el operador v(o). Lo
conjunto de filas que se encuentren tanto en la relación Empleados 1 como en Empleados
que 2. se entiende como el conjunto de filas que se encuentren tanto en
la relación Empleados {t | 1
(t єcomo en Empleados
Empleados 2.
1) v (t є Empleados2)}
{t | (t є Empleados 1) v (t є Empleados2)}
Por otro lado, para obtener FUNDAMENTOS
las filas únicamente DE BASE de DE
los DATOS
empleados 2015
que
62
sean
comunes entre las relaciones Empleados 1 y Empleados 2, es ne-
cesario
Por otro lado,utilizar
para el operador
obtener Ʌ(y),
las filas de la misma
únicamente forma en
de los empleados queque
seanse demues-
comunes entre
tra en la siguiente expresión:
las relaciones Empleados 1 y Empleados 2, es necesario utilizar el operador Ʌ(y), de la
misma forma en que {t se
| (t є Empleados
demuestra 1) Ʌ (texpresión:
en la siguiente є Empleados2)}
Para obtener los datos {t | (t єque
Empleados 1) Ʌ (t є Empleados2)}
correspondan a la relación Empleados 1
Para obtener
pero que nolos se datos que correspondan
encuentren a la relación
en la relación EmpleadosEmpleados
2, se1 debe
pero que no se
utilizar
encuentren en la relación Empleados 2, se debe
el operador ¬ (no) tal cual se denota en la siguiente expresión. utilizar el operador ¬ (no) tal cual se
denota en la siguiente expresión.
{t | (t є Empleados 1) Ʌ¬ (t є Empleados2)}
{t | (t є Empleados 1) Ʌ¬ (t є Empleados2)}
Considerando
Considerando la relaciónla relación
EmpleadosEmpleados y laDepartamentos.
y la relación relación Departamentos.
Empleados
Departamentos
codigo_dep nombre_dep ciudad
4 Sistemas Machala
8 Ventas Santa Rosa
Tabla 22: Ejemplo de relaciones para el cálculo relacional de fila
Si se
Si se desea
desea obtener
obtener las las
filasfilas
de laderelación Empleados
la relación que pertenezcan
Empleados únicamente a
que pertenezcan
cuyo valor de codigo_dep
únicamente a departamento cuyo valor de codigo_dep es igual a 1, sude
departamento es igual a 1, su expresión quedaría demostrada
la siguiente manera:
expresión quedaría demostrada de la siguiente manera:
{t | (t є Empleados) Ʌ (t.codigo_dep=1)}
{t | (t є Empleados) Ʌ (t.codigo_dep=1)}
Para obtener una proyección en base a una relación sobre uno o varios atributos, es
conveniente emplear el constructor “existe” de la logia matemática (Ǝ). Por ejemplo, si se
desea obtener todos los cargos que se encuentren asignados a los empleados de la relación
Empleados, sería necesario emplear la siguiente expresión.
{t | Ǝ s є Empleados (t.cargo = s.cargo)}
De esta manera la expresión anterior describe a todo el conjunto de filas t que existen en la
Para obtener una proyección en base a una relación sobre uno o varios
atributos, es conveniente emplear el constructor “existe” de la logia
matemática (Ǝ). Por ejemplo, si se desea obtener todos los cargos que se
encuentren asignados a los empleados de la relación Empleados, sería
necesario emplear la siguiente expresión.
De esta manera la expresión anterior describe a todo el conjunto de
filas t que existen en la relación Empleados cuyo valor en t tiene corres-
pondencia con los valores de s.
Para obtener tanto el nombre como el cargo de cada empleado que se
encuentre laborando en el departamento cuyo valor en el atributo codi-
go_dep sea 1, se utiliza la siguiente expresión:
{t | Ǝ s є Empleados ((t.nombre_emp = s.nombre_emp) Ʌ (t.cargo =
s.cargo) Ʌ (t.codigo_dep = 1))}
Por otro lado, para realizar la combinación natural entre las relaciones
Empleados y Departamentos los términos para el cálculo relacional
resultan aún más complejos, quedando su expresión planteada de la
siguiente manera:
{t | Ǝ s є Empleados ((t.nombre_emp = s.nombre_emp) Ʌ (t.nombre_emp
= s.nombre_emp) (t.cargo = s.cargo) Ʌ (t.nombre_emp = s.nombre_emp)
Ʌ Ǝ u є Departamentos ((s.codigo_dep = codigo_dep) Ʌ (t.nombre_emp
= u.nombre_emp) Ʌ (t.nombre_emp = u.nombre_emp) Ʌ (t.ciudad =
u.ciudad)))}
En esta expresión se utilizan dos constructores para hacer referencia a
las filas en ambas relaciones (tablas), además se estipulan condiciones
unidas por el operador (y). De las cuales las primeras son utilizadas
con el fin de que las filas t del resultado comprendan todos los atribu-
tos de la relación Empleados. La condición siguiente, es la que vincula
ambas relaciones mediante la clave foránea en relación a la clave prin-
cipal codigo_dep. Y las dos últimas condiciones se encargan de que
las filas t del resultado comprendan todos los atributos de la relación
Departamentos.
Luego de ya haber comprobado cómo se formulan ciertas consultas
en base al cálculo relacional de filas, es posible dar una definición más
formal a este lenguaje, de tal manera que las expresiones del cálculo
relacional de filas se obtienen partiendo de la siguiente forma:
{t | P (t)}
De lo anterior se describe a P como la fórmula del cálculo relacional,

de la cual surgen distintas variables de las filas, Siendo estas variables
libres mientras no sean consideradas mediante Ǝ o ∀, como se demues-
tra a continuación:
{t | (t є Empleados 1) v (t є Empleados2)}
t, correspondería a una variable libre, sin embargo, en la siguiente
expresión la variable s es considerada una variable unida ya que se
encuentra seguida del símbolo Ǝ.
Las formulas del cálculo relacional de filas se construyen mediante
átomos, los cuales pueden tener una de las siguientes formas:
t є r, de las cuales t es una variable fila y r es una relación. No está per-
mitido la utilización del operador.
t.A op s.B, de las cuales t y s son variables de fila, A representa un atri-
buto de la relación en la que se encuentra determinada t, B representa
a un atributo que pertenece a la relación en la que se encuentra deter-
minada s, op es un operador de comparación (<, , >, , =, ≠) y los atri-
butos A y B tiene dominios mientras sus miembros sean comparables.
t.A op c, donde t viene siendo una variable de fila, A es un atributo que
pertenece a la relación en que se encuentra determinada t, op es un
operador de comparación y c es una constante en el dominio de A.
Como ya se había mencionado anteriormente, estas fórmulas se cons-
truyen partiendo de átomos, para lo cual es necesario seguir las si-
guientes normas.
• Cada átomo es una fórmula
• Si P es considerado una fórmula, entonces ¬P y P, también lo
son.
• Si P1, y P2 Son fórmulas, entonces también lo son P1 P2, P1
v P2 y P1⇒ P2
• Si P(s) es una fórmula que contiene una variable fila libre, s y
r son relaciones
∃ s ∈ r (P(s)) y ∀ s ∈ r (P(S))
En el cálculo relacional de filas, se puede escribir términos e, utilizan-

do distintas nomenclaturas, para lo cual se consideran las siguientes
normas.
• P1 P2 es equivalente a ¬ (¬ (P1) v ¬ (P2)).
• ∀ t ∈ r (P (t)) es equivalente a ¬∃ t ∈ r (¬ P (t)).

• P1 ⇒ P2 es equivalente a ¬ (P1) v P2.
3.6. Nociones de Cálculo relacional de Dominios
Existe una forma diferente de cálculo relacional conocida como calculo

relacional de dominós, en el cual se utilizan variables de dominio pro-
piamente, las mismas que adquieren valores del domino de un atributo
en vez de obtenerlas de una fila completa, y sus términos se represen-
tan de la siguiente manera:
{< Z1, Z2, …, Zn > I P(Z1, Z2, …, Zn)}
En la expresión anterior Z1, Z2, …, Zn, representan variables de
dominio mientras que P, corresponde a una formula conformada por
átomos, similar a lo que se presentó en el caso del caculo relacional
de filas, y se deben presentar de la siguiente manera:
< Z1, Z2, …, Zn > ∈ r
De la cual r es una relación que contiene n atributos y Z1, Z2, …, Zn ,
son las variables o constantes de domino.
z op y, de las cuales z e y, son las variables de dominio, mientras que op
es un operador de comparación (<, , >, , =, ≠), además los atributos z
e y, tienen dominios miembros son semejantes mediante op.
z op c, de las cuales z es una variable de dominio, mientras que op es
un operador de comparación y por otro lado c es una constante del do-
minio del atributo para que z sea una variable de dominio.
Cada formula se construye partiendo de átomos, considerante an-
tes las siguientes reglas:
• Un átomo es realmente una fórmula.
• Si P es una fórmula, de igual manera los serán ¬P y (P)
• Si P1, y P2 Son fórmulas, de igual modo lo son P1 P2, P1 v P2
y P1 ⇒ P2
• P(z) es una fórmula que involucra una variable de dominio z,
también son fórmulas
∃ x (P(z)) y ∀ x (P(z))
A continuación, se demostrarán las expresiones de cálculo relacional
de domino aplicado a las consultas que fueron utilizadas para el cálcu-
lo relacional de las filas.
Para obtener los datos de las filas de la relación Empleados 1 conjun-
tamente con los de la relación Empleados 2, es necesario utilizar el

operador v(o), de tal manera que la expresión necesaria quedaría expre-
sada de la siguiente forma:
{<u, o, p> I <u, o, p> ∈ Empleados 1 v <u, o, p> ∈ Empleados 2)}
Si se desea obtener los datos de las filas correspondientes a los em-
pleados frecuentes tanto en la relación Empelados 1 y Empleados 2,
se usará el operador (y), por lo cual la expresión a utilizar seria la
siguiente:
{<u, o, p> I <u, o, p> ∈ Empleados 1 <u, o, p> ∈ Empleados 2)}
Si se desea obtener los datos correspondientes a las filas de los emplea-
dos de la relación Empleados 1 que no se encuentren contenidos en la
relación Empleados 2, se utiliza el operador ¬(no), de lo cual quedaría
constituida la siguiente expresión.
{<u, o, p> I <u, o, p> ∈ Empleados 1 ¬ (<u, o, p> ∈ Empleados 2))}
Considerando que se desea obtener los datos de las filas de la relación
Empleados 1 cuyo valor del atributo codigo_dep sea 1, se utiliza la si-
guiente expresión:
{<u, o, p> I <u, o, p> ∈ Empleados 1 d=1)}
Si se desea obtener todos los cargos que desempeñan los empleados
registrados en la relación Empleados 1, se debe utilizar el operador de
existe (∃), por lo que su expresión quedaría estructurada de la siguiente
manera:
{<p> I ∃ u, o, d (<u, o, p, d> ∈ Empleados 1)}
Si se desea obtener tanto el nombre como el cargo de los empleados
que laboran en el departamento cuyo valor del campo codigo_dep es 1,
es necesario utilizar la siguiente expresión.
{<o, p> I ∃ u, d (<u, o, p, d> ∈ Empleados 1 d=1)}
Ahora para realizar una combinación natural entre las filas de la rela-
ción Empleados 1 y la relación Departamentos, la expresión del cálculo
relacional se logrará de la siguiente manera:
{<ue, oe, p, nd, id, od, c> I ∃ nd(<ue, oe, p, nd> ∈ Empleados 1 ∃ od, c(<nd,
od, c>∈ Departamentos))}
2.7. Teoría de la normalización y sus objetos
Diseñar una base de datos consiste en representar y personalizar un

escenario del mundo real, mediante la utilización de objetos y reglas
que son proporcionados por el mismo modelo de datos que se esté

utilizando, como la prohibición de determinadas agrupaciones o la po-
sibilidad de introducir algunas restricciones.
Cuando se realiza el diseño de una base de datos, utilizando un
modelo relacional, se pueden obtener distintas soluciones desarrolla-
das en diferentes esquemas relacionales, que, aunque no todos tengan
similitudes, algunos se representan con mayor realismo que otros.
En esta sección se expondrá la teoría de la normalización, la cual
propone enfrentar y resolver problemas de bases de datos de forma
objetiva, detallando como llevar a cabo la normalización en un dise-
ño de base de datos relacional, dando a conocer las características y
propiedades con las que debe contar el diseño relacional para lograr
una personificación apropiada con la realidad además de cuáles son
los inconvenientes que se pueden presentar al realizar un mal diseño.
Considerando una relación denominada Pedidos, que almacene da-
tos referentes a los pedidos que son realizados por clientes, en el cual
se registran una referencia y una fecha de pedido, los mismos que
son representados por los campos referencia_ped y fecha_ped, además
que los artículos que se requieren para cada pedido se almacenan en
la relación Articulos considerando como datos su código, descripción,
número de unidades requeridas y el precio unitario, los cuales so re-
presentados por los siguientes campos respectivamente: codigo_art,
descrip_art, cantidad_art y pvp_art. La clave principal en esta relación
está determinada por el encadenamiento de los atributos referencia_
ped y codigo_art. Sin embargo, esta relación presenta varios problemas
de los cuales se menciona los siguientes:
• Existe una gran cantidad de datos repetidos, debido a que la
fecha del pedido se estaría repitiendo si en cada pedido se re-
quieren diferentes artículos, de igual manera si un mismo ar-
tículo es requerido en varios pedidos se repetirán los atributos
descrip_art y pvp_art.
• Alteraciones de inserción, debido a que no es aceptable incluir
en una base de datos, los datos de ciertos artículos que no
existan en algún pedido, luego de establecer el atributo refe-
rencia_ped parte de la clave principal de la relación. Además,
debido a la regla de integridad de una entidad, ningún atributo
que sea parte de la clave principal puede tener un valor nulo.
determinada por el encadenamiento de los atributos referencia_ped y codigo_art. Sin
embargo, esta relación presenta varios problemas de los cuales se menciona los siguientes:
• Existe una gran cantidad de datos repetidos, debido a que la fecha del pedido se
estaría repitiendo si en cada pedido se requieren diferentes artículos, de igual
manera si un mismo artículo es requerido en varios pedidos se repetirán los
atributos descrip_art y pvp_art.
• Alteraciones
Por tanto, de alinserción,
ingresar debido a que noque
un pedido es aceptable
involucre incluir en artículos
varios una base de
datos,
requerirá que se incluyan varias filas en la base de datos.luego de
los datos de ciertos artículos que no existan en algún pedido,
establecer el atributo referencia_ped parte de la clave principal de la relación.
• Alteraciones en las modificaciones, ya que si se intentara mo-
Además, debido a la regla de integridad de una entidad, ningún atributo que sea
dificar el precio o la descripción de cualquiera de los artícu-
parte de la clave principal puede tener un valor nulo. Por tanto, al ingresar un
los que
pedido queinvolucre
ya hayavarios sido artículos
registrado en algún
requerirá que se pedido,
incluyan se lo tendría
varias filas en la
que hacer
base de datos. en diferentes filas de la relación para evitar que se
produzca
• Alteraciones en inestabilidades.
las modificaciones, De la misma
ya que manera
si se intentara sucedería
modificar si se
el precio o la
pretendiera
descripción modificar
de cualquiera la artículos
de los fecha deque unyapedido
haya sido en registrado
el que seenhan algún
pedido, se lo tendría
registrado variosque artículos.
hacer en diferentes filas de la relación para evitar que se
produzca inestabilidades.
• Alteraciones de eliminación,De la misma manera
esto se sucedería
producesi seyapretendiera
que, si modificar
se in-
la fecha de un pedido en el que se han registrado varios
tenta eliminar un pedido de la base de datos y así mismo un artículos.
• Alteraciones
artículo de queeliminación,
esté vinculadoesto seaproduce ya que,
ese pedido, se sieliminarían
se intenta eliminar
de estaun
pedido de la base de datos y así mismo un artículo que esté vinculado a ese pedido,
relación todas las filas de artículos que son requeridos en dicho
se eliminarían de esta relación todas las filas de artículos que son requeridos en
pedido. De igual manera si se necesita eliminar algún artículo
dicho pedido. De igual manera si se necesita eliminar algún artículo que se
que se vinculados
encuentren encuentren vinculados
a diferentes a diferentes
pedidos, se debería depedidos,
eliminar se
unadebería
línea por
de eliminar
cada pedido. una línea por cada pedido.
Pedidos
referencia_ fecha_ped codigo_art descrip_art cantidad_ pvp_art
ped art
P001 10/09/2015 A0025 Teclado 4 8.00
P001 11/10/2015 A0026 Mouse Inalámbrico 12 13.5
P002 12/11/2015 A0027 Disco Duro Samsung 17 85.00
P003 13/12/2015 A0028 Impresora Canon 20 300.50
P004 10/09/2015 A0029 Monitor Samsung 10 375.50
P004 11/10/2015 A0030 Portátil HP 5 800.00
P004 12/11/2015 A0025 Teclado 15 8.00
Tabla 23: Relación Pedidos
En este tipo de relación se demuestra todos estos problemas ya que se guardan situaciones
En este(pedidos
diferentes tipo deyrelación
artículos) se demuestra
en una todos estos problemas ya que se
relación semejante.
guardan situaciones diferentes (pedidos
Existe un procedimiento formal que se adapta a cualquier y artículos) en una que
esquema relacional relación
se apega
a semejante.
la realidad, y de no ser así, nos muestra la manera para lograr que sea lo más idéntico
posibleExiste
del mundo
un real.
procedimiento formal que se adapta a cualquier esque-
ma relacional que se apega a la realidad, y de no ser así, nos muestra
la manera para lograr que sea lo más idéntico posible del mundo real.
El procedimiento mencionado anteriormente es la teoría de la nor- 67
malización, ya que facilita la realización de esquemas relacionales sin
redundancias, por lo tanto, no presentan los problemas que se habían
El procedimiento mencionado anteriormente es la teoría de la normalización, ya que
descrito
facilita anteriormente.
la realización de esquemas relacionales sin redundancias, por lo tanto, no presentan
Si se hubiera
los problemas realizado
que se habían unanteriormente.
descrito proceso de normalización a la relación
anterior,
Si se hubiera se hubiera tenido
realizado un en de
proceso cuenta el siguiente
normalización diseño.anterior, se hubiera
a la relación
tenido en cuenta el siguiente diseño.
Pedido linea Pedido Articulo
#Referencua_Ped #Referencia_Ped #Codigo_Art
Fecha_Ped #Codigo_Art ~ Descrip_Art
Cantidad_Art Pvp_Art

Figura. 39: Diseño de modelo relacional
En
Endiseño
diseñorelacional anterioranterior
relacional se han guardado
se handiferentes hechos
guardado en relaciones
diferentes desiguales.
hechos en
Se puede establecer
relaciones desiguales. a la teoría de la normalización como una técnica formal, que permite la
organización de los datos que pueden ayudar a determinar los errores en un diseño
Se puede establecer a la teoría de la normalización como una técni-
relacional y de igual manera presente la manera de corregirlos.
ca formal, que permite la organización de los datos que pueden ayudar
La teoría de la normalización está fundamentada bajo el concepto de forma normal.
a determinar
Se considera quelos un errores en un diseño
diseño relacional de base relacional
de datos sey encuentra
de igualdentro
manera
de los
presente la
parámetros de manera
una formadenormal
corregirlos.
definida si este cumple con un conjunto específico de
La teoría de la normalización está fundamentada bajo el concepto
limitaciones.
Realmente hay
de forma seis formas normales:
normal.
•SePrimera formaque
considera normal
un diseño relacional de base de datos se encuen-
Segunda
tra •dentro deforma
los normal
parámetros de una forma normal definida si este
• Tercera
cumple con un forma normal específico de limitaciones.
conjunto
• Forma normal de Boyce/Codd
• Cuartahay
Realmente forma normal
seis formas normales:
•• Quinta forma normal
Primera forma normal
En la siguiente figura se podrá apreciar que algunas relaciones se encuentran en primera
• Segunda forma normal
forma normal, de aquellas algunas se hallan en segunda forma normal, de estas únicamente
• Tercera forma normal
una porción está en tercera forma normal, y así sucesivamente; es decir que en la segunda
forma• normal
Forma normal demás
se proporciona Boyce/Codd
limitaciones que en la primera forma normal, la tercera
• Cuarta forma normal
forma normal más que la segunda forma normal, etc. Por tanto, la quinta forma normal es
la que• asigna
Quinta forma normal
las limitaciones más fuertes.
RELACIONES EN PRIMERA
En la siguiente figura se podráFORMA
apreciarNORMAL que algunas relaciones se en-
RELACIONES EN SEGUNDA
cuentran en primera forma normal,FORMA NORMAL de aquellas algunas se hallan en
segunda forma normal, deRELACIONES
estas Eúnicamente
N TERCERA FORMA una porción está en ter-
NORMAL
cera forma normal, y así sucesivamente; es decir que en la segunda
forma normal se proporcionaRELACIONES EN FNBC
más limitaciones que en la primera forma
normal, la tercera forma normal más que la segunda forma normal,
RELACIONES E N C UARTA
FORMA NORMAL
etc. Por tanto, la quinta forma normal
RELACIONES EN
es la que asigna las limitaciones
más fuertes. QUINTA FORMA
NORMAL
Figura. 40: Representación de las formas normales
68

En la siguiente figura se podrá apreciar que algunas relaciones se encuentran en primera
forma normal, de aquellas algunas se hallan en segunda forma normal, de estas únicamente
una porción está en tercera forma normal, y así sucesivamente; es decir que en la segunda
forma normal se proporciona más limitaciones que en la primera forma normal, la tercera
92
forma normalZeamás que la segunda
M, Honores J, Rivas Wforma normal, etc. Por tanto, la quinta forma normal es
la que asigna las limitaciones más fuertes.
RELACIONES EN PRIMERA
FORMA NORMAL
RELACIONES EN SEGUNDA
FORMA NORMAL
RELACIONES EN TERCERA FORMA
NORMAL
RELACIONES EN FNBC
RELACIONES EN CUARTA

FORMA NORMAL
RELACIONES EN
QUINTA FORMA
NORMAL
Figura. 40: Representación de las formas normales
Para llegar a comprender las formas normales, es necesario que pre-

viamente se conozca el concepto de dependencia funcional, el cual se 68

lo expondrá en el siguiente punto.
3.7.1. Concepto de dependencias funcionales

“Una dependencia funcional es una restricción entre dos conjuntos de
atributos de la base de datos.” [17]
La teoría de la normalización se fundamenta del concepto de depen-
dencia funcional, de lo cual se expondrán varios tipos:
3.7.1.1. Dependencia funcional
Si se establecen los subconjuntos X e Y en una relación, se hablaría
de que Y tiene dependencia funcional de X es decir que X se encuentra
involucrado con Y, únicamente si cada valor correspondiente a X con-
tiene un único valor de Y.
Esta dependencia queda representada de la siguiente forma:
X→Y
Por ejemplo, considerando la relación Articulo con sus atributos, codi-
go_art, descrip_art, pvp_art, en donde el campo codigo_art, determina
la descripción y su precio del mismo debido a que al proporcionar un
código de un artículo se conseguirá obtener una única descripción y
precio. Lo cual se ve expresado de la siguiente manera.
codigo_art → descrip_art
codigo_art → pvp_art
De igual manera en la relación Linea_pedidos con sus campos, refe-
rencia_ped, codigo_art, cantidad_art, de los cuales el dúo de atributos
referencia_ped y codigo_art, se establece el campo cantidad_art, debido
X→Y
Por ejemplo, considerando la relación Articulo con sus atributos, codigo_art, descrip_art,
pvp_art, en donde el campo codigo_art, determina la descripción y su precio del mismo
debido a que al proporcionar un código de un artículo se conseguirá obtener una única
Análisis
descripción y precio. del modelo
Lo cual relacional yde
se ve expresado de la
lossiguiente
elementosmanera.
que lo integran 93
codigo_art → descrip_art
a que por cada pedido identificado por el campo referencia_ped y por
codigo_art → pvp_art
cada artículo identificado por el campo codigo_art,
De igual manera en la relación Linea_pedidos con sus solo existe
campos, una can-
referencia_ped,
tidad, dicho de otra manera, por cada línea de pedido únicamente
codigo_art, cantidad_art, de los cuales el dúo de atributos referencia_ped y codigo_art, se
necesita un valor especifico de unidades, es por esto que:
se establece el campo cantidad_art, debido a que por cada pedido identificado por el
campo referencia_ped y por cada artículo
referencia_ped, identificado
codigo_art por el campo codigo_art, solo
→ cantidad_art
existe una cantidad,
El grafo o tambiéndichollamado
de otra manera,
diagramapor cada
de línea de pedido únicamente
dependencias se necesita
funcionales es
un valor especifico de unidades, es por esto que:
una herramienta útil para describir estas dependencias, en donde se
simboliza una agrupación referencia_ped, codigo_arty →
de atributos lascantidad_art
dependencias funcionales
existentes entre ellos.
El grafo o también llamado diagrama de dependencias funcionales es una herramienta útil
Dado a que para cada pedido identificado por una referencia existe
para describir estas dependencias, en donde se simboliza una agrupación de atributos y las
únicamente una fecha
dependencias funcionales en que
existentes fueellos.
entre realizado, surge la siguiente depen-
dencia
Dado funcional.
a que para cada pedido identificado por una referencia existe únicamente una fecha
referencia_ped
en que fue realizado, surge la → fecha_ped
siguiente dependencia funcional.
referencia_ped → fecha_ped
s
1 codigo_art 1
~
1 fecba_ped j .--1
cu-=--t_ped~I
Figura. 41: Diagrama de dependencias funcionales
3.7.1.2. Dependencia funcional completa

Definidos los subconjuntos de atributos X e Y en una relación se indica
que, Y conlleva una dependencia funcional completa de si, la cual de-
pende funcionalmente de X, pero esta no depende de ningún subcon-
junto de X, lo que se representa de la siguiente manera: 69

X ⇒Y
Tomando el ejemplo, con la relación Linea_pedidos y sus atributos,
referencia_ped, codigo_art, cantidad_art, se consigue plantear si la de-
pendencia funcional
(referencia_ped, codigo_art) → cantidad_art
Esta dependencia estará completa si el atributo cantidad_art tiene de-
pendencia de los atributos, referencia_ped, codigo_art y no de uno de
ellos por separado, es decir si las siguientes dos dependencias funcio-
nales no son ciertas:
referencia_ped → cantidad_art
codigo_art → cantidad_art
La primera de las dos dependencias funcionales anteriores no es ver-

dadera, debido a que un pedido identificado por su referencia (referen-
cia_ped) puede tener diferentes cantidades de artículos requeridos; de
hecho, esta situación se repetirá siempre que el pedido involucre algu-
nas líneas de pedido, es decir, siempre que el pedido requiera distintos
artículos.
Por otro lado, la segunda dependencia funcional, será verdadera si
por cada artículo identificado por su código (codigo_art) solo pudiera
existir una cantidad solicitada para dicho artículo. Sin embargo, ya
que se puede solicitar un artículo en varios pedidos en los cuales se
puede solicitar grandes cantidades de dicho artículo, la dependencia
funcional conveniente tampoco es verdadera.
Dado que ambas dependencias funcionales desarrolladas no son ver-
daderas, se puede decir que la dependencia funcional
(referencia_ped, codigo_art) → cantidad_art
Es completa por lo que se constituye de la siguiente manera:
(Referencia_Ped, Codigo_Art) ⇒ cantidad_art
Cabe recalcar, que las de pendencias funcionales completas son gene-
ralmente simbolizadas partiendo la flecha de un rectángulo en el cual
constan más de un atributo.
3.7.1.3. Dependencia funcional mutua o interdependencia

Si tenemos las siguientes dependencias funcionales X → Y e Y → X de
forma paralela en una relación, se diría que entre los atributos X e Y
existe una dependencia funcional recíproca o interdependencia, la cual
se representa de la siguiente forma:
X↔Y

Por ejemplo, si se tiene la relación Libro con los siguientes atributos,
Por ejemplo, si isbn_lib,
#codigo_lib, relación Libro
se tiene latitulo_lib, con los siguientes
paginas_lib, atributos, #codigo_lib,
editorial_lib:
isbn_lib, titulo_lib, paginas_lib, editorial_lib:
Libro
codigo_lib isbn_lib titulo_lib paginas_lib editorial_lib
Lib001 0130417173 Ingeniería de Software 205 McGraw Hill
Lib002 0140418184 Programación Web 306 McGraw Hill
Lib003 0150419195 Fundamentos de Oracle 407 Paraninfo, S.A.
Lib004 0160420206 Auditoria de Sistemas 508 Paraninfo, S.A.
Tabla 24: Reacio Libro
se presentarán las dependencias funcionales que se describe a continuación.

codigo_lib → isbn_lib
isbn_lib → codigo_lib
Dado un libro identificado por un código, este tendrá un único valor de ISBN, o
inversamente, si se tiene un libro que se identifica por su ISBN, este tendrá un único
código. Esto se debe a que ambos atributos son claves candidatas de las cuales unas de

Por ejemplo, si seAnálisis
tiene del
la modelo Libro ycon
relaciónrelacional loselementos
de los siguientes
que atributos, 95
lo integran #codigo_lib,
isbn_lib, titulo_lib, paginas_lib, editorial_lib:
se presentarán las dependenciasLibro funcionales que se describe a conti-
nuación.
codigo_lib isbn_lib titulo_lib paginas_lib editorial_lib
Lib001 0130417173 Ingeniería codigo_lib → isbn_lib
de Software 205 McGraw Hill
Lib002 0140418184 Programación Web
isbn_lib → codigo_lib 306 McGraw Hill
Dado un libro identificado por un código, este tendráParaninfo,
Lib003 0150419195 Fundamentos de Oracle 407 un único S.A.valor
Lib004 0160420206 Auditoria de Sistemas 508 Paraninfo, S.A.
de ISBN, o inversamente, si se tiene un libro que se identifica por su
Tabla 24: Reacio Libro
ISBN, este tendrá un único código. Esto se debe a que ambos atributos
seson
presentarán
claveslas dependencias
candidatas defuncionales
las cuales que se describe
unas de estasa continuación.
dos podrán ser selec-
codigo_lib → isbn_lib
cionadas como clave principal. Pues ahora, al otorgarse las dependen-
isbn_lib → codigo_lib
cias funcionales en ambos sentidos, se podría decir que los atributos
Dado un libro identificado por un código, este tendrá un único valor de ISBN, o
codigo_lib si
inversamente, e isbn_lib
se tiene unconservan
libro que se una dependencia
identifica funcional
por su ISBN, recíproca
este tendrá o
un único
interdependencia:
código. Esto se debe a que ambos atributos son claves candidatas de las cuales unas de
estas dos podrán ser seleccionadas codigo_lib
como clave↔ isbn_lib
principal. Pues ahora, al otorgarse las
dependencias funcionales en ambos sentidos, se podría decir que los atributos codigo_lib e
isbn_lib
3.7.1.4.conservan una dependencia
Dependencia funcional
funcional recíproca o interdependencia:
transitiva
Teniendo una relación R (X, codigo_lib
Z) en la ↔cual
isbn_lib
se ven presentes las siguien-
3.7.1.4. Dependencia funcional
tes dependencias funcionales: transitiva
Teniendo una relación R (X, Z) en la cual se ven presentes las siguientes dependencias
X→Y
funcionales:
Y→Z
X→Y
Y
Y→ →Z X
Por lo tanto, Z contiene una dependencia Y→X funcional transitiva con rela-
ción
Por aXa
lo tanto, Z través
contienede unaY,dependencia
además se simboliza
funcional de lacon
transitiva siguiente
relación aforma.
X a través de
Y, además se simboliza de la siguiente forma. X-→Y
Considerando la relación Vehículos X - →con Y los atributos, #matricula, mar-
Considerando la relación
ca, modelo, color. Vehículos con los atributos, #matricula, marca, modelo, color.
Vehiculos
matricula Marca modelo color
AAC-0123 Chevrolet Aveo Family Gris
AEC-0123 Ford F-150 FX4 Azul
AMC-0123 Hyundai Accent Blanco
CD-0123 Kia Rio Stylus Rojo
Tabla 25: Relación Coche
EnEn
estaesta relación
relación se ven presentes
se ven presentes las siguienteslas siguientesfuncionales:
dependencias dependencias funcio-
nales: matricula → marca
matricula
matricula→→modelo
marca
matricula →
matricula →modelo
color
matricula → color
71

Debido a que, teniendo vehículo que se identifica por su matrícula, este
pertenece
Debido a unavehículo
a que, teniendo sola marca,
que se de igual por
identifica manera pertenecerá
su matrícula, a un aúnico
este pertenece una
sola marca, de igual manera pertenecerá a un único modelo y un único color. Por depen-
modelo y un único color. Por lo cual se ve presente la siguiente lo cual
se vedencia
presentefuncional.
la siguiente dependencia funcional.
modelo → marca
modelo → marca
Ya que
Ya aque
cadaamodelo de vehículo
cada modelo delevehículo
correspondele una sola marca. una sola marca.
corresponde
Todas las dependencias funcionales mencionadas
Todas las dependencias funcionales mencionadas anteriormente se pueden representar se
anteriormente a
través del siguiente grafo:
pueden representar a través del siguiente grafo:

color
Si se Si
presentan las siguientes
se presentan lasdependencias
siguientes funcionales:
dependencias funcionales:
matricula → marca
matricula → marca
modelo → modelo
modelomodelo → modelo
→ color
Se puede decir→que
modelo color
el atributo marca tiene una dependencia funcional transitiva con relación a al
atributo matricula
Se puede decirmediantequeel modelo y se representa
el atributo marcadetiene
la siguiente manera:
una dependencia funcional
matrícula -→ marca
transitiva con relación a al atributo matricula mediante el modelo y se
3.7.1.5. Dependencia multivaluada
representa de la siguiente manera:
Teniendo una relación R (X, Z), se podría decir que, Y tiene una dependencia multivaluada de otro
atributo de X o que X multidetermina a Ymatrícula
si por cada-→ marca
valor de X se establece un conjunto definido
de valores de Y, así mismo dicho conjunto es individual de cualquier valor que contenga otro
atributo Z el cual
3.7.1.5. tiene dependencia
Dependencia del valor de X. Estas dependencias multivaluadas se
multivaluada
representan
Teniendode la forma
una siguiente:
relación R (X, Z), se podría decir que, Y tiene una depen-
X→→Y
dencia multivaluada de otro atributo de X o que X multidetermina a
Por ejemplo, si se tiene la relación Cursos con los atributos, curso, profesor, texto, en la cual se
Y siquepor
presenta por cada valor
cada uno de losde X se
cursos queestablece
se van a dar,un conjuntoquedefinido
los profesores de valores
lo van a impartir y los
libros que serán utilizados. Tanto los atributos Profesor y Texto son asignados convalor
de Y, así mismo dicho conjunto es individual de cualquier que
múltiples
valores hacia un mismo valor de curso. Se ha establecido una norma que
contenga otro atributo Z el cual tiene dependencia del valor de X. Estas sugiere que todos los
profesores de un curso puedan usar cualquier libro de texto que se haya asignado a curso que
dependencias multivaluadas se representan de la forma siguiente:
dictara.
X→→Y
Cursos
Por ejemplo, si se tiene la relación Cursos con los atributos, curso,
Curso profesor texto
profesor,Case
Herramientas texto, en la Bertha
cual Mazón
se presenta que ypor
Análisis cada
Diseño uno de los cursos
de Sistemas
que se van a dar, losMariuxi
profesores
Zea queHerramientas
lo van a impartir y los libros que
cases y sus Aplicaciones
serán utilizados. Tanto los atributos Metodológicas
Profesor y Texto son asignados
Aplicación de Sistemas
con múltiples valoresJoffre
haciaHonores
un mismo Fundamentos
valor de de Sistemas
curso. SeOperativos
ha establecido
Operativos Milton Valarezo Administración de sistemas Operativos
Tabla 26 : Relación Con Dependencias Multivaluadas
72
de valores de Y, así mismo dicho conjunto es individual de cualquier valor que contenga otro
atributo Z el cual tiene dependencia del valor de X. Estas dependencias multivaluadas se
representan de la forma siguiente:
X→→Y
Por ejemplo, si se tiene la relación Cursos con los atributos, curso, profesor, texto, en la cual se
Análisis
presenta que por cada uno dedellos
modelo
cursosrelacional
que se vany de los los
a dar, elementos queque
profesores lo van a impartir y 97
lo integran los
libros que serán utilizados. Tanto los atributos Profesor y Texto son asignados con múltiples
una
valoresnorma
hacia un que
mismo sugiere
valor de quecurso.todos los profesores
Se ha establecido una normadeque
unsugiere
curso quepuedan
todos los
usar cualquier libro de texto que se haya asignado a curso quea dictara.
profesores de un curso puedan usar cualquier libro de texto que se haya asignado curso que
dictara.
Cursos
Curso profesor texto
Herramientas Case Bertha Mazón Análisis y Diseño de Sistemas
Mariuxi Zea Herramientas cases y sus Aplicaciones
Metodológicas
Aplicación de Sistemas Joffre Honores Fundamentos de Sistemas Operativos
Operativos Milton Valarezo Administración de sistemas Operativos
Tabla 26 : Relación Con Dependencias Multivaluadas
Como se observa en la tabla anterior, el atributo curso asigna múlti-

ples valores tanto de profesor como de texto y que además estos dos
atributos no tienen dependencias entre sí. Sin embargo, en un curso, 72

existirá un conjunto de profesores que lo van dictar y de igual manera
un conjunto de textos que serán utilizados, lo cual es realizado a través
de las siguientes dependencias multivaluadas:
curso → → profesor
curso → → texto
3.7.1.6. Dependencia de reunión

Se dice que una relación tiene una dependencia de reunión cuando
esta se puede arreglar sin que se pierda información partiendo de una
mezcla de cualquiera de sus proyecciones. Suele ser difícil descubrir
estas dependencias.
En un segundo nivel se aprecian sus proyecciones con dos atribu-
tos (binarias). Luego, su mezcla se efectúa en dos fases: de las cuales
en la primera se alistan sus dos primeras proyecciones binarias y des-
pués el resultado es mesclado con la tercera proyección binaria. Dado
que el resultado es justamente equivalente a la relación de partida, esta
relación original presenta una dependencia de reunión. Por lo cual se
indica que para cada relación declarada la clave principal estará con-
formada por todos los atributos correspondientes a cada relación.
mezcla se efectúa en dos fases: de las cuales en la primera se alistan sus dos primeras
proyecciones binarias y después el resultado es mesclado con la tercera proyección binaria.
Dado que el resultado es justamente equivalente a la relación de partida, esta relación
original presenta una dependencia de reunión. Por lo cual se indica que para cada relación
98 Zea M,principal
declarada la clave Honores J,estará
Rivas W
conformada por todos los atributos correspondientes a
cada relación.
Vendedor Electrodoméstico Marca
Jonathan Lavadora G
Jonathan Cocina G
Jonathan Lavadora 1
Julia Lavadora G
! l
Vendedor Electrodoméstico Vendedor Marca Electrodoméstico Marca
Jonathan Lavadora Jonathan G Lavadora G

Jonathan Cocina Jonathan B Cocina G
»>
Julia Lavadora Julia G Lavadora l
~
Vendedor
l
Electrodoméstico Marca
fonathan Lavadora G
Jonathan Lavadora l
Jonathan Cocina G
Jonathan Cocina l
Julla Lavadora G
Figura. 43: Comprobación de dependencia de reunión
3.7.2. Análisis y aplicación de las diferentes formas normales: for-

ma normal y la forma normal de Boyce/Codd
En esta sección se efectuará un análisis de cada una de las formas 73

normales.
3.7.2.1. Primera forma normal

Se considera que una relación está en primera forma normal cuan-
do todos sus elementos son atómicos, es decir, si estos no contienen
grupos iterativos. Además, se puede declarar un grupo iterativo como
un atributo o como un conjunto de atributos que contengan valores
múltiples.
Para poder eliminar un grupo iterativo, o, dicho de otra manera,
para convertir una relación en primera forma normal, se debe suprimir
de la relación de origen todos aquellos atributos que formen parte del
grupo iterativo, logrando así crear una nueva relación utilizando la cla-
ve principal de la relación de partida y de igual manera cada atributo
del grupo iterativo.

3.7.2. Análisis y aplicación de las diferentes formas normales: forma normal y la
forma normal de Boyce/Codd
En esta sección se efectuará un análisis de cada una de las formas normales.
La clavePrimera
3.7.2.1. de la nueva
forma normalrelación generalmente consiste en la vinculación
de la clave principal de laestá
Se considera que una relación en primera
relación forma normal
original con lacuando
clavetodos sus elementos
del grupo ite-
son
rativo. atómicos, es decir, si estos no contienen grupos iterativos. Además, se puede declarar
un grupo iterativo como un atributo o como un conjunto de atributos que contengan valores
Por ejemplo, teniendo la siguiente relación:
múltiples.
Pedidos (codigo_ped, fech_ped, codigo_art, descrip_art, cantidad_art,
Para poder eliminar un grupo iterativo, o, dicho de otra manera, para convertir una relación
pvp_art)
en primera forma normal, se debe suprimir de la relación de origen todos aquellos atributos
queSe puede
formen parteobservar
del grupo la información
iterativo, logrando referente
así crear unaa nueva
un pedido
relación yutilizando
a todosla
clave
los principal de
artículos quela relación de partida y de
son requeridos enigual manera cada atributo
él, presentando por del
cadagrupo iterativo.
artículo
La clave de lalos
solicitado, nueva relación generalmente
siguientes datos: código,consistedescripción,
en la vinculación de la clave
número deprincipal
uni-
de la relación original con la clave del grupo iterativo.
dades solicitadas y precio. Los atributos codigo_art, descrip_art, can-
Por ejemplo, teniendo la siguiente relación:
tidad_art y pvp_art forman un grupo iterativo ya que si se considera
Pedidos (codigo_ped, fech_ped, codigo_art, descrip_art, cantidad_art, pvp_art)
como clave principal de la relación Pedidos el atributo codigo_ped, para
Se puede observar la información referente a un pedido y a todos los artículos que son
elrequeridos
mismo pedido identificado
en él, presentando por artículo
por cada su referencia
solicitado,codigo_ped,
los siguientes se podrán
datos: código,
solicitar diversos artículos, de los cuales cada uno
descripción, número de unidades solicitadas y precio. Los atributos codigo_art, de ellos tendrá sus
descrip_art,
atributos cantidad_art
codigo_art, y pvp_art forman
descrip_art, un grupo iterativo
cantidad_art y pvp_art. ya que si se considera
como clave
Esta principal no
relación de laestá
relación Pedidos elforma
en primera codigo_ped,
atributonormal, ya para
queelse mismo
encuen-pedido
identificado por su referencia codigo_ped, se podrán
tra en un grupo iterativo. Para lograr convertirla en primera forma nor-solicitar diversos artículos, de los
cuales cada uno de ellos tendrá sus atributos codigo_art, descrip_art, cantidad_art y
mal, será necesario suprimir de la relación Pedidos cada uno de sus
pvp_art.
atributos
Esta relaciónque no forman parteforma
está en primera del grupo
normal,iterativo, logrando
ya que se encuentra endeun esta
grupomane-
iterativo.
raPara
crear una
lograr nueva relación,
convertirla en primera aforma la cual se la
normal, denominara
será Linea_pedidos.
necesario suprimir de la relación
APedidos
más de cada
esounosededeberá
sus atributos que forman
determinar una parte del grupo
nueva iterativo,
relación que logrando de esta
contendrá
manera crear una nueva relación, a la cual se la denominara
los cuatro atributos del grupo iterativo junto a la clave principal de Linea_pedidos. A más de la
eso
se deberá determinar una nueva relación que contendrá
relación de origen codigo_ped, siendo esta la clave de la nueva relación los cuatro atributos del grupo
iterativo junto a la clave principal de la relación de origen codigo_ped, siendo esta la clave
obtenida, adicionalmente el atributo clave del grupo iterativo codigo_
de la nueva relación obtenida, adicionalmente el atributo clave del grupo iterativo
art quedando así el siguiente diseño relacional:
codigo_art quedando así el siguiente diseño relacional:
Pedido linea Pedido
#Codigo_Ped #Codigo_Ped
Fech_Ped #Codigo_Art
Descrip_Art
Cant_Art
Pvp_Art
Figura. 44: Diseño Relacional
Otro aspecto
Otro aspecto a considerar
a considerarpara que unaque
para relación
unaeste en primera
relación esteforma normal, esforma
en primera que los
atributos contengan valores únicos para cada registro, es decir que en cada dominio existan
normal, es que los atributos contengan valores únicos para cada regis-
valores únicos. Por ello si una relación no está en primera forma normal se debe eliminar
tro, es decir
de ella que
todos los en cada
atributos quedominio existan
tengan valores valores
múltiples únicos.
en cada Porla ello
tupla de si una
relación. Para
relación no está en primera forma normal se debe eliminar de ella todos
los atributos que tengan valores múltiples en cada tupla de la relación.
74
Para
eliminar esto, se debe colocarlos en una nueva relación y relacio-
100 Zea M, HonoresFUNDAMENTOS
J, Rivas W DE BASE DE DATOS 2015
eliminar esto,asetravés
narla debe colocarlos
de la claveenprimaria
una nueva relación
a la relacióny relacionarla
de origen. a través de la clave
primaria a
eliminar esto, la relación
Asísepordebe de origen.
colocarlos
ejemplo si seentiene
una nueva relación
la relación y relacionarla
Alumnos a través
con los de la clave
siguientes
Así
primariaporcampos,
ejemplo si se de
a la relación tiene la relación
origen.
codigo_alum, Alumnosycon
nombre_alum de loscodigo_alum,
los siguientes campos,
asignaturas_alum, cuales
nombre_alum campoy si
Así porelejemplo asignaturas_alum,
se tiene la relaciónde
asignaturas_alum, los cuales
Alumnos
almacena conel los
las campo asignaturas_alum,
siguientes
asignaturas campos,
en las que almacena
codigo_alum,
reci-
las asignaturas
nombre_alum en las que recibe
asignaturas_alum,
y cada clases cada alumno.
de los cuales el campo asignaturas_alum, almacena
be clases alumno.
las asignaturas en las que recibe clases cada alumno.
Alumnos
codigo_alum nombre_alum
Alumnos asignaturas_alum
1 codigo_alum Jonathan
nombre_alum Matemáticas
asignaturas_alum
2
1 Andrés
Jonathan Física, Algebra
Matemáticas
3
2 Jaime
Andrés Geometría, Física
Física, Algebra
Tabla 27: Relación Alumnos
3 Jaime Geometría, Física
Como Como
se observa en la relación
se observa Alumnos,
Tabla
en la relación los registros
27: Relación
Alumnos, los dos
Alumnos y tres dos
registros tienen dominios
y tres tie- que
contienen
Como nen varios
se observa valores
dominios que
en la por tanto
contienen
relación la relación
Alumnos,varioslosno se
valores encuentra
pordos
registros tantoen primera forma
la relación
y tres normal.
no se
tienen dominios que
Para convertir
encuentra
contienen esta relación
en primera
varios valores en la
forma
por tanto primera forma
normal.no
la relación Para normal se
convertir en
se encuentra crea
esta una nueva
relación
primera relación
en normal.
forma la
Asignatura, en donde
Para convertir
primera forma cada asignatura
esta relación
normal enselacrearesponderá
primera a una
forma
una nueva clave principal.
normal
relación seAsignatura,
crea una nueva
en don-relación
Asignatura,
de cadaen donde cada asignatura
asignatura responderá
responderá a una clave
a una clave principal.
principal.
Alumnos
codigo_alum nombre_alum
Alumnos
1 codigo_alum Jonathan
nombre_alum
2
1 Andrés
Jonathan
3
2 Jaime
Andrés
3 Tabla 28: Relación Alumnos
Jaime
Asignaturas
Tabla 28: Relación Alumnos
codigo_asig nombre_asig
Asignaturas
1 codigo_asig Matemáticas
nombre_asig
2
1 Física
Matemáticas
3
2 Algebra
Física
4
3 Geometría
Algebra
4 Tabla 29: Relación Alumnos
Geometría
3.7.2.2 Segunda forma normal Tabla 29: Relación Alumnos
Se considera
3.7.2.2 Segunda que forma
una relación
normal se encuentra en segunda forma normal si primeramente esta
3.7.2.2
en considera
primera forma Segunda
normal, forma
además normal
cada atributo que noforma
pertenezca
Se que una relación se encuentra en segunda normala siuna clave candidata
primeramente esta
guarda Se
una considera
dependencia que una
funcionalrelación
con se encuentra
relación a dicha en segunda
clave, lo que forma normal
indicaría que cada uno
en primera forma normal, además cada atributo que no pertenezca a una clave candidata
de sus si primeramente
atributos tiene que esta en primera
depender de toda forma
la clave normal,
mas no además
solo de cada
una atributo
parte de ella. Para
guarda una dependencia funcional con relación a dicha clave, lo que indicaría que cada uno
lograr que no pertenezca aenuna claveforma
candidata guarda una dependencia fun-
de sus convertir la relación
atributos tiene segunda
que depender de toda la normal,
clave mas se no
necesita
solo deprescindir
una partededelaella.
relación
Para
al cional
atributo con
que relación
forma la a dicha
dependencia clave, lo
parcial que
y indicaría
determinar que
una cada uno
relación de
nueva sus
con ese
lograr convertir la relación en segunda forma normal, se necesita prescindir de la relación
atributo y con
al atributo queel forma
o los atributos del cual depende
la dependencia parcial ycomo clave principal.
determinar una relación nueva con ese
Siempre que una relación que se encuentra en primera forma
atributo y con el o los atributos del cual depende como clave principal. normal presenta una clave
principal, la cual se encuentra formada por un único
Siempre que una relación que se encuentra en primera forma normal atributo, de formapresenta
automática
una estará
clave
en su segunda forma normal. Asimismo, se considerará que se encuentran
principal, la cual se encuentra formada por un único atributo, de forma automática estará en su segunda
en su segunda forma normal. Asimismo, se considerará que se encuentran en su segunda
atributos tiene que depender de toda la clave mas no solo de una parte
de ella. Para lograr convertir la relación en segunda forma normal, se
necesita prescindir de la relación al atributo que forma la dependencia
parcial y determinar una relación nueva con ese atributo y con el o los
atributos del cual depende como clave principal.
Siempre que una relación que se encuentra en primera forma nor-
mal presenta una clave principal, la cual se encuentra formada por un
único atributo, de forma automática estará en su segunda forma nor-
mal. Asimismo, se considerará que se encuentran en su segunda forma
normal todas aquellas relaciones que se encuentren en primera forma
normal y que además no ostenten atributos.
Utilizando el esquema relacional logrado anteriormente, se tendrá
que la relación Pedidos ya se encuentra en su segunda forma normal
inicialmente por el hecho de estar en primera forma normal y contar
como clave principal con un único atributo. Mientras que en lo que res-
pecta a la relación denominada Linea_pedidos, para que logre estar en
su segunda forma normal se deberá verificar que todos sus atributos
que no son considerados clave, como lo son la descrip_art, cantidad_art
y pvp_art, respondan completamente a la clave principal, por lo tanto,
lo siguiente quiere decir que deben tener totalmente una dependencia
funcional con relación al par de atributos (codigo_ped, codigo_art):
(codigo_ped, codigo_art) ⇒ Descrip_art
(codigo_ped, codigo_art) ⇒ cantidad_art
(codigo_ped, codigo_art) ⇒ pvp_art
Primera dependencia funcional total: No es verdadera ya que la des-

cripción del artículo responde únicamente al código del mismo y no al
código del pedido que lo solicita, por ende, es considerada como ver-
dadera la dependencia parcial entre codigo_art → descrip_art. Por este
motivo se puede asegurar que la relación Linea_pedidos no se encuen-
tra en su segunda forma normal.
Segunda dependencia funcional total: Es considerada como ver-
dadera ya que la cantidad que es solicitada de un artículo por un pe-
dido no está determinada únicamente por el pedido con el que se está
tratando o el artículo que es requerido, sino por los dos. Es decir que
se tendría lo siguiente codigo_ped → cantidad_art, puesto que en un
pedido sería posible solicitar varias y distintas cantidades de artículos
descrip_art. Por este motivo se puede asegurar que la relación Linea_pedidos no se
encuentra en su segunda forma normal.
Segunda dependencia funcional total: Es considerada como verdadera ya que la cantidad
que es solicitada
102 de Zea
unM,artículo porW un pedido no está determinada únicamente por el
Honores J, Rivas
pedido conde el forma

que sesimilar,
está tratando
codigo_arto el →artículo que es requerido,
cantidad_art, debido a quesino
unpor los dos. Es decir
artículo
que se tendría
puede lo ser
siguiente codigo_ped
solicitado en diferentes → cantidad_art,
pedidos, de lospuesto
cuales que en un
a cada unopedido sería
posible solicitar varias
solicitará y distintas
cierta cantidadcantidades
de artículos.de artículos de forma similar, codigo_art →
cantidad_art, debido a que un artículo puedetotal:
Tercera dependencia funcional ser solicitado en diferentes
Es considerada pedidos, de los
verdadera
cuando los valores correspondientes
cuales a cada uno solicitará cierta cantidad de artículos. a los artículos no son siempre
los mismos para los pedidos. Es común que el valor de cada artículo
Tercera dependencia funcional total: Es considerada verdadera cuando los valores
sea el mismo para todos y cada uno de los clientes, es por esto que se
correspondientes
compruebaa los la
artículos no sonfuncional
dependencia siempre codigo_art
los mismos→para los pedidos.
pvp_art, motivo porEs común que
el valor de el
cada
cualartículo
tampoco seaseelcumple
mismoque paraaquel
todosatributo
y cada que
uno no
de es
losclave
clientes, es por esto que
pvp_art
se compruebavaya la dependencia
totalmente funcional
a depender de lacodigo_art pvp_art,otra
→ indicaría
clave, lo cual motivo
razón por el cual
tampoco se cumple que aquel atributo que no es clave pvp_art vaya totalmente
para que la relación no se encuentre en su segunda forma normal. Otra a depender
de la clave,manera
lo cual de observar
indicaría cuando
otra razónuna pararelación
que la se encuentra
relación no seenencuentre
su segunda en su segunda
forma normal es examinando su diagrama de dependencias funciona-
forma normal. Otra manera de observar cuando una relación se encuentra en su segunda
les.
forma normal es examinando su diagrama de dependencias funcionales.
codigo_art
11 cantidad_art
l
cantidad_art
1
J descrip_art, pvp_art 1
Si existieraFigura.
alguna flecha en la figura
45: Diagrama anterior quefuncionales
de dependencias cruce el área sobrante entre los atributos
que crean Silaexistiera
clave alguna
compuesta
flechayentodos aquellos
la figura anterior atributos que
que cruce el áreano son claves, por
sobran-
te entre los atributos que crean la clave compuesta y todos aquellos
atributos que no son claves, por consiguiente, existirán atributos que
requieren en su totalidad de la clave, por lo que la relación más conve-
niente no está en su segunda forma normal, como sucede en este caso.
Se transforma la relación Línea_pedidos a la segunda forma nor-
mal, para lo cual es necesario eliminar de la relación cada uno de sus
atributos que no requieran de la clave (descrip_art y pvp_art) y definir
en primera instancia una nueva relación con todos los atributos que
se suprimieron de la relación anterior y los que dependan de, codi-
go_art. Como se ha descrito en el ejemplo, los dos atributos requieren
del mismo codigo_art, por lo que no es indispensable definir una nueva
relación por cada uno de ellos, sino solamente una que contenga am-
relación más conveniente no está en su segunda forma normal, como sucede en este caso.
Se transforma la relación Línea_pedidos a la segunda forma normal, para lo cual es
necesario eliminar de la relación cada uno de sus atributos que no requieran de la clave
(descrip_art y pvp_art) y definir en primera instancia una nueva relación con todos los
atributos que se Análisis
suprimieron de larelacional
del modelo relacióny anterior y los que
de los elementos quedependan 103
lo integrande, codigo_art.
Como se ha descrito en el ejemplo, los dos atributos requieren del mismo codigo_art, por
bos atributos
lo que y el atributo
no es indispensable quenueva
definir una se requiera
relación porcomo clave.
cada uno De lo
de ellos, cual
sino se
solamente
representa en el siguiente esquema relacional.
una que contenga ambos atributos y el atributo que se requiera como clave. De lo cual se
representa en el siguiente esquema relacional.
Pedido LlneaPedldo Articulo

llCOdlgo_Ped #Codlgo_Ped llCodlgo_An
Feeh_Ped #Codlgo_Art _J Oescrlp_An
CanLArt Pvp_An
Figura. 46: Esquema relacional
3.7.2.3 Tercera forma normal

3.7.2.3
La terceraTercera formasenormal
forma normal fundamenta del concepto de dependencia transitiva (esto
La tercera forma normal
sucede cuando un atributo dependese fundamenta
funcionalmente del concepto
de otro y ninguno deesdependencia
parte de la clave),
por lo tanto,(esto
transitiva se dicesucede
que unacuando
relación está
un en tercera forma
atributo dependenormalfuncionalmente
solo si sus atributos
dependen
de otro yúnicamente
ningunoaes la clave
parte principal
de la mas no depor
clave), otros
loatributos.
tanto, se[18]dice que una
Para renunciar
relación está aenlastercera
dependencias
forma transitivas
normalsesolo debesidescartar de la relación
sus atributos que no se
dependen
encuentra en tercera forma normal el atributo que genera
únicamente a la clave principal mas no de otros atributos. [18] la dependencia transitiva y se
crea una relación que contenga los atributos transitivos conjuntamente con el atributo del
Para renunciar a las dependencias transitivas se debe descartar de
que requiere es decir mediante el cual conserva su transitividad. Y de esta manera se asume
la relación que no se encuentra en tercera forma normal el atributo que
la relación R (A1, A1, A3) junto a las siguientes dependencias funcionales:
genera la dependencia transitiva y se crea una relación que contenga
los atributos transitivos conjuntamente #A1 A2 con el atributo
A3 del que requiere
es decir
Existe unamediante
dependencia el funcional
cual conserva A3 con relaciónYade
transitivasudetransitividad. A1esta A3 tiene
manera
ya que
dependencia
se A2 y no Rla (A1,
asume laderelación tieneA1,directamente
A3) junto deaA1,
laslasiguientes
cual es la clave principal. Esto
dependencias
tendría solución pasando la relación a Tercera Forma Normal, utilizando el siguiente
Z
funcionales: /
esquema relacional: #A1 A2 A3
Z
R1 (A1, A2)
Existe una dependencia funcional transitiva de A3 con relación a A1

ya que A3 tiene dependencia deR2A2 (A2,
y A3)
no la tiene directamente de A1,
Suponiendo que la relación Auto con los atributos
la cual es la clave principal. Esto tendría solución (placa, marca,
pasandomodelo, color) de la
la relación
cual ya se había referido con anterioridad, en la cual marca
a Tercera Forma Normal, utilizando el siguiente esquema relacional: tiene una dependencia
funcional transitiva en relación a la placa A2)del modelo debido a que:
a través
R1 (A1,Z
placa modelo marca
R2 (A2, A3)
Suponiendo que la relación Auto con los atributos (placa, marca, mo-
delo, color) de la cual ya se había referido con anterioridad, en la cual
marca tiene una dependencia funcional transitiva en relación a la placa
77
a través del modelo debido a que:
Z
/
placa modelo marca
Z
Z
Por tal motivo, la relación antes descrita no se encuentra en tercera

forma normal y para convertirla a esta forma normal lo que se necesita
hacer es descartar de la relación Auto el atributo transitivo marca y
crear otra relación usando este atributo junto al que está condiciona-
do, por lo que este último es la clave principal de la nueva relación. Por
consiguiente, se tiene el esquema relacional descrito a continuación.
Auto (matrícula, modelo, color)
Z
Modelos (modelo, marca)
3.7.2.4 Forma normal de Boyce/Codd (FNBC)

El concepto inicial de Codd de tercera forma normal presentaba varios
fallos. Entre los cuales se puede mencionar que no trataba de forma
adecuada a una relación que contenga algunas claves candidatas, son
compuestas, y las claves candidatas coinciden (Presenta algún atribu-
to en común). De esta manera, se creó una forma normal más fuerte.
Se considera que una relación está en FNBC si tiene un determinante
que por sí mismo sea clave de la misma, y que por ende es una llave
candidata.
A1 A2 (A1, A2) A3
Z
Determinante Determinante
Por lo tanto, está comprobado que cualquier relación que se encuentre
en FNBC se encuentra en tercera forma normal.
Tomando en cuenta la relación R (A1, A2, A3) de la cual (A1, A2) A3
Z
y A3
Z
A2. Existen dos determinantes que son (A1, A2) y A3, entre las cuales
una solo es llave candidata (A1, A2), esto quiere decir que, la relación
no se encuentra en FNBC.
Para lograr que una relación este en FNBC lo que se debe realizar es
lo siguiente:
Establecer una clave usando la parte de la clave que es independiente
de A1 y cada uno de los atributos que no son principales A3.
R1 (A1, A3)
Se declara otra relación utilizando la otra parte de la clave que sobra
junto con el atributo secundario al cual se encuentra condicionado,
por lo que este último será la clave de la nueva tabla.
R2 (A3, A2)
R1 (A1, A3)
Se declara otra relación utilizando la otra parte de la clave que sobra junto con el atributo
secundario al cual se encuentra condicionado, por lo que este último será la clave de la
nueva tabla. Análisis del modelo relacional y de los elementos que lo integran 105
R2 (A3, A2)
Considerando la siguiente relación: Postal con sus atributos, dirección,
Considerando la siguiente
ciudad, cp. relación: Postal con sus atributos, dirección, ciudad, cp.
Postal
dirección Ciudad cp
Condado. 4 Quito 28809
Alborada. 5 Machala 28823
Los Sauces. 2 Machala 28823
El Bosque. 4 Guayaquil 28019
4. mil. 4 Guayaquil 28007
Tabla 30: Relación Postal
EnPostal
En la relación se posee
la relación lasse
Postal reglas
poseesemánticas descritas a continuación:
las reglas semánticas descritas a conti-
nuación:
• El mismo nombre de una calle puede presentarse en dos ciu-
dades distintas
• A Cada calle se le permitirá poseer un tramo en códigos posta-

les distintos
• No se podrá comprender dos ciudades en un mismo código pos-
tal
• No pueden existir dos ciudades con el mismo nombre
• Esta relación está en Tercera Forma Normal, pero no se en-
cuentra en FNBC, A razón de las siguientes dependencias fun-
cionales.
(dirección, ciudad) → cp
Cp → ciudad
Se cuenta con dos determinantes dirección y ciudad, las cuales repre-
sentan una clave candidata, pero cp no lo es, por lo cual es posible que
existan diversas tuplas utilizando el mismo cp. Convirtiendo la relación
a FNBC:
códigos (cp, ciudad)
Z
direcciones (dirección, cp)
3.7.2.5 Cuarta forma normal

Se considera que una relación se encuentra en cuarta forma normal
razón de las siguientes dependencias funcionales.
(dirección, ciudad) → cp
Cp → ciudad
Se cuenta con dos determinantes dirección y ciudad, las cuales representan una clave
candidata, pero cp no lo es, por lo cual es posible que existan diversas tuplas utilizando el
mismo cp. Convirtiendo la relación a FNBC:
códigos (cp, ciudad)
si la misma ya se encuentra en FNBC y que además no tenga depen-
dencias multivaluadas. Ya que estas suelen ocasionar problemas en el
direcciones (dirección, cp)
mantenimiento de la relación que las muestra. Los cuales se resuelven
dividiendo
3.7.2.5 Cuartalaforma
relación
normal que se muestra y las dependencias multivalua-
Se
das,considera
de tal que una relación
manera que si se seencuentra
tiene la en cuarta forma
relación R (A, normal
B, C) lasi cuan
la misma ya se
cuenta
encuentra en FNBC y que multivaluadas
con las dependencias además no tenga dependencias
A → →B y A →multivaluadas.
→ C, es posibleYa que estas
dividir
suelen ocasionar problemas en el mantenimiento de la relación que
esta relación en R1 (A, B) y R2 (A, C). Es notorio, que estas relacioneslas muestra. Los cuales
se resuelven dividiendo la relación que se muestra y las dependencias multivaluadas, de tal
comprenden los atributos con valores variados.
manera que si se tiene la relación R (A, B, C) la cuan cuenta con las dependencias
Dada la relación Cursos la cual contiene los atributos curso, profesor,
multivaluadas A → →B y A → → C, es posible dividir esta relación en R1 (A, B) y R2
texto
(A, C). presenta las estas
Es notorio, que dependencias multivaluadas
relaciones comprenden los atributos con valores variados.
Dada la relación Cursos la cual contiene los→atributos
curso → profesorcurso, profesor, texto presenta las
dependencias multivaluadas curso → → texto
Por ende, no se encuentrancurso → → profesor
en cuarta forma norma, lo cual se resuelve
estableciendo las relaciones siguientes curso → → texto
Por ende, no se encuentran en cuarta forma norma, lo cual se resuelve estableciendo las
relaciones siguientes:
Cursos 1
Curso Profesor
Herramientas Case Bertha Mazón
Herramientas Case Mariuxi Zea
Aplicación de Sistemas Operativos Joffre Honores
Aplicación de Sistemas Operativos Milton Valarezo
Cursos 2
Curso Texto
Herramientas Case FUNDAMENTOS
Análisis y DiseñoDE BASE DE DATOS
de Sistemas
2015
Herramientas Case Herramientas cases y sus Aplicaciones Metodológicas
Aplicación de Sistemas Operativos Fundamentos de Sistemas Operativos
Aplicación de Sistemas Operativos Administración de sistemas Operativos
Tabla 31: Relaciones en Cuarta Forma normal
3.7.2.6. Quinta forma normal
Se considera que una relación esta quinta forma normal cuando por cada dependencia de 79
3.7.2.6. Quinta forma normal
reunión, su proyección
Se considera que unacomprende una esta
relación clave quinta
de la relación
forma inicial.
normalEs realmente
cuandodifícil
por
identificar las dependencias de reunión, además que no es muy común el uso de esta forma
cada dependencia de reunión, su proyección comprende una clave de
normal. Es por esto que el resultado de aplicar esta forma normal entra en discusión con
la relación inicial. Es realmente difícil identificar las dependencias de
mucha frecuencia debido a la dificultad que involucra la división de la relación inicial en
unreunión, además que
número transcendental deno es muy
nuevas común el uso de esta forma normal.
relaciones.
Considerando la relación que se expuso aplicar
Es por esto que el resultado de esta forma
en el apartado 3.7.1.6, normal
a razón entra
de que enlas
proyecciones
discusión con figura 28frecuencia
de lamucha no comprenden la clave
debido de dificultad
a la la relación de inicio,
que se reconoce
involucra la
que no se de
división encuentra en Quinta
la relación FormaenNormal
inicial por lo que,
un número para solucionar de
transcendental estenuevas
pequeño
problema, la relación vendedores-electrodomésticos-marcas tendrá que dividirse en las tres
relaciones que conforman las proyecciones en esa misma figura.
3.7.3 Ventajas e inconvenientes que justifican una desnormalización de las tablas.

Valoración en diferentes supuestos prácticos.
Ocasionalmente es favorable suavizar las reglas de normalización, es por esto que una de
relaciones.
Considerando la relación que se expuso en el apartado 3.7.1.6, a
razón de que las proyecciones de la figura 28 no comprenden la clave
de la relación de inicio, se reconoce que no se encuentra en Quinta For-
ma Normal por lo que, para solucionar este pequeño problema, la rela-
ción vendedores-electrodomésticos-marcas tendrá que dividirse en las
tres relaciones que conforman las proyecciones en esa misma figura.
3.7.3 Ventajas e inconvenientes que justifican una desnormaliza-

ción de las tablas. Valoración en diferentes supuestos prácticos.
Ocasionalmente es favorable suavizar las reglas de normalización, es
por esto que una de las tareas que se suelen realizar en el diseño lógi-
co una vez que ya se ha obtenido un esquema lógico normalizado, es
justamente pensar en introducir redundancias controladas entre otras
modificaciones en el esquema para lograr optimizar las prestaciones
del sistema.
Existen dos tipos de bases de datos que sobresalen especialmente
debido al tipo de operaciones que resaltan en ellas las cuales son: las
bases de datos en las que generalmente se toma en cuenta más las
consultas y aquellas en las cuales se efectúan con mayor frecuencia las
modificaciones (altas, bajas y alteraciones). En el segundo tipo de ba-
ses de datos, es más adecuado realizar disminuciones de redundancia,
sin sugerir que se suavicen las reglas de normalización. Aunque en las
bases de datos en las que se considera habitualmente las consultas,
suele ser apropiado que en ciertos casos se realice la desnormalización
de la misma de tal forma que las consultas se den de una forma más
satisfactoria.
En la fase de diseño lógico llegar al menos a la tercera forma nor-
mal, y de esta manera obtener un esquema relacional con una estruc-
tura más sólida y que carezca de redundancias. En ocasiones sucede
que las bases de datos que se normalizan de esta manera no ofrecen
la máxima eficacia, por lo que es recomendable desnormalizar ciertas
relaciones (tablas) con el objetivo de perfeccionar su prestación. Sin
embargo, el hecho de que bajo ciertas circunstancias sea favorable des-
normalizar, en ningún caso es aceptable excluir la etapa de normaliza-
ción del diseño lógico.
La desnormalización genera las desventajas descritas a continuación:
•
Puede ocasionar que se detengan las modificaciones, por lo
cual no es apropiado que se efectúe en las bases de datos en
las que predominan las modificaciones.
• Por cada redundancia que se crea, a alguien le corresponde
asegurar la integridad de los datos, y de esta manera evitar
que se presenten inconsistencias. Por cada escenario que surja
se puede proponer dos opciones, la primera implica que sean
justamente los programas de aplicación los encargados de res-
guardar la integridad de los datos y la segunda opción y quizás
la más favorable, es la de crear triggers (es un procedimiento
almacenado en la base de datos que reacciona por cada actua-
lización que se realice a la base de datos.) también conocidos
como disparadores, que cumplan con la tarea de resguardar la
integridad de los datos.
• Es así que gracias al trabajo de este procedimiento se asegura
que todas y cada una de las copias redundantes se conserven
equilibradas.
• Se complicará la agregación de tablas nuevas que refieran da-
tos futuros a causa del crecimiento de la aplicación, en los cua-
les se hubieran ejecutado desviaciones con respecto al modelo
de datos normalizado.
• Se dice que, si se realzan varias consultas a una base de datos
en las cuales se comprenden más de cinco o seis tablas, se su-
giere una desnormalización. Obviamente, esto solo sucedería
si se estuviera hablando de una base de datos en las que las
actualizaciones son más habituales.
Seguidamente se analizarán escenarios en los que generalmente se
debe medir su eventual desnormalización.
3.7.3.1. Combinar relaciones de uno a uno

Se obtiene mayores beneficios agrupando en una misma tabla todos
los atributos correspondientes a dos tablas involucradas en una rela-
ción de uno a uno. Por ejemplo, si se cuenta con las tablas Instituto
y Director las cuales están vinculadas por medio de una relación de
1:1, lo más común seria realizar lo indicado en el esquema relacional
descrito a continuación.
las que las actualizaciones son más habituales.
3.7.3.1. Combinar
Seguidamente relaciones
se analizarán de uno aen
escenarios unolos que generalmente se debe medir su eventual
Se obtiene mayores beneficios agrupando en una misma tabla todos los atributos
desnormalización.
correspondientes a dos tablas involucradas en una relación de uno a uno. Por ejemplo, si se
cuenta
3.7.3.1.con las tablas
Combinar Instituto
relaciones
Análisis del modelo Director
dey uno a unolas ycuales
relacional están vinculadas
de los elementos por medio de una
que lo integran 109
relación
Se obtiene mayores beneficios agrupando en una misma tabla todos los descrito
de 1:1, lo más común seria realizar lo indicado en el esquema relacional atributosa
continuación.
correspondientes a dos tablas involucradas en una relación de uno a uno. Por ejemplo, si se
cuenta con las tablas Instituto y Director las cuales están
lnsbtuto Directorvinculadas por medio de una
#Nombre_lns #NIF_Dir
relación de 1:1, lo más común seria realizar lo indicadoNombre_Dir
Dir_lns en el esquema relacional descrito a
continuación. CP_lns
Localidad ins
Anbguedad_Dir
NIF_Drr
Figura. 47: Relación de uno a uno (1:1)
Sabiendo que se ingresan datos con frecuencia en ambas tablas y que esto sucede al mismo
Sabiendo
tiempo para loquecual se ingresanrealizar
es necesario datosuna con frecuencia
combinación de en ambas
ambas tablas
relaciones y que
(tablas) y
esto
que por sucede al mismo
otro lado cuando Figura. 47:
tiempo
se ingresa Relación
datos para de uno a
lo cual
por separado, uno (1:1)
es necesario
es posible acoplarlasrealizar una
en una misma
combinación
tabla, como
Sabiendo quelose
que depresenta
se ambas
ingresan relaciones
datosa con frecuencia(tablas)
continuación: en ambas ytablas
quey por otrosucede
que esto lado alcuando
mismo
tiempo para lo datos
se ingresa cual es por
necesario realizar es
separado, unaposible
combinación de ambasen
acoplarlas relaciones (tablas)ta-
una misma y
que por otro lado cuando se ingresa datos
bla, como lo que se presenta a continuación:por separado, es posible acoplarlas en una misma
tabla, como lo que se presenta a continuación:
lnsbtuto
Nom_lns
Oor_lns
Figura. 48: CP_lns
Relación Instituto
Localldad_lns
NIF_Oor
Nom_Dor
Anl)Ouedad_01r
Figura. 48: Relación Instituto

81

3.7.3.2. Duplicar atributos que no son llave en relaciones de uno
a varios 81
Para hacer algo diferente a lo que se hizo en la sección anterior con
respecto a las relaciones de 1:1, se puede contener en una composición

de dos tablas todos aquellos atributos de la tabla a la cual le corres-
3.7.3.2. Duplicar atributos que no son llave en relaciones de uno a varios
ponde la cardinalidad uno (1:) en la tabla a la cual le corresponde la
Para hacer algo diferente a lo que se hizo en la sección anterior con respecto a las
cardinalidad n (:n). Por citar un ejemplo, si se dispone de una tabla
relaciones de 1:1, se puede contener en una composición de dos tablas todos aquellos
enatributos
la quedeson almacenados
la tabla los datoslade
a la cual le corresponde los departamentos
cardinalidad con alolaque
uno (1:) en la tabla cual le
cuenta
correspondeuna la
empresa y otra
cardinalidad que
n (:n). Porcontenga los datos
citar un ejemplo, si se de cadadeuno
dispone de los
una tabla en la
que son almacenados
empleados que laboranlos datos
en de los departamentos
ellos, inicialmente conselopresentaría
que cuenta unaelempresa
siguien-y otra
teque contengarelacional
esquema los datos de cada uno de los empleados que laboran en ellos, inicialmente se
presentaría el siguiente esquema relacional
Empleados Departamentos
#NSS_emp ~m----- #num_dep
nom_emp nombre_dep
dir emo dir_dep
tel=emp
num_dep
Figura. 49: Relación de uno a muchos (1:n)
Sabiendo que con frecuencia las consultas que involucra presentar los datos de empleados
también requieren presentar los datos del departamento en el que se encuentra laborando
cada uno de ellos, por lo cual es conveniente consolidar los atributos comprendidos entre
las dos tablas en una solo, de lo cual se tendría como resultado la siguiente tabla
presentaría
Para el siguiente
hacer algo esquema
diferente relacional
a lo que se hizo en la sección anterior con respecto a las
relaciones de 1:1, se puede contener en una composición de dos tablas todos aquellos
atributos de la tabla a la cual le corresponde la cardinalidad uno (1:) en la tabla a la cual le
corresponde la cardinalidad n (:n). Por citar un ejemplo, si se dispone de una tabla en la
que son almacenados los datos de los departamentos con lo que cuenta una empresa y otra
que contenga los datos de cada uno de los empleados que laboran en ellos, inicialmente se
presentaría el siguiente esquema relacional
Sabiendo que con frecuencia las consultas que involucra presentar los
datos de empleados también requieren presentar los datos del departa-
mento en el que se encuentra laborando cada uno de ellos, por lo cual
también requieren presentar los datos del departamento en el que se encuentra laborando
es conveniente
cada uno de ellos, consolidar
por lo cual eslos atributos
conveniente comprendidos
consolidar entre
los atributos las dos entre
comprendidos ta-
las dos
blas entablas
unaensolo,
una solo,
de lodecual
lo cual
sesetendría
tendría como
como resultado la siguiente
resultado tabla
la siguiente tabla
Empelado
~NSS_Emp
Nom_Emp
01rEmp Telf_Emp
también requieren presentar los datos del Num_Dep.
departamento en el que se encuentra laborando
Nom_Dep
cada uno de ellos, por lo cual es conveniente consolidar los atributos comprendidos entre
Dsr_Oep
las dos tablas en una solo, de lo cual se tendría como resultado la siguiente tabla
Figura. 50: Tabla Empleados
3.7.3.3. Duplicar atributos en relaciones de varios a varios

3.7.3.3.
Cuando se Duplicar
presenta unaatributos
relación conen unarelaciones
cardinalidad de varios
de varios a varios
a varios entre dos tablas,
Cuando se presenta una relación con una cardinalidad deuna
en el momento que se realice el diseño lógico surgirá necesariamente tabla con
varios a va-los
rios entre dos tablas, en el momento que se realice el diseño lógico sur-la
atributos clave de las entidades afines en conjunto con los atributos correspondientes a
relación. Si se necesita obtener información de la relación con dicha cardinalidad de varios
girá necesariamente una tabla con los atributos clave de las entidades
a varios usualmente será de carácter Figura.obligatorio realizar la composición de las tres tablas,
50: Tabla Empleados
afines en conjunto
lo que considerado desdeconun los atributos
punto correspondientes
de vista tecnológico a la caro.
resulta ser muy relación. Si
Es posible
3.7.3.3.
se Duplicar
necesita atributosinformación
obtener en relaciones de devarios
laque a varios con dicha cardinalidad
relación
evadir esto guardando algunos de los atributos forman parte de las tablas iniciales en la
Cuando
nueva se presenta
tabla una relación con una N:M.
cardinalidad de varios a varios entre dosesquema
tablas,
de varios aque resulta
varios de la relación
usualmente será de de lo cual
carácter resultaría el siguiente
obligatorio realizar la
enrelacional.
el momento que se realice el diseño lógico surgirá necesariamente una tabla con los
composición
atributos clave dede laslas tres tablas,
entidades afines enlo que considerado
conjunto con los atributos desde un puntoade
correspondientes la
vista tecnológico resulta ser muy caro. Es posible evadir
relación. Si se necesita obtener información de la relación con dicha cardinalidad esto guardan-
de varios
adovarios usualmente
algunos de los seráatributos
de carácterque
obligatorio
forman realizar
parte la de
composición
las tablas de las tres tablas,
iniciales en
lo que considerado desde un punto de vista tecnológico
la nueva tabla que resulta de la relación N:M. de lo cual resultaría resulta ser muy caro. Es posibleel
evadir esto guardando algunos de los atributos que forman parte de las tablas iniciales en la
siguiente
nueva esquema
tabla que resulta relacional.
de la relación N:M. de lo cual resultaría el siguiente esquema
relacional. Figura. 51: Relación de muchos a muchos
Pedidos Linea_pedidos Articulos
#codigo_ped 1--,__m llcodigo_ped #cod_art
fech_ped ilcod_art descrip_art
cant_art pvp_art 82

descrip_art
pvp_art
imp_lin
Figura. 51: Relación de muchos a muchos
Generalmente cuando se solicita información de la línea de pedido,

82
es necesario presentar tanto la descripción de cada artículo como su
valor, por lo cual se tiene que verificar la eventualidad de vincular los
atributos antes mencionados (descrip_art y pvp_art) en la tabla Linea_
pedidos.
3.7.3.4. Incluir datos derivados

En ciertas ocasiones una consulta debe obtener datos que se generen
partiendo de otros, si este dato ya ha sido previamente calculado la
consulta será más eficiente. Tomando DE en cuenta el esquema
DATOS relacional
FUNDAMENTOS BASE DE 2015
del apartado anterior (3.7.3.3) en la cual se puede incrementar en la

tabla Linea_pedidos el valor correspondiente al atributo imp_lin si se
Generalmente cuando se solicita información de la línea de pedido, es necesario presentar
determina que se trata de un dato que es consultado con mayor fre-
tanto la descripción de cada artículo como su valor, por lo cual se tiene que verificar la
cuencia.deElvincular
eventualidad dato mencionado anteriormente
los atributos antes es producto
mencionados (descrip_art y de la multipli-
pvp_art) en la
tablacación entre el atributo cantidad_art de la tabla Linea_pedidos con el
Linea_pedidos.
3.7.3.4. Incluir
valor datos derivados
del atributo pvp_art de la tabla Artículo.
En ciertas ocasiones una consulta debe obtener datos que se generen partiendo de otros, si
este dato ya ha sido previamente calculado la consulta será más eficiente. Tomando en
3.7.3.5. Partición de tablas
cuenta el esquema relacional del apartado anterior (3.7.3.3) en la cual se puede incrementar
Entabla
en la una tabla grande
Linea_pedidos generalmente
el valor correspondientedurante la imp_lin
al atributo ejecución si sede la mayoría
determina que
se de
trataprocesos
de un dato soloque
considera una con
es consultado porción
mayorreducida
frecuencia.deElladatomisma. Lo cual
mencionado
anteriormente
se puede es productoel
acelerar detiempo
la multiplicación entre elde
de ejecución atributo cantidad_art
los procesos de la tabla
almacenando
Linea_pedidos
en una misma con el valor
tabladeltodos
atributo pvp_art
los queArtículo.
de la tabla
atributos suelen ser utilizados con
3.7.3.5. Partición de tablas
mayor frecuencia, y dejando a los demás atributos en una sola tabla. Si
En una tabla grande generalmente durante la ejecución de la mayoría de procesos solo
se tiene
considera unauna tabla
porción pequeña
reducida de laen la cual
misma. Lo secualrealizan
se puedelos ingresos
acelerar más de
el tiempo ha-
bituales,
ejecución de loscada ingreso
procesos en dicha
almacenando en tabla serátabla
una misma realizado
todos loscon mayor
atributos queagilidad.
suelen
ser En
utilizados con mayor
esta tabla frecuencia,
existen ciertosy dejando a los que
atributos demás atributos
son en una con
utilizados sola tabla.
más Sifre-
se tiene una tabla
cuencias enpequeña en la cualysepara
las consultas realizan los ingresos
mejorar más habituales,
el resultado de lascada ingreso
consultas
en dicha tabla será realizado con mayor agilidad.
en apropiado realizar una partición vertical de la tabla para lo cual se
En esta tabla existen ciertos atributos que son utilizados con más frecuencias en las
debe tener
consultas y para presente que toda
mejorar el resultado de partición
las consultasnecesita contener
en apropiado realizaratributos que
una partición
vertical
son de la tabla
clave para lo cual
principal de seladebe tener
tabla presente
para que toda
de esta partición
manera necesita
estar en contener
la capa-
atributos
cidadque deson clave principal
rescatar de la tabla circunstancia
bajo cualquier para de esta manera la estar en la capacidad
información de
inicial.
rescatar bajo cualquier circunstancia la información inicial.
T
•A1(Cl.;)ve)
A2
A3
- A4 ~
AS
T1
T2
1
•A1(Cbve)
A2 1
~ •A1(Clave) 1
A4 1
A3 1 AS 1
Figura. 52: Partición vertical
Si se cuenta con
Figura. 52:una tabla que almacena
Partición vertical los datos correspondientes a los empleados de una
empresa la cual contiene entre sus datos, número de seguridad social, nombre, dirección y
Si se cuenta con una tabla que almacena los datos correspondientes a
teléfono y en la otra, datos que referentes a su labor en una empresa cargo y cualificación y
se sabe que los datos personales tienen mayores ingresos que los que se refieren al trabajo
del empleado, se puede determinar dos segmentos verticales: de los cuales en uno constara
los datos personales y en el otro los datos referentes a su trabajo. Estas dos particiones
necesariamente deben contener la clave principal que será el número de seguridad social
Se debe tener siempre presente que la segmentación vertical soporta los siguientes
problemas:
los empleados de una empresa la cual contiene entre sus datos, núme-
ro de seguridad social, nombre, dirección y teléfono y en la otra, datos
que referentes a su labor en una empresa cargo y cualificación y se
sabe que los datos personales tienen mayores ingresos que los que se
refieren al trabajo del empleado, se puede determinar dos segmentos
verticales: de los cuales en uno constara los datos personales y en el
otro los datos referentes a su trabajo. Estas dos particiones necesaria-
mente deben contener la clave principal que será el número de segu-
ridad social
Se debe tener siempre presente que la segmentación vertical sopor-
ta los siguientes problemas:
Se debe incrementar una tuplas en ambas tablas T1 y T2, por cada re-
gistro que ingresa a la FUNDAMENTOS DE BASE
tabla T, Y de la misma manera por cada2015
DE DATOS registro

que se elimine en la tabla T se deberán eliminar dos tuplas en ambas
tablas T1 y T2.
Se debe incrementar una tuplas en ambas tablas T1 y T2, por cada registro que ingresa a la
tabla T, Para
Y de laconsultar datos
misma manera porcorrespondientes a unoeno la
cada registro que se elimine varios
tabla Tregistros
se deberánde
las tablas T1 o T2es preciso realizar
eliminar dos tuplas en ambas tablas T1 y T2. una composición de las dos tablas
Para consultar
T1 y T2. datos correspondientes a uno o varios registros de las tablas T1 o T2es
preciso realizar una composición de las dos tablas T1 y T2.
T
- AHOavel
A2
-
-
A3
TI A4 TZ
16-- AS Al(Oave}
A2 A2
A3 A3
A4 A4
AS AS
Figura. 53: Partición horizontal
Se debe tener siempre en cuenta que una partición horizontal es tolerante a los siguientes
Se debe tener siempre en cuenta que una partición horizontal es
problemas:
tolerante a losunsiguientes
Cada que se ingrese problemas:
nuevo registro a la tabla T es necesario que se incremente una tupla
en cualquiera de las dos tablas T1 o T2, yaregistro
Cada que se ingrese un nuevo a la tabla
que las aplicaciones se T es necesario
fundamentan que se
del criterio
de partición que se haya seleccionado.
incremente una tupla en cualquiera de las dos tablas T1 o T2, ya que
Si se
lasnecesita obtener losse
aplicaciones datos de uno de las tablas
fundamentan T1 y T2 yde
del criterio quepartición
se encuentran en se
que la tabla
haya
T, se deberá tener conocimiento de a que tabla se tiene que acudir T1 o T2, puesto que los
seleccionado.
programas necesitan conocer el criterio de partición que se haya acogido.
Si se efectuar
Si se necesita necesita obtener
consultas quelos datos de
involucran uno de las
la obtención tablas
de datos T1tablas
de las y T2 T1 y que
o
T2,sees encuentran
necesario usar elenoperador
la tabla T, se
unión, deberá
el cual resultatener conocimiento
ser muy caro, desde el depuntoa de
que
vista tecnológico.
tabla se tiene que acudir T1 o T2, puesto que los programas necesitan
Si conocer
es necesarioel unir los datos
criterio obtenidos de
de partición quela se
tabla T1 con
haya datos provenientes de otras
acogido.
tablas, es preciso efectuar tantas uniones como sea necesario.
Si se necesita
Posteriormente puedeefectuar
cambiar laconsultas
frecuencia deque involucran
utilización de lasla obtención
filas de datos
correspondientes a
ambas tablas, por lo que puede ser necesario que se reformen las tablas, esto provoca que
surjan alteraciones en los aplicativos que usen los datos de estas tablas.
3.7.3.6. Atributos repetidos en la misma fila
La primera forma normal se encarga de suprimir los conjuntos que se vean repetidos los
cuales se presentan en una relación, provocando la creación de una nueva tabla que
Figura. 53: Partición horizontal
Se
de debe tener siempre
las tablas T1 oen cuenta
T2, que una partición
es necesario usar horizontal es tolerante
el operador unión,a los siguientes
el cual re-
problemas:
sulta ser muy caro, desde el punto de vista tecnológico.
Cada que se ingrese un nuevo registro a la tabla T es necesario que se incremente una tupla
Si es necesario unir los datos obtenidos de la tabla T1 con datos pro-
en cualquiera de las dos tablas T1 o T2, ya que las aplicaciones se fundamentan del criterio
venientes
de de se
partición que otras
haya tablas, es preciso efectuar tantas uniones como sea
seleccionado.
necesario.
Si se necesita obtener los datos de uno de las tablas T1 y T2 y que se encuentran en la tabla
T, se Posteriormente
deberá tener conocimiento
puededecambiar
a que tablalase frecuencia deT1
tiene que acudir o T2, puestode
utilización quelas
los
programas necesitan conocer a
filas correspondientes el ambas
criterio detablas,
particiónporque lo
se haya
que acogido.
puede ser necesario
Si se necesita efectuar consultas que involucran la obtención de datos de las tablas T1 o
que se reformen las tablas, esto provoca que surjan alteraciones en los
T2, es necesario usar el operador unión, el cual resulta ser muy caro, desde el punto de
aplicativos
vista que usen los datos de estas tablas.
tecnológico.
Si es necesario unir los datos obtenidos de la tabla T1 con datos provenientes de otras
tablas,
3.7.3.6.es preciso efectuarrepetidos
Atributos tantas uniones encomo sea necesario.
la misma fila
Posteriormente puede cambiar la frecuencia de utilización de las filas correspondientes a
La primera forma normal se encarga de suprimir los conjuntos que se
ambas tablas, por lo que puede ser necesario que se reformen las tablas, esto provoca que
vean alteraciones
surjan repetidos en losloscuales se presentan
aplicativos en una
que usen los datos relación,
de estas tablas. provocando la
creación de una nueva tabla que
3.7.3.6. Atributos repetidos en la misma fila contendrá los atributos que corres-
La primeraalforma
ponden normal repetido
conjunto se encarga adicionalmente
de suprimir los conjuntos
con la queclave
se vean repetidos de
principal los
cuales se presentan
la relación en una relación, provocando la creación de una nueva tabla que
de origen.
contendrá los atributos que corresponden al conjunto repetido adicionalmente con la clave
Si se tiene la tabla Universidad, en la cual serán almacenados por
principal de la relación de origen.
cada
Si universidad
se tiene el nombreendela su
la tabla Universidad, cualrector y sus vicerrectores:
serán almacenados por cada universidad el
nombre de su rector y sus vicerrectores:
Unlverdad
#nom_uni
rector
vicerrector
Figura. 54: Relación Universidad
Dado que por lo general una universidad cuenta con algunos vicerrectores (un máximo de
Dadoloque
tres), por lo general
que representa unarepetido,
un conjunto universidad cuenta
es por esto que lacon algunos
relación vicerrec-
en primera forma
tores (un
normal máximo
se vería de tres),
de la siguiente lo que representa un conjunto repetido, es
manera:
por esto que la relación FUNDAMENTOS
en primera forma DE BASE
normal seDE DATOS
vería 2015
de la siguien-
te manera:
84

Univerdadl Unlversidad2
r::nom_uni #nom_uni
rector vicerrector
Figura. 55: Relación en primera forma Normal
Que se cuente con los datos tanto del rector como los del vicerrector de cada universidad
Que se cuente con los datos tanto del rector como los del vicerrector de
implica unir ambas tablas y analizar alrededor de dos y cuatro filas de datos. Si se quiere
cada
evitar universidad implica
esto, lo que se necesita unir
hacer es ambas tablas
desnormalizar tal ycomo
analizar alrededor
se muestra deque
en el caso dosse
ydescribirá
cuatro afilas de datos. Si se quiere evitar esto, lo que se necesita hacer
continuación.
Como
es en este caso se conoce
desnormalizar que elsenúmero
tal como máximo
muestra en deel vicerrectores
caso que se de ladescribirá
universidad aes
de tres, lo que se debe hacer es concentrar todos los atributos en una misma relación.
Si se tiene lo siguiente, Universidad (nom_uni, rector, vicerrector1, vicerrector2,
vicerrector3) ocasionaría un problema en cada ocasión en la que el número de
vicerrectores con los que cuente una universidad sea menor a tres ya que dada esta
situación va a tener uno o varios atributos con valor nulo.
continuación.
Como en este caso se conoce que el número máximo de vicerrec-
tores de la universidad es de tres, lo que se debe hacer es concentrar
todos los atributos en una misma relación.
Si se tiene lo siguiente, Universidad (nom_uni, rector, vicerrector1, vi-
cerrector2, vicerrector3) ocasionaría un problema en cada ocasión en
la que el número de vicerrectores con los que cuente una universidad
sea menor a tres ya que dada esta situación va a tener uno o varios
atributos con valor nulo.
3.7.4. Desarrollo de diferentes supuestos prácticos de normaliza-

ción de datos incluyendo propuestas de desnormalización de datos
En la Sección de Ejercicios que ya han sido resueltos para el tema 2 se
proponen varias suposiciones prácticas de normalización, los cuales se
señalan al lector. Se puede encontrar más suposiciones de normaliza-
ción en la sección dedicada a ejercicios propuestos.
Resumen
• En una base de datos relacional, los datos son recolectados me-

diante relaciones, y estas a su vez son generalmente representadas
mediante tablas
• Una clave candidata, consiste en una agrupación de atributos que
identifican de manera única a cada fila perteneciente a la relación.
• En un modelo relacional se pueden distinguir dos tipos de res-
tricciones, que son las restricciones inherentes y las restricciones
semánticas.
• El álgebra relacional es un lenguaje formal de consultas a través
de bases de datos relacionales que compone la base del lenguaje de
consulta SQL grandiosamente usado
• Generalmente en todo par de relación, necesita ser relacionadas
con respecto a la unión, es decir que es necesario que sean de un
mismo grado y que sus atributos deben corresponder a un mismo
dominio.
• Las operaciones de la teoría de Conjuntos son: Unión, Intersección,
Diferencia, y Producto cartesiano
• Los operadores relacionales específicos son los siguientes: Opera-
dor de selección o restricción, Operador de proyección, Operador
de división, Operador de combinación.
• Existe una forma diferente de cálculo relacional conocida como cal-
culo relacional de dominós, en el cual se utilizan variables de domi-
nio propiamente, las mismas que adquieren valores del domino de
un atributo en vez de obtenerlas de una fila completa
• La teoría de la normalización, propone enfrentar y resolver proble-
[115]
mas de bases de datos de una forma objetiva e implacable, deta-

llando como llevar a cabo la normalización en un diseño de base de
datos relacional.
• Realmente hay seis formas normales: Primera Forma Normal, Se-
gunda Forma Normal, Tercera Forma Normal, Forma Normal de
Boyce/Codd, Cuarta Forma Normal, Quinta Forma Normal
• La teoría de la normalización se fundamenta del concepto de de-
pendencia funcional, la cuales pueden ser, completa, mutua o in-
terdependiente, transitiva, Multivaluada, de reunión
Modelo orientado a objetos
A continuación, se detalla el objetivo principal de cada contenido del

capítulo 4: Modelos Orientados a objetos.
En el apartado 4.1 se persigue contextualizar los modelos orientados
a objetos dentro del modelado UML
El objetivo del apartado 4.2 es el de exponer una descripción clara so-
bre el modelado de datos orientado a objetos, hablando así también de
los siguientes aspectos:
• Conceptos de objeto, clase, método, y mensaje
• Representación de clases UML
• Relaciones entre clases UML
En el apartado 4.3 se tiene por objetivo realizar una comparación entre
el modelo de clases con el modelo entidad relación
EL apartado 4.4 se orienta a describir los diagramas de objetos como
caso especial del diagrama de clases
Y por último, en el apartado 4.5 se tiene como objetivo principal el ex-
poner de forma clara una descripción sobre los modelos distribuidos
y los enfoques que se deben tener en consideración para realizar un
diseño
4.1. Contextualización del modelo orientado a objeto dentro del

modelado UML
Un lenguaje UML (Lenguaje de Modelo Unificado) sirve para diseñar

modelos y es independiente de los métodos de análisis y diseño. Ade-
[117]
más, permite dar un mejor soporte a la planeación y al control de pro-

yectos.
Las principales características que se deben tener en cuenta en el
UML son los bloques de construcción, reglas y mecanismos comunes
aplicados por medio de UML.
El lenguaje UML posee tres bloques de construcción principales:
• Elementos: Estos elementos son actor, casos de uso y límite de
un sistema.
• Relaciones: Son FUNDAMENTOS
las conexiones DEentro
BASElos DATOS 2015
DE distintos elementos.
• Diagramas: Encargados de agrupar las colecciones de elemen-
tos. [19] del modelo orientado a objeto dentro del modelado UML
4.1. Contextualización
Un En lenguaje UML (Lenguaje deestructuradas
las metodologías Modelo Unificado) una sirve aplicación
para diseñar modelos
(tipo de y esprogra-
independiente de los métodos de análisis y diseño. Además, permite dar un mejor soporte a
ma informático
la planeación diseñado
y al control para permitir a un usuario realizar todo tipo
de proyectos.
deLas trabajo),
principalesestá compuesta
características por tener
que se deben distintos
en cuenta componentes
en el UML son losde software
bloques de lla-
construcción,
mados reglas y mecanismos
generalmente comunesUn
módulos. aplicados
módulo por medio de UML.
realiza determinadas tareas
El lenguaje UML posee tres bloques de construcción principales:
de procesamiento, por lo que es importante utilizar datos concretos.
• Elementos: Estos elementos son actor, casos de uso y límite de un sistema.
Una •aplicación
Relaciones: está
Son lascompuesta
conexiones entropor distintos
los distintos módulos que realizan pe-
elementos.
queñas tareas. Los
• Diagramas: módulos
Encargados se relacionan
de agrupar las colecciones de entre sí realizándose
elementos. [19] llama-
En las metodologías estructuradas una aplicación (tipo
das de unos a otros. En estas llamadas los módulos se intercambian de programa informático diseñado
para permitir a un usuario realizar todo tipo de trabajo), está compuesta por distintos
datos
componentesy a veces devuelven
de software arquitectura
llamados generalmente de una aplicación
módulos. Un módulo realiza informática
determinadas
consta de un tareas de procesamiento,
módulo de control por loprincipal
que es importante
que utilizar
llamadatos concretos.
a varios módulos
Una aplicación está compuesta por distintos módulos que realizan pequeñas tareas. Los
subordinados. Estos módulos llaman a otros y así sucesivamente. La
módulos se relacionan entre sí realizándose llamadas de unos a otros. En estas llamadas los
arquitectura
módulos se intercambiande un programa
datos y a veces se devuelven
simboliza gráficamente
arquitectura mediante un
de una aplicación
informática consta de un módulo de control
diagrama de estructuras, en el que un rectángulo personifica principal que llama a varios módulos
un módu-
subordinados. Estos módulos llaman a otros y así sucesivamente. La arquitectura de un
loprograma
y las flechas que unen los módulos significan llamadas
se simboliza gráficamente mediante un diagrama de estructuras, en el que un del módulo.
Enrectángulo personifica
el diagrama deunestructuras
módulo y las flechas
queque unen los
vamos a módulos
mostrar significan llamadasde con-
el módulo
del módulo. En el diagrama de estructuras que vamos a mostrar el módulo de control
trol principal se llama A y llama a los módulos subordinados B y C; a
principal se llama A y llama a los módulos subordinados B y C; a su vez, b llama al D y al
suE,vez,y el Cbllama
llamaal F. al D y al E, y el C llama al F.
Figura. 56: Diagrama de Estructuras.
En las metodologías estructuradas es importante poner atención en los procesos o tareas

que se necesita llevar a cabo para resolución de un determinado problema, en el cual se
distribuyen estos procesos o tareas en módulos que las realizan. Para llevar a cabo estos
procesos es necesario que los módulos manejen ciertos datos. Los datos que se almacenan
de forma permanente se guardan en una base de datos, sobre la cual los diferentes módulos
Modelo orientado a objetos 119
En las metodologías estructuradas es importante poner atención

en los procesos o tareas que se necesita llevar a cabo para resolución
de un determinado problema, en el cual se distribuyen estos procesos
o tareas en módulos que las realizan. Para llevar a cabo estos procesos
es necesario que los módulos manejen ciertos datos. Los datos que se
almacenan de forma permanente se guardan en una base de datos,
sobre la cual los diferentes módulos realizan operaciones de consulta,
inserción, modificación y/o eliminación.
Los datos de una clase llevan el nombre de atributos y las opera-
ciones que se aplican sobre esos datos se llaman métodos. La ejecución
de todas las tareas encomendadas a un programa se logra mediante la
participación cooperativa de los objetos que constan en la aplicación.
Esta cooperación se da por medio de las llamadas de unos módulos
a otros, en el paradigma orientado a objetos, se consigue mediante el
envío de mensajes. Definimos un mensaje como una solicitud enviada
desde un método de un objeto hasta otro objeto, o él mismo ejecute
otro método.
La filosofía orientada a objetos provocó años más tarde un gran
cambio de paradigma. Este cambio permitiría un cuidado más estricto
a las técnicas brindando mayor seguridad a los datos que es preciso
operar. Las metodologías orientadas a objetos proponen que una apli-
cación informática es formada por diferentes objetos que interactúan
entre ellos. Un objeto vendría a ser una instancia de una clase y la cla-
se está compuesta por una serie de datos y un conjunto de operaciones
que se aplican sobre los datos. Los datos de una clase llevan el nombre
de atributos y las operaciones que se usan en los datos se denominan
métodos. Mediante la aportación conjunta de los objetos que se tiene
en la aplicación se logra la ejecución de los trabajos encargados a un
programa. Este conjunto se da por medio de las llamadas de un módu-
lo a otro, en el ejemplo orientado a objetos, se obtiene con el envío de
mensajes. Definimos un mensaje como una solicitud enviada desde un
método de un objeto hasta otro objeto.
Al desarrollar una aplicación en la filosofía orientada a objetos es
fundamental la preparación de diferentes diagramas. Se considera al
diagrama de clases como lo fundamental. Se construyen otros tipos de
diagramas como los que se muestran a continuación:
• Diagramas de objetos.
• Diagramas de casos de uso.

• Diagramas de secuencia.
• Diagramas de colaboración.
• Diagramas de actividad.
• Diagramas de estados.
• Diagramas de distribución.
• Diagramas de componentes. [19]
4.2. Modelo de datos orientado a objetos
Los datos del modelo orientado a objetos son considerados como un

incremento del modelo Entidad-Relación, es decir para poder entender
este modelo es preciso aprender anticipadamente ciertos significados,
que se ven a continuación.
4.2.1. Conceptos de objeto, clase, método y mensaje

Tal como se mostró al comienzo, una aplicación en la metodología
orientada a objetos consigue sus objetivos con la interacción de los
diferentes objetos.
Se define a un objeto como una entidad que permite mostrar un pro-
cedimiento preciso. Un objeto puede llegar a considerarse igual a una
ocurrencia de una entidad en el modelo Entidad-Relación. A continua-
ción, se muestran algunas características que definen a un objeto:
Su estado: El estado de un objeto es definido por una serie de pro-
piedades que tiene el objeto y los valores que se toman a cada instante.
En el caso de hablar del sistema de gestión de una biblioteca el objeto
puede ser un cualquier libro y su estado es determinado por el código,
ISBN, número de páginas, editorial, título y la situación de entregado
o no, junto con los valores que obtiene cada uno de los libros, por
ejemplo, el código “C1352”, título: Bases de datos relacionales, ISBN:
0987654456987, editorial “Fortuna”, con 250 páginas y situación de
entregado “Falso”.
Su comportamiento: El comportamiento de un objeto se da de-
bido a la forma en que actúa al recibir un mensaje de otro objeto,
sustituyendo su estado casualmente. El mensaje es una petición que
recibe un objeto para que se produzca una operación y cumplir con un
propósito. Por ejemplo, un objeto libro toma un mensaje en el que se
Modelo orientado a objetos 121
solicita que el libro sea traspasado, acción que cambia estado de entre-
gado a “Verdadero”.
El objeto es una instancia de la clase, o también, una clase está
compuesta por una serie de objetos que poseen la misma estructura
y el mismo procedimiento. Por ejemplo, la clase Libro constituye cual-
quier libro de la biblioteca siendo un objeto cada uno de los ejemplares
de libros que se encuentran disponibles en la biblioteca.
Una clase está compuesta por los atributos que vendrían a ser las pro-
piedades que tiene la clase. Por ejemplo, la clase libro posee los atribu-
tos código, título, ISBN, entregado y editorial. Cada atributo tendrá su
nombre, un tipo de dato ya sea este (numérico, cadena de caracteres,
texto, alfanumérico etc.) y un valor por defecto.
Los métodos son considerados como las operaciones que se llevan a
cabo sobre los objetos de una clase y son quienes determinan el com-
portamiento de la clase. Khoshafian y Abnous (1990) clasifican los mé-
todos en tres clases:
• De acceso: Este método proporciona la facilidad de acceder a
las valore de los atributos para recuperar su valor.
• De actualización: Permite la modificación de estado o valor de
un respectivo atributo.
• Constructores y destructores: Métodos se encargan de crear y
destruir objetos de la clase a la que corresponden.
4.2.2. Representación de clases en UML

Cuando usamos la notación UML para los diagramas de clase, se re-
presenta una clase con un rectángulo divido en tres secciones. En la
parte superior se coloca el nombre de la clase. Los atributos se colocan
en la parte del centro y los métodos se colocan en la parte inferior. Se
debe tomar en cuenta los siguientes aspectos sobre los atributos:
• Indicar por cada atributo su nombre.
• Indicar su visibilidad, el tipo de dato del atributo y su valor por
defecto, en caso de que lo tenga.
El tipo de dato de los atributos pueden ser: numérico entero (integer),
carácter (char), numérico real (float), cadena de caracteres (String),
booleano (boolean), etc.
La visibilidad de un atributo genera una referencia en la aplicación en
la que ese atributo es visible. La visibilidad puede tomar valores como:
Público: El atributo se muestra para toda la aplicación. El símbolo

se coloca al frente del nombre del atributo.
Privado: El atributo se muestra únicamente para la misma clase.
El símbolo se coloca al frente del nombre del atributo.
Protegido: El atributo se muestra para la misma clase y todas las
sub clases. El símbolo se coloca al frente del nombre del atributo.
Se debe definir el tipo de visibilidad al crear los atributos, caso contra-
rio se definen automáticamente como privados. El valor por defecto
hace referencia al valor que toma el atributo si no se indica lo contrario.
Este valor se declara después del tipo del atributo y el símbolo (=).
Esta información se enuncia de la siguiente forma:
• Visibilidad Nombre Atributo: Tipo Dato = ValorPorDefecto
Se debe tomar en cuenta los siguientes aspectos sobre los métodos:
Nombre del método.
• La visibilidad del método, es similar a la de los atributos igual-
mente el símbolo se coloca antes del nombre del método.
• La lista de parámetros que recibe el método se especifica entre
paréntesis y lleva la siguiente información.
• Nombre del parámetro, Tipo de dato y el valor por defecto del
parámetro.
La información relativa a cada uno de los parámetros se escribirá de
esta forma:
Nombre Parámetro: TipoDato = ValorPorDefecto, es decir el tipo de
dato correspondiente al dato devuelto por el método.
La información referente a cada método adoptará la siguiente forma:
Visibilidad Nombre Método (Nombre Parámetro1: TipoDato1 = Valor Por
Defecto1
Nombre Parámetro2: TipoDato2 = ValorPorDefecto, ...): TipoDatoDe-
vuelto
Al desarrollar los diagramas de clase no es necesario indicar el tipo
de método al inicio, este puede definirse más adelante en las fases de
análisis y diseño de software.
La clase Libro se puede simbolizar de algunas formas. Anteriormente,
se ha venido indicando que se debe definir para cada atributo su nom-
bre, visibilidad, tipo de dato y valor por defecto. [20]
Visibilidad Nombre Método (Nombre Parámetro1: TipoDato1 = Valor Por Defecto1
Nombre Parámetro2: TipoDato2 = ValorPorDefecto, ...): TipoDatoDevuelto
Al desarrollar los diagramas de clase no es necesario indicar el tipo de método al inicio,
este puede definirse más adelante en las fases de análisis y diseño de software.
La clase Libro se puede simbolizar de algunas formas. Anteriormente, se ha venido
indicando que se debe definir para cada atributo su Modelo orientado
nombre, visibilidad, tipo de dato123
a objetos y
valor por defecto. [20]
Libro Libro
Codlgo -Codlgo: lnteger
Tllulo ·Titulo: Strtng
ISBN ·ISBN: Strtng
Edltortal ·Edltortal: Sb1ng
Páginas ·Páginas: Number
Prestado -Prestado: Boolean
+Prestar(Usuarto:Usuarto): Booleen
+Devolver(Usuarto:Usuarto): Boolean
Figura. 57: Dos representaciones de la clase libro.
4.2.3. Relaciones entre clases en UML

Tal

como en las entidades se suelen crean relaciones en los diagramas 92
Entidad Relación, de igual forma se crean relaciones entre clases en los
diagramas de clases. Existen cuatro tipos de relaciones entre clases:
asociación agregación, composición, generalización y dependencia.
4.2.3.1. Asociación
A una relación normal entre las clases se la denomina asociación. Esta
suele ser reflexiva si existe una relación de clase consigo misma, bi-
naria si relaciona dos clases, ternaria si relaciona tres clases, y así
sucesivamente.
Las relaciones reflexivas y las binarias utilizan como símbolo una
línea para unir las asociaciones. Si la relación es de nivel superior a
dos, se simboliza gráficamente por medio de un rombo quien se encar-
ga de unir a las clases asociadas en la relación.
Las relaciones tienen un nombre, pero no de forma necesaria y se
detalla sobre la línea que simboliza la relación o interiormente del rom-
bo si la relación es de nivel superior a dos. Se dibuja una flecha en un
extremo de la asociación, lo que indica en qué sentido hay que leerla.
En toda relación se debe mostrar las cardinalidades que le corres-
pondan. Las cardinalidades tienen el mismo significado en los dia-
gramas de clase que en los diagramas Entidad Relación, pero no se
representan de la misma forma. Las posibles cardinalidades son:
*: Cero o varios.
1…*: Uno o varios
n…m: De n a m.
simboliza la relación o interiormente del rombo si la relación es de nivel superior a dos. Se
dibuja una flecha en un extremo de la asociación, lo que indica en qué sentido hay que
leerla.
En toda relación se debe mostrar las cardinalidades que le correspondan. Las
124cardinalidades
Zea M,tienen el mismo
Honores J, Rivassignificado
W en los diagramas de clase que en los diagramas
Entidad Relación, pero no se representan de la misma forma. Las posibles cardinalidades
También
son: se debe especificar en una relación los roles que desempeñan
las clases varios.
*: Cero o participantes en la relación. Cada rol especifica con una o
1…*: Uno
diversas o varios al lado de las clases participantes en la relación y al
palabras
n…m: De n a m.
lado de la línea que le corresponde a la asociación.
También se debe especificar en una relación los roles que desempeñan las clases
Con la figura
participantes 58 se mostrará
en la relación. una asociación
Cada rol especifica binaria
con una o diversas entre
palabras las de
al lado cla-
las
sesclases
Cliente y Cuenta Bancaria, con el cual un cliente puede ser dueño
participantes en la relación y al lado de la línea que le corresponde a la asociación.
unala ofigura
de Con 58 se mostrará
diversas cuentasuna asociación binaria
bancarias, y unaentre las clases
cuenta Cliente ypuede
bancaria Cuenta
Bancaria,
tener uno con el cual un inscripciones.
o muchas cliente puede ser dueño
Como de una o diversas cuentas
se observa, no se bancarias,
ha estable-y una
cuenta bancaria puede tener uno o muchas inscripciones. Como se observa, no se ha
cido nombre a la asociación, pues es opcional.
establecido nombre a la asociación, pues es opcional.
Cliente CuentaBancana
-NF -Num_cta
-Nombre 1 1 -Tipo
-OM'eccoon -sateo
-Telelono
-Emad
Figura. 58: Asociación binaria sin nombre.
La figura 58 muestra una asociación reflexiva con el nombre "es jefe de", por lo que un
La figura 58 muestra una asociación reflexiva con el nombre “es jefe
practicante puede tener o no un jefe y, a la vez, un practicante puede ser jefe de varios
de”, por lo que
empleados un practicante
o de ninguno. Como se ve,puede tener o no
a esta agrupación se leun
ha jefe y, a launvez,
establecido uny
nombre
practicante puede ser
se han detallado roles. jefe de varios empleados o de ninguno. Como se
FUNDAMENTOS DE BASE DE
ve, a esta agrupación se le ha establecido un nombre y se han detallado DATOS 2015
roles.

93
Empleado
-NIF
-
-Nombre
-Direccion
o 1
-Telefono
-Emall
subordinado o • es jefe de
Figura. 59: Asociación reflexiva con nombres y con valores.
En la figura 60 se mostrará una asociación ternaria entre las clases Cliente, Proveedor y
Producto. Esta asociación nos muestra qué bienes surte un distribuidor a qué clientes.
En la figura 60 se mostrará una asociación ternaria entre las clases
Cliente, Proveedor y Producto. Esta asociación nos muestra qué bienes
surte un distribuidor a qué clientes.
Figura. 59: Asociación reflexiva con nombres y con valores.
En la figura 60 se mostrará
Análisis una asociación
del modelo relacionalternaria
y de los entre las clases
elementos que loCliente,
integranProveedor125
y
Producto. Esta asociación nos muestra qué bienes surte un distribuidor a qué clientes.
Cliente Pro11eedor
PYodUCIO
Figura. 60. Asociación Ternaria.
Las asociaciones poseen atributos y métodos, dando lugar a las llamadas clases asociativas.
Las asociaciones
Las clases asociativasposeen atributos
se simbolizan y métodos,
como unas dando lugar
clases cualquieras a las llama-
que se acopla con la
das clases asociativas. Las clases asociativas se simbolizan
línea que personaliza la asociación con una línea de trazado discontinuo. como unas
La figura
clases 61 indica una
cualquieras queclase
se asociativa
acopla con nombrada
la líneaLínea
quePedido, la que indica
personaliza cada
la asocia-
encargo
ción y artículo
con pedidode
una línea en trazado
él, la cantidad requerida de ese artículo en ese encargo.
discontinuo.
La figura 61 indica una clase asociativa nombrada Línea Pedido, la
que indica cada encargo y artículo pedido DEen él, la cantidad
DATOS requerida
FUNDAMENTOS BASE DE 2015
de ese artículo en ese encargo.

Pedido Alticulo
-1d_ped • -cod_an
-fecha_ped o . 1 -descnp_an
: .pvp~an
'
''
'
Linea Pedido
-e anudad 94

Figura. 61: Clase Asociativa.
4.2.3.2. Agregación
La agregación es un tipo especial de asociación que personifica un ob-
La agregación es un tipo especial de asociación que personifica un objeto mezclado por
jeto mezclado
distintos por
objetos. Se distintos
trata objetos.
de una relación entreSe trata(agregado)
un todo de unayrelación entre
las porciones un
que lo
todo (agregado)
disponen y lasLos
(componentes). porciones
componentes quealcanzan
lo disponen
a existir (componentes). Los
sin el añadido o, los
componentes que
componentes se hallan
alcanzan anteriormente
a existir sin el al elaboraro, el
añadido losañadido e inclusive
componentes que
consecutivamente de esfumarse el añadido.
se hallan anteriormente al elaborar el añadido e inclusive consecutiva-
Una agregación se figura mediante una línea que realiza la unión con el agregado y cada
mente de esfumarse el añadido.
uno de sus componentes, y con un rombo con fondo blanco al lado del agregado.
Una
En la agregación se figuraunmediante
figura 62 se representa ejemplo de una líneaenque
agregación realiza
el cual la unión
el agregado Auto con
se
compone de un motor y cuatro llantas. Las llantas y el motor pueden existir antes de que
exista el auto como tal y pueden existir después de que el auto como tal haya desaparecido.
Figura. 61: Clase Asociativa.
La agregación es un tipo especial de asociación que personifica un objeto mezclado por
126 Zea M, Se
distintos objetos. Honores J, Rivas
trata de una Wrelación entre un todo (agregado) y las porciones que lo
disponen (componentes). Los componentes alcanzan a existir sin el añadido o, los
el componentes
agregado y que cadaseuno de sus
hallan componentes,
anteriormente y con el
al elaborar un añadido
rombo con fondo
e inclusive
blanco al lado del
consecutivamente agregado.
de esfumarse el añadido.
UnaEn agregación
la figura se figura
62 semediante
representauna línea
unque realiza ladeunión
ejemplo con el agregado
agregación en elycual
cada
el uno de sus componentes,
agregado y con un rombo
Auto se compone de uncon motor
fondo blanco al ladollantas.
y cuatro del agregado.
Las llantas
En la figura 62 se representa un ejemplo de agregación en el cual el agregado Auto se
y el motor pueden existir antes de que exista el auto como tal y pueden
compone de un motor y cuatro llantas. Las llantas y el motor pueden existir antes de que
existir después
exista el auto comodetalque el auto
y pueden existircomo tal
después dehaya
que el desaparecido.
auto como tal haya desaparecido.
Aut>
Llanta Motor
Figura. 62. Agregación
4.2.3.3. Composición
4.2.3.3. Composición
Una composición entre clases se facilita una relación más grande que una agregación.
Una composición
Naturalmente, entre
asimismo clases
presta se de
el nombre facilita unafuerte.
agregación relación más grande que
una agregación. Naturalmente, asimismo presta el nombre de agrega-
ción fuerte.
Los componentes se realizan en el mismo momento que el agregado
y se destruyen al momento de destruir el agregado. Es decir, un com-
ponente solo debe pertenecer a un agregado. 95

Una composición se figura por una línea que forma la unión con el
añadido y cada mecanismo y con un polígono con base negra al lado
del añadido.
En la figura 63 se muestra ejemplo de composición entre la clase
Ventana de un entorno de ventanas y sus componentes: título, menú y
contenido. En este caso se trata de una composición porque los com-
ponentes no tienen existencia propia ni pueden pertenecer a otro agre-
gado y, además, nacen y mueren con su agregado.
Una composición se figura por una línea que forma la unión con el añadido y cada
mecanismo y con un polígono con base negra al lado del añadido.
En la figura 63 se muestra ejemplo de composición entre la clase Ventana de un entorno
de ventanas y sus componentes: título, menú y contenido. En este caso se trata de una
composición porque los componentes no tienen existencia propia ni pueden pertenecer a
Análisis del modelo relacional y de los elementos que lo integran
otro agregado y, además, nacen y mueren con su agregado.
127
Ventana
Título Contenido
Figura. 63: Composición.
4.2.3.4. Generalización
4.2.3.4.
Se defineGeneralización
a una generalización como la relación que se da entre diferentes clases por la que
Se consta
defineunaaclase
unallamada
generalización
superclase quecomo
sujetan la
los relación que sefrecuentes
atributos y métodos da entre di-
a varias
clases, que
ferentes tienenpor
clases el nombre
la quede subclases.
consta De una estaclase
manerallamada
las subclases se sistematizan
superclase queen
una superclase
sujetan y la superclase
los atributos se dominafrecuentes
y métodos en otras subclases (especialización).
a varias clases, que tienen
Se considera a la herencia como una propiedad
el nombre de subclases. De esta manera las subclases de las subclases queseademás de tener sus
sistematizan
atributos y métodos propios, constituyen una parte de los atributos y métodos de su
en una superclase y la superclase se domina en otras subclases (espe-
superclase.
cialización).
Se representa a una generalización con la unión de la subclase con la superclase por una
Se considera a la herencia como una propiedad de las subclases
línea y trazando un triángulo con fondo blanco al lado de la superclase.
queEnademás de tener sus atributos y métodos propios, constituyen una
la figura 64 se mostrará la especialización de la clase Vehículo en las subclases Coche
parte de los atributos
y Camión. Vemos como la y superclase
métodostiene de su
dos superclase.
atributos (Matrícula y Precio), que son los
Se comunes
representa a una
a las clases generalización
Coche y Camión, cada con
una de lalas
unión
cuales de la un
posee subclase con la
atributo específico:
Plazas y Tonelaje.
superclase por una línea y trazando un triángulo con fondo blanco al
lado de la superclase.
En la figura 64 se mostrará la especialización de la clase Vehículo
en las subclases Coche y Camión. Vemos como la superclase tiene dos
atributos (Matrícula y Precio), que son los DE comunes a las clases Coche
FUNDAMENTOS BASE DE DATOS 2015
y Camión, cada una de las cuales posee un atributo específico: Plazas

y Tonelaje.
Vehiculo
-matricula 96
-orec¡o
Figura. 64: Generalización.
En una jerarquía de clase y sus clases puede haber más de un nivel como en la siguiente
figura.
Figura. 64: Generalización.
Enuna
En una jerarquía
jerarquía dey clase
de clase y sus
sus clases puedeclases puede
haber más de unhaber másen de
nivel como un nivel
la siguiente
figura.
como en la siguiente figura.
Vehic ulo Terrestre
t
Camión Auto Avión Helicóptero
Figura. 65: Generalización de dos niveles.
Existen
Existen diferentes tipos de
diferentes especializaciones:
tipos de especializaciones:
• • Disjuntas o no disjuntas:
Disjuntas o no disjuntas: Una especialización es disjunta si unesobjeto
Una especialización solo debe
disjunta si un
pertenecer a una sola subclase; no disjunta, será lo inverso a la disjunta.
objeto solo debe pertenecer a una sola subclase; no disjunta,
• Totales (completas) o parciales (incompletas): Una especialidad es de tipo total si
será lo inverso a la disjunta.
las subclases establecen todos los casos que se puedan de la superclase; arbitraria,
• en Totales (completas) o parciales (incompletas): Una especialidad
caso inverso.
es deo dinámica:
• Estática tipo total Essi las subclases
cuando establecen
la especialidad todos
es estática, un objetolos casos que
es solicitud a
partir
se de su fabricación
puedan de la de la subclase yarbitraria,
superclase; la superclase en
en la que ha
caso fue creado. La
inverso.
• especialidad
Estáticaesodinámica,
dinámica: un objeto suele marcharse
Es cuando a lo extenso es
la especialidad de su vida entreun
estática,
las diferentes subclases de la especialidad.
objeto es solicitud a partir de su fabricación de la subclase y la
En la figura 66 se muestra una especialización disjunta porque un auto en concreto solo
superclase en la que ha fue creado. La especialidad es dinámi-
puede estar funcionando o estropeado, total porque no existirán autos que no se puedan
ca,
clasificar en losun
dosobjeto suele (funcionando
tipos indicados marcharseoaestropeado)
lo extenso de su porque
y dinámica vida entre
un autolas
en concreto,diferentes
a lo largosubclases de la especialidad.
de su existencia, puede pasar de estar funcionando a estar
estropeado
En la figura y viceversa.
66 se muestra una especialización disjunta porque un auto
en concreto solo puede estar funcionando o estropeado, total porque no
existirán autos que no se puedan clasificar en los dos tipos indicados
(funcionando o estropeado) y dinámica porque un auto en concreto,97

a lo largo de su existencia, puede pasar de estar funcionando a estar
estropeado y viceversa.
Existe herencia simple o herencia múltiple. En una herencia sim-
ple, cada subclase deriva de una sola superclase. En caso de ser he-
rencia múltiple, una subclase puede proceder de varias subclases.
También, en la jerarquía de clases de la figura 67 poseemos herencia
múltiple porque las subclases Camión y Bote proceden cada una de dos
superclases.


Análisis del modelo relacional y de los elementos que lo integran
2015
129

Auto
f
1 1
Figura. 66: Especialización disjunta,
Funcionando
total y dinámica
Estropeado
Existe herencia simple o herencia múltiple. En una herencia simple, cada subclase deriva
de una sola superclase. En caso de ser herencia múltiple, una subclase puede proceder de
varias subclases. También, en Especialización
Figura. 66: la jerarquía de clasestotal
disjunta, deyla figura 67 poseemos herencia
dinámica
múltiple porque las subclases Camión y Bote proceden cada una de dos superclases.
Existe herencia simple o herencia múltiple. En una herencia simple, cada subclase deriva
de una sola superclase. En caso de ser herencia
Vehículo múltiple, una subclase puede proceder de
varias subclases. También, en la jerarquía de clases de la figura 67 poseemos herencia

múltiple porque las subclases Camión y Bote proceden cada una de dos superclases.
f
1 1 1 1
Impulsado_Viento lmpulsado_Motor Terrestre Marítimo
t t t
1 1
1 Velero 1 1 Camión 1
1 1 1 1
1 1 1 1
Figura. 67: Herencia Múltiple.
4.2.3.5. Dependencia
Se define a la dependencia como la relación que se da por dos clases la cual una de las
Se define
clases seainstancia
la dependencia como
a otra clase,Figura.
es decir la
67: relación
que una depende
Herencia quedese
Múltiple. otrada poruna
o que dos clases
clase lade
solicita
cualotra
unapara
deque
laspueda trabajar.
clases Por ejemplo,aen
se instancia un entorno
otra clase,de esventanas
decir queuna aplicación
una depen- gráfica
deSe instancia
de otra aouna ventana.
define laque una clase
dependencia como solicita de que
la relación otrasepara
da porque dos pueda
clases latrabajar.
cual una dePorlas
La relación de dependencia se simboliza mediante una flecha con diseño interrumpido que
ejemplo,
clases se en un entorno
instancia a otra clase,de ventanas
es decir que unauna aplicación
depende de otra o que gráfica
una claseinstancia
solicita de
empieza a partir de la clase dependiente.
unaotraventana.
para que pueda trabajar. Por ejemplo, en un entorno de ventanas una aplicación gráfica
instancia una ventana.
La relación de dependencia se simboliza mediante una flecha con
La relación de dependencia seFUNDAMENTOS
simboliza mediante una DEflecha
BASE DE
con DATOS
diseño 2015
interrumpido que
diseño interrumpido que empieza a partir de la clase dependiente.
empieza a partir de la clase dependiente.
Aplicación Aplicación
~
-
98

Figura. 68: Relación de Dependencia
4.3. Comparación del modelo de clases con el modelo Entidad-Relación

98
La
analogía que se ha logrado establecer entre el modelo Entidad-Relación y el modelo de
clases es la siguiente:
• Dentro de los diagramas Entidad-Relación las entidades se convierten en clases
dentro de los diagramas de clases.
4.3. Comparación del modelo de clases con el modelo Entidad-Re-

lación
La analogía que se ha logrado establecer entre el modelo Entidad-Rela-

ción y el modelo de clases es la siguiente:
• Dentro de los diagramas Entidad-Relación las entidades se
convierten en clases dentro de los diagramas de clases.
• Los atributos que se hallan en las entidades de los diagramas
Entidad-Relación se transformaran en atributos de las clases
adecuadas.
• De igual manera como los diagramas ER es justo escoger cierto
atributo como AIP para cada entidad, en los diagramas de cla-
ses no es necesario. Esto se debe a que cada uno de los objetos
de una clase en una aplicación orientada a objetos, tiene seña-
lado un identificador que puede referirse a él sin problema a
medida que se va elaborando la aplicación.
• Las relaciones normales en los diagramas ER van a ser asocia-
ciones en los diagramas de clases.
• En los diagramas ER las relaciones frágiles (dependencias en
existencia y en identificación) se transforman en agregaciones
o disposiciones en los diagramas de clases, dependiendo de si
son similares el tiempo de vida de los dispositivos con el del
añadido.
• Es preciso asociar a cada relación una cardinalidad. La manera
de definir las cardinalidades es igual en los dos tipos de diagra-
mas, sin embargo, se usan una simbología desigual.
• En los diagramas ER los atributos de relaciones producen cla-
ses asociativas en los diagramas de clases. A estas clases se les
fijara un nombre y tendrán como atributos los que formarían
parte a las relaciones de los diagramas ER.
• En los diagramas ER las jerarquías de tipos y subtipos corres-
ponden a las jerarquías de clases en los diagramas de clases.
[20]
4.4. Diagrama de objetos como caso especial del diagrama de clases
Se considera un caso especial de los diagramas de clase a los diagra-

mas de objetos. En estos diagramas se muestran objetos, es decir las

instancias de clases en un momento en el tiempo.
Los objetos en los diagramas de objetos se personifican de manera re-
sumida o de forma específica:
De manera resumida los objetos se simbolizan dentro de en un rec-
tángulo colocando en su interior el nombre del objeto marcado o solo el
nombre del objeto, el símbolo de dos puntos
FUNDAMENTOS (:) yDE
DE BASE el nombre
DATOS de la clase
2015
a la que el objeto es.

En la figura 69 se mostrará un objeto de la clase Cliente:
FUNDAMENTOS
CUENTE 1 DE BASE DE DATOS 2015

CUENTE 1: CUENTE

Figura. 69: Objeto de la clase cliente
De manera más especificada un objeto se puede representar mediante un rectángulo con

Decortes.
dos manera En elmás
corte especificada
superior se pone un objetoel se
subrayado puede
nombre representar
del objeto, el símbolomediante
de dos
un rectángulo con dos cortes. En el corte
superior
puntos (:) y por siguiente el nombre de la clase. En la parte inferiorse
sepone
pone sussubrayado
atributos y el
para
nombrecada unodeldeobjeto,
ellos después Figura.
del
el símbolo 69:de
nombre Objeto
del
dos depuntos
la clase
atributo secliente
escribe el símbolo
(:) y por de igualel(=)
siguiente y
nom-
elbre
valor
De dequela obtiene
manera elEn
atributo
más especificada
clase. para ese
un objeto
la parte objeto. A
secontinuación,
se puede
inferior representar
pone se simboliza
susmediante
atributos un objeto cada
un rectángulo
y para decon
clase Cliente
la dos En de modo la figura
detalladoseenpone 70. el nombre del objeto, el símbolo de dos
uno cortes.
de ellos eldespués
corte superior
del nombre subrayado
del atributo se escribe el símbolo de
puntos (:) y por siguiente el nombre de la clase. En la parte inferior se pone sus atributos y
igual (=) y el valor que obtiene el atributo para ese objeto. A continua-
para cada uno de ellos después del nombre del atributo se escribe el símbolo de igual (=) y
ción, seque
el valor simboliza un objeto
obtiene el atributo para esede objeto.
la clase Cliente dese modo
A continuación, simbolizadetallado
un objeto de en
lala figura 70. de modo detallado en la figura 70.
clase Cliente
Cliente1 :Cliente
NIF= ·2314123C•
Figura. 70: Representación detallada
Nombre= •Juan Rojas•de un objeto de la clase cliente
Direccion= ·E1 Bosque Sector #1"
Un diagrama de objetos para Telefono=
el diagrama de clases tendría las cuentas bancarias de que
2925934
ubican uno o Email=
varios clientes en ·¡uanr23@hotmail.com·
un instante en específico de realización de la aplicación.
Como, por ejemplo, en la figura 71 se simboliza un diagrama de objetos en el que se
muestra el hecho de que el70:
Figura. cliente con NIEdetallada
Representación 12345678A
de un tiene
objeto dos
de lacuentas bancarias. [21]
clase cliente
Un diagrama de objetos para el diagrama de clases tendría las cuentas bancarias de que
ubican
Un uno o varios
diagrama clientes enpara
de objetos un instante en específico
el diagrama de realización
de clases tendríade las
la aplicación.
cuentas
por ejemplo, en la figura 71
bancarias de que ubican uno o varios clientes en un instante enque
Como, se simboliza un diagrama de objetos en el se
espe-
muestra el hecho de que el cliente con NIE 12345678A tiene dos cuentas bancarias. [21]
cífico de realización de la aplicación. Como, por ejemplo, en la figura
71 se simboliza un diagrama de objetos en el que se muestra el hecho
de que el cliente con NIE 12345678A tiene dos cuentas bancarias. [21]
Figura. 70: Representación detallada de un objeto de la clase cliente
Un diagrama de objetos para el diagrama de clases tendría las cuentas bancarias de que
ubican uno o varios clientes en un instante en específico de realización de la aplicación.
132
Como, por ejemplo, en la J,figura
Zea M, Honores Rivas W71 se simboliza un diagrama de objetos en el que se
muestra el hecho de que el cliente con NIE 12345678A tiene dos cuentas bancarias. [21]
Cliente 1 :Cliente Cuenta1 :Cuenta Bancaria

NIF= •2314123c· Num_Cta=1200067567234
Nombre= ·Maria Ramón" Tipo= ·corriente•
Direccion= •El Bosque Sector 111 • Saldo= 2000,00
Telefono= 2945236
Email= ·¡uanr23@holmail.com•
Num_Cta=2302054779298
Tipo= "Ahorro·
Saldo= 7600,00
Figura. 71: Diagrama de objetos.

100

Resumen
• El modelo orientado a objeto nace como parte de las metodologías de

análisis, en los años 80 del diseño orientado a objetos, en el que ini-
ciaron su camino durante las épocas pasadas.
• Los datos del modelo orientado a objetos son considerados como un
incremento del modelo Entidad-Relación.
• Se define a un objeto como una entidad que permite mostrar un pro-
cedimiento preciso
• Cuando usamos la notación UML para los diagramas de clase, se re-
presenta una clase con un rectángulo divido en tres secciones.
• Tal como en las entidades se suelen crean relaciones en los diagramas
Entidad Relación, de igual forma se crean relaciones entre clases en
los diagramas de clases.
• A una relación normal entre las clases se la denomina asociación.
Esta suele ser reflexiva si existe una relación de clase consigo misma,
binaria si relaciona dos clases, ternaria si relaciona tres clases, y así
sucesivamente.
• La agregación es un tipo especial de asociación que personifica un
objeto mezclado por distintos objetos.
• Una composición entre clases facilita una relación más grande que
una agregación. Naturalmente, asimismo presta el nombre de agre-
gación fuerte.
• Se define a una generalización como la relación que se da entre di-
ferentes clases por la que consta una clase llamada superclase que
sujetan los atributos y métodos frecuentes a varias clases, que tienen
el nombre de subclases.
[133]
• Se considera un caso especial de los diagramas de clase a los diagra-

mas de objetos. En estos diagramas se muestran objetos, es decir las
instancias de clases en un momento en el tiempo
Ejercicios propuestos y resueltos
Ejercicios Resueltos FUNDAMENTOS DE BASE DE DATOS

2015

TEMA: Análisis del modelo relacional y los elementos que lo integran.
Ejercicios
1. Resueltos relacional con información de las personas que for-
Esquema
TEMA:
man Análisis
parte de undel directorio.
modelo relacional y los elementos que lo integran.
1.
Directorio (Nombre,con
Esquema relacional información
FecNac, de las personas
Ciudad, Celular,queCodPro)
forman parte de un directorio.
Directorio (Nombre, FecNac,
Provincias (CodPro, Pro) Ciudad, Celular, CodPro)
Provincias (CodPro, Pro)
Directorio
Nombre FecNac Ciudad Teléfono CodPro
Rosa Cheve 19/10/85 Machala 0938563142 10
Karla Feijoo 10/01/95 Guayaquil 0979290223 32
Ligia Sánchez 11/02/90 Manta 0997177423 25
Joel Cabrera 02/08/80 Cuenca 0988505376 45
Tabla 32: Datos de un Directorio
Provincias
CodPro Pro
32 Guayas
45 Azuay
10 El Oro
Tabla 33: Código de Provincia
Para las consultas es necesario mostrar el resultado de cada una y escribir las expresiones
Para las consultas es necesario mostrar el resultado de cada una y
del álgebra y cálculo relacional de tuplas y el cálculo de relacional de dominios.
escribir las expresiones
a) Obtener las ciudades dedel álgebradelydirectorio.
las personas cálculo relacional de tuplas y el
cálculo de relacional de dominios.
b) Obtener las personas que viven en Guayaquil.
a).- c)Obtener
Obtener las
el nombre y la fecha
ciudades de de
lasnacimiento
personas de las
delpersonas que tienen menos de 28
directorio.
años.
b).- Obtener las personas que viven en Guayaquil.
c).- d) Obtener nombre, ciudad y provincia de las personas mayores de 35 años.
Obtener el nombre y la fecha de nacimiento de las personas que
e) Obtener nombre, fecha de nacimiento y teléfono de las personas de la Provincia de
tienen El menos
Oro.
de 28 años.
Solución
a) πciudad(Directorio) [135]
t|∃s Є Directorio (t.Ciudad=s.Ciudad))
b) αciudad=Guayaquil (Directori0)
t| (t Є Directorio) ∧ (t.Ciudad=”Guayaquil”))
Provincias
CodPro Pro
32 Guayas
45 Azuay
10 El Oro
Tabla 33: Código de Provincia
Para las consultas es necesario mostrar el resultado de cada una y escribir las expresiones
del álgebra
d).- y cálculo
Obtener relacionalciudad
nombre, de tuplasyy provincia
el cálculo de de
relacional de dominios.
las personas mayores de
a) Obtener las ciudades de las personas del directorio.
35 años.
b) Obtener las personas que viven en Guayaquil.
e).-c)Obtener nombre, fecha de nacimiento y teléfono de las personas de
Obtener el nombre y la fecha de nacimiento de las personas que tienen menos de 28
la Provincia
años. de El Oro.
d) Obtener nombre, ciudad y provincia de las personas mayores de 35 años.
e) Obtener nombre, fecha de nacimiento y teléfono de las personas de la Provincia de
Solución
El Oro.
a).- πciudad(Directorio)
Solución
a) πciudad(Directorio)
b).- αciudad=Guayaquil (Directori0)
t| (tb)Є Directorio)
αciudad=Guayaquil ∧ (t.Ciudad=”Guayaquil”))
(Directori0)
<c>|∃n, t| (tf,Єt,Directorio)
cp (<n, f, ∧c, (t.Ciudad=”Guayaquil”))
t, c p> Є Directorio)
<c>|∃n,
< n, f, c, f, t, cp (<n,
t, cp >|(<n, a, c,f, t,c,ct,p>
c p>ЄЄDirectorio∧|=”Guayaquil”)
Directorio)
< n, f, c, t, cp >|(<n, a, c,
c).- πNombre, Fec_Nac (αFec_Nac<28(Directori0)) t, c p> Є Directorio∧|=”Guayaquil”)
c) πNombre, Fec_Nac (αFec_Nac<28(Directori0))
t|∃s Є Directorio (t.Nombre=s.Nombre) ∧(t.FecNac=s.FecNac) ∧ cNac<28))
t|∃s Є Directorio (t.Nombre=s.Nombre) ∧(t.FecNac=s.FecNac) ∧ cNac<28))
Directorio
Nombre FecNac Ciudad Telefono CodPro
Karla Feijoo FUNDAMENTOS
10/01/95 Guayaquil DE BASE
0979290323 DE DATOS
32 2015
Tabla 34 Registro de Directorio

<n, f<n,
>∃ f >∃
c, t,c, cp
t, cp(<
(< n,
n, f,
f, c,c, t,t,cp>
cp>Є Directorio ∧ f< 28
Є Directorio ∧ f< 28
103
Nombre FecNac
Karla Feijoo 10/01/95
Ligia Sánchez 11/02/90
Tabla 35: Nombre - Fecha de un Directorio

Ciudad
Machala
Guayaquil
Manta
Cuenca
Tabla 36: Tabla Ciudad
2. Se presenta algunos condicionales prácticos de normalización que son más que la

2. relación
Seuniversal
presenta y se usará lascondicionales
algunos formas normalesprácticos
de la primera a la tercera en
de normalización
quesecuencia,
son más dando
quelugar a un esquema
la relación relacional
universal y secon más relaciones
usará las formasy normalizado
normales
hasta la tercera forma normal. También se presenta ejercicios propuestas de des
de la primera a la tercera en secuencia, dando lugar a un esquema re-
normalización.
lacional con más relaciones y normalizado hasta la tercera forma nor-
mal. También
Solicitud se presenta
de un pedido ejercicios
en una empresa. Se va apropuestas de des
registrar los datos normalización.
de cada solicitud en la
base de datos:
Fecha: 28 de Mayo del 2014
Núm. Pedido: 555555
Núm. Proveedor: 1990
Nombre Proveedor: Ecotel
Dirección Proveedor: Marcel Laniado y 10 de agosto, Machala
Tabla 36: Tabla Ciudad
2. Se presenta algunos condicionales prácticos de normalización que son más que la

relación universal y se usará las formas normales de la primera a la tercera en
secuencia, dando lugar a un esquema relacional con más relaciones y normalizado
hasta la tercera forma normal. También seEjercicios
presentapropuestos
ejerciciosy resueltos 137
propuestas de des
normalización.
Solicitud de un pedido en una empresa. Se va a registrar los datos de
cada solicitud
Solicitud en la
de un pedido en base de datos:
una empresa. Se va a registrar los datos de cada solicitud en la
base de datos:
Fecha: 28 de Mayo del 2014
Fecha: 28
Núm. de Mayo555555
Pedido: del 2014
Núm. Pedido: 555555
Dirección Proveedor:
Dirección Proveedor: MarcelMarcel
Laniado Laniado y 10Machala
y 10 de agosto, de agosto, Machala
NumPro Detalle PreUni Cantidad Importe

1102 Celular 60,00 2 120,00
1103 Lámpara de mesa 30,00 3 90.00
1104 Mueble desarmable 150,00 1 150,00
TOTAL 360,00
Tabla 37: Datos de un Encargo
Solución:
Solución:
La relación universal es que con el grupo repetitivo que se encuentra subrayado como
La
claverelación universal
principal el es que con el grupo repetitivo que se encuentra
atributo NPed:
subrayado como clave
Pedido (NroPed, FPed, NroPro, principal el atributo
NPro, DPro, NroProd, NPed:
DetalleProd, PUnit, Can, Impor,
Total)
Pedido (NroPed, FPed, NroPro, NPro, DPro, NroProd, DetalleProd, PU-
La relación
nit, pasa a otra
Can, Impor, forma normal suprimiendo el grupo repetitivo y con una nueva
Total)
relación con los atributos del grupo repetitivo y la llave principal de la relación.
La relación pasa a otra forma normal suprimiendo el grupo repetitivo y
Pedido (NroPed, FPed, NroPro, NPro, DPro, Total)
con una nueva relación con los atributos del grupo repetitivo y la llave
principal de la relación.
104

Línea Pedido (NroPed, NroProd, DetProd, PUnit, Can, Impor)
Se necesita que la relación Línea Pedido este en la segunda forma nor-
mal, y que todos sus atributos no claves dependan de la clave.
(NroPed, NroPro) → DetProd
(NroPed, NroPro) → PUnit
(NroPed, NroPro) → Cant
(NroPed, NroPro) → Impor
Se supone que los valores de los productos son únicos, se entregan
con el mismo valor independientemente de a quien se realice la venta.
Tenemos que las 2 primeras dependencias no son correctas ya que un
producto y su valor no dependen del pedido.
NroPro -> DetProd
NroProd->PUnit
Los atributos DetProdu y Punit no dependen de la clave porque la re-

lación no está en segunda forma normal. Para pasar a esta forma se
deberá eliminar los atributos de la relación y crear una nueva relación.
Solución
to (NroProd) Crearemos una nueva relación con ellos más el atributo
del que dependen. El esquema relacional en forma normal quedará de
la siguiente forma:
NroProd, DetProd, PUnit, Can, Impor)

Línea Pedido (NroPed,
Producto (NroProd, DetProd,

PUnit)
Si las relaciones están en tercera forma normal tratando de buscar de-
pendencias transitivas, en la relación Pedido tenemos una dependencia
transitiva:
NroPed -* NroPro—+ NPro, DPro
Los atributos NPro y DPro no dependen de la clave (NroPed), sino del
atributo NroPro.
La relación pedida pasará a tercera forma normal, lo primero será eli-
minar los atributos que no dependen de la clave y se creará una rela-
ción por cada uno de ellos. El esquema quedará de la siguiente forma.
Pedido (NroPed, FPed, NroPro, Total)
Proveedor (NroPro, NPro, DPro)
Línea Pedido (NroPed, NroProd, Can, Impor)
Producto (NroProd, DetProd, PUnit)
Propuestas de desnormalización:
Generalmente al mostrar datos de un pedido y haciendo referen-
cia a la tabla proveedor no proporciona actualizaciones, por lo que es
recomendable relacionar Proveedor en la relación Pedido y eliminar la
tabla proveedor.
Si obtenemos información de una línea de pedido es imprescindible
consultar datos del producto.
Registro de matrícula colegial.
Se presenta una relación universal y las siguientes hipótesis semán-
ticas: Matrícula (ID, Códmateria, Ape, Nom, Nota, Curso, Aula, Lugar)
Hipótesis semánticas:
• El atributo Codmateria guarda las materias en la cual están
Ejercicios propuestos y resueltos 139
matriculados los estudiantes.

• El atributo Aula es el lugar en donde se dictará la docencia de
todas las materias, entretanto que Lugar se refiere al sitio del
centro en el que se encuentra el aula (el piso, edificio, entre
otros.) y estas aulas poseen un código que identifican el sitio en
el que se ubica el aula.
• La materia, asociada con la docencia de un solo curso.
• Una materia puede distribuirse a cualquier aula, pero depen-
diendo el grupo que integre.
• El estudiante matriculado en diferentes materias debe registrar
una única nota.
Solución:
En este ejercicio la clave principal será el ID del estudiante, lo que per-
mite mover del orden de los atributos en la relación. Algunos atributos
del grupo repetitivo están subrayados, ya que un estudiante puede ma-
tricularse en varias materias.
Matrícula (ID, Nom, Apellidos, Codmateria, Nota, Curso, Aula, Lu-
gar)
Debido al grupo repetitivo, la relación no está en 1era forma normal
Ya que existe un grupo repetitivo, la relación no está en primera forma
normal. La llevamos a esta forma normal descartando el grupo repeti-
tivo de la relación y estableciendo una nueva. La estructura relacional
en primera forma normal se vería de la siguiente manera:
Registro_Matricula (ID, Nom, Apellidos)
Documentación (ID, Codmateria, Nota, Curso, Aula, Lugar)
Para estar en segunda forma normal, las relaciones de documentación
necesitan que sus atributos no claves dependen totalmente de la clave,
obligando así a cumplir las dependencias funciones totales.
La relación Documentación para que se halle en segunda forma
normal es necesario que sus atributos no clave dependan de la totali-
dad de la clave, por lo tanto, deben cumplir las dependencias funciona-
les totales a continuación.
(ID, Codmateria) Nota
(ID, Codmateria) Curso
(ID, Codmateria) Aula
(ID, Codmateria) Lugar
140 Zea M, Honores J, Rivas W FUNDAMENTOS DE BASE DE DATOS 201

Al depender una materia a un único curso la segunda dependencia
funcional total no
Al depender unasemateria
cumple, entonces
a un tenemos
único curso que: dependencia funcional total no
la segunda
Codmateria -* Curso
cumple, entonces tenemos que:
Para llevar a segunda
Codmateria -* Cursoforma normal la relación documentación des-
carta el atributo curso y debe establecer una nueva relación con él y el
Para llevar a segunda forma normal la relación documentación descarta el atributo curs
atributo del que depende. Siendo de la siguiente manera el esquema de
debe establecer una nueva relación con él y el atributo del que depende. Siendo de
segunda forma normal:
siguiente manera el esquema de segunda forma normal:
Registro_Matricula’ (ID, Nombre, Apellidos)
Registro_Matricula' (ID, Nombre, Apellidos)

Documentación (ID, Codmateria, Nota, Aula, Lugar)
Documentación
Documentación (ID,
(ID, Codmateria,Nota,
Codmateria, Nota,Aula,
Aula, Lugar)
Lugar)
Documentación (ID, Codmateria, Nota, Aula, Lugar)

Materia (Codmateria, Curso)
La relación materia ya se
Materia (Codmateria, encuentra en tercera forma normal, y se debe
Curso)
buscar alguna materia
La relación dependencia
ya se funcional
encuentra entransitiva. La relación
tercera forma normal,dey docu-
se debe buscar algu
mentación se halla:
dependencia funcional transitiva. La relación de documentación se halla:
(ID, Codmateria) Aula Lugar

Entendemos que la relación aula necesita de una clave principal. Para llevar la relac
Entendemos que la relación aula necesita de una clave principal. Para
documentación a tercera forma normal se descarta el atributo lugar y se crea una nue
llevar la relación documentación a tercera forma normal se descarta
relación. El esquema en tercera forma normal será el siguiente:
el atributo lugar y se crea una nueva relación. El esquema en tercera
Matrícula (ID, Nombre, Apellidos)
forma normal será el siguiente:
Documentación (ID, Codmateria, Nota, Nota, Aula)
Matrícula (ID, Nombre, Apellidos)
Ubicación (Aula, Lugar)
Documentación (ID, Codmateria, Nota, Nota, Aula)
Materia(Aula,
Ubicación (Codmateria,
Lugar) Curso)
Propuestas
Materia de desnormalización:
(Codmateria, Curso)
Cuando se presentan los datos de documentación de un estudiante se precisa conocer c
siempre eldecurso
Propuestas al que pertenece cada materia, y teniendo en cuenta que este d
desnormalización:
cambiará con poca
Cuando se presentan los frecuencia,
datos dese podría proponer
documentación deañadir el atributo
un estudiante se Curso a la ta
Documentación
precisa conocer casi y eliminar
siempre la tabla Materia.
el curso Podríamoscada
al que pertenece obrarmateria,
de manera similar si
consultar el Documentación de un estudiante fuese necesario
y teniendo en cuenta que este dato cambiará con poca frecuencia, casi siempre
se conocer el lu
en elproponer
podría que recibeañadir
docencia: eliminaríamos
el atributo Cursoen a este caso Documentación
la tabla la tabla Ubicaciónyy colocaríamo
atributo Lugar en la tabla Documentación.
eliminar la tabla Materia. Podríamos obrar de manera similar si al con-
Empleados
sultar el Documentación de un estudiante fuese necesario casi siempre
Relación universal e hipótesis semánticas:
Empleado (NroEp, NSS, Sección, NroJefeSec, NroCurso, Tema)
• El empleado posee un número único.
• El empleado se ocupa de una sola sección. Esta sección contiene
conocer el lugar en el que recibe docencia: eliminaríamos en este caso

la tabla Ubicación y colocaríamos el atributo Lugar en la tabla Docu-
mentación.
Empleados
Relación universal e hipótesis semánticas:
• El empleado posee un número único.
• El empleado se ocupa de una sola sección. Esta sección contie-
ne un empleado jefe.
Un empleado debe hacer muchos cursos, y estos tienen un código que
lo identifica contiene un solo tema.
Solución:
Se ha colocado como llave principal a NroEp, ya que un Empleado pue-
de hacer varios cursos cada uno con su tema.
Con la presencia de un grupo repetitivo la relación empleada está en la
primera forma normal, y debemos cambiar la forma adecuada descar-
tando el grupo repetitivo creando una nueva relación con los atributos
del grupo más una clave principal. Entonces el esquema relacional en
primera forma normal sería de la siguiente manera.
Empleado (NroEp, NSS, Sección, NroJefeSec)
Estudios (NroEp, NroCurso, Tema)

La relación estudios no se encuentra en segunda forma normal, y para
cambiarla el atributo no clave deberá formar parte de la totalidad de las
claves, debiendo ser cierta la siguiente dependencia funcional:
(NroEp, NroCurso) =>Tema
Esta dependencia no es correcta, ya que el tema del curso está asocia-
do con el curso en el que se trate mas no de quien lo haga. Cumplién-
dose así la siguiente dependencia.
NroCurso— Tema
Es por esta razón que la relación Estudios debe pasar a segunda forma
normal y para ello debemos eliminar de dicha relación el atributo Tema
y crear una nueva relación con aquel atributo y del cual depende. El
esquema relacional en segunda forma normal será el siguiente:
Empleado’ (NroEp, NSS, Sección, NroJefeSec)

Empleado (NroEp, NroCurso)
Cursos (NroCurso, Tema)

Ya se encuentran en forma normal las relaciones Estudios y Curso,
debido a q están en segunda forma normal y poseen menos de 2 atri-
butos no clave. La relación Empleado no se encuentra en tercera forma
normal, mostrando la siguiente dependencia funcional:
NroEp -> Sección -> NroJefeSec

El atributo NroJefeSec no depende de la clave NroEp, sino del atributo
sección. Para pasar a la tercera forma normal debemos eliminar de la
relación Empleado el atributo NroJefeSc y crear una nueva relación
con aquel atributo y del cual depende. El esquema relacional en tercera
forma normal quedará como sigue:
Empleado (NroEp, NSS, Sección)
Sección (Sección, NroJefeSec)
Empleado (NroEp, NroCurso)
Cursos (NroCurso, Tema)
Propuestas de desnormalización:
Al conocer la información de un trabajador es necesario saber de quién
se trata si es un jefe, se puede desmoralizar agregando el atributo Nro-
JefeSec a la tabla Empleado y desasociando la relación con la tabla
Secciones.
La información de los cursos que han sido hechos por cada trabajador
y conocer el tema que trata, si la información no varía mucho se puede
eliminar la tabla cursos y en la tabla Estudios el atributo Tema.
Tema: Descripción y aplicación del modelo entidad-relación para

el modelado de datos
Referente a este tema se mostrarán varios ejercicios para modelar mo-
delos entidad – relación. Se explica el paso a paso para obtener un mo-
delo entidad- relación y a partir de este poder transformar al esquema
relacional sin olvidar cada una de las reglas de transformación vistas
anteriormente.
Empleados y departamentos
Para los empleados se necesita almacenar información como un núme-
ro que lo identifique, nombre, apellido, salario y comisión. Cada uno de
estos empleados tiene designado un departamento y se almacenará un
número de departamento, nombre y localidad. También es necesario
almacenar la relación entre empleados y conocer si tiene designado un
jefe o no.
Solución:
En la entidad Empleado como atributos tenemos: un número, su nom-
bre, apellido, salario y comisión. Como atributo identificador principal
tomaremos el atributo número ya que para cada empleado es el iden-
tificador único.
En la entidad Departamento como atributos tenemos: un número,
nombre y localidad. Como atributos identificadores principal tomare-
mos el atributo número ya que para cada Departamento el número
será único.
Para crear las relaciones debemos saber por cada empleado el de-
partamento en donde trabaja, para ello creamos la relación entre Em-
pleado y Departamento con cardinalidad 1,1 junto al Departamento, ya
que todo empleado trabaja en un solo departamento; y la cardinalidad
1, n junto al Empleado, ya que en cada departamento trabajará como
mínimo un empleado y como máximo varios.
Otra relación seria entre los empleados y conocer cuál es su jefe,
para ello se crea una relación reflexiva en la entidad Empleado. Como
cardinalidad tendremos 1, N, con la que sabremos cual es el jefe de
cada empleado. Si es queFUNDAMENTOS
lo tiene o no. LaDE
otra cardinalidad es 0,N ya
que un empleado puede o no tener subordinados.
BASE DE DATOS 2015
El diagrama entidad - relación que se propone es el siguiente:
1:1
Figura. 72: Diagrama entidad - relación para el supuesto 1
Para obtener el esquema relacional, cada entidad se transformará en una relación en este
caso las entidades de Empleado y Departamento con cada uno de sus atributos.
Se analizarán cada una de las relaciones del diagrama entidad - relación:
La relación Trabaja es de cardinalidad 1,N, dando lugar a la cardinalidad N aparezca una
clave secundaria con el atributo de clave principal de la otra relación NroDep. El método
Para obtener el esquema relacional, cada entidad se transformará en

una relación en este caso las entidades de Empleado y Departamento
con cada uno de sus atributos.
Figura. 72: Diagrama entidad - relación para el supuesto 1
Se analizarán cada una de las relaciones del diagrama entidad - rela-
Para obtener el esquema relacional, cada entidad se transformará en una relación en este
ción:
caso las entidades de Empleado y Departamento con cada uno de sus atributos.
SeLa relación
analizarán Trabaja
cada una de lasesrelaciones
de cardinalidad
del diagrama1,N, dando
entidad lugar a la cardi-
- relación:
nalidad N aparezca
La relación Trabaja esuna clave secundaria
de cardinalidad 1,N, dandocon lugarela atributo de clave
la cardinalidad prin-una
N aparezca
clave
cipal desecundaria con el atributo
la otra relación de clave
NroDep. El principal
métodode la otra
que relación
se debe NroDep.
aplicar esElcrear
método
que se debe aplicar es crear una nueva tabla y creamos
una nueva tabla y creamos en la tabla Empleado una clave secundaria en la tabla Empleado una clave
secundaria con el atributo
con el atributo NroDep. NroDep.
El esquema relacional resultante es el siguiente:
El esquema relacional resultante es el siguiente:
Empleado (NroEmple, Nombre, Salario, Comision, NroEmpleJefe, NroDep)
Departamento (NroDep,
Departamento (NroDep, Nombre,
Nombre,Localidad)
Localidad)
Tema: Modelo orientado a
Tema: Modelo orientado a objeto objeto
Se proponen varios ejercicios para la modelización de diagramas de clases. Por cada
Se proponen varios ejercicios para la modelización de diagramas de cla-
ejercicio se proporciona el enunciado que describe como se desea obtener el diagrama de
ses. Por cada ejercicio se proporciona el enunciado que describe como
clase.
se Sistema
desea obtener el diagrama
de monitorización de clase.
de sensores.
Para un sistema de monitorización de sensores se desea crear un diagrama de clases
•
Sistemaconde métodos para la monitorización.
monitorización de sensores.Este sistema además de monitorizar también
deberá indicar problemas.
• Para un sistema de monitorización de sensores se desea crear
• Como atributos del sensor tenemos fabricante, número de modelo, secuencia de
un diagrama de clases con métodos para la monitorización.
iniciación, factor de escala y unidad de medida, intervalo de muestreo, ubicación,
Este sistema además de monitorizar también deberá indicar
estado, valor actual y umbral de alarma.
• problemas.
El sistema hace seguimiento de cada sensor ubicados en edificios. Como atributos
• Como atributos
del edificio tenemosdel sensor
dirección tenemos
y número fabricante, número de mo-
de contacto.
• delo, secuenciadede
Una característica losiniciación, factor
sensores críticos es lade escala y unidad de me-
tolerancia.
dida, intervalo de muestreo, ubicación, estado, valor actual y
umbral de alarma.
• El sistema hace seguimiento de cada sensor ubicados en edi-
ficios. Como atributos del edificio tenemos dirección y número
110
de contacto.
• Una característica de los sensores críticos es la tolerancia.
• Para que el sistema se active debe superarse el umbral de cada
sensor. A los dispositivos de alarma se los identifica de acuerdo
a su funcionamiento: el estado del dispositivo y la duración de

la alarma.
• Al provocarse una alarma el sistema deberá almacenar la fe-
cha, hora, severidad, tiempo de reparación y estado.
• La monitorización de los sensores se da desde que se inicia
hasta que se apaga, el intervalo de muestreo toma una mues-
tra, que la convierte utilizando el factor escala y la unidad de
medida. Esta muestra se la compara con el umbral, para de
esta manera ver si iguala o supera para poder crear la alarma
y activar el dispositivo.
•
Solución:
Para la creación del diagrama de clase primeramente creamos la clase
Sensor con cada uno de sus atributos. Como se conoce existe otro tipo
de sensores con un atributo propio que lo identifica, para ellos debe-
mos crear una subclase con el nombre Sensor Crítico con el atributo
tolerancia, pero debido a la herencia entre estas clases además de sus
propios atributos tendrá los atributos de la clase Sensor.
Creamos otra nueva clase que será Edificio, porque es necesario co-
nocer la ubicación de cada sensor, se establecerá la relación entre un
sensor y Edificio.
Para tener información acerca de los sucesos de alarma es necesa-
rio crear una clase que almacena esta información: fecha, hora, severi-
dad, tiempo de reparación y estado. Por cada sensor puede o no tener
sucesos de alarma, y la asociación se daría entre Sensor y sucesos.
Para controlar la activación de cada dispositivo se crea la clase Dispo-
sitivo Alarma con los atributos Estado y Duración. Se establecerá la
relación entre Suceso y Dispositivo Alarma.
Los métodos que se darán a las clases serán:
Iniciar(), método que será invocado cuando el sensor deberá funcionar.
Monitoriza(), método que calculará el valor del umbral sino se encuen-
tra dicho valor se producirá el suceso de alarma.
Activar(), método de la clase Dispositivo Alarma.
146 Zea M, Honores J,FUNDAMENTOS
Rivas W DE BASE DE DATOS 2015

SENSOR
EDIFICIO
2015
Está en
"Fabricaute *Dirección
"Nro. Modelo *NumContacto
"Secuencialniciación
"Factorlíscala
*UnidadMedida SUCESOALARMA DISPOSITIVOALA

Se producen RMA
"Intervalolvíuestreo "Fecha Activa
*Estado
"Ubicacióu *Hora
*DuraciónAlarma
"Estado "Severidad
+ActivarQ
•v alorActual *TiempoReparacion
*UmbralAlarma *Estado
T
SENSORCRITICO
*Tolerancia
+Iniciar O
+MonitorizarO
Figura. 73: Diagrama de sistema de monitorización de sensores
Ejercicios Propuestos
Figura. 73: Diagrama de sistema de monitorización de sensores
1. Se proporciona
TEMA: Análisis el siguiente esquemarelacional
del modelo relacional: y los elementos que lo inte-
Pedido(RefPed, FPed)
gran.
Línea Pedido (RefPed, CodArt, Can, Impor)
1.
Articulo
Se proporciona
1. Se proporciona el siguiente
(CodArt, DetProd,
el siguiente
esquema
PUnit)
esquema relacional:
relacional:
Línea Pedido
Línea Pedido (RefPed,
(RefPed,CodArt, Can, Impor)
CodArt, Can, Impor)
Articulo (CodArt, DetProd, PUnit) Pedido
Articulo (CodArt, DetProd, PUnit)
Pedido FecPed
E010 05/01/2014
E011 Pedido
10/01/2014
Pedido
E012 FecPed
15/01/2014
E010
E013 05/01/2014
25/01/2014
E011 Tabla 38: Tabla
10/01/2014
pedido
E012 15/01/2014
E013 25/01/2014
Tabla 38: Tabla pedido

112

112



Linea Pedido
RefPed CodArt CantArt
E010 A0043 10
E011 A0078 12
E012 A0043 5
E013 A0075 20
E010 A0012 15
E011 A0043 5
E012 A0089 50
Tabla 39: Tabla línea de pedido
Articulo
Cod Art DesArt PVPArt
A0043 Esfero negro fino 0,60
A0078 Esfero verde normal 0,45
A0075 Cuaderno espiral a cuadros x100 hojas 1,50
A0012 Tijera 1,00
A0089 Lápices de colores 1,25
Tabla 40: Tabla Artículo
PorPor
cadacadaconsulta
consulta indicar el resultado
indicar y escribirylas
el resultado expresiones
escribir lasdel algebra relacional,
expresiones del
cálculo relacional de tuplas y cálculo relacional de dominios:
algebra relacional, cálculo relacional de tuplas y cálculo relacional de
a) Adquirir artículos de precio inferior a 0,25 C.
dominios:
b) Adquirir la descripción y el precio de los artículos con precio superior a 1€.
a).- Adquirir artículos
c) Adquirir de precio
la descripción de losinferior
artículos ay 0,25 C.
las unidades solicitadas en el pedido
P0004.
b).- Adquirir la descripción y el precio de los artículos con precio supe-
d) Adquirir por cada pedido realizado con posterioridad al 20 de febrero de 2013, la
rior a 1€.
fecha del pedido, y por cada uno de los artículos solicitados en él, su descripción, el
c).- Adquirir la descripción de los artículos y las unidades solicitadas
precio del articulo y el número de unidades solicitadas.
en el
2. pedido P0004.varios ejercicios prácticos para la normalización en los cuales se
Se proporciona
d).- Adquirir por cada
deberán aplicar pedido
las formas realizado
normales desde lacon posterioridad
primera forma normal al 20lade
hasta fe-
tercera
brero forma
de 2013,normal,lapara mostrar
fecha del un esquemay relacional
pedido, por cada conuno
muchas
de más
los relaciones
artículosy
normalizado.
solicitados en él, su descripción, el precio del articulo y el número de
unidades solicitadas.
2. Se proporciona varios ejercicios prácticos para la normaliza-

ción en los cuales se deberán aplicar las formas normales desde la
primera forma normal hasta la tercera forma normal, para mostrar un
esquema relacional con muchas más relaciones y normalizado.
2.1. Liga de futbol
Relación universal:
Liga (ON!, Nombre jugador, Fecha nacimiento, Sueldo, Nacionalidades, 113

idiomas, Nombre equipo, Ciudad, Presidente, Código partido, Fecha,
Resultado)
• Un jugador puede tener una o varias nacionalidades.
• Un jugador puede hablar uno o varios idiomas.
• Un jugador pertenecerá a un solo equipo.
• Un equipo solo pertenecerá a una ciudad con un único presi-
dente.
• Un código de partido es solo los partidos que ha jugado dicho
jugador.
2.2. Almacén
Almacén (con Tienda, Nombre jinda, Código Ciudad, Nombre Ciudad,
Provincia, Con Autónoma, Código Art, Nombre Art, Cantidad Art, PVP
Art, IVA Art)
• Los artículos se identifican por un código y nombre.
• La mercancía Llevada depende de las necesidades locales.
• La cantidad y precio unitario de un artículo difiere de una tien-
da a otra depende siendo de la demanda local.
• Cada artículo posee el mismo IVA.
•
2.3. Cursos
Cursos (Código Curso, Nombre Curso, Dm Estudiante, Nombre Estu-
diante, Numero Matricula, Centro, Profesor, Texto)
• El identificador único de un curso es su código.
• Un estudiante puede estar matriculado en varios cursos.
• Un estudiante posee números de matrícula distinta respecto a
cada curso matriculado.
• Un curso se imparte en un solo centro.
• Un curso se imparte por un solo profesor.
• Un profesor puede impartir varios cursos.
• Un profesor imparte clases en un solo centro.
• Un curso se apoya en distintos textos, y un mismo texto puede
servir para varios cursos.
• Tema: Descripción y aplicación del modelo entidad-relación

para el modelado de datos
• Referente a este tema se mostrarán varios ejercicios para mo-
delar modelos entidad – relación. Se explica el paso a paso para
obtener un modelo entidad - relación y a partir de este poder
transformar al esquema relacional sin olvidar cada una de las
reglas de transformación vistas anteriormente.
Tema: Descripción y aplicación del modelo entidad-relación para

el modelado de datos
Referente a este tema se mostrarán varios ejercicios para modelar mo-
delos entidad – relación. Se explica el paso a paso para obtener un mo-
delo entidad - relación y a partir de este poder transformar al esquema
relacional sin olvidar cada una de las reglas de transformación vistas
anteriormente.
Liga de futbol
La Liga de Fútbol Profesional (LFP) requiere implementar una base de
datos con estadísticas de la temporada.
• Los jugadores serán identificados por un número de ficha,
nombre, apellido, fecha de nacimiento, peso y estatura.
• Los equipos se identificarán por su nombre, año de fundación,
nombre del presidente, número de socio y estadio.
• Un jugador puede participar en varios equipos a lo largo de su
carrera, pero no al mismo tiempo.
• Del contrato que se realiza entre un club y un jugador, se desea
almacenar fecha de comienzo, duración, ficha anual y cláusula
de rescisión.
• De los partidos jugados se almacenará un código, fecha, resul-
tado y la jornada.
• Todos los jugadores pueden o no participar en todos los parti-
dos, siendo importante sus minutos jugados, goles anotados y
tarjetas recibidas.
• De los árbitros se requiere información del número de colegia-
do, nombre del colegio arbitral, nombre, apellido y numero de
temporadas.
• En cada partido hay cuatro árbitros siendo importante almace-
nar la función que desempeña cada uno
Supermercado
En un supermercado existen varios proveedores, la información que se
desea guardar es su nombre, dirección y teléfono.
• Todo proveedor puede suministrar uno o varios artículos a la
vez, la información del artículo que se requiere almacenar es el
nombre, precio, número y el precio tanto del proveedor como el
precio de venta.
• Todo supermercado está estructurado por departamentos, la
información que se requiere es el código, director y la serie de
empleados. Cada uno de estos departamentos es responsable
de un área específica y cada departamento puede vender una
clase de artículo.
• De los empleados que trabajan en un supermercado, la infor-
mación que se necesita almacenar es el nombre, dirección, te-
léfono, salario y departamento.
• De los clientes que tiene el supermercado, la información que
se necesita almacenar es el nombre, dirección, teléfono y saldo.
• Cada cliente realiza un pedido la información a almacenar es el
número del pedido, fecha, artículos y cantidad.
Tema: Modelo orientado a objeto.

Se proponen varios ejercicios para la modelización de diagramas de cla-
ses. Por cada ejercicio se proporciona el enunciado que describe como
se desea obtener el diagrama de clase.
Biblioteca
Una biblioteca tiene copias de libros.
• Los libros poseen un título, año y autor o autores.
• Los autores se caracterizan por su nombre y nacionalidad.
• Un libro puede ser escrito por uno o varios autores.
• Una copia de libro posee un identificador.
• Un libro puede estar en una biblioteca por motivos de présta-
mos, retraso o en reparación.
• Se almacena información acerca de los préstamos actuales y
antiguos.
• De un lector se almacena su ID, nombre, apellidos y dirección.
• Cada libro se presta un máximo de 30 días.

• Si un libro no es devuelto en la fecha límite, se sanciona con
dos días sin posibilidad de hacer préstamos de un nuevo libro.
Obtenga el diagrama de clases con atributos para cada clase.
Entidad bancaria
Se desea sistematizar las operaciones de un banco del cual se necesita
conocer nombre, OF y dirección. Y de la cual se necesita obtener:
• Lista de sucursales: código de la sucursal, dirección, celular.
• Lista de cuentas corrientes: número de la cuenta, NIF del titu-
lar, nombre y apellidos, celular, dirección y saldo.
• Lista de operaciones realizables: código de la operación y des-
cripción.
• Lista de recibos domiciliados: número de recibo, número de
cuenta de pago, importe del recibo, entidad emisora (empresa
que emite el recibo) y fecha.
Las reglas del sistema son las siguientes:
• El banco posee varias sucursales.
• Cada sucursal posee varias cuentas corrientes.
• Una cuenta corriente puede asociar a uno o más clientes, es
decir varios clientes con la misma cuenta.
• Un cliente puede tener varias cuentas, y realizar operaciones
distintas en cada una de ellas.
• Cada cuenta puede o no tener uno o varios recibos domicilia-
dos.
Obtener el diagrama de clases indicando para cada clase su nombre y
los atributos.
Puerto de Santurce
Se desea conocer y analizar el control de tráfico del puerto de Santurce.
Del puerto los datos a almacenar son: el número, la denominación y la
razón social.
• Del muelle los datos a almacenar son: número, nombre des-
criptivo asociado y longitud variable entre 30 y 3000 metros.
• En este puerto transitan barcos de carga y de transbordo, den-
tro de los de carga hay varios tipos como pesqueros y comer-
ciales.
•
Los barcos pesqueros se dedican a la pesca de sardina, de este
tipo de barco se necesita almacenar el nombre del barco, el nú-
mero de licencia de pesca, la empresa propietaria, la longitud
del barco en metros y la capacidad total de carga en toneladas.
• De los buques petroleros la información que se necesita alma-
cenar es: nombre, país, empresa propietaria, eslora, la capaci-
dad total de carga en toneladas y la densidad del petróleo.
• De los barcos mercantes la información que se necesita alma-
cenar es: nombre, país, empresa, eslora, capacidad total de
carga y el factor de peligrosidad de la mercancía transportada.
• Existe una línea de transbordadores y se debe almacenar el
nombre, la eslora, el número de pasajeros y el número de ve-
hículos.
• Cada barco puede realizar operaciones y de cada operación
se debe almacenar nombre del barco, eslora, fecha y hora de
la operación. Si la operación es de entrada, se almacenará el
tiempo de estancia aproximado, y si operación de salida se al-
macenará el destino del barco y las observaciones que sean
necesarias.
• De la tripulación se almacenará ID, nombre, apellidos y sueldo.
Si es el capitán, también se requiere la antigüedad.
• Para realizar una operación el barco debe solicitar al capitán
del barco.
• Para realizar una operación de entrada, se necesita conocer si
hay espacio en el muelle.
• El espacio del muelle debe ser actualizada cada vez que se una
operación de entrada o salida.
Se pide obtener el diagrama de clases indicando para cada clase su
nombre, los atributos y los métodos.
Glosario
Agregación: La agregación permite crear a partir de más de dos en-

tidades y una relación que las asocia entre sí, una entidad de nivel
mucho más alto.
Asociación: Es aquella relación normal que existe entre las clases. Es-
tas suelen ser: reflexiva si existe una relación de clase consigo misma,
binaria si relaciona dos clases, ternaria si relaciona tres clases, y así
sucesivamente.
Atributo: Son las características de una entidad y son representados
de varias maneras; ya sea con un óvalo y el nombre del respectivo atri-
buto en su interior puede ser incorporado directamente con la entidad
o con la relación.
Composición: Una composición entre clases resulta ser una relación
más grande que una agregación.
Dependencia: Es aquella relación que se da entre dos clases, la cual
una de las clases se instancia a otra clase. Es decir, que una depende
de otra o que una clase solicita de otra para que pueda trabajar.
Entidad: Se define a una entidad como un objeto del cual se desea
almacenar información en la base de datos.
Herencia: Es un tipo de asociación entre una entidad padre y una
entidad hijo y se representa por medio de un triángulo inverso que se
conecta con las entidades mediante una línea.
Relación: Es la correspondencia entre entidades y es representada por
medio de un rombo con el respectivo nombre en su interior.
[153]
Bibliografía
[1] A. Silberschatz, H. F. Korth y S. Sudarshan, Fundamentos de Ba-

ses de Datos, España: MacGraw Hill, 2002.
[2] C. J. Date, Introducción a los Sistemas de Bases de Datos, México:
Pearson Educación, 2001.
[3] M. J. Ramos Martín, A. Ramos Martín y F. Montero Rodriguez, Sis-
temas Gestores de Bases de Datos, España: McGraw Hill, 2006.
[4] M. Marqués, «Sapientia,» 2011. [En línea]. Available: http://www.
uji.es/bin/publ/edicions/bdatos.pdf. [Último acceso: 2016].
[5] J. Sánchez, «jorgesanchez.net,» 2004. [En línea]. Available: http://
www.jorgesanchez.net/bd/bdrelacional.pdf.
[6] J. Sanchez, «Principios sobre Bases de Datos Relacionales,» 2004.
[En línea]. Available: http://www.jorgesanchez.net/bd/.
[7] J. Sanchez, «Diseño Conceptual de Base de datos,» 2004. [En lí-
nea]. Available: http://www.jorgesanchez.net/bd/.
[8] D. M. KROENKE, Procesamiento de bases de datos: fundamentos,
diseño e implementación., MÉXICO: Cámara Nacional de la Indus-
tria Editorial Mexicana, 2003.
[9] I. M. Jareño, El Modelo Entidad- Relación CASE-METHOD, Wilm-
ington: Días de Santos S.A, 1994.
[10] M. V. N. Cabello, Introducción a la Base de Datos Relacionales,
Madrid: Visión Libros, 2010.
[11] V. F. Alarcón, Desarrollo de sistemas de información: una me-
todología basada en el modelado., Catalunya: Edicions UPC, 2010.
[12] Universidad de Sevilla, «Modelo Entidad-Relación Extendido,»
02 2007. [En línea]. Available: http://www.lsi.us.es/docencia/get.
[155]
php?id=1864.
[13] D. C. Costa, Introducción al Diseño de Bases de Datos, Edito-
rial UOC.
[14] A. C. Yera, Diseño y Programación de bases de Datos, Madrid:
Visión Libros.
[15] J. M. Vara, «Transformación de Modelos para el Desarrollo de
Bases de Datos Objeto-Relacionales,» 07 2007. [En línea]. Availa-
ble: http://www.ewh.ieee.org/reg/9/etrans/ieee/issues/vol05/
vol5issue4July2007/5TLA4_09Vara.pdf.
[16] M. C. Pabón, «Gestion y Modelación de Datos Diseño de
BD - Modelo Entidad Relación,» 06 2011. [En línea]. Avai-
lable: http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.
php?media=materias:bd1:3_mer.pdf.
[17] M. A. Rodriguez, «Amazon S3,» 2014. [En línea]. Available:
https://s3.amazonaws.com/piazza-resources/hyiw1nus1o81pv/
i0dww1j7zt36sw/Normalizacion.pdf?AWSAccessKeyId=AKIAIEDN
RLJ4AZKBW6HA&Expires=1454108791&Signature=irOD1NHnty
NLUcYHjqkfM6oscUE%3D. [Último acceso: 28 01 2016].
[18] J. M. Cotos Yáñez y J. Á. Taboada González, Sistemas de infor-
mación medioambiental, España: Netbiblo, 2005.
[19] M. Y. Jimenez Capel, IFCT0310: Bases de datos relacionales y
modelado de datos., Malaga: IC Editorial, 2015.
[20] J. M. Piñeiro Gomez, Base de datos relacionales y modelos de
datos, España: Paraninfo, 2013.
[21] J. M. Peñiero Gómez, Lenguajes de definicion y modificacion de
datos SQ, España: Ediciones Paraninfo, S.A..
Se terminó de imprimir en marzo de 2016 en la
imprenta de la UTMACH, calle Loja y 25 de Junio
(campus Machala)
Esta edición consta de 300 ejemplares.
www.utmachala.edu.ec
ISBN: 978-9942-24-07 4-3
1
9 789942 240743

6 Version Electronica de Una Revista

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

6 Version Electronica de Una Revista

Uploaded by

Copyright:

Available Formats

Fundamentos de bases

Universidad Técnica de Machala

Ing. Amarilis Borja Herrera, Mg. Sc.

Soc. Ramiro Ordóñez Morejón, Mg. Sc.

Tomás Fontaines-Ruiz, PhD.

Ing. Karina Lozano Zambrano

Ing. Jorge Maza Córdova, Ms.

Mariuxi Zea Ordoñez

UNIVERSIDAD TÉCNICA DE MACHALA

D.R. © 2015, universidad técnica de machala

Este texto ha sido sometido a un proceso de evaluación por pares externos

Diseño, montaje y producción editorial: UTMACH

Impreso y hecho en Ecuador

Advertencia: “Se prohíbe la reproducción, el re-

2.2.3. Atributo y dominio..................................................... 47

3.7.4. Desarrollo de diferentes supuestos prácticos de

Figura. 1: Relación empleados con sus campos y registros..28

Tabla 1: Definición matemática de relacion.......................... 68

En la actualidad, se considera a las bases de datos como un elemento

Dedico la realización de este libro a mis padres por el apoyo que me

Con base a las investigaciones se ha comprobado que en la actualidad

gramas Entidad-Relación y desarrollo de diversos supuestos prácticos

Descripción del capítulo

A continuación, se presentará los objetivos principales de cada aparta-

1.1. Generalidades de bases de datos

• Base datos relacional: Es aquella que está compuesta por un con-

Administrador de la base de datos: Es la persona encargada

Diseñadores de la base de datos: Aquellos que diseñan la

Programadores de aplicaciones: Encargados de implementar

A continuación, se definen los elementos de una base de datos relacio-

Tupla: Se considera tupla a cada una de las filas de una tabla.

Atributo: Son las columnas de una tabla.

Grado: Número de atributos por los que está compuesta una

Cardinalidad: Corresponde al número de tuplas de una tabla.

Dominio: Permite especificar los posibles valores válidos para

Valor nulo: Indican contenidos de atributos que no tienen nin-

Relaciones: Son aquellas que permiten evitar los datos redun-

• Formularios: Se utilizan para actualizar los datos.

En una base de datos relacional los datos se obtienen en relaciones

e:] Andrea Pineda ::'vfasculino Gerente de operaciones

1001 Cri sthian Durán Masculino Director técnico

1003 Roció Ruiz Femenino Analista

• Clave candidata: Es el conjunto de atributos de una tabla por los

1.3. Concepto de modelos de datos. Funciones y sublenguajes

Un modelo de datos es un instrumento usado para crear una base de

segmento estático y dinámico.

Por ejemplo, si guardamos información de cinco empleados en una ta-

elaboración de esta tarea es el Modelo Entidad Relación.

1.3.1. Diseño de los sistemas de bases de datos

1.3.2. Funciones de un SGBD

1.3.2.1. Función de definición

1.3.2.2. Función de manipulación.

lenguajes de especificación por medio de cada sentencia del DML logra

1.3.2.3. Función de control

1.4. Clasificación de los varios tipos de diseño de datos de acuerdo

Existen diferentes tipos de diseño de datos que se adaptan a lo largo del

1.4.1. Modelos de datos conceptuales

1.4.1.1. Modelos Entidad Relación

ejemplares, etc. Las entidades son representadas a través de

Figura. 2: Esquema entidad relación de una biblioteca

1.4.1.2. Diseño orientado a objetos

• Atributo: Los atributos vienen hacer las características de una

Figura. 3: Diagrama de clases para una biblioteca.

1.4.2. Modelos deModelos