Módulo 2.

Base de datos y modelo

relacional

Introducción
En el módulo 2 conoceremos lo que es un modelo de datos y aprenderemos los
componentes que posee un sistema administrador de base de datos (DBMS, por sus siglas
en inglés). Luego ampliaremos sobre modelos de datos existentes como: el de red, el
jerárquico y, finalmente, el modelo relacional. Además del modelo relacional, analizaremos
qué es un diagrama de entidad-relación, cuáles son las reglas de Codd y qué es una
dependencia funcional. Por último, profundizaremos en las diferentes formas normales y la
normalización de base de datos, proceso que nos servirá para mejorar la calidad de nuestras
bases de datos.

Video de Inmersión
Unidad 1. Sistemas de bases de datos y modelos
Tema 1. Modelos de datos y sistemas de base de datos

Modelo de datos
Los modelos de datos están integrados por una serie de conceptos para describir los
datos, sus relaciones y restricciones, y son útiles para representar, de manera
abstracta, el mundo real. Su propósito es, además de facilitar la descripción de los
datos y sus relaciones, permitir la representación de los datos y hacerlos
comprensibles. Por esta razón, los modelos de datos facilitan el diseño de bases de
datos. Para especificar la estructura y las restricciones, se usa un lenguaje de
definición de datos (Data Definition Language, DDL, por sus siglas en inglés) y para
especificar la manipulación de los datos se utiliza el lenguaje de manipulación de
datos (Data Manipulation Language - DML, por sus siglas en inglés). Un DML ofrece
mecanismos para recuperar datos de la base de datos vigente y para actualizar datos.
Algunas de las utilidades que tiene un modelo de datos son: facilitar la especificación
de los tipos y la forma en que los datos están organizados en una base de datos y
servir de base para desarrollar metodologías de diseño y lenguajes de alto nivel para
consultar y manipular los datos. (Millán, 2012, p. 17)
Un modelo de datos debe tener, según [Codd80]:
 Un conjunto de elementos atómicos y de relaciones entre estos elementos,
denominado espacio de datos; una especificación de restricciones aplicadas a las
relaciones en el espacio de datos, denominada restricciones de definición de tipo;
un conjunto de operaciones para crear y destruir elementos y modificar las relaciones
entre estos, denominada operaciones de manipulación; y un lenguaje de predicados
para identificar de la base de datos elementos individuales por medio de sus
propiedades lógicas. (Millán, 2012, p. 18)
Sistema de gestión de base de datos
Un sistema de gestión de bases de datos (SGBD) es una capa de software que necesitamos
si deseamos crear, manipular y recuperar datos desde una base de datos. Como
herramienta, sirve para realizar tareas generales, como estructurar, almacenar y controlar los
datos, y provee interfaces de acceso a esta. Dentro de las tareas fundamentales que este
sistema realiza, podemos mencionar los siguientes: mantenimiento de la integridad,
seguridad de acceso, mecanismos de recuperación cuando surgen fallos tanto físicos como
lógicos, control de concurrencia al acceso de los datos y eficiencia del sistema, que se
evalúa, por lo general, según el tiempo que lleva responder preguntas de usuarios (Millán,
2012).
Mediante el DDL y el DML, respectivamente, un usuario define una base de datos
(tipos, estructura y restricciones) y puede recuperar, actualizar, insertar o borrar datos.
Los usuarios no necesitan conocer detalles de almacenamiento de la base de datos,
solo deben tener una vista abstracta de los datos. Por esta razón, la arquitectura de
un SGBD, generalmente, se basa en la arquitectura de tres niveles (externo,
conceptual e interno) ANSI-SPARC de la figura 1, tomada de [AA93]. Se trata de
separar la forma en que los usuarios ven los datos de los detalles de almacenamiento
físico de estos datos. (Millán, 2012, p. 19)

Este principio de independencia de datos hace posible que el administrador de la

base de datos (BD) cambie la estructura física (nivel interno) sin que cambie la
manera en la cual los diferentes usuarios ven los datos (nivel externo). El nivel interno
describe la forma sobre cómo los datos se almacenan en la base de datos
(estructuras de datos, espacios de almacenamiento, índices, formato de registros). El
nivel más bajo, el físico, trata con los mecanismos de almacenamiento físico que el
sistema operativo utiliza (dispositivos físicos). (Millán, 2012, p. 19)
Esto es lo que se conoce como “arquitectura funcional de una base de datos”. Veamos,
entonces, los diferentes niveles que puede tener una base de datos, según su función.

Figura 1: Arquitectura funcional de una base de datos ANSI-SPARC

Fuente: Millán, 2012, p. 20.

Rol del DBA

Como programadores, es común que interactuemos con el administrador de la base de
datos. Por eso, es necesario conocer cuál es el rol que este cumple. Veremos que, en
algunos casos, podremos compartir tareas en común. Sus tareas son las siguientes:

Definir estructuras. Esto es la creación de la base de datos: tablas y sus relaciones.

Definir estructuras físicas, es decir, qué archivos se van a crear para cada esquema.
Especificar perfiles y seguridad: usuarios, roles y permisos a la base de datos.
Implementar integridad: relaciones entre tablas.
Definir métodos de respaldo y recuperación. Estas políticas se definen acorde a la
importancia y la sensibilidad de los datos.
Monitorear el rendimiento, con el objetivo de optimizar consultas y el acceso a los datos
para mejorar la experiencia del usuario final.

Sistema gerencial de una base de datos

Las siglas SGI (o MIS, en inglés) se utilizan para denominar un sistema gerencial de
información. Un SGI es el resultado de la interacción colaborativa de varias partes, como, por
ejemplo, personas, tecnologías y procedimientos.

Habitualmente, para analizar la información, se alimentan de otros sistemas de la empresa u

organización. Sus funciones gerenciales son planificación, dirección, control y organización,
todas necesarias para un buen desempeño de la organización. Los SGI tienen como función
ayudar a proporcionar información que cumpla con las siguientes características:

Calidad: la información proporcionada debe ser fidedigna y no debe contener errores de

procesamiento.

Oportuna: la información debe estar disponible, en el momento preciso que se la necesita.

Cantidad: su presentación debe ser orientada al usuario y mostrará mayor nivel de detalle a
un operario y menor detalle a un gerente, para que pueda tomar decisiones oportunas.

Relevante: la información brindada debe estar relacionada con sus tareas y

responsabilidades.
Tema 2. Componentes de un DBMS
Detallamos, a continuación, los componentes de un DBMS y su definición:

Tabla 1: Componentes del DBMS

Componente Definición

Compilador DDL Procesa las definiciones de los esquemas y almacena las descripciones de los esquemas en

el catálogo.

Compilador de consultas Analiza las consultas sintácticamente, nombres de elementos y objetos. Traduce a formato

interno.

Optimizador de Reconfigura, reordena, elimina redundancias y usa algoritmos e índices para mejorar la

consultas ejecución de la consulta. Genera código ejecutable.

Precompilador DML Extrae los comandos DML y los envía al compilador DML. Envía el resto del programa al

compilador del lenguaje host.

Compilador DML Compila y genera código objeto que le pasa al procesador de DB runtime.

Compilador de Compila el programa y lo prepara para enlazar la transacción.

lenguaje host

Procesador de BD Recibe comandos y los ejecuta, accede al diccionario de datos y se comunica con el sistema

runtime operativo (SO) para E/S. Administra el buffer en la memoria de procesamiento, compartida o

no con SO.

Subsistema de control Subfunción del procesador de BD para colaborar con el control de concurrencia.

de concurrencia

Administración de Funciona con el procesador de BD para poder comunicarse con el SO y realizar E/S.

datos almacenados
Fuente: elaboración propia.

Para comprender mejor cada uno de estos componentes y sus relaciones, podemos
observar en la siguiente gráfica cómo es su interacción:

Figura 2: Componentes del DBMS

Fuente: Braghetto, 2017, p. 20.

Seguridad de una base de datos

Conceptos para tener en cuenta:

Aspectos legales y éticos ante información privada.

Política para dejar información públicamente disponible (créditos).
A nivel de sistema, reforzando determinadas funciones (hard, SO, DBMS).
Nivel de seguridad de datos.
Disponibilidad.
Confidencialidad.

Este último punto es muy

importante. Si no contamos
con un buen sistema de
seguridad a nivel de datos y
hard, se puede producir
pérdida o degradación de la
información. También es
importante proteger la
información almacenada en
términos de integridad,
 protegerla de modificaciones
inadecuadas.
Medidas de control

Control de acceso: sirve para restringir el acceso con la creación de cuentas y

contraseñas.
Control de flujo: sirve para evitar que cierta información llegue a usuarios no
autorizados. Esto se realiza otorgándoles a los usuarios diferentes perfiles o privilegios,
según la información que estén autorizados a ver.
Cifrado de datos: se realiza con algoritmos de cifrado, con clave, para disfrazar un
mensaje.

Seguridad y DBA

Creación de cuentas para usuarios o grupo de acceso a DBMS.

Concesión de derechos o privilegios y grant option.
Retiro de privilegios revoke.
Asignación de nivel de seguridad: ambientes militares, Gobierno.
Auditoría de BD: registrar acciones desde usuario o terminal.

Respaldo y recuperación
En todo sistema de base de datos, es vital contar con una copia de los datos originales, para
poder recuperarlos en caso de que ocurra una pérdida parcial o total de la información.

La contrapartida del proceso de copia de seguridad es el proceso de restauración de los

datos.

Las copias de seguridad pueden almacenarse en diferentes dispositivos, cada uno de los
cuales posee ventajas y desventajas. Al momento de seleccionar uno, hay que tener en
cuenta diferentes aspectos, como, por ejemplo, facilidad de traslado, duplicidad de
información, seguridad de los datos.

Hay diferentes estrategias de backups o respaldos, pero a la hora de seleccionar una

debemos tener en cuenta la capacidad de almacenamiento disponible, si pensamos en
duplicar datos. Lo usual es hacer una copia inicial y luego hacer copia de las modificaciones
que van ocurriendo. Este tipo de resguardo se denomina incremental, ya que cada copia no
posee la totalidad de los datos, sino que contiene la diferencia de aquellos datos
modificados.
Las copias de seguridad
garantizan la integridad y la
disponibilidad de una base
de datos.
Tipos de respaldo
Depósito del sistema de archivos: es un tipo de copia de seguridad rápida. Como
característica negativa, exige que la base de datos no se esté usando en el momento de la
copia, lo cual, muchas veces, no es factible en los sistemas que poseen una alta
disponibilidad para el usuario.

Control de cambios: este tipo de respaldo consiste en copiar los archivos que solo han sido
modificados. Varios sistemas de archivos cuentan con un bit de archivo para cada uno, que
nos permite identificar si el archivo fue modificado o no, luego de la copia anterior. Si ha sido
modificado se resguarda, en caso contrario, no. Otra forma de saber si el sistema de
archivos ha sido modificado es mirando la fecha de creación o modificación del archivo.

Incremental a nivel de bloque: una vez que se hace la copia base o primera copia, una
forma de hacer una copia de seguridad de los archivos es copiar los bloques físicos que han
sufrido cambios. Este tipo de copia es más compleja.
Incremental o diferencial binaria: es similar a la anterior, pero toma las diferencias binarias
entre el backup anterior y el actual. La ventaja de este tipo de backup es que, al trabajar a
nivel de byte, ahorra espacio y no depende del sistema operativo.

Versionado del sistema de archivos: se basa en los cambios del archivo y crea estos
cambios accesibles al usuario. Este tipo de copia de seguridad está integrada al ambiente
informático.
Las unidades de cambio que
maneja el sistema de
bloques se basan en
unidades de cambio
relativamente grandes
(bloques de 8 ks, 4 ks, 1 ks).
Copia de seguridad de datos en uso
Si al momento de ejecutar el backup, la base de datos está siendo usada, corremos el riesgo
de que existan archivos abiertos y que se esté trabajando sobre esos archivos. Si esto
sucede, posiblemente, el contenido del disco no refleje exactamente lo que el usuario ve.
Nos resulta raro que esto pueda ocurrir, pero es muy frecuente.

Sí debemos tener en cuenta que este tipo de copia de seguridad suele tardar más tiempo. A
fin de copiar un archivo en uso, es muy importante que la copia de seguridad entera
represente un único paso, lo cual es todo un desafío cuando se está copiando un archivo en
continua modificación. En estos casos, el archivo de base de datos está bloqueado para
evitar cambios, pero debemos implementar un método para asegurar que el snapshot
original es preservado con tiempo de sobra para ser copiado, incluso, cuando se mantengan
los cambios.

La operación de recuperación de la información se realiza de manera inversa a la operación

de backup o resguardo y de acuerdo con la técnica de backup que se haya implementado.

Tener copias de los datos originales no posee importancia

Verdadero

Falso

Justificación

Tema 3. Modelos jerárquico, de red y relacional

Modelo de red
Los datos son representados como colección de registros de estructura arbitraria. Como
desventaja, podemos mencionar que poseen una estructura compleja para problemas
simples. Tienen algunas restricciones al momento de las implementaciones, como, por
ejemplo, no poder insertar el detalle de una factura (hijo) si no hay una cabecera de factura
(padre). Las órdenes implican acciones físicas:

Find: localiza un registro por condición y ubica el puntero.

G​​et: copia un registro señalado por el puntero actual al buffer.
Store: crea un registro con valores de datos ubicados en la memoria.
Modify: implica encontrarlo, subirlo a la memoria y modificarlo.
Erase: elimina registro, con previa búsqueda.
Connect: conecta un registro con un conjunto de registros.
Disconnect: desconecta un registro de un conjunto de registros.
Reconnect: mueve un registro de un conjunto a otro.

Figura 3: Modelo de red

Fuente: elaboración propia.

Modelo jerárquico
El modelo jerárquico es una implementación particular del modelo de red. Los datos están
representados como colección de registros, pero con estructura padre/hijo. Las relaciones
también son punteros o enlaces y permiten las relaciones de uno a uno y uno a muchos.
Como restricción, podemos mencionar que todo hijo tiene un solo padre y que un padre
puede tener uno o más hijos.

Las órdenes implican acciones físicas:

Get/Where: localiza y copia registro a memoria.

Insert: localiza a su registro padre y luego inserta.
Replace: modifica uno o más campos de un registro.
 Delete: elimina el registro actual de la base de datos.

Figura 4: Modelo jerárquico

Fuente: elaboración propia.

Modelo relacional
El modelo relacional tiene base en el concepto de relación matemática, más precisamente,
en la teoría de conjuntos.
Intuitivamente, las relaciones se asocian con tablas nombradas cuyas columnas
representan atributos que también tienen asociado un nombre. Las filas de las tablas
se denominan tuplas. Los valores que toman esas tuplas se extraen de conjuntos de
constantes, llamados dominios. Todas las tablas constituyen la estructura de la base
de datos que se representa en un esquema de base de datos (nivel intensional) y su
contenido en una instancia de base de datos (nivel extensional). La propuesta inicial
del modelo de datos relacional caracteriza las relaciones como la estructura
fundamental para describir y organizar los datos y el álgebra relacional para
manipularla.

El modelo relacional se define integrado a partir de tres elementos:

un conjunto de relaciones que varía en el tiempo;

reglas de inserción-actualización-eliminación;
y un álgebra relacional. (Millán, 2012, p. 25)

Para diseñar un modelo de datos relacional, se utilizan una serie de normas o reglas
denominadas formas normales y son las que establecen el fundamento teórico de la
normalización.

Características o propiedades de las relaciones:

Las tuplas no están ordenadas (conjunto matemático).

Los atributos en las tuplas no están ordenados (conjunto matemático).
Los valores en los atributos deben ser atómicos (relaciones normalizadas).
No hay tuplas repetidas (hechos diferentes del mundo real).
 Tema 4. Modelado y diseño de una BD relacional

Modelo relacional
Las bases de datos recopilan datos. Estos pueden ser manipulados con facilidad, así como
mostrados o presentados de diversas maneras. El proceso de construir una base de datos
se denomina diseño de base de datos.

La definición del problema es:

El proceso por el cual se determina la organización de una base de datos, incluidos su
estructura, contenido y las aplicaciones que se han de desarrollar.
​
Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para
expertos: más un arte que una ciencia. Sin embargo, se ha progresado mucho en el
diseño de bases de datos y este se considera ahora una disciplina estable, con
métodos y técnicas propias.

La aceptación de las bases de datos en la industria y el Gobierno en el plano

comercial se ha incrementado. Además, existe una pluralidad de aplicaciones técnicas
y científicas. Estos dos factores han provocado que el diseño de bases de datos tenga
hoy un rol esencial en el empleo de los recursos de información en la mayor parte de
las organizaciones. El diseño de bases de datos ha pasado a constituir parte de la
formación general de los informáticos, en el mismo nivel que la capacidad de construir
algoritmos mediante un lenguaje de programación convencional. (AIU Universidad en
Línea, s. f., p. 3)
Captura de requerimientos
Para definir correctamente el problema, lo primero que debemos hacer es realizar un diseño
conceptual que parte de las especificaciones de los requisitos del usuario. El resultado será
el esquema conceptual de la base de datos que corresponderá a un modelo entidad-relación
(E/R). Un esquema conceptual es “una descripción de alto nivel de la estructura de la base
de datos, independientemente del DBMS que se vaya a utilizar para manipularla” (Campus
MVP, s. f., https://bit.ly/3NXytPa).

Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales.

El objetivo del diseño conceptual “es describir el contenido de los datos de la base de datos
(DB) y no las estructuras de almacenamiento que se necesitarán para manejar esta
información” (Campus MVP, s. f., https://bit.ly/3NXytPa).
 El modelo relacional representa un sistema de bases de datos en un nivel de
abstracción un tanto alejado de los detalles de la máquina subyacente. De hecho, el
modelo relacional puede considerarse un lenguaje de programación más bien
abstracto, orientado de manera específica a las aplicaciones de bases de datos.
(Giraudo, 20 de agosto de 2012, https://bit.ly/3Kv9ZdS)
Podemos asemejar una relación a un archivo, una tupla a un registro y un atributo a un
campo. Sin embargo, estos parecidos son aproximados, en el mejor de los casos. Una
relación no debe pensarse como un solo archivo, sino como un archivo disciplinado, gracias
a lo cual se simplifican considerablemente las estructuras de datos con las que debe
interactuar el usuario que, asimismo, facilita los operadores necesarios para manejar dichas
estructuras.
Generación de estructuras relacionales
El primer paso para la definición del problema es la producción del esquema conceptual.
Normalmente, se construyen varios esquemas conceptuales, cada uno para
representar las distintas visiones que los usuarios tienen de la información. Cada una
de estas visiones suele corresponder a las diferentes áreas funcionales de la
empresa, como, por ejemplo, producción, ventas, recursos humanos, etcétera. A los
esquemas conceptuales correspondientes a cada vista de usuario se los denomina
esquemas conceptuales locales. Cada uno de estos esquemas se compone de
entidades, relaciones, atributos, dominios de atributos e identificadores. El esquema
conceptual también tendrá una documentación, que se irá produciendo durante su
desarrollo. Las tareas que se deben realizar en el diseño 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 entidad-relación; y
8. revisar el esquema conceptual local con el usuario. (Atlantic International
University, s. f., pp. 9-10)

El modelo entidad-relación (E/R) se basa en una representación del mundo real en la que los
datos se describen como entidades, relaciones y atributos.
El principal concepto del modelo E/R es la entidad, que es una “cosa” en el mundo
real con existencia independiente. Una entidad puede ser un objeto físico (una
 persona, un auto, una casa o un empleado) o un objeto conceptual (una compañía, un
puesto de trabajo o un curso universitario). En nuestro ejemplo de la sección anterior,
podemos definir dos entidades: alumnos y cursos. Cada entidad tiene propiedades
específicas, llamadas “atributos”, que la describen. Por ejemplo, un curso tiene un
nombre, un cupo máximo, un profesor.

Una entidad particular tiene un valor para cada uno de los atributos, y cada uno de
ellos posee un dominio, que corresponde al tipo del atributo. Por ejemplo, matrícula
tiene como dominio al conjunto de los enteros positivos, y nombre tiene como dominio
al conjunto de caracteres. Para todo conjunto de valores de una entidad, debe existir
un atributo o combinación de atributos que identifique a cada entidad en forma única.
Este atributo o combinación de atributos se denomina “llave (primaria)”. Por ejemplo,
el número de matrícula es una buena llave para la entidad del alumno, pero no así el
nombre, porque pueden existir dos personas con el mismo nombre.
​
Una relación se puede definir como una asociación entre entidades. Por ejemplo, la
entidad libro puede estar relacionada con la entidad persona por medio de la relación
“está pedido”. La entidad curso puede estar relacionada con la entidad alumno
mediante la relación… [tiene]. (Guerrero, s. f., https://bit.ly/3QxN2dJ)
Siguiendo con la relación mencionada “Curso-tiene-Alumno”, también surge la necesidad de
indicar la cardinalidad de la relación. En este caso, tenemos que un (1) curso puede tener
muchos (N) alumnos. Según lo que venimos detallando, podemos tener un modelo entidad-
relación como el siguiente:

Figura 5: Modelo entidad-relación Curso-Alumno

Fuente: elaboración propia.

Vemos, entonces, que las entidades se indican con un rectángulo; la relación, con un rombo
y enumerando las diferentes cardinalidades; y, por último, los atributos, con elipses o
círculos. Siempre debemos indicar el nombre para cada elemento (entidad, atributo,
relación).

De acuerdo al modelo relacional, completa las siguientes oraciones.

“Las ……… representan entidades del mundo real”

 Respuesta

“Las …….. representan los atributos de las entidades”

Respuesta

“Los registros o filas de cada tabla se denominan …..”

Respuesta

Tema 5. Reglas de Codd y dependencia funcional

Reglas de Codd
En 1970 el modo en que se veían las bases de datos cambió por completo cuando E.
F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente
para la estructura de las bases de datos utilizaba punteros físicos (direcciones de
disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería
relacionar un registro con otro, se debía añadir al registro un campo que contuviera la
dirección en disco del registro. Este campo añadido, un puntero físico, siempre
señalaría desde el registro al registro. Codd demostró que estas bases de datos
limitaban en gran medida los tipos de operaciones que los usuarios podían realizar
sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el
entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los
datos se movían de una localización física a otra, se requería una conversión de los
ficheros de datos. Estos sistemas tenían base en el modelo de red y el modelo
jerárquico, los dos modelos lógicos que constituyeron la primera generación de los
DBMS.
​
El modelo relacional representa la segunda generación de los DBMS. En él, todos los
datos están estructurados a nivel lógico (como tablas formadas por filas y columnas)
aunque a nivel físico pueden tener una estructura completamente distinta. Un punto
fuerte del modelo relacional es la sencillez de su estructura lógica. Sin embargo,
detrás de esa simple estructura hay un fundamento teórico importante del que
carecen los DBMS de la primera generación, lo que constituye otro punto a su favor.
(La Web del Programador, s. f., https://bit.ly/447Ws3u)
Codd se dio cuenta de que existían bases de datos en el mercado que decían ser
relacionales, pero vio que esas bases de datos solo guardaban la información en las tablas,
sin estar estas tablas realmente normalizadas. Entonces, publicó las 12 reglas que un
verdadero sistema relacional debería tener. Ya sabemos que en la práctica es muy difícil que
todas sean aplicadas. Mientras más reglas apliquen a un sistema, más “relacional” podrá
considerarse.
Regla N.o 1 - La regla de la información
Toda la información en un RDBMS está explícitamente representada de una sola
manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe
del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas,
nombres de columnas y los datos de las columnas, debe estar almacenada en tablas
dentro de las bases de datos. Las tablas que contienen tal información constituyen el
diccionario de datos. Esto significa que todo tiene que estar almacenado en las
tablas. Toda la información en una base de datos relacional se representa
explícitamente en el nivel lógico exactamente de una manera: con valores en tablas.
Por tanto, los metadatos (diccionario, catálogo) se representan exactamente igual que
los datos de usuario. Y puede usarse el mismo lenguaje (por ejemplo, SQL) para
acceder a los datos y a los metadatos (regla 4).

Regla N.o 2 - La regla del acceso garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que
combine el nombre de la tabla, su clave primaria y el nombre de la columna. Esto
significa que, dado un nombre de tabla, dado el valor de la clave primaria y dado el
nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por
esta razón, la definición de claves primarias para todas las tablas es prácticamente
obligatoria.

Regla N.o 3 - Tratamiento sistemático de los valores nulos

La información inaplicable o faltante puede ser representada a través de valores
nulos. Un RDBMS (sistema gestor de bases de datos relacionales) debe ser capaz de
soportar el uso de valores nulos en el lugar de columnas cuyos valores sean
desconocidos o inaplicables.
Regla N.o 4 - La regla de la descripción de la base de datos
La descripción de la base de datos es almacenada de la misma manera que los datos
ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios
autorizados. La información de tablas, vistas, permisos de acceso de usuarios
autorizados, etc. debe ser almacenada exactamente de la misma manera: en tablas.
Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias
de SQL (o similar).

Regla N.o 5 - La regla del sublenguaje integral

Debe haber, al menos, un lenguaje que sea integral para soportar la definición de
datos, manipulación de datos, definición de vistas, restricciones de integridad y control
de autorizaciones y transacciones. Esto significa que debe haber, por lo menos, un
lenguaje con una sintaxis bien definida que pueda ser usado para administrar
completamente la base de datos.

Regla N.o 6 - La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables deben ser actualizables por el
mismo sistema. La mayoría de las RDBMS permite actualizar vistas simples, pero
deshabilitan los intentos de actualizar vistas complejas.
Regla N.o 7 - La regla de insertar y actualizar
La capacidad de manejar una base de datos con operandos simples aplica no solo
para la recuperación o consulta de datos, sino también para la inserción, actualización
y borrado de datos. Esto significa que las cláusulas para leer, escribir, eliminar y
agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar
disponibles y operables, independientemente del tipo de relaciones y restricciones que
haya entre las tablas.

Regla N.o 8 - La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de
aplicación debe permanecer consistente lógicamente cuando quiera que haya
cambios en los datos almacenados o sean cambiados los métodos de acceso a los
datos. El comportamiento de los programas de aplicación y de la actividad de usuarios
vía terminales debería ser predecible, basados en la definición lógica de la base de
datos; este comportamiento debería permanecer inalterado, independientemente de
los cambios en la definición física de esta.

Regla N.o 9 - La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben
permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los
permisos asignados) en las tablas de la base de datos. La independencia lógica de los
datos especifica que los programas de aplicación y las actividades de terminal deben
ser independientes de la estructura lógica, por lo tanto, los cambios en la estructura
lógica no deben alterar o modificar estos programas de aplicación.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore ipsum dolor sit
Regla N.o 10 - La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definidas a nivel de datos y
almacenadas a nivel de catálogo, no en el programa de aplicación.

La clave primaria no puede tener valores en blanco o nulos en ninguno de sus

componentes. (Norma básica de integridad).
 Para cada valor de clave foránea es imprescindible que exista un valor de clave
primaria concordante. La combinación de estas reglas asegura la integridad
referencial.

Regla N.o 11 - La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de
datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los
programas de aplicación. El soporte para bases de datos distribuidas significa que una
colección arbitraria de relaciones, bases de datos corriendo en una mezcla de
distintas máquinas y distintos sistemas operativos y que esté conectada por una
variedad de redes pueda funcionar como si estuviera disponible como en una única
base de datos en una sola máquina.

Regla N.o 12 - Regla de la no subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes, de ninguna manera,
pueden ser usados para violar la integridad de las reglas y restricciones expresadas
en un lenguaje de alto nivel (como SQL). Algunos productos solamente construyen
una interfaz relacional para sus bases de datos no relacionales, lo que hace posible la
subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.
(Fabian, 16 de febrero de 2012, https://goo.gl/YURydK)

Dependencia funcional
Las formas normales son sobres que se deben utilizar en el diseño de una base de datos y el
sustento conceptual de la normalización. Actualmente, se encuentran definidas cinco formas
normales mencionadas por su orden, además de una especialización de la tercera forma
normal, denominada forma normal Boyce-Codd. Las formas normales tienen base en los
siguientes conceptos:

Dependencia funcional (DF) y dependencia funcional completa (DFC).

Dependencia multivaluada (DMV).
Dependencia de reunión.

Siendo a y b atributos de una misma relación T, se dice que b es funcionalmente

dependiente de a si, para el mismo valor de a, tiene asociado un único valor de b o, lo
que es lo mismo, en todas las tuplas de T en las que el atributo a toma el mismo valor
v1, el atributo b toma también un mismo valor v2.
 La dependencia funcional se denota T.a → T.b o bien, simplemente, a → b.

Los atributos a y b pueden ser simples o compuestos (formados por la agregación de

varios atributos). Los atributos funcionalmente dependientes pueden o no formar parte
de la clave primaria de la tabla, de una clave candidata o de una clave foránea de otra
tabla.

Claramente, a → b no implica b → a. Pueden repetirse los valores del atributo b para

distintos valores de a. (Universidad Autónoma del Estado de Hidalgo, s. f.,
https://bit.ly/3NTkiuk)
Ejemplo
Tabla 2: Datos de comprobantes

Punto de venta y comprobante Fecha Id cliente Nombre cliente Total

01-100 01/03/17 01 María Paz 55

01-100 01/03/17 01 María Paz 55

02-101 21/03/17 02 Juan Casas 40

01-102 03/04/17 10 Ana Godoy 60

01-102 03/04/17 10 Ana Godoy 60

A B

Fuente: elaboración propia.

Consideremos el ejemplo de una tabla que contiene datos de comprobantes. Podemos

observar claramente que el atributo Nombre cliente depende funcionalmente del Id cliente.
a →b.
Dependencia funcional completa
Dada una relación T, siendo x y z atributos compuestos pertenecientes a T, se dice que z
depende funcionalmente de x de forma completa si z depende de x y no depende de ningún
subconjunto de x. La dependencia funcional se representa como z => x. Si z es un atributo
simple y z → x, entonces la dependencia funcional es, con seguridad, completa.
Dependencia multivaluada
En una relación T, con los atributos a, b y c, existe una dependencia multivaluada de b con
respecto a si los posibles valores de b para un par de valores de a y c dependen únicamente
del valor de a.

Características:

Debemos observar que, para cada atributo de la relación, haya una evidente repetición
de valores que nos haga pensar en redundancia de datos.
La relación debe tener, por lo menos, tres atributos.
Debe observarse que dos de los atributos sean independientes entre sí
funcionalmente.
El tercer atributo establece una dependencia funcional con los otros dos.

Dependencia de reunión
Una relación R satisface la dependencia de reunión (DR)*(A, B, Z) si y solo si R se puede
construir con la reunión de sus proyecciones A, B, Z, siendo A, B, Z subconjuntos de
atributos de R.

Características:

La cantidad de atributos de la entidad es tres o superior a tres.

Todos los atributos de la relación componen la clave primaria.
No debe haber dependencia funcional entre ninguno de sus atributos y tampoco
dependencias multivaluadas no triviales.
La entidad se encuentra en 4F.

Unidad 2. Formas normales

Normalización
Cuando se trabaja sobre la normalización de un modelo para resolver un problema, se está
realizando un análisis de la lógica funcional de este. Esta acción de entender un problema
permite identificar datos con características y propiedades que dan origen y establecen los
atributos. Muchos de estos se encuentran ligados entre sí con determinada dependencia de
funcionamiento.
Los atributos (datos) responden a una mecánica interna de funcionalidad que podríamos
definir como procesos internos. Estos procesos dan el estado de asociación y dependencia
de los atributos y generan cierta definición de cómo se asocian estos entre sí. Las
colecciones de atributos asociados semánticamente con un fin común permiten individualizar
las entidades que conforman la estructura lógica. La aplicación de las formas normales
permite que el entendimiento que se está realizando del problema se represente en un
modelo normalizado de solución.
Terminología

Entidad
Atributo
Instancia
Dominio

Entidad
Se denomina entidad al contenedor de una colección de atributos que se encuentran
fuertemente relacionados entre sí por una interpretación semántica que determina a la
entidad misma. Por ejemplo, si nos encontramos observando una problemática que involucra
personas, terminaremos infiriendo que debemos asociar todas las características o atributos
de las personas en una entidad que las represente.

Una entidad comparte los mismos principios de definición que una relación, pero solo en el
diseño de la estructura, sin hacer énfasis en sus características físicas y de almacenamiento.
Atributo
Se denomina atributo a cada componente de una entidad que califica y establece una
propiedad dentro de ella. En una entidad, los atributos tienen un nombre único y no poseen
un orden específico.
Instancia
Se denomina instancia a una ocurrencia de valores o al conjunto de valores que conforman
un mismo grupo. Una instancia dentro de una entidad encuentra correspondencia con una
tupla dentro de la relación. Las instancias son combinaciones ordenadas de valores
irrepetibles. Una instancia de valores tiene una única posibilidad de existir dentro de la
entidad. Las instancias no tienen orden.
Dominio
El dominio, en el diseño lógico, es la caracterización conceptual del atributo, la definición de
lo que queremos que represente ese atributo al que le estamos asignando el dominio. Esta
definición está ligada al nombre propio del atributo y no al tipo de dato de este. Eso será
motivo de análisis en una instancia posterior del modelo, en el diseño físico. Por ello, se
recomienda establecer un nombre de atributo suficientemente representativo del dominio al
que se quiere asignar, para que esto sea adecuado para su encasillamiento. Por ejemplo, si
para una entidad Personas, establecemos un atributo de nombre Fecha, su contenido puede
ser amplio: fecha de nacimiento, de defunción, de ingreso, casamiento o cualquier otra fecha
que se le pueda atribuir a la persona. Pero si el atributo se denomina Fecha nacimiento, en
él solo se podrá almacenar este concepto.
Formas normales
La dependencia funcional brinda la base conceptual para las siguientes formas normales:

Primera forma normal [1FN o 1NF]

Segunda forma normal [2FN o 2NF]
Tercera forma normal [3FN o 3NF]
Forma normal de Boyce-Codd [FNBC o NFBC]

La dependencia multivaluada solo actúa en la siguiente:

Cuarta forma normal [4FN o 4NF]

La dependencia de reunión solo actúa en la siguiente:

Quinta forma normal [5FN o 5NF]

Si bien las formas normales son seis, los casos más comunes de normalización se suscitan
en el rango que va de la primera forma normal hasta Boyce-Codd.
Tema 1. Primera forma normal
Una relación está en primera forma normal si y solo si todos los dominios simples
subyacentes de los atributos poseen valores atómicos y monovalentes.

Dominios simples de los atributos

Se refiere a que todos los atributos que componen una entidad tienen un único dominio y
que, por ello, este es simple. Los atributos se encuentran reducidos conceptualmente a la
mínima definición de dominio y por eso su expresión no resiste mayor división. Si el dominio
es simple, como mencionamos, sus valores serán atómicos. La expresión atómico no
significa que el contenido no pueda ser compuesto, por ejemplo, el nombre de una persona
(María José), sino que el dominio Nombre no está integrado a otro dominio, como el apellido.
Atributos monovalentes
Hace referencia a que la información se representa una única vez dentro del modelo.
Entonces, se debe arbitrar proyecciones (descomposiciones) de entidades suficientes para
que la información sea reflejada una sola vez.
Explicación desde la práctica
Observamos la siguiente planilla de datos, que consta de un resumen de ventas de una
librería que procesa todos sus datos desde una planilla de cálculos del tipo Excel.
Tomaremos esta tabla y la procesaremos para que se transforme en N relaciones que
cumplan con 1FN.

Tabla 3: Resumen de ventas

Pto. de Fecha Id Nombre Id Forma Id Nombre Precio Cant. Total

venta y cliente cliente pago pago producto producto unitario

comprobante

01-100 01/03/ 01 María 1 Tarjeta 1 Mapa 2,5 10 55

17 Paz

01-100 01/03/ 01 María 1 Tarjeta 2 Hoja 1 30 55

17 Paz

02-101 21/03/ 02 Juan 2 Contado 3 Sobre 4 10 40

17 Casas

01-102 03/04/ 10 Ana 3 Débito 1 Mapa 4,5 10 60

 17 Godoy

01-102 03/04/ 10 Ana 3 Débito 2 Hoja 1,5 10 60

17 Godoy

Fuente: elaboración propia.

Dominios simples de los atributos

Primero, se deben observar los dominios de los atributos y detectar aquellos que no son
dominios simples. Observamos que el dominio de la columna Pto. (punto) de venta y
comprobante está compuesto por dos valores. Este dominio, evidentemente, no es simple.
Los dos valores son el punto de venta y el número de comprobante, respectivamente.

Tabla 4: Identificar los dominios que no son simples

Punto de venta y comprobante

01-100

01-100

02-101

01-102

01-102

Punto de venta Número de comprobante

01 100

01 100

02 101

01 102

01 102

Fuente: elaboración propia.

Para lograr que la columna Punto de venta y comprobante posea dominio simple, se debe
dividir en dos columnas: una para el punto de venta y otra para el número de comprobante.

Tabla 5: 1FN aplicada (dominio simple de los atributos)

Pto. N.° de Fecha Id Nombre Id Forma Id Nombre Precio Cant. Total

de comprobante cliente cliente pago pago producto producto /

venta unidad

01 100 01/03/ 01 María 1 Tarjeta 1 Mapa 2,5 10 55

17 Paz

01 100 01/03/ 01 María 1 Tarjeta 2 Hoja 1 30 55

17 Paz

02 101 21/03/ 02 Juan 2 Contad 3 Sobre 4 10 40

17 Casas o

01 102 03/04/ 10 Ana 3 Débito 1 Mapa 4,5 10 60

17 Godoy

01 102 03/04/ 10 Ana 3 Débito 2 Hoja 1,5 10 60

17 Godoy

Fuente: elaboración propia.

Atributos monovalentes
Ahora, deberíamos fijar nuestra atención en el concepto de atributos monovalentes.
Todavía no puede ser denominada relación, pues sigue sin respetar algunas restricciones
necesarias para serlo. Otra forma de expresarlo sería evitar los grupos repetitivos, para que
la información se encuentre expresada una sola vez.

Tabla 6: Identificando grupos repetitivos

Pto. N ° de Fecha Id Nombre Id Forma Id Nombre Precio/ Cant. Total

de comprobante cliente cliente pa- pago Producto producto unidad

venta go
 01 100 01/03/ 01 María 1 Tarjeta 1 Mapa 2,5 10 55

17 Paz

01 100 01/03/ 01 María 1 Tarjeta 2 Hoja 1 30 55

17 Paz

02 101 21/03/ 02 Juan 2 Contado 3 Sobre 4 10 40

17 Casas

01 102 03/04/ 10 Ana 3 Débito 1 Mapa 4,5 10 60

17 Godoy

01 102 03/04/ 10 Ana 3 Débito 2 Hoja 1,5 10 60

17 Godoy

Fuente: elaboración propia.

Observen que para los comprobantes 100 y 102 se repiten datos. Esto es porque, en ambos
casos, hay dos productos detallados. Estos valores repetidos no respetan la definición de
monovalentes, por lo tanto, se debe operar algún cambio para que los valores se presenten
una sola vez. Las columnas que contienen valores repetidos son las resaltadas con fondo
amarillo. La acción que se debe aplicar es la separación de las columnas que contienen el
grupo repetitivo en una tabla y las columnas que no contienen el grupo repetitivo en otra
tabla.

Tabla 7: Comprobantes con datos repetitivos

Punto de Número de Fecha Id Nombre Id Forma Total

venta comprobante cliente cliente pago pago

01 100 01/03/17 01 María Paz 1 Tarjeta 55

01 100 01/03/17 01 María Paz 1 Tarjeta 55

02 101 21/03/17 02 Juan Casas 2 Contado 40

01 102 03/04/17 10 Ana Godoy 3 Débito 60

01 102 03/04/17 10 Ana Godoy 3 Débito 60

Fuente: elaboración propia.

Tabla 8: Detalle de comprobantes sin datos repetitivos

Id producto Nombre producto Precio unitario Cantidad

1 Mapa 2,5 10

2 Hoja 1 30

3 Sobre 4 10

1 Mapa 4,5 10

2 Hoja 1,5 10

Fuente: elaboración propia.

Identificando claves primarias y foráneas

Ahora que tenemos dos tablas, deberíamos nombrarlas para poder individualizarlas. Cuando
las mencionemos, simplemente, diremos Comprobantes o Detalle comprobantes. Observen
que tenemos dos tablas, pero no queda establecido en Detalle comprobantes.
¿Qué detalle corresponde para cada comprobante?
También, siguen duplicadas las filas en la tabla Comprobantes. La forma que tenemos para
relacionar Detalle comprobantes con Comprobantes es estableciendo una clave foránea en
Detalle comprobantes que apunte a Comprobantes. Para crear la FK en Detalle de
comprobantes, primero, debemos tener declarada una clave primaria en Comprobantes.
Para ello, en los comprobantes no debe haber filas duplicadas. Eliminemos las filas
duplicadas de Comprobantes para poder declarar la PK.

Tabla 9: Comprobantes sin datos repetitivos y establecimiento de clave primaria

PK

Punto de Número de Fecha Id Nombre Id Forma Total

venta comprobante cliente cliente pago pago

01 100 01/03/17 01 María Paz 1 Tarjeta 55

02 101 21/03/17 02 Juan 2 Contado 40

Casas
 01 102 03/04/17 10 Ana 3 Débito 60

Godoy

Fuente: elaboración propia.

Aquí ya está la tabla de comprobantes sin filas duplicadas. Para establecer la PK, se debe
elegir la mínima combinación irrepetible de valores que garanticen la unicidad. Los atributos
de Punto de venta y Número de comprobante proporcionan esa condición de unicidad;
entonces, serán la PK de Comprobantes.

Al tener definida la PK de Comprobantes, ya podemos establecer la FK en Detalle

comprobantes. La FK en Detalle de comprobantes tiene que ser una estructura del mismo
tipo que la PK de Comprobantes.

Tabla 10: Detalle de comprobantes sin datos repetitivos y establecimiento de clave

foránea

Punto de venta Número de comprobante Id producto Nombre producto Precio unitario Cantidad

01 100 1 Mapa 2,5 10

01 100 2 Hoja 1 30

02 101 3 Sobre 4 10

01 102 1 Mapa 4,5 10

01 102 2 Hoja 1,5 10

FK

Fuente: elaboración propia.

FK establecida, redundancia controlada. Ya tenemos establecida la relación entre ambas

relaciones (dejaron de ser tablas). Lo único que falta es definir la PK de Detalle
comprobantes. Debemos establecer una combinación irrepetible de valores de atributos que
permita identificar en forma inequívoca cada tupla de la relación Detalle comprobantes. La
combinación resaltada tiene características de unicidad. Esta será la PK de Detalle
comprobante.
Tabla 11: Detalle de comprobantes y establecimiento de clave primaria

PK

Punto de venta Número de comprobante Id producto Nombre producto Precio unitario Cantidad

01 100 1 Mapa 2,5 10

01 100 2 Hoja 1 30

02 101 3 Sobre 4 10

01 102 1 Mapa 4,5 10

01 102 2 Hoja 1,5 10

FK

Fuente: elaboración propia.

Tabla 12: Definición del modelo en 1FN

COMPROBANTES DETALLE COMPROBANTES

PK Punto de Venta PK PK Punto de venta FK

Comprobante Comprobante

Fecha Id producto

Id cliente Nombre producto

Nombre cliente Precio unitario

Id pago Cantidad

Forma pago

Fuente: elaboración propia.

Tema 2. Segunda forma normal

Una relación está en segunda forma normal si y solo si, primero, está en primera forma
normal y, además, todos los atributos no claves dependen por completo de la clave primaria.
Es muy importante tener en claro que no se puede alcanzar la 2FN si alguna relación del
modelo no está en 1FN.

Cuando hacemos referencia a que todos los atributos no claves dependen por completo de
la clave primaria, es importante entender que la expresión “atributos no claves” está utilizada
en su más amplio espectro. Entonces, los atributos no tienen que pertenecer ni a la clave
primaria ni a ninguna clave candidata que pueda existir. Expresar atributos no claves
equivale a decir atributos no primarios. Los atributos no claves deben depender por
completo de la PK. Esto no se cumple cuando hay atributos no claves que dependen de una
parte de la clave. Esta, entonces, indudablemente, debe ser compuesta. Si la clave fuese
simple, no hay posibilidad de encontrar esta situación.

Explicación desde la práctica

Debemos encontrar un atributo que dependa de una parte de la PK y no de la PK completa.
Observen el atributo Nombre producto de la relación Detalle comprobantes. Este atributo
tiene una fuerte dependencia con el Id producto, pues al cambiar el código, necesariamente,
debemos cambiar el nombre. Para quebrar esa fuerte dependencia entre los atributos
destacados, se debe descomponer la relación al sacar los atributos que dependen de Id
producto a otra relación.

Tabla 13: Identificando atributos no claves que dependen de una parte de la clave
primaria

PK

Punto de venta Número de comprobante Id producto Nombre producto Precio unitario Cantidad

01 100 1 Mapa 2,5 10

01 100 2 Hoja 1 30

02 101 3 Sobre 4 10

01 102 1 Mapa 4,5 10

01 102 2 Hoja 1,5 10

 FK

Fuente: elaboración propia.

Se deben despejar los atributos que dependen funcionalmente de Id producto a una nueva
relación que los contenga. Para ello, la nueva relación (que llamaremos Productos) debe
tener los mismos atributos que se encuentran resaltados en la relación Detalle
comprobantes.

Ahora, debemos retirar los atributos de la relación Detalle comprobante que causan que la
2FN no se cumpla y declarar la PK en la relación Productos.

Observen que el precio sigue estando en Detalle comprobantes. Esto es porque este atributo
representa el valor en el momento en que se realizó la compra. Observen que la clave
foránea que vincula Detalle comprobantes con Productos ya se encuentra declarada. Esto
hace que ambas tablas mantengan una relación denominada integridad referencial.

Tabla 14: Relación Detalle de comprobantes en 2FN

PK

Punto de venta Número de comprobante Id producto Precio unitario Cantidad

01 100 1 2,5 10

01 100 2 1 30

02 101 3 4 10

01 102 1 4,5 10

01 102 2 1,5 10

FK FK

Fuente: elaboración propia.

Tabla 15: Relación Productos en 2FN

PK

Id producto Nombre producto Precio unitario

 3 Sobre 4

1 Mapa 4,5

2 Hoja 1,5

Fuente: elaboración propia.

Definición de modelo en 2FN

Tabla 16: Definición del modelo en 2FN

COMPROBANTES DETALLE COMPROBANTES PRODUCTOS

PK Punto de venta PK PK Punto de venta FK PK Id PK

producto

Comprobante Comprobante Nombre producto

Fecha Id producto Precio unitario

Id cliente Nombre producto

Nombre cliente Precio unitario

Id pago Cantidad

Forma pago

Fuente: elaboración propia.

Tema 3. Tercera forma normal y forma de Boyce-Codd

Una relación está en tercera forma normal si y solo si está en 2FN y si ningún subconjunto
de atributos no primarios tiene dependencia entre sí y, como segunda medida, dependen
transitivamente de la clave primaria.
Atributos no primarios: es atributo no clave, que no forma parte de ninguna
combinación de claves candidatas posibles.
La dependencia transitiva ocurre cuando dos atributos no primarios que, por lo tanto, no
forman parte de ningún tipo de clave, tienen una dependencia funcional entre sí más fuerte
que la que se produce con la PK de la relación. Entonces, dependen entre sí uno del otro y,
por ende, dependen transitivamente de la PK.
Explicación desde la práctica
Tenemos que observar dos o más atributos no claves (no primarios) que tengan una
dependencia funcional entre sí, más fuerte que la que poseen con la PK de la relación. Esta
situación solo se presenta en la relación Comprobantes, entre los atributos Id cliente y
Nombre cliente, por un lado, e Id pago y Forma pago, por otro.

Ambos atributos dependen uno del otro y no forman parte de ninguna clave.

Tabla 17: Relación Comprobantes - Identificando atributos no primarios con

dependencia entre sí
PK

Punto de Número de Fecha Id Nombre Id Forma Total

venta comprobante cliente cliente pago pago

01 100 01/03/17 01 María Paz 1 Tarjeta 55

02 101 21/03/17 02 Juan Casas 2 Contad o 40

01 102 03/04/17 10 Ana Godoy 3 Débito 60

Fuente: elaboración propia.

Se deben desagregar de esta relación los atributos que causan que no se alcance la 3FN.
Para ello, se deben crear dos relaciones en donde se coloquen los juegos de atributos que
tienen DF. Estos dos atributos tienen DF entre sí y luego dependen en forma transitiva de la
PK. Declaramos la PK de las nuevas relaciones para poder establecer las FK desde la
relación que estamos analizando. Entre estos otros dos también existe la misma situación.
Ahora debemos eliminar las columnas Nombre cliente y Forma pago y establecer las FK
para que la información quede integrada.

Tabla 18: Relación Comprobantes - Identificando atributos no primarios con

dependencia entre sí
PK

Punto de Número de Fecha Id Id Total

venta comprobante cliente pago

01 100 01/03/17 01 1 55
 02 101 21/03/17 02 2 40

01 102 03/04/17 10 3 60

FK FK

Fuente: elaboración propia.

Tabla 19: Relación Clientes

PK

Id cliente Nombre cliente

01 María Paz

02 Juan Casas

10 Ana Godoy

Fuente: elaboración propia.

Tabla 20: Relación Forma de pagos

PK

Id pago Forma pago

1 Tarjeta

2 Contado

3 Débito

Fuente: elaboración propia.

Tabla 21: Definición del modelo en 3FN

COMPROBANTES DETALLE COMPROBANTES PRODUCTOS

PK Punto PK PK Punto de FK PK Id producto PK

de venta venta

Comprobante Comprobante Nombre

producto

Fecha Id producto Precio

unitario

Id cliente Nombre producto

Nombre Precio

cliente unitario

Id pago Cantidad

Forma pago
Fuente: elaboración propia.
Forma normal de Boyce-Codd
Determinante: uno o más atributos son determinantes cuando, de manera funcional,
determinan a otro(s) atributo(s). En la dependencia funcional (A, B)-->C, (A, B) son los
determinantes.

Definición formal: cuando un determinante es una llave candidata, una relación R está en
FNBC. Una tabla se considera en esta forma si y solo si cada determinante o atributo es una
llave candidata.
Tema 4. Cuarta forma normal
La 4NF es muy usada en el diseño de base de datos y garantiza que las dependencias
multivaluadas independientes estén efectivamente correctas. La 4NF es el nivel siguiente de
normalización después de la forma normal de Boyce-Codd.

Características
Una tabla se encuentra en 4NF si y solo si está en tercera forma normal y no presenta
dependencias multivaluadas no triviales.
Explicación desde la práctica
Supongamos que poseemos una tabla con clientes.

Tabla 22: Relación Clientes

PK

Id cliente Nombre cliente Teléfono Correo electrónico

01 María Paz 156145579 [email protected]

02 Juan Casas 153467367 [email protected]

10 Ana Godoy 155908786 [email protected]

Fuente: elaboración propia.

¿Qué sucede si el cliente tiene más de un teléfono o dirección de correo electrónico?

Podríamos tener una tabla como la siguiente:

Tabla 23: Relación Clientes con más de un teléfono

PK

Id cliente Nombre cliente Teléfono Correo electrónico

01 María Paz 156145579 – 4895233 [email protected]

 02 Juan Casas 153467367 [email protected]

10 Ana Godoy 155908786 [email protected] –

[email protected]

Fuente: elaboración propia.

Como podemos observar, en este caso, se rompen las reglas de la normalización, desde la
FN1 que indica que los campos deben ser atómicos. Una solución podría ser repetir las filas,
como se muestra en la tabla 23.

Tabla 24: Relación Clientes con más de un teléfono

PK

Id cliente Nombre cliente Teléfono Correo electrónico

01 María Paz 156145579 [email protected]

01 María Paz 4895233 [email protected]

02 Juan Casas 153467367 [email protected]

10 Ana Godoy 155908786 [email protected]

10 Ana Godoy 155908786 [email protected]

Fuente: elaboración propia.

Sin embargo, en este caso, si bien logramos la atomicidad de los campos, estamos
rompiendo con otra FN, ya que estamos repitiendo los datos de Id cliente, Nombre cliente y
Teléfono o Correo electrónico, según corresponda. Lo que podemos observar es que tanto el
teléfono como el correo son de dependencias multivaluadas con clientes, lo que nos lleva a
una FN4 en la cual se eliminan las dependencias multivaluadas.

Tabla 25: Relación Clientes

PK

Id cliente Nombre cliente Teléfono Correo electrónico

01 María Paz 156145579 [email protected]

01 María Paz 4895233 [email protected]

02 Juan Casas 153467367 [email protected]

10 Ana Godoy 155908786 [email protected]

10 Ana Godoy 155908786 [email protected]

Fuente: elaboración propia.

Tabla 26: Relación Clientes y teléfono

PK

Id cliente Teléfono

01 156145579

01 4895233

02 153467367

10 155908786

10 155908786

Fuente: elaboración propia.

Tabla 27: Relación Clientes y correo electrónico

PK

Id cliente Correo electrónico

01 [email protected]

01 [email protected]

02 [email protected]

10 [email protected]

10 [email protected]

Fuente: elaboración propia.

¿Cuántas formas normales existen y qué características poseen?

Existen 3 formas normales y son superficiales, es decir, es necesario estar en la

superficie.

Existen 6 formas normales y son exclusivas, es decir, es necesario no estar en

la forma normal anterior, para considerarse de la siguiente.

Existen 4 formas normales y son inclusivas, es decir, la siguiente forma incluye

a la anterior.

Video de habilidades
Texto explicativo:

Es importante saber normalizar nuestros modelos de datos. En este módulo lo que

buscamos es poder saber cómo separar y organizar los datos en tablas con atributos y que
esté dicho modelo que se plantea cumpla (al menos con la tercera forma normal) con lo
estipulado. En el video vemos con desde el ejemplo de pedido proveedor y producto
llegamos a armar el DER.

La normalización permite obtener estructuras de datos ineficientes.

Verdadero

Falso

Justificación

¿Cuál de las formas normales dice que un registro no puede contener

grupos de datos repetitivos?

FN1

FN2

FN3

FN4

Forma normal de Boyce-Codd

Justificación

Si una relación está en FN1 y no tiene claves compuestas quiere decir

que también está en:

FN1

FN2

FN3
 FN4

Forma normal de Boyce-Codd

Justificación

En la FN3 los atributos deben depender solo de la clave y de ningún

otro atributo de la relación.

Verdadero

Falso

Justificación

Cuando una entidad tiene clave compuesta indica que existe una
relación de muchos a muchos.

Verdadero

Falso

Justificación

Microactividades
Para realizar los ejercicios, recordemos leer el Manual de uso de PostgreSQL:

Al final de este apartado, encontraremos un archivo descargable con las respuestas de cada
ejercicio. Estas respuestas servirán como guía para que revisemos si realizamos
correctamente los ejercicios.
Requerimientos
Utilización de la plataforma PostgreSQL.

Enunciados
Ejercicio 2.1

Será nuestra tarea identificar las entidades y sus atributos y nombrarlos siempre en
minúsculas.

Ejercicio 2.2

Creemos las tablas de las entidades encontradas. Ya sabemos que el año de cursado se
representa como un número entero, el nombre de las materias nunca excede los 30
caracteres, el nombre, apellido y e-mail no tendrán más de 50 caracteres y el DNI se
considera como cadena de caracteres. Y que, además, ningún atributo de las entidades
admite valor nulo y se utilizará como clave primaria en cada tabla un entero autoincremental.

Ejercicio 2.3

Será nuestra tarea encontrar la o las relaciones entre tablas. De ser necesario, creemos su
estructura.

Ejercicio 2.4

Agreguemos los datos de alumnos y materias para conseguir la siguiente estructura:

Alumnos

Tabla 28. Alumnos

Fuente: elaboración propia

Materias

Tabla 29. Materias

Fuente: elaboración propia

Ejercicio 2.5

Inscribamos a los alumnos en las materias para obtener la siguiente estructura:

Tabla 30. Alumno/materia

Fuente: elaboración propia

Ejemplo de resolución

Glosario
Referencias
AIU Universidad en Línea. (s. f.). Modelos de datos.
https://www.aiu.edu/cursos/base%20de%20datos/pdf%20leccion%202/lecci%C3%B3n%202.
pdf

Atlantic International University. (s. f.). Modelo entidad relación.

https://cursos.aiu.edu/Base%20de%20Datos/pdf/Tema%203.pdf

Braghetto, K. (2017). Introducción a los sistemas de bases de datos.

https://paca.ime.usp.br/pluginfile.php/128755/mod_resource/content/1/mac313_aula2.pdf

Campus MVP. (s. f.). Diseñando una base de datos en el modelo relacional.
https://www.campusmvp.es/recursos/post/Disenando-una-base-de-datos-en-el-modelo-
relacional.aspx
Costal Costa, D. (2017). Introducción al diseño de bases de datos.
https://pdfslide.net/documents/dolors-costal-costa-introduccion-al-diseno-de-bases-de-
datospdf.html

Fabian. (16 de febrero de 2012). Normalización.

http://fabian8a.blogspot.com/2012/02/normalizacion_16.html
Giraudo, P. (20 de agosto de 2012). Modelos de bases de datos.
https://cursoprogramador.wordpress.com/2012/08/20/modelos-de-bases-de-datos/

Guerrero, L. (s. f.). Modelo entidad relación.

https://users.dcc.uchile.cl/~nbaloian/cc20a/post/e-
r.html#:~:text=En%20nuestro%20ejemplo%20de%20la,%2C%20un%20cupo%20m%C3%A1
ximo%2C%20etc.

La Web del Programador. (s. f.). Definición de modelo relacional.

https://www.lawebdelprogramador.com/diccionario/Modelo-Relacional/

Millán, M. (2012). Fundamentos de bases de datos. Programa Editorial.

Universidad Autónoma del Estado de Hidalgo. (s. f.). Dependencias funcionales.

http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro14/413_dependencias_funcionales.
html