BDP Compendio Unidad 1 Tema 2 2022 2

BASES DE DATOS
5 créditos
Bases de datos
Unidad 1: Diseño de bases de datos relacionales
Tema 2: Diseño de bases de datos
TABLA DE CONTENIDO
Tabla de contenido ................................................................................................................................ 2

Tabla de Ilustraciones ............................................................................................................................ 3
Organización de la lectura para el estudiante por semana del compendio ............................................ 4
Resultado de aprendizaje ....................................................................................................................... 4
De la asignatura de Base de datos .................................................................................................. 4
Unidad 1. Diseño de bases de datos ............................................................................................... 4
2.1. Modelado de datos y modelo de datos ........................................................................................... 5
2.1.1 La importancia de los modelos de datos ............................................................................... 5
2.1.2 Lo básico de los modelos de datos ........................................................................................ 6
2.1.3 Las reglas de negocio o requerimientos de automatización ................................................ 11
2.1.4 La evolución de los modelos de datos................................................................................. 13
2.2 Tipos de modelos de datos ............................................................................................................ 14
2.2.1 Modelo de datos jerárquico: Características básicas ........................................................... 14
2.2.2 Modelo de datos de red: Características básicas ................................................................. 17
2.2.3 Modelo de datos relacional: Características básicas ........................................................... 20
2.3. Metodología de diseño de bases de datos ..................................................................................... 25
2.3.1 Niveles de abstracción: conceptual, lógico y físico ............................................................ 26
2.4 Diseño conceptual ......................................................................................................................... 27
2.4.1 Esquema conceptual: de alto nivel, detallado ..................................................................... 28
2.4.2 Modelo entidad-relación ..................................................................................................... 30
2.4.3 Entidad: fuerte, débil; supertipo, subtipo ............................................................................ 33
2.4.4 Atributos: simples, compuestos; monovalentes, multivalentes; derivados ......................... 38
2.4.5 Identificadores: internos, externos, mixtos; simples y compuestos .................................... 38
2.4.6 Relaciones ........................................................................................................................... 42
2.4.7 Jerarquía de generalización ................................................................................................. 50
2.5 Diseño lógico de datos................................................................................................................... 52
2.5.1 Metodología de diseño lógico en el modelo relacional ....................................................... 54
2.5.2 Reglas de Codd ................................................................................................................... 59
Referencias .......................................................................................................................................... 61
2
Bases de datos
TABLA DE ILUSTRACIONES
La presente imagen dentro del manual mostrará información

interesante y novedosas de la asignatura.
Sabías que
La presente imagen dentro del manual permite recordar

información que es relevante y que vas necesitar en tu vida
Recuerde que profesional.
Es un cuestionario de un conjunto de preguntas que se confecciona

para obtener información con algún objetivo en concreto. Por cada
Comprueba tu tema de la unidad se tendrá cuestionario que el estudiante debe
aprendizaje resolver entre preguntas teóricas y prácticas.
Para complementar contenidos de la unidad dentro del manual se

tiene videos que permitirá al estudiante revisar y explorar
Videos conocimientos auditivos y visuales.
La presente imagen en el manual mostrará información que debe

conocer de la asignatura.
Curiosidades.
La presente imagen en el manual mostrará información que deberá

tomar en cuenta para otras unidades de la asignatura o de otras
asignaturas en semestre superiores.
Datos útiles.
3
Bases de datos
ORGANIZACIÓN DE LA LECTURA PARA EL ESTUDIANTE POR

SEMANA DEL COMPENDIO
Semanas Compendio
Semana 4 Páginas 5 – 26
RESULTADO DE APRENDIZAJE
De la asignatura de Base de datos
El estudiante al finalizar el curso estará en capacidad para ser parte de un equipo de

profesionales de distintas áreas del conocimiento, demostrando una efectiva cooperación,
comunicación, con habilidades para resolver conflictos y contribuyendo proactivamente en la
propuesta de líneas estratégicas desde el punto de vista informático, para la solución de problemas
de procesamiento de datos.
Unidad 1. Diseño de bases de datos
Tema 1: Explicar los componentes principales de las bases de datos y las funciones básicas de los
sistemas de gestión de bases de datos. Diferenciar los tipos de bases de datos, en especial al modelo
jerárquico, de red y relacional, mediante sus características más relevantes y su estructura.
Tema 2: Diseñar esquemas conceptuales, utilizando el modelado entidad-relación, de sistemas de

base de datos que den solución a un problema específico.
Tema 3: Optimizar la estructura relacional, esquema lógico de datos, de las tablas aplicando la
normalización y desnormalización.
4
Bases de datos
2.1. MODELADO DE DATOS Y MODELO DE DATOS
El modelado de datos es el proceso de crear un modelo de datos para que los datos se
almacenen en una base de datos. Es decir, el modelado de datos es el proceso de describir
estructuras de información y ayuda en la representación visual de los datos y hace cumplir las
reglas de negocios, el cumplimiento normativo y las políticas gubernamentales sobre los datos
(Beynon-Davies, 2018). Tiene como finalidad simbolizar una parte del mundo real para almacenarla
en una base de datos (Sánchez, 2004). Los modelos de datos garantizan la coherencia en las
convenciones de nomenclatura, los valores predeterminados, la semántica y la seguridad, al tiempo
que garantizan la calidad de los datos y es el primer paso en el diseño de la base de datos.
El modelo de datos se define como un modelo abstracto que organiza la descripción de los
datos, la semántica de los datos y las restricciones de coherencia de los datos (Elmasri et al., 2002).
El modelo de datos enfatiza qué datos se necesitan y cómo deben organizarse en lugar de qué
operaciones se realizarán con los datos y se lo puede expresar como el plan de construcción de un
arquitecto, que ayuda a construir modelos conceptuales y establecer una relación entre los
elementos de datos. Un tipo de técnica de modelado de datos es el modelo entidad-relación (ER)
que se abarcará más adelante.
2.1.1 La importancia de los modelos de datos
El modelo de datos se puede referir a un modelo abstracto que organiza elementos de datos
y estandariza cómo se relacionan entre sí y con las propiedades de las entidades del mundo real
(Ordoñez et al., 2016). Un modelo de datos determina explícitamente la estructura de los datos y
facilita la interacción del diseñador de la base de datos, la persona que programa las aplicaciones y
los usuarios finales y permiten entender la interacción de los datos dentro de una organización.
La aplicación de modelos de datos es importante dentro de una organización por las

siguientes razones:
 Asegura que todos los objetos de datos requeridos por la base de datos estén
representados con precisión. La omisión de datos dará lugar a la creación de informes
defectuosos y producirá resultados incorrectos.
5
Bases de datos
 Un modelo de datos ayuda a diseñar la base de datos en los niveles conceptual, físico y
lógico.
 La estructura del modelo de datos ayuda a definir las tablas relacionales, las claves
primarias y externas y los procedimientos almacenados.
 Proporciona una imagen clara de los datos base y los desarrolladores de bases de datos
pueden utilizarla para crear una base de datos física.
 También es útil identificar datos faltantes y redundantes.
 Facilita la comunicación y organiza los datos de los usuarios.
 Aunque la creación inicial del modelo de datos requiere mucho tiempo y trabajo, a
largo plazo, hace que la actualización y el mantenimiento de su infraestructura de TI
sean más baratos y rápidos.
Video: En el siguiente enlace podrán profundizar un poco más sobre el modelo de
datos: https://www.youtube.com/watch?v=4qFZ-5i4GS8
2.1.2 Lo básico de los modelos de datos
Los modelos de datos funcionan como una abstracción simplificada de la realidad. En un

hospital, cada paciente es diferente y debe tratarse de forma individual. En software, sin embargo,
hablamos de un paciente abstracto. Lo mismo se aplica a los restaurantes y cualquier otro ámbito.
Cada vez, debe tomar decisiones sobre qué información es importante y debe incluirse en el modelo
de datos y qué omitir. En un hospital, debe conocer la edad del paciente. Pero la edad de la misma
persona no tendrá mucha importancia en un restaurante. En aplicaciones complejas, a menudo es
necesario responder a cientos de preguntas antes de escribir una sola línea de código.
Entonces, ¿cómo se ve un modelo de datos, en realidad? Por lo general, se crea en forma

gráfica. Hay que crear un diagrama que identifique los principales conceptos del dominio, sus
características y relaciones. Los conceptos suelen adoptar la forma de rectángulos con nombre. En el
6
Bases de datos
caso de un hospital, podrían nombrarse: paciente, médico, sala, etc. Las relaciones entre ellos se
ilustran como líneas o flechas que conectan los rectángulos.
Los rectángulos se pueden anotar de varias formas para mostrar información adicional. Por
ejemplo, podría enumerar toda la información necesaria para un paciente: nombre, edad, sexo, etc.
Clasificación de los modelos de datos
Figura 1. Clasificación de los modelos de datos.
Fuente: Sánchez (2004)
Los elementos del esquema presentado en la Figura 1 son:
• Mundo real: Contiene la información tal cual la percibimos como seres humanos. Es el
punto de partida
• Esquema conceptual: Representa el modelo de datos de forma independiente del SGBD

que se utilizará
• Esquema canónico (o de base de datos): Representa los datos en un formato más

cercano al del ordenador
• Esquema interno: Representa los datos según el modelo concreto de un sistema gestor
de bases de datos. Por ejemplo, Oracle
• Base de datos física: Los datos tal cual son almacenados en disco.
7
Bases de datos
Conceptos fundamentales usados en el modelo de datos
Existen conceptos generales que están asociados al modelo de datos:
• Entidad: Es un objeto específico que existe en el mundo real. Por ejemplo, una oficina,
departamento, empleado, computadora, cliente o producto. Las entidades deben tener
claves para poder relacionarse con otras entidades.
• Relación: Son los vínculos entre entidades. Por ejemplo, una relación entre la entidad
Empleado y la entidad Departamento puede ser que un empleado sea miembro de un
departamento. En una relación uno a uno (1:1 o 1..1), cada instancia de una entidad se
relaciona con una instancia de una segunda entidad. En una relación de uno a muchos
(1:M o 1..*), cada instancia de una entidad se relaciona con una o más instancias de una
segunda entidad. En una relación de muchos a muchos (M:N o *..*), muchas instancias
de una entidad se relacionan con muchas instancias de la otra entidad.
• Atributo: Es una propiedad o característica propiedad de una entidad o relación. Por

ejemplo, la entidad Empleado puede tener los atributos de nombre, dirección particular,
número de teléfono particular y fecha de contratación.
• Restricción: Son las reglas que obligan a los SGDB a verificar que los datos satisfagan la
semántica establecida. Las restricciones se utilizan para limitar el tipo de datos que
pueden incluirse en una tabla. Esto asegura la precisión y confiabilidad de los datos en
la tabla. Si hay alguna violación entre la restricción y la acción de datos, la acción se
cancela. Las restricciones pueden ser de nivel de columna o de tabla.
• Dominio: Es un objeto definido que contiene metadatos del modelo de datos. Es decir,
datos sobre datos, como tipos de datos, reglas de validación, dependencias o valores
predeterminados que agrupa datos y el comportamiento requerido para su
funcionamiento
• Diccionario de datos: Es un conjunto de metadatos. Cuando el modelo de datos se

implementa en un SGBD, el diccionario de datos se convierte en un conjunto de tablas y
vistas de solo lectura.
8
Bases de datos
Es importante recalcar que los nombres que se les otorguen a las entidades, atributos o
relaciones tienen que describir los objetos a los que se refiere, usando terminología que sea familiar
a los usuarios. Por ejemplo, si una entidad es referente a un estudiante, esta se debería llamar
Estudiante o Alumno. De esta forma, se facilita la comunicación entre diferentes usuarios que
intervienen en el modelo de datos.
Ventajas y desventajas del modelo de datos
Entre las ventajas de implementar el modelo de datos encontramos:
• El objetivo principal del diseño de un modelo de datos es asegurarse de que los objetos
de datos ofrecidos por el equipo funcional se representen con precisión.
• El modelo de datos debe ser lo suficientemente detallado para ser utilizado para
construir la base de datos física.
• La información del modelo de datos se puede utilizar para definir la relación entre
tablas, claves primarias y externas y procedimientos almacenados.
• El modelo de datos ayuda a las empresas a comunicarse dentro y entre organizaciones.
• El modelo de datos ayuda a reconocer las fuentes correctas de datos para poblar el
modelo.
Con respecto a las desventajas se nombran las siguientes:
• Para desarrollar el modelo de datos, se deben conocer las características físicas de los
datos almacenados.
• Incluso los cambios más pequeños realizados en la estructura requieren modificaciones

en toda la aplicación.
• No hay un lenguaje de manipulación de datos establecido en SGBD.
9
Bases de datos
Propiedades de los datos
Para proceder con el modelo de datos, hay que considerar algunas propiedades importantes
de los datos y su calidad, mismos que deben cumplir los siguientes requisitos para asegurar un
buen desempeño del modelo:
• Propiedades relacionadas con la definición:
o Relevancia: La utilidad de los datos en el contexto del negocio o Consistencia:

La compatibilidad del mismo tipo de datos de diferentes fuentes
• Propiedades relacionadas con el contenido:
o Puntualidad: La disponibilidad de datos en el momento requerido y qué tan

actualizados están los datos
o Precisión: Qué tan cerca de la verdad están los datos
• Propiedades relacionadas tanto con la definición como con el contenido:
o Integridad: Cuántos de los datos requeridos están disponibles o Accesibilidad:

dónde, cómo y para quién están disponibles o no los datos o Costo: El costo
incurrido para obtener los datos y ponerlos a disposición para su uso
10
Bases de datos
Figura 2. Propiedades de calidad de los datos en el modelo de datos.
2.1.3 Las reglas de negocio o requerimientos de automatización
Las reglas de negocios son una parte fundamental del modelo de datos. La regla de negocio
es una descripción breve, precisa e inequívoca de una política, procedimiento o principio dentro del
modelo de datos y es importante porque prepara el escenario para la identificación adecuada de
entidades, atributos, relaciones y restricciones (Pereira Toledo et al., 2020). Las reglas de negocio
están dirigidas a especificar qué restricciones o condiciones deben cumplirse para que un dato se
considere válido en una base de datos (Boggiano-Castillo et al., 2013).
También se la puede definir como una declaración que impone algún tipo de restricción
sobre un aspecto específico de la base de datos, como los elementos dentro de una especificación de
campo para un campo en particular o las características de una relación determinada. Una regla de
negocio se basa en la forma en que la organización percibe y utiliza sus datos, que se determina a
partir de la forma en que la organización funciona o realiza sus negocios.
En las reglas del negocio, generalmente los sustantivos se usan para describir entidades (i.e.,
estudiantes, clases) y los verbos para las relaciones entre las entidades (i.e., los estudiantes pueden
11
Bases de datos
tomar una clase). Las relaciones pueden ser uni o bidireccionales como se explicó en los conceptos
fundamentales de modelo de datos. Es decir, un estudiante que repite por tercera ocasión debe
tomar una sola clase (1:1), o un estudiante de 4to semestre debe tomar 4 clases (1:M)
Para identificar las reglas de negocios, se pueden obtenerlas de diferentes fuentes como los
gerentes, los tomadores de decisiones, jefes departamentales, documentos escritos o entrevistas
directas con usuarios finales para determinar como usan los sistemas y cuáles son los
requerimientos y retos a los que se enfrentan cuando usan las aplicaciones. Las razones para
identificar y documentar las reglas de negocios dentro de una organización son para:
• Estandarizar la visión de los datos de la organización
• Facilitar la comunicación entre usuarios y diseñadores
• Asistir a los diseñadores a entender la naturaleza, rol, alcance de los datos y los
procesos de la organización
• Desarrollar reglas apropiadas para la relación de entidades y restricciones • Crear un

modelo de datos preciso y confiable
Por ejemplo, una regla de negocio es que una persona puede tener varios vehículos y cada
uno de esos vehículos tiene que pertenecer a una persona. Otra puede ser que no se permita emitir
una factura a un cliente inexistente o controlar que el saldo negativo de una cuenta bancaria no
sobrepase una cantidad determinada.
Implementación de las reglas del negocio
• Reglas de modelo de datos (constraints): Son aquellas reglas que se encargan de

controlar que la información almacenada para cada atributo o propiedad es válida. Por
ejemplo, no hay precios negativos de productos.
• Reglas de restricción (rules): Restringen los datos que el sistema puede contener. Es
decir, su función principal es garantizar que el dato insertado o modificado cumpla con
cierta condición. Por ejemplo, en la columna teléfono sólo puede ingresarse datos
numéricos.
12
Bases de datos
• Reglas de relación (foreign keys): Controlan las relaciones entre los datos. Por ejemplo,
todo pedido debe ser realizado por un cliente, quien debe estar en estado activo en la
base de datos. Además, una vez que el cliente ha hecho un pedido no se lo puede
eliminar, a menos que previamente se eliminen sus otros pedidos.
• Reglas de flujo (store procedures): Indican qué camino recorre la información y obliga a
qué sólo se siga ese camino.
• Reglas de derivación (views): Especifican y controlan la obtención de información. Por

ejemplo, el total de un pedido se puede derivar de los distintos productos que lo
componen. Mientras que el total de cada producto se calcula por el número de unidades
del producto vendido y el precio por unidad.
Video: En el siguiente enlace pueden reforzar sus conocimientos de las reglas de negocios
https://www.youtube.com/watch?v=mb6ezioTpIc
2.1.4 La evolución de los modelos de datos
Los modelos de datos definen cómo se modela la estructura lógica de una base de datos y
son entidades fundamentales para introducir la abstracción en un SGBD. Los modelos de datos
definen cómo se conectan los datos entre sí y cómo se procesan y almacenan dentro del sistema.
El primer modelo de datos podría ser modelos de datos planos, donde todos los datos
utilizados debían mantenerse en el mismo plano. Los modelos de datos anteriores no eran tan
científicos, por lo que eran propensos a introducir muchas anomalías de duplicación y
actualización. Sin embargo, los modelos de datos planos no califican estrictamente como un modelo
de datos ya que consta de una matriz bidimensional única de elementos de datos, en la que se
supone que todos los miembros de una columna determinada tienen valores similares y que todos
los miembros de una fila están relacionados entre sí.
En la década de 1960 se crearon los modelos jerárquicos y de redes. El modelo jerárquico

presentaba cierto grado de dificultad para representar relaciones M:N. En estos modelos, se
evidenció la dependencia estructural de los datos y no se podían realizar consultas ad hoc.
13
Bases de datos
A inicios de los 70 aparece el modelo relacional, que presentó un modelo conceptual más
sencillo y que demostraba independencia estructural. Si permite las consultas ad hoc a través del
lenguaje SQL. En 1976 surge el modelo relacional que es mucho más fácil de entender por su
aspecto semántico, pero estaba limitado al modelo de datos conceptual.
Posteriormente, hasta 1990 se desarrollaron modelos semánticos, en donde surgen modelos

orientados a objetos y los SGBDR, los cuales dan soporte a objetos complejos, permite el uso de
datos sin estructura y permite la jerarquía de clases.
Finalmente, durante la última década han surgido modelos No SQL que se enfocan en el
meta datos (big data). Estos modelos presentan menos dependencia a la parte semántica y es
aprovechado cuando se trata de enormes cantidades de datos.
2.2 TIPOS DE MODELOS DE DATOS
Un modelo de base de datos es una especificación que describe cómo se estructura y se

utiliza una base de datos. Es decir, un tipo determinado de modelo de base de datos define el
diseño lógico y la estructura de una base de datos y define cómo se almacenarán, accederán y
actualizarán los datos en un sistema de gestión de bases de datos. Se han sugerido varios de estos
modelos y los más comunes incluyen el modelo de datos jerárquico, de red y relacional.
2.2.1 Modelo de datos jerárquico: Características básicas
Este modelo de datos organiza los datos en una estructura en forma de un árbol invertido,
con una única raíz, a la que están vinculados todos los demás datos (Sánchez Romero & Villacis
Miranda, 2020). La jerarquía comienza con los datos raíz (o nodo raíz que es el nivelo 0) y se
expande como un árbol, agregando nodos secundarios a los nodos principales. El modelo de base
de datos jerárquico exige que cada nodo secundario tenga solo un padre, mientras que cada registro
principal puede tener uno o más registros secundarios. Los nodos que no tienen hijos se denominan
hojas y la altura representa el número de niveles de la estructura jerárquica. Uno de los principales
objetivos de las bases de datos jerárquicas es gestionar grandes volúmenes de datos.
El concepto del modelo de datos jerárquico se basa en la representación de las situaciones de

la vida real en las que predominan las relaciones tipo uno a muchos (1:M). Su esquema se organiza
14
Bases de datos
en niveles múltiples en función de una estricta relación padre-hijo, de tal modo que un padre puede
tener más de un hijo, todos ellos localizados en el mismo nivel, pero un hijo sólo puede tener un
padre situado en el nivel inmediatamente superior al suyo. Las entidades en este modelo se
denominan segmentos (nodos) y los atributos campos. Los segmentos se organizan en niveles, así
en un mismo nivel estarían todos los segmentos que dependen de un segmento del nivel
inmediatamente superior. Este modelo describe de manera eficiente muchas relaciones del mundo
real, como el índice de un libro. La relación puede ser de uno a muchos (1:M) entre dos tipos
diferentes de datos, por ejemplo, un departamento puede tener muchos cursos, muchos profesores
y, por supuesto, muchos estudiantes.
Para recuperar datos de un modelo de datos jerárquico, es necesario recorrer todo el árbol
comenzando desde el nodo raíz. Este modelo es reconocido como el primer modelo de base de
datos creado por IBM en la década de 1960.
Ejemplo1: En una universidad se implementa un modelo de datos jerárquico para almacenar

información de docentes y estudiantes. Así, el nodo raíz es la coordinadora académica, quien es el
nodo padre del coordinador de computación. Este, a su vez es el nodo padre de los profesores,
quienes tienen múltiples hijos (alumnos).
Figura 3. Representación de un modelo de datos jerárquico. La altura del modelo es de 4
1
https://sites.google.com/site/fsisbdd/home/base-de-datos-jerarquica
15
Bases de datos
Las características principales de implementar este modelo son:
 Globalización de la información: Permite a los diferentes usuarios considerar la información

como un recurso corporativo que carece de dueños específicos.
 Eliminación de información inconsistente: Si existen dos o más archivos con la misma
información, los cambios que se hagan a éstos deberán hacerse a todas las copias del archivo
de facturas.
 Permite compartir información.
 Independencia de datos: el concepto de independencia de datos es quizás el que más ha
ayudado a la rápida proliferación del desarrollo de este tipo de modelo de datos.
En este tipo de modelos se establece en forma de árbol donde la raíz es un nodo ficticio. Así
tenemos que, una base de datos jerárquicas es una colección de árboles.
Ventajas del modelo jerárquico
El modelo de base de datos jerárquico ofrece las siguientes ventajas:
• El modelo permite agregar y eliminar información nueva fácilmente.
• Se puede acceder rápidamente a los datos de la parte superior de la jerarquía.
• Este modelo funciona bien con medios de almacenamiento de datos lineales como cintas.
• Es compatible con sistemas que funcionan a través de una relación de uno a muchos. Por
ejemplo, la estructura orgánica funcional en una empresa, representada mediante un
organigrama. Hay un presidente con muchos gerentes debajo de ellos, y esos gerentes
tienen muchos empleados debajo de ellos, pero cada empleado tiene solo un gerente.
Desventajas del modelo jerárquico
Si bien el modelo jerárquico es adecuado para estructuras simples, solo admite relaciones de
uno a muchos (1:M). Esto significa que cada nodo hijo solo puede tener un padre. Si, por ejemplo, la
base de datos contiene los nombres de ambos padres y sus hijos que trabajan para una empresa, no
puede describir el hecho de que ambos padres de cada hijo trabajaban para esa empresa. En el
lenguaje de las bases de datos, esto sería una relación de "muchos a uno" (o "muchos a muchos" si
hay más de un hijo involucrado) y las bases de datos jerárquicas no las describen bien. Otras
desventajas incluyen:
16
Bases de datos
• Requiere que los datos se almacenen repetidamente en muchas entidades diferentes

debido a la estructura en forma de árbol.
• Necesita una búsqueda secuencial, lo que significa que el sistema de administración de

la base de datos tiene que recorrer todo el modelo de arriba a abajo hasta que se
encuentre la información requerida. Esto hace que las consultas sean lentas cuando hay
bastantes datos.
2.2.2 Modelo de datos de red: Características básicas
El modelo de red es la extensión de la estructura jerárquica porque permite que las

relaciones de muchos a muchos se gestionen en una estructura en forma de árbol que permite
múltiples padres. Una característica única del modelo de red es su esquema, que se ve como un
gráfico donde los tipos de relación son arcos y los tipos de objeto son nodos (Castillo Arrojo, 2018).
A diferencia de otros modelos de bases de datos, el esquema del modelo de red no se limita a ser un
entramado o una jerarquía; el árbol jerárquico se reemplaza por un gráfico, que permite conexiones
más básicas con los nodos. Hay dos conceptos fundamentales de un modelo de red:
• Los registros contienen campos que necesitan una organización jerárquica.
• Los conjuntos se utilizan para definir relaciones de uno a varios entre registros que
contienen un propietario, muchos miembros.
• Un registro puede actuar como propietario en cualquier número de conjuntos y como

miembro en cualquier número de conjuntos. Un conjunto es definido como dos tipos de
registro, los cuáles están ligados con una relación muchos a muchos (M:N).
• Un registro en el nodo miembro no puede existir sin estar relacionado con un registro
existente en el nodo propietario. Por ejemplo, un cliente debe asignarse a un agente, pero
un agente sin clientes aún puede aparecer en la base de datos.
Un conjunto se diseña con la ayuda de listas circulares enlazadas donde un tipo de registro,
el propietario del conjunto también llamado padre, aparece una vez en cada círculo, y un segundo
tipo de registro, también conocido como subordinado o hijo, puede aparecer múltiples veces en
cada círculo. Se establece una jerarquía entre dos tipos de registros en los que un tipo (A) es
17
Bases de datos
propietario de otro tipo (B). Al mismo tiempo, se puede desarrollar otro conjunto donde el último
conjunto (B) es el propietario del primer conjunto (A). En este modelo, la propiedad se define por la
dirección, por lo que todos los conjuntos comprenden un gráfico dirigido general. El acceso a los
registros se desarrolla mediante la estructura de indexación de listas enlazadas circulares.
Ejemplo2: Los vendedores de leche pueden distribuir determinados productos en algunas

ciudades de la costa. Cada producto puede ser distribuido por más de un vendedor, así mismo cada
vendedor puede distribuir en diferentes ciudades.
Figura 4. Representación de un modelo de datos de red.

Características del modelo de red
El modelo de red tiene las siguientes características principales:
• Puede representar la redundancia en los datos de manera más eficiente que en el modelo
jerárquico.
• Puede haber más de una ruta desde un nodo anterior a los nodos sucesores.
• Las operaciones del modelo de red se mantienen mediante la estructura de indexación de la

lista enlazada (circular) donde un programa mantiene una posición actual y navega de un
registro a otro siguiendo las relaciones en las que participa el registro.
• Los registros también se pueden localizar proporcionando valores clave.
2
https://www.dataprix.com/es/mineria-datos-aplicada-encuesta-permanente-hogares/262-bases-datos-red
18
Bases de datos
Ventajas del modelo de red
El modelo de red conserva casi todas las ventajas del modelo jerárquico al tiempo que
elimina algunas de sus deficiencias. Las principales ventajas del modelo de red son:
• Simplicidad conceptual: Al igual que el modelo jerárquico, el modelo de red es también

conceptualmente simple y fácil de diseñar.
• Capacidad para manejar más tipos de relaciones: El modelo de red puede manejar las
relaciones de uno a muchos (1: M) y de muchos a muchos (M:N), lo que es una ayuda real
para modelar las situaciones de la vida real.
• Facilidad de acceso a los datos: El acceso a los datos es más fácil y flexible que el modelo
jerárquico.
• Integridad de los datos: El modelo de red no permite que un miembro exista sin un
propietario. Por lo tanto, un usuario debe definir primero el registro de propietario y luego
el registro de miembro. Esto asegura la integridad de los datos.
• Independencia de los datos: El modelo de red es mejor que el modelo jerárquico para aislar
los programas de los complejos detalles de almacenamiento físico.
• Estándares de bases de datos: Uno de los principales inconvenientes del modelo jerárquico
fue la no disponibilidad de estándares universales para el diseño y modelado de bases de
datos. El modelo de red se basa en los estándares formulados por DBTG y aumentados por
ANSI / SPARC (Instituto Nacional Estadounidense de Estándares / Comité de Requisitos y
Planificación de Estándares) en la década de 1970. Todos los sistemas de gestión de bases
de datos de la red se ajustaban a estos estándares. Estos estándares incluyen un lenguaje de
definición de datos (DDL) y el lenguaje de manipulación de datos (DML), lo que mejora
enormemente la administración y portabilidad de la base de datos.
19
Bases de datos
Desventajas del modelo de red
Entre sus desventajas encontramos:
• Complejidad del sistema: Todos y cada uno de los registros deben mantenerse con la ayuda
de punteros, lo que hace que la estructura de la base de datos sea más compleja.
• Defectos funcionales: Debido a que una gran cantidad de punteros es esencial, la inserción,
las actualizaciones y la eliminación se vuelven más complejas.
• Falta de independencia estructural: Un cambio en la estructura también exige un cambio en

la aplicación, lo que conduce a una falta de independencia estructural.
• Flexibilidad incompleta: Aunque más flexible que el modelo jerárquico, el modelo de red
aún no puede satisfacer todas las relaciones asignando otro propietario.
2.2.3 Modelo de datos relacional: Características básicas
El modelo relacional representa la base de datos como una colección de relaciones (Beynon-
Davies, 2018), la que expresa la base de datos como un conjunto de relaciones (tabla de valores).
Cada relación tiene columnas y filas que se denominan formalmente atributos y tuplas,
respectivamente. Cada tupla en relación es una entidad o relación del mundo real. El nombre de la
relación y el nombre de los atributos contribuyen a interpretar el sentido de cada tupla.
Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse en forma

lógica como conjuntos de datos llamados tuplas. En este modelo todos los datos son almacenados
en relaciones, y como cada relación es un conjunto de datos, el orden en el que estos se almacenen
no tiene relevancia.
El modelo de datos relacional proporciona herramientas conceptuales para diseñar el

esquema de base de datos de la base de datos relacional. Es decir, describe los datos, la relación
entre esos datos, la semántica de los datos y las restricciones sobre los datos en la base de datos
relacional.
20
Bases de datos
Ejemplo3: La Figura 5 muestra las relaciones entre Clientes que hacen Compras. Las compras
tienen uno o más Productos, y estos productos son distribuidos por proveedores.
Figura 5. Representación de un modelo de datos relacional.
Características del modelo relacional
El modelo de datos relacional presenta las siguientes características:
• La base de datos es un conjunto de relaciones relacionadas (tabla de valores).
• Cada relación tiene un nombre que indica qué tipo de tuplas tiene la relación. Por ejemplo,
una relación denominada "Estudiante" indica que tiene entidades de estudiante.
• Cada relación tiene un conjunto de atributos (nombres de columna) que representa qué tipo
de información tienen las entidades o tuplas.
3
https://sites.google.com/site/michellesyllabus/unidad-2-implementacion-de-base-de-datos-relacionales/2-2modelos-
relacionales
21
Bases de datos
• Una tupla (fila) en una relación, es una entidad del mundo real, tiene un conjunto de
valores para los atributos correspondientes.
• Cada valor de datos en una fila o tupla se llama campo.
Ventajas del modelo relacional
El modelo relacional es uno de los modelos de base de datos más utilizados. Algunas de
las ventajas clave de un modelo de datos relacional son:
• El acceso a los datos no se ve afectado por los cambios en la estructura de la base de datos.
• Es más fácil mantener la seguridad en comparación con otros modelos.
• Puede utilizar bases de datos relacionales con poca o ninguna formación.
• Las entradas de la base de datos se pueden modificar sin especificar todo el cuerpo.
• Evitan errores al permitir que un registro se aplique a cualquier número de otras tablas. Por
ejemplo, puede hacer referencia a un registro secundario en una relación 'es el hijo de' y
puede usar el mismo registro en una tabla de 'niños que asisten a un evento de la empresa'. Esto
ayuda a evitar la replicación y puede usar la misma información de varias formas, sin
cambiar involuntariamente ningún registro.
• Son eficientes para proporcionar otros tipos de datos ocultos en los registros, utilizando
consultas escritas en SQL. Esto le permite explorar la base de datos de formas que no son
evidentes de inmediato, como encontrar a todos los niños mayores de cierta edad o a todos
los padres con tres o más niños.
Desventajas del modelo relacional
En el caso de una base de datos relacional, los datos están normalizados, lo que significa
muchas uniones. Esto puede afectar el rendimiento. Además, tiene problemas para trabajar con
datos semiestructurados porque no obedecen a la estructura tabular de los modelos de datos
asociados. En general, una base de datos relacional tiene los siguientes inconvenientes:
• El mapeo de objetos en una base de datos relacional puede tornarse complejo.
22
Bases de datos
• Se incurre en gastos generales de hardware que lo hacen costoso.
• La base de datos relacional oculta las complejidades de la implementación y los detalles de

almacenamiento de datos físicos de los usuarios.
Sabías que: El Registro de Windows usan modelo de datos jerárquico.

Tablas y sus características: Filas, columnas
Una tabla se percibe como una estructura bidimensional compuesta por filas y columnas. En
una tabla se guardan los datos recogidos por un SGBD y su estructura general se asemeja a la vista
general de programas de hojas de cálculo. Una tabla también se llama relación porque el creador del
modelo relacional, E. F. Codd, usó el término relación como sinónimo de tabla. Una tabla es el
componente principal en el modelo de datos relacionales.
Las características de una tabla relacional se resumen a continuación:
• Una tabla se percibe como una estructura bidimensional compuesta de filas y columnas.
• Cada fila de la tabla (tupla) representa una ocurrencia de entidad única dentro del
conjunto de entidades.
• Cada columna de la tabla representa un atributo y cada columna tiene un nombre

distinto.
• Cada intersección de fila / columna representa un valor de datos único.
• Todos los valores de una columna deben ajustarse al mismo formato de datos.
• Cada columna tiene un rango específico de valores conocido como dominio de atributo.
• El orden de las filas y columnas es irrelevante para el SGBD.
• Cada tabla debe tener un atributo o una combinación de atributos que identifique de
forma única cada fila.
23
Bases de datos
Claves: Clave candidata, superclave, clave primaria, clave foránea
Una clave en un SGBD es un atributo o un conjunto de atributos que ayudan a identificar de

forma única una tupla en una tabla. Las claves también se utilizan para establecer relaciones entre
las diferentes tablas y columnas de una base de datos relacional. Una clave se utiliza en las
definiciones de varios tipos de restricciones de integridad. Una tabla en una base de datos
representa una colección de registros o eventos para una relación en particular. Ahora puede haber
miles y miles de esos registros, algunos de los cuales pueden estar duplicados. Entonces, debe haber
una forma de identificar cada registro por separado y de forma única, es decir, sin duplicados y
para eso se usan las claves en un SGBD.
Tomemos un ejemplo de la vida real de la base de datos de cada estudiante que estudia en
una escuela de ingeniería. ¿Qué atributo del estudiante van a identificar de manera única a cada
uno de ellos? Se puede referir a un estudiante usando su nombre, departamento, año y sección. O
bien, puede mencionar solo el número de registro universitario del estudiante, y puede obtener
todos los demás detalles del estudiante. Una clave puede ser una combinación de uno o más de un
atributo. El motivo principal de esto es darle a cada registro una identidad única.
• Clave candidata: Conjunto de atributos que identifican unívocamente cada tupla de la

relación. Es decir, columnas cuyos valores no se repiten para esa tabla.
Figura 43. Ejemplo de claves candidatas.
• Superclave: Una superclave es un conjunto de uno o más atributos que, tomados

colectivamente, permiten identificar de forma única una entidad en el conjunto de
entidades. Esto significa que todas aquellas columnas de una tabla que sean capaces de
identificar las otras columnas de esa tabla de forma única se considerarán superclaves.
24
Bases de datos
Figura 44. Ejemplo de una superclave.
• Clave primaria: Es la clave candidata que se escoge como identificador de las tuplas. Se
elige clave primaria a la clave candidata que identifique mejor a cada tupla en el
contexto de la base de datos. Por ejemplo, un campo con la cédula de identidad sería
clave candidata de una tabla de clientes. Aunque, si en esa relación existe un campo de
código de cliente, este sería mejor candidato para clave principal, porque es mejor
identificador para ese contexto. En el caso de la Figura 44, la clave primaria sería
Id_cliente.
• Clave alternativa: Es cualquier clave candidata que no sea primaria. En el ejemplo de la

Figura 44 sería Nombre, Teléfono y No_IFE.
• Clave foránea: Se utiliza para establecer relaciones entre dos tablas. Una clave externa
requerirá que cada valor de una columna o conjunto de columnas coincida con la clave
principal de la tabla de referencia. Las claves externas ayudan a mantener los datos y la
integridad referencial.
2.3. METODOLOGÍA DE DISEÑO DE BASES DE DATOS
El diseño de bases de datos es una colección de procesos que facilitan el diseño, desarrollo,
implementación y mantenimiento de sistemas de gestión de datos empresariales. Las bases de datos
correctamente diseñadas son fáciles de mantener, mejoran la coherencia de los datos y son rentables
25
Bases de datos
en términos de espacio de almacenamiento en disco (Cobo, 2007). El diseñador de la base de datos

decide cómo se correlacionan los elementos de datos y qué datos deben almacenarse.
En esta sección veremos el proceso de diseño de la base de datos en términos de

especificidad. Así como cualquier diseño comienza en un nivel alto y avanza hacia un nivel de
detalle cada vez mayor, también lo hace el diseño de bases de datos. Por ejemplo, al construir una
casa, comienza con cuántos dormitorios y baños tendrá la casa, si será de una o varias plantas, etc.
El siguiente paso es conseguir que un arquitecto diseñe la casa desde una perspectiva más
estructurada. perspectiva. Este nivel se vuelve más detallado con respecto al tamaño real de las
habitaciones, cómo se conectará la casa, dónde se colocarán los accesorios de plomería, etc. El
último paso es contratar a un contratista para construir la casa. Eso es mirar el diseño desde un alto
nivel de abstracción hasta un nivel de detalle cada vez mayor. El diseño de la base de datos se
parece mucho a eso. Comienza con la identificación de los usuarios de las reglas comerciales.
Luego, los diseñadores y analistas de la base de datos crean el diseño de la base de datos.
Finalmente, el administrador de la base de datos implementa el diseño usando un SGBD. Las
siguientes subsecciones resumen los modelos en orden decreciente de nivel de abstracción.
2.3.1 Niveles de abstracción: conceptual, lógico y físico
Existen tres tipos diferentes de arquitectura de diseño de datos: conceptuales, lógicos y

físicos (figura 6), y cada uno tiene un propósito específico. Los modelos de datos se utilizan para
representar los datos y cómo se almacenan en la base de datos y para establecer la relación entre los
elementos de datos.
• Diseño conceptual: este modelo de datos define QUÉ contiene el sistema. Este modelo
lo suelen crear las partes interesadas de la empresa y los arquitectos de datos. El
propósito es organizar, ampliar y definir conceptos y reglas comerciales.
• Diseño lógico: define CÓMO se debe implementar el sistema independientemente del

SGBD. Este modelo lo suelen crear arquitectos de datos y analistas de negocios. El
propósito es desarrollar un mapa técnico de reglas y estructuras de datos.
26
Bases de datos
• Diseño físico: este modelo de datos describe CÓMO se implementará el sistema

utilizando un sistema SGBD específico. Este modelo lo suelen crear DBA y
desarrolladores. El propósito es la implementación real de la base de datos.
Figura 6. Metodología de diseño de bases de datos.
2.4 DISEÑO CONCEPTUAL
La fase inicial del diseño de la base de datos es caracterizar completamente las necesidades de datos
de los posibles usuarios de la base de datos. El diseñador de la base de datos necesita interactuar
ampliamente con los expertos y los usuarios del dominio para llevar a cabo la tarea. El resultado de
esta fase es una especificación de los requisitos del usuario. En la siguiente fase, el diseñador elige
un modelo de datos y, aplicando los conceptos del modelo de datos elegido, traduce estos requisitos
en un esquema conceptual de la base de datos. El esquema desarrollado en esta fase de diseño
conceptual proporciona una descripción detallada de la empresa. El modelo ER se utiliza
normalmente para representar el diseño conceptual.
27
Bases de datos
El esquema conceptual especifica las entidades que están representadas en la base de datos,
los atributos de las entidades, las relaciones entre las entidades y las restricciones sobre las
entidades. La fase de diseño conceptual da como resultado la creación de un diagrama entidad-
relación que proporciona una representación gráfica del esquema. El diseñador revisa el esquema
para confirmar que todos los requisitos de datos están efectivamente satisfechos y no están en
conflicto entre sí.
Un esquema conceptual completamente desarrollado indica los requisitos funcionales de la

empresa. En una especificación de requisitos funcionales, los usuarios describen los tipos de
operaciones o transacciones que se realizarán en los datos. Ejemplos: modificar y actualizar los
datos buscando y recuperando datos específicos. En esta etapa del diseño conceptual, el diseñador
puede revisar el esquema para asegurarse de que cumpla con los requisitos funcionales.
Las tareas para realizar en el esquema conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama ER.
8. Revisar el esquema conceptual local con el usuario.
2.4.1 Esquema conceptual: de alto nivel, detallado
El esquema conceptual de alto nivel es una descripción general simplificada y detallada del
proceso de diseño de la base de datos. El primer paso que se realiza es la recopilación y el análisis
de requisitos (Museros & Sanz, 2010). Durante este paso, los diseñadores de la base de datos
entrevistan a los posibles usuarios de la base de datos para comprender y documentar sus
requisitos de datos. El resultado de este paso es un conjunto de requisitos de los usuarios escrito de
forma concisa. Estos requisitos deben especificarse de la forma más detallada y completa posible.
28
Bases de datos
Paralelamente a la especificación de los requisitos de datos, es útil especificar los requisitos

funcionales conocidos de la aplicación. Estos consisten en las operaciones (o transacciones)
definidas por el usuario que se aplicarán a la base de datos, incluidas tanto las recuperaciones como
las actualizaciones. En el diseño de software, es común utilizar diagramas de flujo de datos,
diagramas de secuencia, escenarios y otras técnicas para especificar requisitos funcionales. No
discutiremos ninguna de estas técnicas aquí ya que generalmente se describen en detalle en
ingeniería de software.
Una vez recopilados y analizados los requisitos, el siguiente paso es crear un esquema
conceptual para la base de datos, utilizando un modelo de datos conceptual de alto nivel. Este paso
se llama diseño conceptual. El esquema conceptual es una descripción concisa de los requisitos de
datos de los usuarios e incluye descripciones detalladas de los tipos de entidad, relaciones y
restricciones; estos se expresan utilizando los conceptos proporcionados por el modelo de datos de
alto nivel. Debido a que estos conceptos no incluyen detalles de implementación, generalmente son
más fáciles de entender y pueden usarse para comunicarse con usuarios no técnicos. El esquema
conceptual de alto nivel también se puede utilizar como referencia para garantizar que se cumplan
todos los requisitos de datos de los usuarios y que los requisitos no entren en conflicto. Este enfoque
permite a los diseñadores de bases de datos concentrarse en especificar las propiedades de los
datos, sin preocuparse por los detalles de almacenamiento e implementación. Esto facilita la
creación de un buen diseño de base de datos conceptual. El objetivo de esta etapa es elaborar un
modelo conceptual del problema. Este modelo se representa mediante algún modelo de datos de
alto nivel. Uno de los modelos más conocidos es el modelo entidad-relación (ER).
Durante o después del diseño del esquema conceptual, las operaciones básicas del modelo
de datos se pueden utilizar para especificar las consultas y operaciones de los usuarios de alto nivel
identificadas durante el análisis funcional. Esto también sirve para confirmar que el esquema
conceptual cumple con todos los requisitos funcionales identificados. Se pueden introducir
modificaciones al esquema conceptual si algunos requisitos funcionales no se pueden especificar
utilizando el esquema inicial.
Un esquema de datos conceptual identifica las relaciones de más alto nivel entre las
diferentes entidades. Las características del esquema de datos conceptuales son:
• Incluye las entidades importantes y las relaciones entre ellas.
29
Bases de datos
• No se especifica ningún atributo.
• No se especifica ninguna clave principal.
Figura 32. Modelo de esquema conceptual.
En la Figura 32, podemos ver que la única información que se muestra a través del modelo
de datos conceptual son las entidades que describen los datos y las relaciones entre esas
entidades. No se muestra ninguna otra información a través del modelo de datos conceptual.
2.4.2 Modelo entidad-relación
El modelo entidad relación es el modelo conceptual más utilizado para el diseño conceptual
de base de datos y permite representar de manera simplificada los componentes que participan en
un proceso de negocio y el modo en el que estos se relacionan entre sí.
El modelo entidad relación tiene tres elementos principales:
30
Bases de datos
1. Entidades: El modelo contará con una entidad por cada uno de los componentes del proceso
de negocio. Así, en un negocio de venta de suscripciones a revistas, podemos tener
entidades “Cliente”, “Dirección”, “Factura”, “Producto”, o “Incidencias”, entre otras.
2. Atributos: Los atributos, componente fundamental de cada modelo entidad-relación, nos
permiten describir las propiedades que tiene cada entidad. “Nombre”, “Primer Apellido”,
“Segundo Apellido”,” Fecha de nacimiento”, “Género” o “Segmento de valor” serán
atributos de la entidad “Cliente”.
3. Relaciones: Con las relaciones se establecen vínculos entre parejas de entidades. Cada
“Cliente” tendrá una “Dirección” de envío en la que recibirá la suscripción, podrá estar
suscrito a uno o varios “Productos”, y recibirá una “Factura” con la periodicidad acordada.
El diagrama entidad relación (DER) es la expresión gráfica del modelo entidad-relación. En él las
entidades se representan utilizando rectángulos, los atributos por medio de círculos o elipses y las
relaciones como líneas que conectan las entidades que tienen algún tipo de vínculo, en algunos
cases se denotan con un rombo. También es muy común el formato de diagrama en el que los
atributos de una entidad aparecen listados en filas dentro del rectángulo que representa a esa
entidad.
¿Por qué utilizar diagramas ER?
Las principales razones para utilizar el diagrama ER son:
 Ayuda a definir términos relacionados con el modelado de relaciones entre entidades

 Proporciona una vista previa de cómo deben conectarse todas sus tablas y qué campos
estarán en cada tabla
 Ayuda a describir entidades, atributos, relaciones.
 Se pueden traducir a tablas relacionales, lo que le permite crear bases de datos rápidamente
 Las personas encargadas de diseñar bases de datos pueden utilizar los diagramas ER como
un modelo para implementar datos en aplicaciones de software específicas.
 Permite comunicarse con la estructura lógica de la base de datos a los usuarios.
Símbolos y notaciones de diagramas ER
Como se mencionó anteriormente, para diagramar ER se usan tres símbolos básicos que son el
rectángulo, óvalo y rombo para representar relaciones entre elementos, entidades y atributos. Hay
31
Bases de datos
algunos sub-elementos que se basan en los elementos principales del diagrama ER. A continuación,
se muestran los componentes principales y sus símbolos en los diagramas ER:
• Rectángulo: Representa tipos de entidades como cosas, objetos, conceptos del mundo real
que pueden ser concretos o abstractos. Se puede asociar a las entidades con sustantivos, Por
ejemplo, una persona, casa o un carro son entidades concretas, mientras que una asignatura
o un trabajo son entidades abstractas. Una relación también se conoce como tabla. Dentro
de una tabla, cada fila representa un grupo de valores de datos relacionados. Una fila o
registro también se conoce como tupla. Las columnas de una tabla son un campo y también
se las denomina atributo. Los nombres de las tablas deben ser únicos en la base de datos.
• Elipse: Representa los atributos de una entidad. Es decir, son las características que
identifican o definen una entidad. Por ejemplo, la entidad persona tiene atributos como
cédula, nombres, apellidos, sexo, edad. Los nombres de los atributos tienen que ser únicos
dentro de cada entidad.
• Rombo: Representa tipos de relaciones entre las entidades. Es decir, cómo las entidades
interactúan o se asocian entre sí. Piensen en las relaciones como si fueran verbos. Por
ejemplo, el estudiante mencionado podría inscribirse en un curso. Las dos entidades serían
el estudiante y el curso, y la relación representada es el acto de inscribirse, que conecta
ambas entidades de ese modo.
• Líneas: Vincula atributos a tipos de entidad y tipos de entidad con otros tipos de relación.
32
Bases de datos
Figura 10. Ejemplo de un diagrama ER.
En la Figura 10 existen dos entidades: USUARIO y EJEMPLAR. La relación es PRESTA y los

atributos de la entidad USUARIO son: CódigoUsuario y nombre, por dar un ejemplo.
Recuerde que: Una base de datos se compone de varias tablas y cada tabla contiene los
datos. En cada tabla, el orden o la secuencia de columnas o filas es insignificante.
2.4.3 Entidad: fuerte, débil; supertipo, subtipo
Como se abordó en la subsección anterior, una entidad puede ser un lugar, una persona, un
objeto, un evento o un concepto, que almacena datos en la base de datos. Las características de las
entidades es que deben tener un atributo y una clave única. Cada entidad está formada por algunos
atributos que representan esa entidad. Como ejemplos de entidades encontramos:
• Persona: Empleado, estudiante, paciente
• Lugar: Tienda, edificio
• Objeto: Máquina, producto y automóvil
• Evento: Venta, registro, renovación
33
Bases de datos
• Concepto: Cuenta, curso
Tipos de entidades
Las entidades pueden existir por sí mismas o solo pueden existir cuando están asociadas con
algún otro tipo de entidad. Podemos diferenciar dos tipos de entidades en base a su asociación:
• Entidad fuerte: Es un tipo de entidad que si tiene un atributo considerado como clave primaria.
• Entidad débil: Es un tipo de entidad que no tiene un atributo como clave primaria, es decir,
necesita de una entidad fuerte para existir. Por este motivo Puede identificarse de forma
única considerando la clave principal de otra entidad. Para eso, los conjuntos de entidades
débiles deben tener participación. Los registros que pertenecen a una entidad débil son
identificados por estar relacionados con registros específicos de una entidad fuerte.
Figura 11. Símbolos y significados de entidades y relaciones.
Por ejemplo, en un video-club que renta videos, las copias tienen que estar asociadas a una
película. Por lo tanto, la entidad COPIA es débil y depende de la entidad PELÍCULA. El diagrama
ER quedaría así:
34
Bases de datos
Figura 12. Diagrama ER de un video-club4
De igual forma, si queremos diagramar el modelo ER de los movimientos bancarios de los

movimientos de una cuenta bancaria y las transacciones realizadas, quedaría de la siguiente forma:
Figura 13. Diagrama ER de movimientos bancarios5
Nótese que la clave primaria de la Figura 13 está asociada con la entidad fuerte que es
CUENTA. Recordar que la entidad TRANSACCIÓN puede identificarse con un número de
transacción, pero no tiene sentido sin estar asociada con una cuenta bancaria.
Tabla 1
Diferencias entre entidades fuertes y débiles
Entidad fuerte Entidad débil
Siempre tiene una clave primaria. No tiene suficientes atributos para construir
una clave primaria.
4
http://dryvalleycomputer.com/index.php/bases-de-datos/el-modelo-entidadrelacion/56-entidades-fuertes-ydebiles
5
https://virtual.itca.edu.sv/Mediadores/dbd/u1/entidades_dbiles.html
35
Bases de datos
Está representado por un símbolo de Está representado por un símbolo de doble

rectángulo. rectángulo.
Contiene una clave principal representada Contiene una clave parcial que puede
por el símbolo de subrayado. representarse por un símbolo de subrayado
discontinuo.
La relación entre dos conjuntos de entidades La relación entre un conjunto de entidades

fuertes se muestra mediante el uso de un fuerte y débil se muestra mediante el
símbolo de rombo. símbolo de doble rombo.
A menudo, algunas instancias de una entidad tienen atributos y / o relaciones que otras
instancias no tienen. Imaginen una empresa que necesita realizar un seguimiento de los pagos de
los clientes. Los clientes pueden pagar en efectivo, con cheque o con tarjeta de crédito. Todos los
pagos tienen algunos atributos comunes: fecha de pago, monto del pago, etc. Pero solo las tarjetas
de crédito tendrían un atributo de "número de tarjeta". Y para pagos con tarjeta de crédito y
cheques, es posible que necesitemos saber qué CLIENTE realizó el pago, aunque esto no es
necesario para pagos en efectivo. ¿Deberíamos crear una sola entidad de PAGO o tres entidades
separadas EFECTIVO, CHEQUE y TARJETA DE CRÉDITO? ¿Y qué pasa si en el futuro
introducimos un cuarto método de pago?
A veces, tiene sentido subdividir una entidad en diferentes tipos. Este puede ser el caso
cuando un grupo de instancias tiene propiedades especiales, como atributos o relaciones que
existen solo para ese grupo o, por otro lado, atributos que pueden ser compartidos entre entidades.
Dependiendo de si comparte o no atributos, las entidades pueden estar clasificadas en supertipo y
subtipo, donde la entidad supertipo puede ser considerada la entidad padre y la entidad subtipo
como entidad hijo:
• Supertipo: Es un tipo de entidad que tiene relación con uno o más subtipos y contiene
atributos que son comunes a los subtipos.
• Subtipo: Son subgrupos dentro de las entidades supertipo que tienen atributos únicos, pero
que serán distintos para cada subtipo. Posee las siguientes características:
36
Bases de datos
o Hereda todos los atributos del supertipo

o Hereda todas las relaciones del supertipo
o Por lo general, tiene sus propios atributos o relaciones.
o Se dibuja dentro del supertipo
o Nunca existe solo
o Puede tener subtipos propios
Las claves primarias de las entidades supertipo y subtipo son siempre idénticas. Por
ejemplo, en el diagrama de la figura 14 se muestra una representación al diseñar la base de datos
para PERSONAS, se puede definir a una entidad supertipo llamada PERSONA y sus entidades
subtipo pueden ser ESTUDIANTE y PROFESOR. La entidad PERSONA puede tener atributos
como cédula, nombres, etc. que son comunes a las entidades subtipo descritas anteriormente. Y a las
tres entidades subtipo, se pueden agregar atributos específicos a cada una de ellas.
Otro ejemplo, se podría citar en una entidad SEGURO es supertipo y entidades como
SEGURO DE SALUD, SEGURO CONTRA ACCIDENTES o SEGURO DE MUERTE se
consideran subtipo.
Así mismo el ejemplo sobre la entidad TARJETA DE CRÉDITO es supertipo, mientras que
TARJETA DE TRANSFERENCIA, CRÉDITO DE REEMBOLSO EN EFECTIVO o TARJETA DE
CREDITO ESTUDIANTIL son consideradas entidades subtipo.
Figura 14. Visualización de entidades supertipo y subtipo.
37
Bases de datos
2.4.4 Atributos: simples, compuestos; monovalentes, multivalentes; derivados
Es una propiedad de valor único de un tipo de entidad o de un tipo de relación. Por ejemplo,
una conferencia puede tener atributos: hora, fecha, duración, lugar, etc. Un atributo en el diagrama
ER está representado por un óvalo.
Tabla 2. Tipos de atributos existentes en un diagrama ER
Tipo Descripción
Simple Los atributos simples no se pueden dividir más. Por ejemplo, el número
de teléfono de un estudiante. También se le llama valor atómico.
Compuesto Es posible descomponer el atributo compuesto. Por ejemplo, el nombre

completo de un estudiante se puede dividir en nombre, segundo nombre
y apellido.
Monovalente Una instancia de un atributo monovalente puede contener un solo valor.

Por ejemplo, la cédula de un estudiante.
Multivalente Pueden tener más de un valor. Por ejemplo, un estudiante puede tener
más de un número de teléfono o dirección de correo electrónico.
Derivado Este tipo de atributo no se incluye en la base de datos física. Sin embargo,
sus valores se derivan de otros atributos presentes en la base de datos.
Por ejemplo, la edad no debe almacenarse directamente, sino que se
deriva de la fecha de nacimiento. Igual con el salario promedio que se
deduce del promedio de todos los salarios.
2.4.5 Identificadores: internos, externos, mixtos; simples y compuestos
La razón para tener una base de datos es almacenar valores de datos sobre entidades y luego
recuperar los valores de datos sobre esas entidades según sea necesario. Para lograr esto, debe haber
alguna forma de distinguir una entidad de otra. Los identificadores de entidad realizan esta función.
Los identificadores de entidad son atributos, específicamente, atributos clave que identifican de
forma única a cada entidad.
El nombre de un objeto de base de datos se conoce como su identificador. Cualquier

elemento de dentro de una base de datos puede tener un identificador. Servidores, bases de datos y
38
Bases de datos
objetos de bases de datos, como tablas, vistas, columnas, índices, desencadenadores,

procedimientos, restricciones, reglas, etc. pueden tener identificadores. Se requiere que la mayor
parte de los objetos tengan identificadores. Pero para ciertos objetos, como las restricciones, son
opcionales.
El identificador de un objeto se crea cuando se define el objeto. A continuación, el

identificador se utiliza para hacer referencia al objeto. Por ejemplo, en la Figura 15 se observa los
atributos de la entidad AUTOR: CódigoAutor, Nombres; siendo el primero el identificador de la
entidad.
Figura 15. Identificadores dentro de un diagrama ER.
Un identificador de entidad no es un atributo opcional; cada entidad debe tener un atributo

clave para identificarla de forma única. Los identificadores de entidad (atributos clave) se
convierten en claves primarias en una tabla.
Existen diversos tipos de identificadores:
• Identificador interno: Si el identificador está formado por uno o más atributos de la

propia entidad. En este caso hablamos de un identificador interno que se transforma
en clave primaria de una tabla. Por ejemplo, en la figura 16, se muestra un
identificador interno para la entidad AUTOMÓVIL con atributos Matrícula, Modelo,
y Color, será el atributo Matrícula, asumiendo que no pueden existir dos vehículos
39
Bases de datos
con la misma matrícula. De la misma forma, un identificador interno para la entidad

PERSONA con atributos Cédula, Nombres y Fecha de nacimiento, será Cédula el
identificador interno asumiendo nuevamente que no pueden existir personas con el
mismo número de cédula.
Figura 16. Identificadores internos dentro de entidades.
• Identificador externo: A veces, sin embargo, los atributos de una entidad no son
suficientes para identificar sus ocurrencias sin ambigüedades. Considere, por
ejemplo, la entidad ESTUDIANTE en la Figura 17. A primera vista, puede parecer
que el atributo Registro puede ser un identificador de dicha entidad, pero no es así.
El esquema, de hecho, describe a los estudiantes matriculados en varias
universidades, y dos estudiantes matriculados en diferentes universidades podrían
tener el mismo número de registro. En este caso, para identificar a un estudiante de
forma inequívoca, necesitamos la universidad correspondiente, así como el número
de matrícula. Así, un identificador correcto para la entidad ESTUDIANTE en este
esquema se compone del atributo Registro y de la entidad UNIVERSIDAD. A esto se
le llama un identificador externo. Cabe señalar que esta identificación es posible
gracias a la relación obligatoria uno a muchos (1:M) entre las entidades
UNIVERSIDAD y ESTUDIANTE, que asocia a cada estudiante con una sola
universidad. Así, una entidad E puede ser identificada por otras entidades solo si
40
Bases de datos
cada una de estas entidades está involucrada en una relación en la que E participa
con cardinalidad (1,1).
Figura 17. Identificadores externos dentro de entidades.
En base a lo que hemos dicho sobre el tema de los identificadores, podemos hacer algunas
observaciones generales:
• Un identificador puede involucrar uno o más atributos, siempre que cada uno de
ellos tiene una cardinalidad (1:1).
• Un identificador externo puede involucrar a una o más entidades, siempre que cada
una de ellas sea miembro de una relación en la que participa la entidad a identificar
con cardinalidad igual (1:1).
• Un identificador externo puede involucrar a una entidad que a su vez está

identificada externamente, siempre que no se generen ciclos.
• Cada entidad debe tener un identificador (interno o externo), pero puede tener más
de uno. En realidad, si hay más de un identificador, el indicador se denomina mixto.
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los
identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos.
De cada entidad se escoger uno de los identificadores como clave primaria en la fase del diseño
lógico.
• Identificador simple: Cuando una clave principal está relacionada con una sola
columna, solo se puede asignar un atributo en el identificador principal.
41
Bases de datos
• Identificador compuesto: Cuando la clave primaria está relacionada con más de una
columna
Cada entidad puede tener múltiples identificadores alternativos como se muestra en la

Figura 18. Todos los identificadores de las entidades se deben anotar en el diccionario de datos.
Figura 18. Tipos de identificadores dentro de una base de datos.
2.4.6 Relaciones
Las relaciones hacen referencia a la correspondencia o asociación entre dos o más entidades
y se se representan gráficamente mediante rombos y su nombre aparece en el interior
El grado de una relación es el número de tipos de entidades que participan o se asocian en

una relación. Al ver un diagrama ER, simplemente podemos decir el grado de una relación, es decir,
el número de un tipo de entidad que está conectado a una relación es el grado de esa relación.
Según el número de tipos de entidad que están conectados, tenemos el siguiente grado de
relaciones: unaria, binaria, ternaria y n-aria
42
Bases de datos
• Unaria: Existe una relación unaria cuando ambos tipos de entidad participante son
iguales. Cuando existe tal relación, decimos que el grado de relación es 1. Por ejemplo,
supongamos que en un aula tenemos muchos estudiantes que pertenecen a un club de
baile y de baloncesto y algunos de ellos son líderes de club. Entonces, un grupo
particular de estudiantes es administrado por su respectivo líder de club. Aquí, el grupo
está formado por estudiantes y también, los líderes del club se eligen entre los
estudiantes. Entonces, la entidad ESTUDIANTE es la única entidad que participa aquí.
Podemos representar esta relación usando el diagrama ER en la figura 19.
Figura 19. Relación unaria.
• Binaria: Existe una relación binaria cuando participan exactamente dos tipos de
entidad. Cuando existe tal relación, decimos que el grado es 2. Este es el grado de
relación más común. Es fácil lidiar con esta relación, ya que se pueden convertir
fácilmente en tablas relacionales. Por ejemplo, en la figura 20, se muestran dos tipos de
entidades: CLIENTE y CUENTA, donde cada cliente tiene una cuenta que almacena los
detalles de la cuenta del cliente. Dado que tenemos dos tipos de entidades que
participan, lo llamamos una relación binaria. Además, un CLIENTE puede tener
muchas CUENTAS, pero cada CUENTA debe pertenecer a un solo CLIENTE. Podemos
decir que es una relación binaria de uno a muchos.
43
Bases de datos
Figura 20. Relación binaria.
• Ternaria: Existe una relación ternaria cuando participan exactamente tres tipos de
entidad. Cuando existe tal relación, decimos que el grado es 3. A medida que aumenta
el número de entidades en la relación, se vuelve complejo convertirlas en tablas
relacionales. Por ejemplo, en la figura 21, se muestran tres tipos de entidad
EMPLEADO, DEPARTAMENTO y UBICACIÓN. La relación entre estas entidades se
define como un empleado trabaja en un departamento, un empleado trabaja en una
ubicación particular. Entonces, podemos ver que tenemos tres entidades participando
en una relación, por lo que es una relación ternaria.
Figura 21. Relación ternaria.
• N-aria: Existe una relación N-aria cuando participan "n" entidades. Entonces, cualquier
número de entidades puede participar en una relación. No hay limitación al número
máximo de entidades que pueden participar. Pero las relaciones con un grado superior
no son comunes. Esto se debe a que la conversión de relaciones de grado superior en
tablas relacionales se vuelve compleja. Estamos haciendo un modelo ER porque se
puede convertir fácilmente en cualquier otro modelo para implementar la base de
44
Bases de datos
datos. Pero este beneficio no está disponible si usamos relaciones de mayor grado. Por
tanto, las relaciones binarias son más populares y utilizadas. Esta representación se
ilustra en la figura 22, en donde E1 denota el primer tipo de entidad, E2 denota el
segundo tipo de entidad y así sucesivamente. R representa la relación. Entonces, aquí
tenemos un total de 5 tipos de entidades que participan en la relación. Por lo tanto, el
grado de la relación n-aria anterior es 5
Figura 22. Relación ternaria.

Cardinalidad de correspondencia de clases
La cardinalidad se especifica para cada entidad que participa en una relación y describe el
número máximo y mínimo de ocurrencias de relación en las que una ocurrencia de entidad puede
participar. Por lo tanto, establece cuántas veces en una relación entre entidades una ocurrencia de
una de estas entidades puede estar vinculada a ocurrencias de las otras entidades involucradas.
Por ejemplo, en la figura 23 se muestra una relación ASIGNAR entre las entidades
EMPLEADO y TAREA; especificamos para la primera entidad una cardinalidad mínima igual a
uno y una cardinalidad máxima igual a cinco (1,5). Esto significa que deseamos indicar que un
empleado puede participar en un mínimo de una y un máximo de cinco ocurrencias de la relación
de ASIGNAR. En otras palabras, deseamos decir que, en nuestra aplicación, se debe asignar al
menos una tarea a un empleado, pero no más de cinco. Por otro lado, suponga que para la entidad
TAREA especificamos una cardinalidad mínima igual a cero y una cardinalidad máxima igual a 50
(0, 50). En este caso, solo imponemos la restricción de que una tarea puede aparecer en un máximo
de 50 ocurrencias de la relación ASIGNAR. Así, una determinada tarea podría no ser asignada a
ningún empleado o podría asignarse a 50 o menos empleados. En un esquema ER, las
cardinalidades mínima y máxima de la participación de las entidades en las relaciones se
especifican entre paréntesis.
45
Bases de datos
Figura 23. Cardinalidad de una relación.
En principio, es posible asignar cualquier entero no negativo a la cardinalidad de una

relación con la única restricción de que el mínimo la cardinalidad debe ser menor o igual que la
cardinalidad máxima. En la mayoría de los casos, sin embargo, es suficiente usar solo tres valores:
cero, uno y el símbolo "M" o “N” (que se llama "muchos" e indica genéricamente un número entero
mayor que uno):
• Asociación de (1:1): Cuando decimos que hay una relación 1:1 entre dos entidades,
significa que por cada ocurrencia de una entidad hay exactamente una ocurrencia de
una entidad relacionada. Las relaciones (1:1) no son muy frecuentes en los modelos de
datos. A menudo, este tipo de relación se puede capturar suficientemente dentro de una
sola entidad. Dividimos estos valores en tablas separadas con una relación de (1:1)
cuando se obtiene una ventaja de rendimiento utilizando la tabla separada. Por ejemplo,
en la figura 24 se muestra que la entidad PAÍS con la entidad CAPITAL manejan una
relación (1:1) ya que cada país tiene exactamente una capital y viceversa. La
cardinalidad “uno” puede ser representada visualmente con una raya vertical.
46
Bases de datos
Figura 24. Relación (1:1).
• Asociación de (1:M): Cuando decimos que hay una relación 1:M entre dos entidades,
significa que por cada ocurrencia de una entidad hay dos o muchas ocurrencias de una
entidad relacionada. Es una de las relaciones más comunes en las bases de datos. Por
ejemplo, en la figura 25 se muestra que cada ciudad está en exactamente un país, pero la
mayoría de los países tienen muchas ciudades. La cardinalidad “muchos” se lo
representa visualmente con el siguiente símbolo
Figura 25. Relación (1:M).
• Asociación (M:N): Cuando decimos que hay una relación M:N entre dos entidades
relacionadas, significa que para cada ocurrencia de cualquiera de las entidades, hay dos
o muchas ocurrencias de la otra entidad. Por ejemplo, en la figura 26 se muestra que un
ESTUDIANTE puede inscribirse en muchas MATERIAS y una MATERIA puede tener
muchos ESTUDIANTES matriculados.
47
Bases de datos
Figura 26. Relación (M:N).
Para fortalecer las bases de datos, es necesario establecer la clase de membresía que se refiere
a la condición de participación, la cual puede ser de tipo obligatoria u opcional:
• Participación obligatoria: En la participación obligatoria, para cada instancia de la

entidad A, debe existir una instancia de la entidad B y viceversa. Un ejemplo de
participación obligatoria sería la relación entre madre e hijo (figura 27). La entidad del
HIJO existiría sólo si hubiera una MADRE y, de manera similar, una MADRE existiría
solo si hubiera un HIJO. Se lo puede representar visualmente con un círculo relleno.
Figura 27. Participación obligatoria.
48
Bases de datos
• Participación opcional: En participación opcional, no es necesario que todas las

instancias de la entidad participen en una relación. Puede ser que el número de
instancias que participan para una entidad en particular sea incluso cero. La
participación opcional es buena para representar relaciones que no son obligatorias o
pueden ser temporales, es decir, relaciones que pueden cambiar durante un período de
tiempo. La relación podría ser obligatoria para la primera entidad y opcional para la
segunda, o al revés. O puede ser opcional para ambas. Por ejemplo, en la figura 28 se
muestra que un ARTISTA debe estar representado por un AGENTE, pero un agente no
tiene que representar a un artista. Por lo tanto, la relación es obligatoria para un artista
intérprete o ejecutante, pero opcional para un agente.
Figura 28. Participación opcional en la entidad AGENTE.

Relaciones redundantes
A veces, en los modelos ER va a existir una relación redundante. Son relaciones que ya están
indicadas por otras relaciones, aunque no directamente. Por ejemplo, En la Figura 33, si todos los
empleados pertenecen a un servicio y todos los servicios a un departamento, la asociación directa
de DEPARTAMENTO y EMPLEADO es redundante y por tanto habría que eliminarla. Sin
embargo, si se da la especificación o requisito de usuario de que un empleado puede trabajar en un
departamento sin pertenecer a ningún servicio, esta asociación no será redundante.
49
Bases de datos
Figura 33. Ejemplo de relaciones que pueden ser o no redundantes.
Hay que entender que las relaciones redundantes se replican en un sinnúmero de

oportunidades de forma consecutiva. Si se desea eliminar una tabla o dato que se encuentren bajo
una relación con este tipo de comportamientos no se corre el peligro de perder el vínculo que ha
sido establecido en la tabla.
2.4.7 Jerarquía de generalización
Las jerarquías de generalización presentan la propiedad de cobertura. La cobertura puede

ser parcial o total y exclusiva o superpuesta.
De forma general, podemos decir que la cobertura parcial o total permite especificar una
restricción entre el tipo de entidad genérica y sus tipos de entidad subconjunto, donde todos los
elementos del tipo de entidad genérica deben pertenecer a alguno de sus tipos de entidad
subconjunto (si es total), o no (si es parcial). La cobertura exclusiva o superpuesta permite
especificar una restricción entre los tipos de entidad subconjunto, donde los elementos que
pertenecen a un tipo de entidad subconjunto pueden pertenecer también a otro tipo de entidad
subconjunto (si es superpuesto) o no (si es exclusiva).
50
Bases de datos
• Parcial: Especifica que cada entidad del conjunto de entidades puede participar o no en
la instancia de relación de ese conjunto de relaciones. Por eso, también se denomina
participación opcional. La participación parcial se representa mediante una única línea
entre el conjunto de entidades y el conjunto de relaciones. Por ejemplo, la gráfica 29 se
muestra una línea entre la entidad CURSO y la relación "enrolar", el cual significa
participación parcial. Especifica que pueden existir algunos cursos para los que no se
realizan enrolamientos o matriculaciones.
Figura 29. Participación parcial en la entidad CURSO.
• Total: Especifica que cada entidad en el conjunto de entidades debe participar

obligatoriamente en al menos una instancia de relación en ese conjunto de relaciones.
Por eso, también se denomina participación obligatoria. La participación total se
representa mediante una línea doble entre el conjunto de entidades y el conjunto de
relaciones. Por ejemplo (figura 30), la línea doble entre la entidad ESTUDIANTE y la
relación "enrolar" significa participación total. Especifica que cada alumno debe estar
enrolado o matriculado en al menos un curso.
Figura 30. Participación total en la entidad ESTUDIANTE.
51
Bases de datos
• Exclusiva: Los elementos que pertenecen a una entidad no pueden pertenecer a otra
entidad. Por ejemplo, el sexo de una persona es mujer u hombre.
• Superpuesta: Los elementos que pertenecen a una entidad pueden pertenecer también
a otra entidad. Por ejemplo, un empleado de una universidad puede ser al mismo
tiempo administrativo y dar clases.
En la Figura 31 se evidencian algunos ejemplos prácticos de como se pueden combinar la

cobertura de clases, donde t significa total, p parcial, e exclusiva y s superpuesta.
Figura 31. Combinación de la cobertura de clases.
2.5 DISEÑO LÓGICO DE DATOS
Un esquema lógico de una base de datos, es una descripción de la estructura de la base de

datos que puede procesar un SGBD. El propósito del esquema de datos lógicos es comprender la
información recibida, almacenada y transmitida por un sistema. En el contexto de esta
especificación de captura del sistema, es para comprender y caracterizar los datos y los flujos que
52
Bases de datos
cruzan los límites del sistema para solidificar conceptualmente las interfaces que un sistema
proporciona o requiere.
Un esquema de datos lógicos se basa en la mayoría de los casos en un esquema de datos

conceptual que, con el uso de ciertas pautas y reglas, se transforma en un esquema relacional
(modelo). Un esquema de datos lógicos describe los datos con el mayor detalle posible, sin importar
cómo se implementarán físicamente en la base de datos.
Las características de un esquema de datos lógicos son:
 Incluye todas las entidades y relaciones entre ellas

 Se especifican todos los atributos de cada entidad
 Se especifica la clave principal para cada entidad
 Se especifican claves externas (claves que identifican la relación entre diferentes entidades).
 La normalización ocurre en este nivel.
Los pasos para diseñar el esquema de datos lógicos son los siguientes:
1. Especificar claves primarias para todas las entidades

2. Encontrar las relaciones entre diferentes entidades
3. Encontrar todos los atributos de cada entidad
4. Resolver las relaciones M:N
5. Normalización
53
Bases de datos
Figura 35. Modelo de esquema lógico.
En la Figura 35 se muestra el modelo de esquema lógico implementado en donde se

muestran los atributos de cada entidad, además de sus identificadores internos y externos, en
donde, CP significa clave primaria y CF clave foránea.
Las principales diferencias del esquema de datos conceptual y lógico son:
 En un modelo de datos lógicos, las claves primarias están claramente presente, mientras que
en un modelo de datos conceptual no se incluyen claves primerias.
 En un modelo de datos lógicos, se deben incluir todos los atributos específicos dentro de una
entidad, mientras que en un modelo de datos conceptual no.
 Las relaciones entre entidades se especifican mediante claves primarias y claves foráneas en
un modelo de datos lógicos. En un modelo de datos conceptual, las relaciones simplemente
se establecen, no se especifican, por lo que simplemente sabemos que dos entidades están
relacionadas, pero no especificamos qué atributos se utilizan para esta relación.
2.5.1 Metodología de diseño lógico en el modelo relacional
El objetivo del diseño lógico es construir un esquema relacional que representa correcta y
eficientemente toda la información descrita por un esquema ER producido durante la fase de diseño
54
Bases de datos
conceptual. Este proceso no es solo una simple transformación de un modelo a otro por dos razones
principales:
 No todos los constructos del modelo ER pueden ser transformado naturalmente al modelo
relacional
 El esquema debe reestructurarse de tal manera que la ejecución de las operaciones
proyectadas de la manera más eficiente posible.
Las reglas básicas para convertir un esquema conceptual a un esquema lógico relacional son
las siguientes:
1. Eliminación de atributos múltiples: Todos los atributos múltiples se deben transformar

en un tipo de entidad débil por existencia con una relación de M:N o de 1:M, según sea
el caso, con el tipo de entidad sobre el cual estaba definido. Si se considera que la nueva
entidad creada resulta ambigua, se le pueden añadir atributos o heredarlos de la otra
entidad. En el caso del ejemplo de la figura 36, en donde una persona puede tener
varios números de teléfono:
Figura 36. Ejemplo de atributos múltiples.
En este caso ser a necesario expresar el esquema relacional de la forma:
PERSONA ( idPersona, ... lista de atributos ...)

TELEFONO(idPersona*, numero, tipo)
2. Eliminación de atributos compuestos: Todos los atributos compuestos deben ser

descompuestos en atributos simples que quedan asociados a la misma entidad. Por
55
Bases de datos
ejemplo, la gráfica de la figura 37, al aplicar la transformación, se expresaría mediante el

siguiente esquema relacional: PERSONA (DNI, nombre, apellido1, apellido2, peso)
Figura 37. Ejemplo de atributos compuestos.
3. Transformación de entidades fuertes: En principio las entidades fuertes del modelo ER

son transformadas siguiendo estas instrucciones:
a) Las entidades pasan a ser tablas.

b) Los atributos pasan a ser columnas.
c) Los identificadores principales pasan a ser claves primarias.
d) Los identificadores candidatos pasan a ser claves candidatas.
Esto hace que la transformación se produzca según este ejemplo:
Figura 38. Ejemplo de transformaciones de entidades fuertes.
56
Bases de datos
4. Transformación de relaciones: En el caso de las relaciones, la idea inicial es transformar

cada relación en una tabla, pero hay que distinguir según el tipo de relación.
 Relación varios a varios: La relación se transforma en una tabla cuyos atributos son: los
atributos de la relación y las claves de las entidades relacionadas, que pasarán a ser
claves externas. La clave de la tabla la forman todas las claves externas (figura 39).
Figura 39. Ejemplo de transformación de relación varios a varios.
 Relación uno a varios o uno a uno: La relación de tipo uno a varios no requiere ser
transformadas en una tabla en el modelo relacional. En su lugar la tabla del lado varios
(tabla relacionada) incluye como clave externa el identificador de la entidad del lado
uno (tabla principal). En el caso de que el número mínimo de la relación sea de cero
(puede haber ejemplares de la entidad uno sin relacionar), se deberá permitir valores
nulos en la clave externa identificador2. En otro caso no se podrán permitir, ya que
siempre habrá un valor relacionado (figura 40).
57
Bases de datos
Figura 40. Ejemplo de transformación de relación uno a varios o uno a uno.
En el caso de las relaciones uno a uno, ocurre lo mismo: la relación no se convierte en

tabla, sino que se coloca en una de las tablas (en principio daría igual cuál) el
identificador de la entidad relacionada como clave externa. En el caso de que una
entidad participe opcionalmente en la relación, entonces es el identificador de esta el
que se colocará como clave externa en la tabla que representa a la otra entidad.
 En el caso de las relaciones reflexivas o recursivas se tratan de la misma forma que las
otras, sólo que un mismo atributo puede figurar dos veces en una tabla como resultado
de la transformación.
Figura 41. Ejemplo de transformación de relación reflexiva o recursiva.
5. Transformación de entidades débiles: Toda entidad débil incorpora una relación

implícita con una entidad fuerte. Esta relación no necesita incorporarse como tabla en el
modelo relacional. Si se necesita incorporar la clave de la entidad fuerte como clave
externa en la entidad débil. Es más, normalmente esa clave externa forma parte de la
clave principal de la tabla que representa a la entidad débil. En ocasiones el
identificador de la entidad débil es suficiente para identificar los ejemplares de dicha
entidad, entonces ese identificador quedaría como clave principal, pero el identificador
de la entidad fuerte seguiría figurando como clave externa en la entidad débil.
58
Bases de datos
Figura 42. Ejemplo de transformación de entidades débiles.
2.5.2 Reglas de Codd
E.F Codd fue un informático que inventó el modelo relacional para la gestión de bases de
datos. Codd propuso 13 reglas conocidas popularmente como las 12 reglas de Codd para probar el
concepto de SGBD contra su modelo relacional (las reglas empiezan por la Regla cero). La regla de
Codd actualmente define qué calidad requiere un SGBD para convertirse en un SGBDR. Hasta
ahora, casi no hay ningún producto comercial que siga las 13 reglas de Codd. Incluso Oracle tiene
ocho y medio (8.5) de trece. Las reglas de Codd son las siguientes:
1. Regla cero: Regla de fundación: Esta regla establece que para que un sistema califique
como SGBDR, debe poder administrar la base de datos por completo a través de las
capacidades relacionales.
2. Regla 1: Regla de información: Toda la información (incluidos los metadatos) debe

representarse como datos almacenados en celdas de tablas. Las filas y columnas deben estar
estrictamente desordenadas.
3. Regla 2: Regla de acceso garantizado: Cada dato único (valor atómico) debe ser accesible
por: Nombre de la tabla + Clave principal (Fila) + Atributo (columna). NOTA: La
posibilidad de acceder directamente a través de POINTER es una violación de esta regla.
4. Regla 3: Regla de tratamiento sistemático de NULL: NULL tiene varios significados,

puede significar datos faltantes, no aplicable o sin valor. Debe manejarse de manera
59
Bases de datos
consistente. Además, la clave principal nunca debe ser nula. La expresión en NULL debe
dar un valor nulo.
5. Regla 4: Catálogo dinámico en línea: El diccionario de la base de datos (catálogo) es la

descripción de la estructura de la base de datos completa y debe almacenarse en línea. El
catálogo debe regirse por las mismas reglas que el resto de la base de datos. Se debe usar el
mismo lenguaje de consulta en el catálogo que se usa para consultar la base de datos.
6. Regla 5: Lenguaje potente y bien estructurado: Debe existir un lenguaje bien estructurado
para proporcionar todas las formas de acceso a los datos almacenados en la base de datos,
como por ejemplo el SQL. Si la base de datos permite el acceso a los datos sin el uso de este
lenguaje, entonces represente una violación.
7. Regla 6: Regla de actualización de vistas: Todas las vistas que son teóricamente
actualizables también deben serlo por el sistema.
8. Regla 7: Operación a nivel relacional: Debe haber operaciones para Insertar, Eliminar,
Actualizar en cada nivel de relaciones. También se deben admitir operaciones de
configuración como Unión, Intersección y borrados.
9. Regla 8: Independencia físico de datos: El almacenamiento físico de datos no debería

importarle al sistema. Si, por ejemplo, se cambia el nombre de alguna tabla de soporte de
archivos o se mueve de un disco a otro, no debería afectar la aplicación.
10. Regla 9: Independencia lógica de datos: Si hay un cambio en la estructura lógica

(estructuras de tabla) de la base de datos, la vista de los datos por parte del usuario no
debería cambiar. Digamos, si una tabla se divide en dos tablas, una nueva vista debería dar
como resultado la unión de las dos tablas. Esta regla es muy difícil de cumplir.
11. Regla 10: Independencia de la integridad: La base de datos debe hacer cumplir su propia
integridad en lugar de utilizar otros programas. Las restricciones de clave y verificación,
disparadores, etc. deben almacenarse en el diccionario de datos. Esto también hace que
SGBDR sea independiente de las interfaces existentes.
60
Bases de datos
12. Regla 11: Independencia de distribución: Una base de datos debería funcionar de forma
correcta, independientemente de su distribución en una red. Incluso si una base de datos
está distribuida geográficamente, con datos almacenados en diferentes partes, el usuario
final debe tener la impresión de que está almacenada en el mismo lugar. Esto sienta las
bases de una base de datos distribuida.
13. Regla 12: Regla de no subversión: Si se permite el acceso de bajo nivel a un sistema, no
debería poder subvertir o eludir las reglas de integridad para cambiar los datos. Esto se
puede lograr mediante algún tipo de búsqueda o cifrado.
Lectura complementaria de la asignatura:
• Gómez, Á. P., Jalca, J. J. R., García, J. G., Sánchez, O. Q., Parrales, K. M., & Merino, J. M.
(2017). Fundamentos sobre la gestión de base de datos (Vol. 23).
• Beynon-Davies, P. (2018). Sistemas de bases de datos. Reverté.
REFERENCIAS
Beynon-Davies, P. (2018). Sistemas de bases de datos. Reverté.
Boggiano-Castillo, M. B., Pereira, A., Pérez, A., González-González, L.-M., & Pérez-Vázquez, R.
(2013). Inserción automática de reglas de negocio en bases de datos. Revista Técnica de La
Facultad de Ingeniería Universidad Del Zulia, 36(3), 253–261.
Castillo Arrojo, Y. (2018). Diseño de una base de datos aplicada al proceso de tramitación en
Planificación Física Ranchuelo. Universidad Central ‘“Marta Abreu”’de Las Villas.
Facultad de Ingeniería ….
61
Bases de datos
Cobo, Á. (2007). Diseño y programación de bases de datos. Visión Libros.
Elmasri, R., Navathe, S. B., Castillo, V. C., Pérez, G. Z., & Espiga, B. G. (2002). Fundamentos de
sistemas de bases de datos (Issue QA76. 9D3 E553 2007.). Addison-Wesley.
Museros, L., & Sanz, I. (2010). Tema 8: Diseño Lógico de Bases de Datos Relacionales.
Ordoñez, M. Z., Tapia, J. H., & Asanza, W. R. (2016). Fundamentos de base de datos.
Machala: Ecuador.
Pereira Toledo, A., Rodríguez Morffi, A., Pérez Alonso, A., & González González, L. M. (2020).
Un enfoque ER/SBVR para la modelación conceptual en bases de datos de restricciones
de integridad. Revista Cubana de Ciencias Informáticas, 14(4), 48–66.
Sánchez, J. (2004). Diseño conceptual de bases de datos. Creative Commons.
Sánchez Romero, C. R., & Villacis Miranda, S. P. (2020). Análisis, diseño y desarrollo de prototipo
funcional de un intérprete para la transformación y ejecución de un lenguaje natural escrito a
sentencias SQL. PUCE-Quito.
62

BDP Compendio Unidad 1 Tema 2 2022 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BDP Compendio Unidad 1 Tema 2 2022 2

Cargado por

Copyright:

Formatos disponibles

BASES DE DATOS

Tabla de contenido ................................................................................................................................ 2

La presente imagen dentro del manual mostrará información

La presente imagen dentro del manual permite recordar

Es un cuestionario de un conjunto de preguntas que se confecciona

Para complementar contenidos de la unidad dentro del manual se

La presente imagen en el manual mostrará información que debe

La presente imagen en el manual mostrará información que deberá

ORGANIZACIÓN DE LA LECTURA PARA EL ESTUDIANTE POR

De la asignatura de Base de datos

El estudiante al finalizar el curso estará en capacidad para ser parte de un equipo de

Unidad 1. Diseño de bases de datos

Tema 2: Diseñar esquemas conceptuales, utilizando el modelado entidad-relación, de sistemas de

2.1. MODELADO DE DATOS Y MODELO DE DATOS

2.1.1 La importancia de los modelos de datos

La aplicación de modelos de datos es importante dentro de una organización por las

Video: En el siguiente enlace podrán profundizar un poco más sobre el modelo de

2.1.2 Lo básico de los modelos de datos

Los modelos de datos funcionan como una abstracción simplificada de la realidad. En un

Entonces, ¿cómo se ve un modelo de datos, en realidad? Por lo general, se crea en forma

Clasificación de los modelos de datos

Figura 1. Clasificación de los modelos de datos.

Fuente: Sánchez (2004)

Los elementos del esquema presentado en la Figura 1 son:

• Esquema conceptual: Representa el modelo de datos de forma independiente del SGBD

• Esquema canónico (o de base de datos): Representa los datos en un formato más

Conceptos fundamentales usados en el modelo de datos

Existen conceptos generales que están asociados al modelo de datos:

• Atributo: Es una propiedad o característica propiedad de una entidad o relación. Por

• Diccionario de datos: Es un conjunto de metadatos. Cuando el modelo de datos se

Ventajas y desventajas del modelo de datos

Entre las ventajas de implementar el modelo de datos encontramos:

• El modelo de datos ayuda a las empresas a comunicarse dentro y entre organizaciones.

Con respecto a las desventajas se nombran las siguientes:

• Incluso los cambios más pequeños realizados en la estructura requieren modificaciones

• No hay un lenguaje de manipulación de datos establecido en SGBD.

Propiedades de los datos

• Propiedades relacionadas con la definición:

o Relevancia: La utilidad de los datos en el contexto del negocio o Consistencia:

• Propiedades relacionadas con el contenido:

o Puntualidad: La disponibilidad de datos en el momento requerido y qué tan

o Precisión: Qué tan cerca de la verdad están los datos

• Propiedades relacionadas tanto con la definición como con el contenido:

o Integridad: Cuántos de los datos requeridos están disponibles o Accesibilidad:

Figura 2. Propiedades de calidad de los datos en el modelo de datos.

2.1.3 Las reglas de negocio o requerimientos de automatización

• Estandarizar la visión de los datos de la organización

• Facilitar la comunicación entre usuarios y diseñadores

• Desarrollar reglas apropiadas para la relación de entidades y restricciones • Crear un

Implementación de las reglas del negocio

• Reglas de modelo de datos (constraints): Son aquellas reglas que se encargan de

• Reglas de derivación (views): Especifican y controlan la obtención de información. Por

2.1.4 La evolución de los modelos de datos

En la década de 1960 se crearon los modelos jerárquicos y de redes. El modelo jerárquico

Posteriormente, hasta 1990 se desarrollaron modelos semánticos, en donde surgen modelos

2.2 TIPOS DE MODELOS DE DATOS

Un modelo de base de datos es una especificación que describe cómo se estructura y se

2.2.1 Modelo de datos jerárquico: Características básicas

El concepto del modelo de datos jerárquico se basa en la representación de las situaciones de

Ejemplo1: En una universidad se implementa un modelo de datos jerárquico para almacenar

Figura 3. Representación de un modelo de datos jerárquico. La altura del modelo es de 4

Las características principales de implementar este modelo son:

 Globalización de la información: Permite a los diferentes usuarios considerar la información