Módulo 2.

Base de datos y modelo relacional

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.

Creemos las entidades, atributos y relaciones de nuestra base de datos

Unidad 2.1. Sistemas de bases de datos y modelos

Unidad 2.2. Formas normales

Video de habilidades

¡Vamos a practicar!
Cierre

Referencias

Descargá la lectura
Lección 1 de 8

Creemos las entidades, atributos y relaciones de

nuestra base de datos

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

C O NT I NU A R
Lección 2 de 8

Unidad 2.1. Sistemas de bases de datos y

modelos

Video de inmersión

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

2.1.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 dichos datos.

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”.
Sistema de gestión de base de datos

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

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.
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.

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) se afecte. El nivel interno describe la forma sobre como
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). 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: [Imagen sin título sobre arquitectura funcional en una base de datos]. (s.f.)

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, y 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:

1 Calidad: la información proporcionada debe ser fidedigna y no

debe contener errores de procesamiento.
 2 Oportuna: la información debe estar disponible, en el momento
preciso que se la necesita.

3 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.

4 Relevante: la información brindada debe estar relacionada con

sus tareas y responsabilidades.

Componentes de un DBMS

Detallamos a continuación los componentes de un DBMS y su definición:

Tabla 1. Componentes de un DBMS

Componente Definición

Procesa las definiciones de los esquemas y

Compilador DDL almacena las descripciones de los
esquemas en el catálogo.

Analiza las consultas sintácticamente,

Compilador de
nombres de elementos y objetos. Traduce a
consultas
formato interno.
 Componente Definición

Reconfigura, reordena, elimina

Optimizador de redundancias y usa algoritmos e
consultas indicaciones para mejorar la ejecución de
la consulta. Genera código ejecutable.

Extrae los comandos DML y los envía al

Precompilador DML compilador DML. Envía el resto del
programa al compilador del lenguaje host.

Compila y genera código objeto que le pasa

Compilador DML
al procesador de DB runtime.

Compilador de lenguaje Compila el programa y lo prepara para

host enlazar la transacción.

Recibe comandos y los ejecuta, accede al

diccionario de datos y se comunica con el
Procesador de BD
sistema operativo (SO) para E/S.
runtime
Administra el buffer en la memoria de
procesamiento, compartida o no con SO.

Subsistema de control Subfunción del procesador de BD para

de concurrencia colaborar con el control de concurrencia.

Funciona con el procesador de BD para

Administración de datos
poder comunicarse con el SO y realizar
almacenados
E/S.
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 de un DBMS

Fuente: [Imagen sin título sobre componentes DBMS]. (s.f.).

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

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

de cuentas y contraseñas.
 2 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.

3 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 grantoption.

Retiro de privilegios revoke.

Asignación 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 del 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 base

en unidades de cambio relativamente grandes (bloques de 8Ks,
4Ks, 1K).

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 se realiza de acuerdo con
la técnica de backup que se haya implementado.

Tener copias de los datos originales no posee importancia.

Verdadero.

Falso.

SUBMIT

2.1.2 Modelos jerárquico, de red y relacional

Verify to continue
 We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

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: localizar un registor por condición y ubicar el puntero.

Get: 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: [Imagen sin título sobre modelo de red]. (s.f.).

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:

Localiza y copia registro a

Get/Where
memoria.

Se localiza a su registro
Insert
padre y luego inserta.
 Modifica uno o más campos
Replace
de un registro.

Elimina el registro actual de la

Delete
base de datos.

Figura 4. Modelo jerárquico

 Fuente: [Imagen sin título sobre modelo jerárquico]. (s.f.).

Modelo relacional

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

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:

1 un conjunto de relaciones que varía en el tiempo,

2 reglas de inserción-actualización-eliminación, y

3 un álgebra relacional.

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).

2.1.3 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 (Costal Costa, 2017).

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.

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.

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.

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

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms
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:

identificar las entidades;

identificar las relaciones;

identificar los atributos y asociarlos a entidades y relaciones;

determinar los dominios de los atributos;

determinar los identificadores;

determinar las jerarquías de generalización (si las hay);

dibujar el diagrama entidad-relación; y

 revisar el esquema conceptual local con el usuario.

Hacé clic en este botón para realizar ahora los ejercicios 2.1 y 2.2

¡A PRACTICAR!

El modelo entidad-relación (E/R) tiene base en una representación del

mundo real en 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”. 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: [Imagen sin título sobre modelo entidad-relación]. (s.f.).

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, complete las siguientes oraciones.

“Las ……… representan entidades del mundo real”

Escriba su respuesta aquí

SUBMIT

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

Escriba su respuesta aquí

SUBMIT

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

 Escriba su respuesta aquí

SUBMIT

2.1.4. 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.

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°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 deben estar almacenados 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 (ej. SQL) para acceder a los datos y a los metadatos (regla 4).

Regla N°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°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°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°5 - La regla del sub-lenguaje 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°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°7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples

aplica no sólo 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°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, y este comportamiento debería permanecer inalterado,
independientemente de los cambios en la definición física de esta.

Regla N°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.

Regla N°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 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. (Fabián, 16 de febrero de 2012,
recuperado de https://goo.gl/YURydK)

Regla N°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.

R l N°12 R l d l b ió
 Regla N°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
(Reglas de Codd, s.f, https://bit.ly/2VaHARB).

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, 2017, https://bit.ly/3esioP3).

Veamos un ejemplo.

Tabla 2. Datos de comprobantes

Punto de
venta y Nombre
Fecha Id cliente Total
comproba cliente
nte
 Punto de
venta y Nombre
Fecha Id cliente Total
comproba cliente
nte

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

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

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

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 4FN.

C O NT I NU A R
Lección 3 de 8

Unidad 2.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 se encuentra
observando una problemática que involucra personas, terminará infiriendo
que debe 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 o 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 o1NF]

Segunda forma normal [2FN o2NF]

Tercera forma normal [3FN o3NF]

Forma normal de Boyce-Codd [FNBC oNFBC]

La dependencia multivaluada solo actúa en la siguiente:

Cuarta forma normal [4FN o 4NF]

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
 reCAPTCHA
Privacy - Terms

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.

2.2.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 deben arbitrar proyecciones (descomposiciones) de
entidades suficientes para que la información sea reflejada una sola vez.

Explicación desde la práctica

Observe 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

 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. Observe 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 Número de

Punto de venta
comprobante comprobante

01-100 01 100
 Punto de venta y Número de
Punto de venta
comprobante comprobante

01-100 01 100

02-101 02 101

01-102 01 102

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)

 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

Fuente: elaboración propia.

Observe 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

Pto.
Id Nombr
de N° de Fec Id Forma Tot
client e
vent comprobante ha pago pago al
e cliente
a

01/0 María
01 100 01 1 Tarjeta 55
3/17 Paz

01/0 María
01 100 01 1 Tarjeta 55
3/17 Paz

21/0 Juan Contad

02 101 02 2 40
3/17 Casas o

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

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

Fuente: elaboración propia.

Tabla 8. Detalle de comprobantes sin datos repetitivos

 Precio
Id producto Nombre producto Cantidad
unitario

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. Observe 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 los comprobantes. Para
ello, en 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

Pto.
N° de Id Nombr Id
de Forma
comproban Fecha client e pag Total
vent pago
te e cliente o
a

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

21/03/1 Juan Contad

02 101 02 2 40
7 Casas o

03/04/1 Ana
01 102 10 3 Débito 60
7 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
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

Pto.
N° de Id Nombre Precio
de Cantida
comprobant product product unitari
vent d
e o o o
a

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

Pto.
N° de Id Nombre Precio
de Cantida
comprobant product product unitari
vent d
e o o o
a

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

 PK

FK

Fuente: elaboración propia.

Tabla 12. Definición del modelo en 1FN

Fuente: elaboración propia.

2.2.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á expresada en su más amplio espectro. Entonces,
los atributos tienen que no 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. Está, 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. Observe 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 debe 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

Pto.
N° de Id Nombre Precio
de Cantida
comprobant product product unitari
vent d
e o o o
a

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 las 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.
Observe 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. Observe 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

Pto.
N° de Precio
de Id producto Cantidad
comprobante unitario
venta

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

Nombre
Id producto Precio unitario
producto

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 de modelo en 2FN

 Fuente: elaboración propia.

2.2.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 si más fuerte que la que posee 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

For
Punto N° de Nombr Id
Id ma Tota
de comproban Fecha e pa
cliente pag l
venta te cliente go
o

01/03/1 María Tarj

01 100 01 1 55
7 Paz eta
 PK

21/03/1 Juan Con

02 101 02 2 40
7 Casas tado

03/04/1 Ana Débi

01 102 10 3 60
7 Godoy to

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
colocan los juegos de atributos que tienen DF. Estos dos atributos tienen DF
entre sí y luego dependen en forma transitiva de la PK. Declare 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 debe 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 no primarios con

dependencia entre sí

PK

Id Id
Punto de Tota
N° de comprobante Fecha clie pag
venta l
nte o

01 100 01/03/17 01 1 55
 PK

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

 PK

1 Tarjeta

2 Contado

3 Débito

Fuente: elaboración propia.

Tabla 21. Definición del modelo en 3FN

Fuente: elaboración propia.

Forma normal de BoyceCodd

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.

2.2.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

Margaret S. Wu (1992) notó que, en la práctica, la normalización de base de
datos generalmente solo alcanza hasta la 3FN. Esto se debe a la creencia
de que las tablas violan la 4FN y que raramente las vamos a encontrar en
aplicaciones organizacionales. Pese a esto, esta creencia puede no ser
exacta.

Supongamos que poseemos una tabla con clientes.

Tabla 22. Relación clientes

PK

Nombre Correo
Id cliente Teléfono
cliente electrónico

mpaz@gmail.c
01 María Paz 156145579
om

jcasas@hotma
02 Juan Casas 153467367
il.com

anag@gmail.c
10 Ana Godoy 155908786
om

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

Nombre Correo
Id cliente Teléfono
cliente electrónico

156145579 - mpaz@gmail.c
01 María Paz
4895233 om

jcasas@hotma
02 Juan Casas 153467367
il.com

anag@gmail.c
om -
10 Ana Godoy 155908786
ana.godoy@g
mail.com

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
 PK

Nombre Correo
Id cliente Teléfono
cliente electrónico

mpaz@gmail.c
01 María Paz 156145579
om

mpaz@gmail.c
01 María Paz 4895233
om

jcasas@hotma
02 Juan Casas 153467367
il.com

anag@gmail.c
10 Ana Godoy 155908786
om

ana.godoy@g
10 Ana Godoy 155908786
mail.com

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

Nombre Correo
Id cliente Teléfono
cliente electrónico

mpaz@gmail.c
01 María Paz 156145579
om

mpaz@gmail.c
01 María Paz 4895233
om

jcasas@hotma
02 Juan Casas 153467367
il.com

anag@gmail.c
10 Ana Godoy 155908786
om

ana.godoy@g
10 Ana Godoy 155908786
mail.com

Fuente: elaboración propia.

Tabla 26. Relación clientes y teléfono

PK

Id cliente Teléfono
 PK

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 mpaz@gmail.com

01 mpaz@gmail.com

02 jcasas@hotmail.com

10 anag@gmail.com
 PK

10 ana.godoy@gmail.com

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.

SUBMIT

Hacé clic en este botón para realizar ahora los ejercicios 2.3, 2.4 y 2.5

¡A PRACTICAR!
C O NT I NU A R
Lección 4 de 8

Video de habilidades

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 este modelo que se plantea cumpla al menos con
la tercera forma normal, que es hasta donde llegan la mayoría de los
diagramas entidad relación.

En el video vemos con desde el ejemplo de pedido proveedor y producto

llegamos a armar el DER.

Video 1. Ejemplo de normalización

EJEMPLO DE NORMALIZACION
Fuente: Malvarezrc (s.f.). Ejemplo de normalización. [Video de YouTube]. Recuperado de

https://www.youtube.com/watch?v=-HajWU4pDLM

1. La normalización permite obtener estructuras de datos ineficientes.

Verdadero.

Falso.

SUBMIT

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

grupo de datos repetitivos?

FN1.
 FN2.

FN3.

FN4.

Forma normal de Boyce-Codd.

SUBMIT

3. 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.

SUBMIT

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

atributo de la relación.

Verdadero.

Falso.

SUBMIT

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

Falso.

SUBMIT

C O NT I NU A R
Lección 5 de 8

¡Vamos a practicar!

Para realizar estas actividades deberás utilizar el programa pgAdmin, previamente descargado en el
Módulo 1. De esta forma, podrás acceder a los ejercicios indiferentemente, ya sea que cierres o reinicies
el programa en tu computadora.

Si no podés descargar pgAdmin, utilizá la herramienta online. Recordá que, en esta herramienta,
deberás guardar las consultas que vayas realizando en tu computadora, tal y como se indica en el
Manual de Uso. De esta manera, podrás avanzar en los próximos ejercicios sin necesidad de volver a
escribirlas una a una nuevamente.

Para realizar los ejercicios, recordá leer el Manual de uso de PostgreSQL:

Manual PostgreSQL.pdf
311.8 KB

Al final de este apartado, encontrarás un archivo descargable con las

respuestas de cada ejercicio. Esas respuestas te van a servir como guía,
para que revises si realizaste correctamente los ejercicios.
Introducción
Si utilizás pgAdmin, todas las tablas, datos, funciones, procedimientos
almacenados y triggers, serán guardados en tu computadora. De esta
forma, podrás acceder a ellos, indiferentemente si cerrás el programa o
reiniciás tu sistema.

Si no puedes usar pgAdmin, utilizá la herramienta online. En este

caso, deberás guardar las consultas que vayas realizando. Esto sucede
porque al cerrar el navegador se perderán todos los datos y se deberán
copiar, pegar y ejecutar las consultas que ya habías ejecutado. De tal
manera, podrás avanzar en los próximos ejercicios sin necesidad de volver
a escribirlas una a una nuevamente.

Situación
En el recorrido de todos los ejercicios vas a tener que crear y trabajar sobre
un sistema para una universidad.

Desde la universidad Puls-ar te solicitan llevar el registro de los alumnos y

las materias que ellos cursan. Cuando los alumnos se inscriben se les pide
su DNI, nombre, apellido e e-mail.

Dados de alta en la universidad, ellos ya están en condiciones de anotarse a

las materias disponibles, teniendo en cuenta que las materias tienen un
nombre y un año de cursado.
Requerimientos
Utilización de la plataforma PostgreSQL.

Enunciados

Ejercicio 2.1
Será tu tarea identificar las entidades y sus atributos, y nombrarlos siempre
en minúsculas.

Ejercicio 2.2
Creá las tablas de las entidades encontradas. Ya sabés 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 e 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á tu tarea encontrar la o las relaciones entre tablas. De ser necesario,
creá su estructura.
Ejercicio 2.4
Agregá los datos de alumnos y materias para conseguir la siguiente
estructura:

Alumnos

Tabla 1. Alumnos

Fuente: elaboración propia

Tabla 2. Materias

Fuente: elaboración propia

Ejercicio 2.5
Inscribí a los alumnos en las materias para obtener la siguiente estructura:

Tabla 3. Alumno/materia
Fuente: elaboración propia

Ejemplo de resolución - M2. pdf.pdf

35 KB
C O NT I NU A R
Lección 6 de 8

Cierre

Para finalizar este módulo, repasemos los conceptos más importantes.

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 dichos datos.
Rol del DBA
–

Definir estructuras. Esto es, la creación de la base de datos. Tablas y

sus relaciones.

Definir estructuras físicas, es decir, que 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 rendimiento, con el objetivo de optimizar consultas y el

acceso a los datos, para mejorar la experiencia del usuario final.

Modelos jerárquico, de red y relacional

–

Modelo de red: los datos son representados como colección de

registros, de estructura arbitraria. Las relaciones entre estos son
punteros o enlaces y permiten relaciones uno a muchos y muchos a
muchos.

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.
 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).

FN1
–
Dice que 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.

FN2
–
Dice que debe estar en FN1 y además, todos los atributos no claves
dependen por completo de la clave primaria o está en FN1 y no tiene clave
compuesta.

FN3
–
Dice que debe estar en FN2 y además si ningún subconjunto de atributos
no primarios tiene dependencia entre sí y como segunda medida dependen
transitivamente de la clave primaria.

FN4
–
Dice que asegura de que las dependencias multivaluadas independientes
estén efectivamente correctas.

C O NT I NU A R
Lección 7 de 8

Referencias

Blogger. (s.f.). Reglas de Codd. [Teoría y Algebra] Recuperado de

https://teoriayracional.blogspot.com/p/reglas-de-codd.html

Costal Costa, D. (2017). Introducción al diseño de bases de datos.

Recuperado de https://pdfslide.net/documents/dolors-costal-costa-
introduccion-al-diseno-de-bases-de-datospdf.html

Universidad Autónoma del Estado de Hidalgo. (2017). Diseño de base de

datos. Recuperado de https://bit.ly/3esioP3

C O NT I NU A R
Lección 8 de 8

Descargá la lectura

Módulo 2.pdf
1.3 MB

Base de datos - Módulo 2.mp3

21.9 MB