Diseño lógico 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 lógico de la base de datos

1. Introducción
¿Qué tan relevante y justificable es el uso del tradicional modelo relacional en la
creación de una base de datos teniendo en cuenta las diferentes herramientas de
gestión de bases de datos existentes?

En la actualidad el modelo relacional ésta considerado como uno de los más

robustos y confiables en la estructuración de una base de datos, por sus
características que posibilitan que la información almacenada en ella sea íntegra.

De igual manera se caracteriza por ser un sistema amigable y sencillo para el

usuario que tiene poca capacitación y manejo del lenguaje. Dentro sus cualidades
importantes se evidencian la llamada restricciones que permiten la correlación de
los datos que poseen cada uno de los campos de las tablas con la realidad de una
organización; además de la integridad de los datos y de la relación que existe entre
ellos en el entorno de la base de datos a nivel general
En documento anterior “4. Unidad 2. Diseño conceptual de la base de datos”. se
realizó el procedimiento para la creación del diagrama entidad relación con base a
nuestro caso práctico, dando como resultado la estructura de dicho modelo ver
Figura 1. Una vez realizado el diagrama entidad relación (Modelo conceptual), se
debe proceder realizar el modelo relacional con base a este, teniendo en cuenta los
diferentes pasos o procedimientos para su conversión.

Figura 1. Diagrama entidad relación del caso practico

 Diseño lógico de la base de datos

Partiendo de la base que ya se tiene diseñado el modelo entidad relación, en este

capítulo se procederá a reducirlo a un modelo relacional teniendo en cuenta los
diferentes casos y el proceso de normalización que se requiere para dicho proceso.

2. conversión del modelo entidad relación a el modelo relacional

¿Qué es el modelo relacional y que relacional guarda con el diagrama entidad

relación?

Empecemos por mirar las diferencias que hay entre el uno y el otro, partiendo de
que el diagrama entidad relación como se vio en el capítulo anterior es un modelo
conceptual que va muy de la mano con las reglas del negocio y que con base a este
se genera el diseño de la base de datos; en cambio el modelo relacional es una
estructura que con base a unas tablas y una relación entre ellas, permite el
almacenamiento físico de los datos bajo una estructura jerárquica y con bases de
integridad; lógicamente es un proceso a seguir donde primeramente se crea la
estructura bajo el diagrama entidad relación y posteriormente una conversión o
mapeo a un modelo relacional.

Mapeo del diagrama entidad relación al modelo relacional:

Recordemos que el diagrama entidad relacional costa de unas entidades, unos

atributos y unas relaciones; lo que convertiremos en un modelo relacional donde,
las entidades se convierten en tablas; los atributos se convierten en campos de la
tabla; las relaciones se convierten en llaves foráneas y/o tablas de relación
dependiendo del tipo de relación; y los identificadores se convertirán en llaves
primarias.
Las relaciones se van convertir en tablas de relación para los casos en que es del
tipo muchos a muchos.
Existen algunas reglas o condiciones específicas para pasar el diagrama entidad
relación al modelo relacional:

Entidades → Tablas
• Para las entidades fuertes se generan tablas con relación del mismo tipo,
mismo nombre y con todos sus atributos que se convierten en campos de la
tabla resultante.
• Las entidades débiles generan una tabla con relación del mismo tipo y
mantienen sus atributos.
Llaves
• Los identificadores que son los atributos resaltados en el diagrama entidad
relación pasan a ser las llaves primarias o principales.
• Las relaciones se convertirán en tablas y/o llaves foráneas.

Las llaves son los atributos o campos con los que se relacionan las tablas, y
cada una de las tablas puede tener una llave principal además de las foráneas
necesarias para relacionar las tablas que guarden algún tipo de relación entre
 Diseño lógico de la base de datos

sus datos. La única manera de relacionar una tabla con otra es a través de sus
llaves partiendo de una tabla padre hacia una tabla relacionada o tabla
dependiente. Existen diferentes tipos de llaves:

1. Llave principal: también llamada llave primaria, y cómo se mencionó

anteriormente la deben tener todas las entidades fuertes, y es utilizada para
crear la relación con otra tabla; se puede decir que con la llave primaria se
identifican de manera única cada uno de los registros de la tabla sin temor a
que haya duplicidad en la información tal como lo indica la primera forma
normal. En el diagrama entidad relación está se identifica por estar subrayada
o resaltada para diferenciarla de los demás atributos.
2. Llave foránea: también llamada llave externa, y corresponde a un atributo o
campo que se genera en una tabla con la que la tabla principal quiere
establecer alguna relación; esta llave se debe generar con las mismas
características de la llave primaria de la tabla padre; se puede decir que a
través de esta llave los datos de la tabla padre se trasladan a la tabla hija
para establecer una relación. En la figura 2, se evidencia como de define la
llave primaria y la llave foránea en un conjunto de entidades.

Figura 2: identificación de la llave primaria y la llave foránea

Relaciones
1. En las relaciones de uno a varios se genera una llave foránea en la tabla
dependiente, a través de la cual se genera la relación. En este tipo de
relación no se crean una nueva tabla, solamente se representa la llave
foránea en la tabla de la cardinalidad varios.
Atributos
2. Los atributos univaluados se convierten en campos de la nueva tabla
3. Los atributos compuestos son representados en la nueva tabla sólo los
campos que se desprenden del nombre compuesto; es decir sí el campo es
nombres, en la nueva tabla se representarán sólo los campos que se
desprenden de nombres (primer nombre, segundo nombre).
4. Los atributos multivaluados generalmente conllevan a una nueva tabla,
dando como resultado una tabla cuya clave principal es la combinación de la
tabla original y el atributo multivaluado; y así sucesivamente se realizará el
mismo procedimiento por cada uno de los atributos multivaluados que existan
 Diseño lógico de la base de datos

en una entidad, dichas tablas serán consideradas como entidades débiles

dentro de la relación

Conversión del diagrama entidad relación al modelo relacional

1. Con base a lo descrito anteriormente se puede proceder a la conversión del
diagrama entidad relación al modelo relacional, este se realizará por partes para
una mejor conversión, iniciando con un par de entidades A y B que tienen una
relación de UNO a MUCHOS (ver Fugura3)

Figura 3: transformación del diagrama E/R al modelo relacional con una

relación de uno a muchos

En la figura 3 se evidencia la transformación del diagrama entidad relación a un

modelo relacional con una relación de uno a muchos, con cardinalidad uno y uno
para una tabla y uno y muchos para la otra (1,1) – (1, M); para este caso cada
entidad que contenga cardinalidad (1,1) o (0,1) a la que llamaremos tabla principal
se transformará en una tabla con su propia llave principal; y la entidad que contenga
la cardinalidad máxima (1,M) o (0,M) a la que llamaremos tabla dependiente se
transforma en una tabla con todos sus atributos, con una llave principal y con una
llave externa con las mismas características de la llave principal de la tabla principal.
El mapeo al modelo relacional genera la siguiente estructura para las tablas:

Entidad A (Llave_primaria_A, Atributo A1, Atributo A2)

Entidad B (Llave_primaria_B, Atributo B1, Atributo B2, Llave foránea_A)

Para llevar este ejemplo a la práctica tomando nuestro caso de estudio, se usará el
diagrama donde se encuentran relacionadas las entidades CLIENTE – FACTURA,
dado que estas tienen una relación de UNO a MUCHOS; por tanto, al mapearlo al
modelo relacional quedará tal como se muestra en la Figura 4.
 Diseño lógico de la base de datos

Figura 4: transformación de las entidades CLIENTES Y FACTURA al

modelo relacional

2. En las relaciones de MUCHOS a MUCHOS se crea una tabla intermedia con las
llaves foráneas de las tablas principales (ver Figura 5)

Figura 5: transformación del diagrama E/R al modelo relacional con una

relación de muchos a muchos
 Diseño lógico de la base de datos

La figura 5 muestra la generación de un modelo relacional con base a un

diagrama entidad relación, con la siguiente estructura para las tablas:

Entidad A (Llave_primaria_A, Atributo A1, Atributo A2)

Relación R (Llave foránea_A, Llave foránea_B, Atributo_R)

Entidad B (Llave_primaria_B, Atributo B1, Atributo B2

En esta estructura se denota que toda relación de muchos a muchos genera

una tabla de relación con las llaves externas de las tablas principales como
se evidencia en la Relación_R; ahora realizaremos este procedimiento, pero
aplicado a nuestro caso práctico, ver Figura 6.

Figura 6: transformación de las entidades FACTURA y PRODUCTOS

al modelo relacional.

3. En las relaciones de UNO a UNO se genera una llave foránea en cualquiera de

las dos tablas, aunque se puede priorizar en la tabla donde existan otras llaves
foráneas tal como se aprecia en la Figura 7.
 Diseño lógico de la base de datos

Figura 7: transformación del diagrama E/R al modelo relacional con una

relación de uno a uno

En la figura 3 se evidencia la transformación del diagrama entidad relación a

un modelo relacional con una relación de uno a uno; se evidencia una tabla
principal (tabla A) y una tabla dependiente (Tabla B); se construyó la llave
foránea (llave foránea_A)) en la tabla dependiente.

En este caso la cardinalidad mínima y máxima de la relación debe de ser uno

y uno, (1,1), y puede ocurrir que ambas tablas tengan el mismo identificador
lo que transformará la relación de una única tabla y en ella los atributos de
las mismas; en caso que las llaves primarias o identificadores sean distintos
se genera una relación como lo muestra la figura 3.
El mapeo al modelo relacional genera la siguiente estructura para las tablas:

Entidad A (Llave_primaria_A, Atributo A1, Atributo A2)

Entidad B (Llave_primaria_B, Atributo B1, Atributo B2, Llave foránea_A)

Reglas de normalización
Al mapear el diagrama al modelo relacional se realiza el proceso de normalización
mínimo a las primeras tres formas normales que se resumirán a continuación:
• Primera Forma Normal: todo atributo principal o llave primaria debe estar
definido dentro de la tabla, por ende, no puede haber registros duplicados.
• Segunda Forma Normal: las relaciones que existen entre cada uno de los
registros deben de ser únicos para poder ser identificados dentro de la tabla.
 Diseño lógico de la base de datos

• Tercera Forma Normal: los datos de un registro que no sean únicos deben
estar directamente relacionados con la clave o identificador, de lo contrario
deberá ser separado a otra tabla.

En conclusión, el proceso de normalización, aplicando las 3 formas normales,

conlleva a que el modelo relacional cumpla con las siguientes características:
1. Se definan las llaves primarias en las tablas padres, para que los registros
de las tablas sean atómicos.
2. Los campos estén en las tablas correspondientes, evitando redundancia
en cada uno de los campos y en las relaciones.
3. Desglosar las tablas que contienen campos que se puedan separar.

En ese sentido se puede evidenciar que la tabla clientes se puede normalizar,

separando los campos tipo_cliente, zona_cliente, ciudad_cliente y estado cliente.
De igual manera en este punto se deben de tener en cuenta las restricciones del
problema inicial:

La tabla CLIENTES normalizada quedaría como se muestra en la Figura 8,

asumiendo las siguientes reglas básicas de negocio:
• Un cliente pertenece a un solo tipo, pero un tipo puede tener asociados
muchos clientes.
• Un cliente pertenece a una zona, pero una zona contiene muchos clientes
• Un cliente es de una única ciudad, pero esa ciudad contiene a muchos
clientes
• Un cliente pertenece a un estado, pero un estado contiene a muchos clientes.

Figura 8: Tabla CLIENTES normalizada

 Diseño lógico de la base de datos

Finalmente, y unificando cada una de las partes realizadas en cada uno de los
ejemplos y demostraciones, el modelo relacional quedaría tal como se evidencia en
la Figura 9, tras relacionar la tabla CLIENTES con la tabla FACTURA.
 Diseño lógico de la base de datos

GLOSARIO DE TÉRMINOS

Atributo multivaluado: para una misma ocurrencia de entidad pueden tomar varios
valores. (Luis hueso Ibáñez, 2014, p.44)
Campos: atributos por registros de una tabla. (mercedes marqués, 2011, p. 16)
Entidad débil: posee dependencia de existencia (depende de la existencia de la
entidad fuerte). (Luis hueso Ibáñez, 2014, p.51)
Entidad fuerte: no depende de la existencia de ninguna otra entidad. (Luis hueso
Ibáñez, 2014, p.51)
Estructura jerárquica: estructura en forma de árbol.(mercedes marqués,2011,p. 5)
Identificadores: son hombres que identifican las propiedades de una tabla.
(mercedes marqués, 2011, p. 111)
Índice: que es un tipo especial de objeto de base de datos que permite búsquedas
rápidas de valores de columna. (Andy Opel, 2010, p.47)
Integridad: se refiere a la validez de los datos almacenados. (mercedes marqués,
2011, p. 10)
Llave externa: es la denominada llave foránea, y recibe su nombre de las columnas
copiadas de otra tabla (externa). (andy oppel, 2010, p.47)
Primera forma normal: eliminación de los atributos parcialmente dependientes.
(andy oppel, 2010, p.191)
Registro: son colecciones de valores o elementos de información relacionados
cada uno de los cuales corresponde a un campo del registro. (Luis hueso Ibáñez,
2014, p.13)
Reglas del negocio: describen las características principales sobre el
comportamiento de los datos tal y como las de la empresa. (mercedes marqués,
2011, p. 5)
Restricciones: reglas que no se pueden violar (mercedes marqués, 2011, p. 10)
Tabla: es un conjunto de filas (tuplas) que equivalen a cada uno de los registros que
contendrá la base de datos y las columnas corresponden a las características
(atributos) de cada registro localizado en la tupla. (Luis hueso Ibáñez, 2014, p.25)
Tabla dependiente: son las tablas que no poseen atributos identificadores.
(mercedes marqués, 2011, p. 111)
Unique: específica como restricción de columna que la columna sólo puede
contener valores únicos. (mercedes marqués, 2011, p. 46)