Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Normalizacion de Bases de Datos
Normalizacion de Bases de Datos
PRESENTADO POR:
PROGRAMA DE FORMACIÓN
MODALIDAD VIRTUAL
2018
TABLAS
Las tablas son las unidades que almacenan los datos. Como norma general se
suele imponer que cada tabla, almacena información común sobre una entidad en
particular. Esta norma se conoce como normalización.
Para tomar estas decisiones se cuenta con un número de formas normales que
ayudarán a diseñar la mejor estructura lógica con el mayor rendimiento posible.
Las formas normales, son los modelos o maneras en que se pueden representar
la estructura de tablas. Gracias a estos modelos conseguiremos mayor eficacia.
Pero no se debe entender por eficacia como una reducción del tamaño, nos
estamos refiriendo a que se obtendrá una estructura muy bien organizada, de tal
modo que será escalable fácilmente, permitiendo realizar modificaciones en un
futuro sin muchos ni mayores problemas. Aunque habrá veces donde gracias a la
normalización también se reduzca el tamaño, este no es el objetivo que se busca.
La función de la normalización es favorecer la integridad de los datos. Trata de
evitar lo máximo posible la posibilidad de introducir datos que no sean razonables.
Dentro del proceso de normalización se distinguen tres tipos de integridades:
• Integridad de entidad.
• Integridad de dominio.
• Integridad referencial.
Estas normas o reglas de integridad de dominio pueden indicar que campos son
necesarios tener obligatoriamente con valores (no se pueden dejar vacíos, NULL)
para que la base de datos no tenga datos sin conectar en el caso de tener
relaciones o dependencias entre tablas.
Las herramientas que nos ofrece SQL Server para asegurar la integridad de
dominio son: los Tipos de datos, la restricción CHECK, la definición DEFAULT, las
claves foráneas (FOREIGN KEY) y las definiciones NOT NULL. La integridad
referencial preserva las relaciones definidas entre tablas, cuando se entran,
modifican o borran registros. En SQL Server, la integridad referencial está basada
en interrelaciones entre claves ajenas y claves primarias o entre claves ajenas y
claves únicas (a través de las restricciones FOREIGN KEY y CHECK). La
integridad referencial asegura que los valores de las claves son consistentes a
través de distintas tablas. Tal consistencia requiere que no existan referencias a
valores inexistentes.
Con esta integridad limitaremos la actividad que puede realiza un usuario sobre la
base de datos.
Formas de normalización
Las formas normales definen una serie de normas o reglas que ayudan a
organizar los datos en la estructura lógica de una base de datos.
Cada una de las formas heredan las reglas de su antecesora, así la forma normal
C, incluye las reglas de las formas A y B.
TABLA: MEDICOS
Idmedic Nombre_es Genero_ Genero_ Direccio Teléfon Teléfon Teléf Turno
o pecialidad Masculin Femenin n o_1 o_2 ono_
o o 3
(UROLOGO
)
Se debe tener claro que esta tabla contiene los datos sin ser normalizados, si bien
son los datos que se van a almacenar. Vamos a basaremos en esta tabla para ver
cómo aplicar sobre ella el proceso de normalización.
Regla: Cada uno de los campos de la tabla solo puede almacenar un tipo de
datos, y además cada dato se debe almacenar por separado, es decir
individualmente.
Para entender mejor el significado de esta regla, vamos a explicar cómo se podría
solucionar. En la tabla “MEDICOS”, se observa que se están guardando los datos
del nombre del médico y su especialidad en un solo campo. De este modo no se
está cumpliendo la norma, ya que estamos guardando información de diferentes
características en un único campo.
Otra manera de no cumplir la primera forma normal es la repetición de un campo
(teléfonos). Esta técnica es muy común en administradores que se están iniciando
en el desarrollo de bases de datos.
Este tipo de soluciones provoca bastantes problemas, el principal causante de
estos problemas es la poca flexibilidad que nos ofrece esta estructura. La tabla
dejará de cumplir con las necesidades en el momento en que un médico solicite
que se almacenen más de tres teléfonos que además no se distingue si son fijos,
celulares o empresariales.
Por lo tanto esta estructura lejos de ser sencilla es muy compleja, es imposible
definir en un principio los diferentes tipos de números telefónicos que debemos
controlar. Ahora, se puede pensar, que se van a poner suficientes campos de
modo que nuestras necesidades nunca superen ese número de campos. Como ya
se supondrá, tomar este tipo de soluciones es un error enorme. Estaremos
reservando memoria sin ninguna necesidad, muchas personas solo tendrán un
teléfono y tendremos campos vacíos que resultarán completamente inútiles.
Para solucionar el problema que hemos planteado como ejemplo, tenemos varias
soluciones, como almacenar la misma persona en diferentes registros de la tabla.
Esta es una solución válida, pero muy poco o nada eficaz desde el punto de vista
del rendimiento.
La solución es determinar cuáles son los números telefónicos importantes para el
hospital y determinar para ellos el nombre más adecuado (Residencia, Celular,
etc) y limitarlo solo a dos o máximo tres teléfonos por persona.
Para solucionar el problema de almacenar el nombre con la especialidad del
médico, es adicionando un campo “Especialidad” y si llegaran a ser varias las
especialidades de un mismo médico, se solucionaría, sacando "fuera" una tabla
con las especialidades llamada “MEDICOS-ESPEC” por ejemplo y utilizar la
integridad referencial para relacionarla con la tabla “MEDICOS” e idealmente,
crear una tabla adicional llamada “ESPECIALIDADES”. Con esta solución se hace
una especialización de la base de datos.
La tabla que hemos presentado al principio podemos decir que NO cumple la
primera forma normal.
Si se tiene por ejemplo una tabla donde se almacene la placa de un vehículo
registrado en Colombia, alguien podría pensar que como la placa consta de tres
caracteres alfabéticos y tres numéricos, divide ese campo en dos con diferentes
tipos de datos y los muestra como si fueran uno solo en las consultas SQL
mediante la sentencia SELECT. Lo que debe hacer es almacenarlo en un solo
campo llamado “Placa” con tipo de dato “CHAR” y longitud “6” haciendo la
restricción CHECK que permita el almacenamiento correcto de los seis caracteres.
La definición de esta regla puede parecer complicada, pero es tan sencilla como
las dos anteriores y se explica en dos formas, la primera es que en una tabla no
deben existir campos calculados pues a ellos se puede llegar en las consultas
mediante cualquier operación matemática; y la segunda, es que los campos que
formen las tablas deben describir completamente el contenido de las mismas, por
ello el campo “turno” quebrante esta norma pues hace parte de otra tabla diferente
a MEDICOS.
De otro lado, las tablas no deben tener ningún campo que sea irrelevante, o sea,
que no de valor a la misma, como podría ser que en la tabla MEDICOS se
almacenara el nombre de los padres de cada médico. Ese dato no aportaría valor
en ningún aspecto a la base de datos.
Las reglas 3 y 4 van de la mano, por ello se deben evitar datos innecesarios para
poder hacer cambios sin afectar el funcionamiento y la consistencia de la base de
datos, para entenderlo, hágase las siguientes preguntas: ¿qué pasaría si se
almacenara el nombre del médico en cada factura y por alguna razón se tuviera
que modificar su nombre?, ¿dónde habría que hacer los cambios?, ¿sería una
operación sencilla?