Diseño conceptual de la base de datos

CORPORACIÓN DE
EDUCACIÓN TECNOLÓGICA
COLSUBSIDIO

Curso Análisis de datos y Big Data

Unidad 2

Diseño de bases de datos relacionales

 Diseño conceptual de la base de datos

1. Introducción
En esta unidad temática, se continúa trabajando bajo el contexto de nuestro caso
práctico, tomando como modelo para los ejemplos que se realizarán durante toda
la unidad, por lo que se hace necesario recordar el problema planteado.

Caso práctico: La empresa ABC es una comercializadora de ropa, y desea realizar un

análisis completo de su proceso de facturación, con la finalidad de tomar decisiones
comerciales inmediatas, teniendo en cuenta los resultados que arrojen los datos.
Dentro de los procesos que maneja la empresa se destacan los siguientes:
Realiza un proceso de facturación, que incluye productos facturados a sus clientes,
donde los elementos de la factura son: el encabezado y el detalle.
El encabezado contiene el número de la factura, la fecha, el nombre del cliente, el tipo
de cliente, la zona (Norte, Sur, Centro) y la ciudad (solo se tienen clientes en las
siguientes ciudades: Bogotá D.C, Cali, Cartagena de indias y Medellín) y el valor total de
la factura; el detalle de la factura contiene los productos (Camisas, Pantalones,
Chaquetas y Buzos), que se identifican con un consecutivo, un código, el nombre del
producto, el precio de venta por unidad y la cantidad de productos vendidos.
La información del cliente es la siguiente: número de identificación, nombre, tipo
(frecuente, ocasional) y estado (Activo, Inactivo).
Es necesario tener en cuenta las siguientes restricciones:
1. Un cliente puede realizar muchas compras
2. Una factura puede contener muchos productos en su zona de detalle, pero este
detalle corresponde a una única factura.
3. Un producto puede estar contenido en muchas facturas, dentro de su respectivo
detalle.
4. El detalle de una factura puede contener muchos productos.

Una vez realizado el análisis para identificar las entidades, atributos, llaves y
relaciones. se llegó al siguiente resultado (Para revisar el procedimiento con el que
se llegó a este resultado no olvide consultar el material de estudio “6. Unidad 1.
Introducción a las bases de datos” de la unidad 1):

Posibles entidades con sus respectivos atributos

Posibles Posibles atributos Posibles Posibles
entidades llaves relaciones
FACTURA Número de la factura, fecha, valor Número de Factura - Clientes
total de la factura, cantidad de la factura
productos vendidos. Factura -
Productos
PRODUCTOS Código, Nombre del producto, Código
precio de venta, cantidad de Productos - factura
productos vendidos
CLIENTES Número de identificación, Número de Clientes - Factura
nombre, tipo, estado, ciudad y identificación
zona
 Diseño conceptual de la base de datos

2. El modelo relacional
Históricamente existen varios modelos de bases de datos en donde encontramos el
modelo plano, el modelo jerárquico, el modelo de red, el modelo orientado a objetos
y el modelo relacional, siendo este último uno de los más usados por su capacidad
para almacenar, administrar y extraer la información.
En esta unidad nos centraremos en el modelo relacional dadas sus ventajas frente
a los demás modelos.

Un sistema de bases de datos con base al modelo relacional se fundamenta en la

relación que existe entre cada una de sus tablas, a este concepto se le denomina
relación entre tablas; y el proceso de relacionar un conjunto de tablas no es más
que presentar una tabla que guarda alguna relación con los datos de otra; y este
procedimiento se realiza durante la estructuración lógica y el diseño de la base de
datos y este concepto para el usuario final es irrelevante.

Etapas de un diseño de base de datos relacional:

En esta unidad se trabajará el nivel conceptual partiendo de la creación de los

diagramas (diagrama entidad relación y posteriormente su transformación a un
modelo relacional); recordemos que el nivel conceptual es un procedimiento basado
en el análisis de los requerimientos que presenta una organización para el
tratamiento de sus datos, con base esta información se desarrollan una serie de
herramientas conceptuales tales como los diagramas de entidad, que permiten
obtener un esquema general de la base de datos que se va a desarrollar.

El diagrama Entidad Relación (E/R)

Consiste en un diseño esquemático al modo gráfico donde se ilustran los diferentes

elementos que conforman un sistema (Las entidades y sus relaciones), la relación
que existe entre ellos y las características que lo componen. En estos diagramas se
usa una simbología que permite caracterizar cada uno de los objetos anteriormente
mencionados, este tipo de diagramas se asemeja mucho a los diagramas de flujo
tradicionales que utilizan las organizaciones para el modelamiento de la información
organizacional. Para el diseño de este tipo de diagramas se recomienda utilizar
herramientas CASE (ArgoUML, StarUML, LucidChart, Drawio), las cuales son
esenciales para generar este tipo de diagramas; para la creación de los diagramas
ejemplos de nuestro caso de estudio se ha utilizado la herramienta online Drawio.

Componentes: para realizar un diagrama entidad relación o también llamado

modelo E/R se requiere definir varios elementos; las entidades que son elemento
principal del diagrama, éstas pueden ser débiles o fuertes, las cuales están
relacionadas con otras entidades; pero cada entidad puede tener uno o varios
 Diseño conceptual de la base de datos

atributos, estos atributos a su vez puede ser simples o compuestos; las entidades,
relaciones y atributos van unidos con líneas de conexión (ver figura 1).

Entidad Atributo Relación conexión

Fuerte Simples -
compuesto Entidad
Débil fuerte

Multivalorado

Entidad
Derivado débil

Figura 1: representación gráfica de los componentes de un diagrama entidad

relación.

Las entidades: Es un objeto del mundo real o conceptual, que posee unas
características únicas que permiten diferenciarlas de otras entidades. Una entidad
puede ser fuerte o débil, donde la primera debe tener atributos claves, en cambio
las entidades débiles se caracterizan por no poseer llaves propias, pero sí pueden
tener llaves de relación (llaves de otras tablas, son las llamadas foráneas). Son
ejemplos de entidades: un vehículo, una persona, una FACTURA, un servicio, un
CLIENTE, un tratamiento, una historia clínica, un medicamento, un PRODUCTO.
En la figura 2 se representan las 3 entidades resultantes de nuestro caso de estudio,
las cuales son fuertes en su totalidad.

CLIENTES FACTURA PRODUCTOS

Figura 2: representación gráfica de las entidades fuertes de nuestro caso práctico

También existe el conjunto de entidades que se caracterizan por poseer los mismos
atributos (En nuestro caso práctico no se presenta este fenómeno); pero suele
ocurrir en muchas bases de datos; por ejemplo, si hubiese una entidad llamada
empleados, podrá haber atributos similares a los de la entidad CLIENTES, tales
como el nombre, la ciudad, entre otros; dado este caso, los atributos similares se
podrían agrupar en otra entidad genérica (personas) para evitar redundancia.

Los atributos: Son características que tiene cada una de las entidades del sistema;
y éstos pueden ser:
• Simples: son atributos atómicos o que no se subdividen; por ejemplo, en la
tabla CLIENTES, el tipo, estado, ciudad y zona.
• Compuestos: estos son divisibles, o pueden contener otros atributos que
especifican las características del mismo; por ejemplo, en la tabla CLIENTES
 Diseño conceptual de la base de datos

está nombre, que se puede dividir en nombres y apellidos; en otros casos

también se podría incluir la fecha de nacimiento, la dirección, entre otros.
• Multivalorados: son atributos que pueden tener múltiples ocurrencias (en
nuestro caso no se relacionan atributos de este tipo), pero un ejemplo puede
ser, las especialidades de un profesional (un profesional puede tener
múltiples especialidades), o el teléfono (puede tener varios números de
teléfono).
• Derivados: son los que surgen o se derivan de un dato ya existente, por
ejemplo, la antigüedad de la factura, que se puede generar a partir de la fecha
en caso que sea requerida.
También pueden existir aquellos atributos en los que no es necesario o no aplica
asignarle algún valor, a estos se les llama atributos nulos, los cuales, dentro de la
tabla quedarán vacíos. En la figura 3 se puede apreciar el ejemplo de la entidad
CLIENTES con relación a nuestro caso práctico.

Figura 3: Una entidad fuerte con atributos simples y compuestos

En este punto es importante aclarar que los atributos se deben denominar con una
sola palabra y que puede incluir números, pero no incluyen espacios ni caracteres
especiales; en muchas ocasiones se relacionan con palabras nemotécnicas que
caractericen su significado, por ejemplo para identificar el número de la factura se
podría utilizar el nombre “num_factura” como nombre de la entidad tal como se
evidencia en la figura 3; en nuestro caso práctico la relación de los atributos para
cada una de las entidades quedaría de la siguiente manera:

Entidades Atributos
FACTURA num_factura, fecha_factura, cant_productos_vend
PRODUCTOS codigo_prod, nombre_prod, precio_venta, cant_productos_vend
CLIENTES n_identificacion, nombre_cliente, tipo_cliente, estado_cliente,
ciudad_cliente, zona_cliente

Existen algunos atributos que no se incluyen dentro de este modelo conceptual tales
como el del valor total de la factura (este ya no se evidencia en el modelo de la
figura 3), esto porque es un dato de consulta; es decir que suele ser el resultado de
la suma los valores unitarios de los productos y se genera como resultado de
 Diseño conceptual de la base de datos

operaciones matemáticas, lo que los hace atributos de salida que generalmente se

evidencian en los reportes o en la misma factura impresa, pero no es un dato que
se requiere ingresar a la base de datos. De igual manera es importante aclarar que
el atributo que corresponde a la cantidad de productos vendidos hasta este punto
se encuentra en las entidades FACTURA y PRODUCTOS, lo cual crearía
redundancia y será necesario identificar a qué entidad pertenece realmente (este
caso se profundizará más adelante).

Finalmente, la información que corresponde a cada uno de los atributos es la

relación de datos que se puede especificar de acuerdo a lo que allí se solicita, por
ejemplo, para el nombre y el apellido del cliente claro que el dato puede ser algo
como “Pedro” o “Andrea”.

Las relaciones: permiten la relación o asociación entre las diferentes entidades;

estas se representan con un rombo y en su interior se le puede destacar un nombre
que generalmente es un verbo. Las relaciones también pueden o no tener uno o
varios atributos que hacen parte de las entidades que estén asociadas a través de
la relación (en un siguiente apartado se hará claridad en cuales de los casos una
relación podrá tener atributos asociados). En la figura 4, se representan las
entidades CLIENTES y FACTURA relacionadas a través de una relación llamada
tiene.

Figura 4: relación de entidades.

Las entidades débiles se relacionan a través de una relación para entidades débiles
(rombo con líneas dobles), y las entidades fuertes se relacionan a través de una
relación para entidades fuertes (rombo con líneas sencilla), el caso de la figura 4 es
una relación de entidades fuertes tal como se puede apreciar.

Existen diferentes tipos de relaciones:

• Relaciones binarias: son las que relacionan sólo dos entidades.
• Relaciones ternarias: estas relacionan tres entidades.
• Relaciones n-arias: relacionan más de tres entidades
• Relaciones reflexivas: en este tipo de relación la entidad se relaciona con ella
misma.
• Relaciones dobles: en este caso se usan do relaciones para un par de
entidades.
En la figura 5, se representa una relación de tenencia entre el CLIENTE y la
FACTURA (binaria); una relación de tenencia y otra de pertenencia entre el
CLIENTE Y LA FACTURA (doble); una relación donde el VENDEDOR es su propio
jefe (Reflexiva) y una relación en donde tanto el CLIENTE como el VENDEDOR
tienen relación con la FACTURA (ternaria).
 Diseño conceptual de la base de datos

Figura 5. Tipos de relaciones

NOTA: Cabe aclarar que los ejemplos que se demuestran en la figura 5 son solo
para ejemplificar los tipos de relaciones, dado que, hasta este punto solo la relación
binaria aplica para nuestro caso de estudio y la aplicación de cada tipo de relación
dependerá del análisis de cada problema en particular.

La cardinalidad: indica el nivel de relación que existe entre entidades, o la forma

en la que éstas se relaciona:

1. Con respecto a la forma existen cuatro tipos de relaciones:

o Uno a uno: este tipo de relación se da cuando un registro de una entidad

A tiene una relación únicamente con otro de la entidad B; un ejemplo es
el caso de un paciente tiene una sola historia clínica y como consecuencia
una historia clínica sólo pertenecía a un único paciente (En nuestro caso
práctico ninguna de las relaciones tiene este tipo de cardinalidad).

o Uno a muchos: este tipo de relación se da cuando un registro de la entidad

A, se relaciona con varios registros de la entidad B; por ejemplo, un
CLIENTE puede tener muchas facturas asociadas, pero una FACTURA
solo será de un único CLIENTE.

o Muchos a muchos: este tipo de relación será cuando muchos atributos de

la entidad A se relacionan con varios de una entidad B; por ejemplo, una
FACTURA tendrá asociados muchos PRODUCTOS, de igual manera un
PRODUCTO estará relacionado en muchas FACTURAS.
En la figura 6, se representan los ejemplos anteriores de cada
cardinalidad.
 Diseño conceptual de la base de datos

Figura 6: tipo de relaciones con base a su cardinalidad (el ejemplo de la relación

uno a uno es solo ilustrativa, ya que no hace parte de nuestro caso práctico)

2. De acuerdo al nivel de relación: al establecer una relación entre dos tablas

estas se comparten información, pero en ocasiones es necesario establecer
una restricción para compartir cierta información bajo unos extremos o limites
definidos como mínimos o máximos, es decir, que se pueda compartir
información bajo ciertos límites.
o Cardinalidad mínima: corresponde a la cantidad mínima de ocurrencias
con la que puede estar relacionada una entidad (éste puede ser un valor
de 0 o 1, lo que significa que puede haber un mínimo de cero o una
ocurrencia); por ejemplo, un CLIENTE puede tener mínimo 1 (una) o
hasta varias FACTURAS asociadas dadas sus compras; pero una
FACTURA va a corresponder a uno y solo un CLIENTE.
o Cardinalidad máxima: corresponde a la cantidad máxima de ocurrencias
con la que puede estar relacionada una entidad (éste puede ser un 1 o M,
lo que significa que puede haber un máximo de una o muchas
ocurrencias); por ejemplo, una FACTURA podrá tener mínimo uno o hasta
varios PRODUCTOS, al igual que un PRODUCTO podrá estar mínimo
una FACTURA o varias de ellas.

La cardinalidad se puede expresar como un conjunto de pares donde el

primer elemento del conjunto es la expresión mínima y el segundo la
máxima así: (mínima ocurrencia, máxima ocurrencia) por ejemplo, (0,1) –
(1,1) – (0,M) – (1,M) – (N,M). Finalmente, para definir la forma de la
relación se toman solo los extremos máximos; por ejemplo, en la relación
CLIENTES – FACTURA, un cliente puede tener una o muchas
FACTURAS, pero una FACTURA solo estará asociada a un único cliente,
esto indica en definitiva que es una relación de uno a muchos. En la figura
7, se relacionan 2 grupos de entidades definiendo el tipo de relación con
base a la cardinalidad mínima y máxima existente.
 Diseño conceptual de la base de datos

Figura 7. Relación entre tablas con base a sus cardinalidades.

NOTA: Cuando un par de entidades tiene una relación de muchos a muchos, esta
relación puede contener atributos, esto debido a que esta relación se convertirá en
una tabla en el modelo relacional, este caso se refleja en la Figura 8.

Figura 8. Relación entre tablas con base a sus cardinalidades.

 Diseño conceptual de la base de datos

El caso que representa la Figura 8, es nuestro caso puntual de la FACTURA con los
PRODUCTOS; en el problema se logra entender que la cantidad de productos
vendidos hace referencia a los productos y debería de estar en la tabla
PRODUCTOS, pero como están relacionados en la factura de venta se podría
entender que también hace parte de la entidad FACTURA, y esta afirmación es
correcta; pero en lo posible se debe de evitar la redundancia al máximo durante el
diseño de la base de datos, y como se evidencia que hay relación de muchos a
muchos entre las entidades PRODUCTOS y FACTURA entonces es posible asignar
este atributo directamente a esta relación, lo cual indicaría que el atributo
cant_productos_vend hace parte de las 2 entidades y de esta manera no se
relaciona en cada entidad y se evita esta redundancia.

Las llaves primarias: Una llave primaria es un campo especial definido para
identificar en forma única cada registro de una tabla; estos se definen desde el
modelo entidad relación, sobre ese atributo que representará de manera única cada
registro; basta con resaltarlo para que se diferencie con los demás atributos

En la Figura 9, se diseña el modelo conceptual (Diagrama Entidad Relación)

de manera completa como consecuencia de cada uno de los conceptos
relacionados en este documento:

Figura 9. Diagrama entidad relación

 Diseño conceptual de la base de datos

GLOSARIO DE TÉRMINOS

Atributo: es un hecho unitario que caracteriza o describe de alguna manera a una

entidad. (andy oppel, 2009, p.32)
Atributo nulo: es un atributo que no tiene ningún contenido. (pablo valderrey sanz,
2014, p. 45)

Cardinalidad: es el número de tuplas que contiene una relación. (mercedes

marqués, 2011, p. 16)
Cardinalidad máxima: es la cantidad máxima de instancias de una entidad que se
puede asociar con la entidad en el extremo opuesto de la línea. (andy oppel, 2009,
p.32)
Cardinalidad mínima: es la cantidad mínima de instancias de una entidad que se
puede asociar con la entidad en el extremo opuesto de la línea. (andy oppel, 2009,
p.33)
Entidad: es una persona, lugar, cosa, suceso o concepto sobre el que se compilan
datos. (andy oppel, 2009, p.30)
Modelo Entidad Relación: es una herramienta para el modelado de datos de un
sistema de información. (Pablo Valderrey Sanz, 2014, p. 25)
Modelo relacional: que es el modelo de datos en el que se basan la mayoría de los
SGBD en uso hoy en día donde los datos se describen como un conjunto de tablas
con referencias lógicas entre ellas. (Mercedes Marqués, 2011, p. 14)
Redundancia: campos repetidos en diferentes tablas. (pablo valderrey sanz, 2014,
p. 31)

Relación muchos a muchos: es una asociación entre dos entidades en que

cualquier instancia de la primera entidad puede asociarse con cero, una o más
instancias de la segunda, y viceversa. (andy oppel, 2009, p.36)
Relación uno a muchos: es una asociación entre dos entidades en que cualquier
instancia de la primera entidad puede asociarse con una o más instancias de la
segunda entidad y cualquier instancia de la segunda entidad puede asociarse con
cuando mucho una instancia la primera. (andy oppel, 2009, p.35)
Relación uno a uno: es una asociación en que una instancia de una entidad se
puede asociar cuando mucho con una instancia de la otra entidad. (andy oppel,
2009, p.34)