Normalizacin de la base de datos

Normalizacin de datos
La normalizacin es el proceso que permite distribuir todos los campos de la base de datos
en tablas relacionadas entre s, de forma que cumplan con el funcionamiento esperado de la
base de datos.
Ahora ya estamos preparados para comenzar un anlisis ms profundo de los datos y la
organizacin de los elementos individuales en grupos.
Como premisa fundamental partiremos del propio significado de relacin, que supone el
agrupar en una misma tabla todos los campos de informacin relacionados por su
significado.
Para evitar la inconsistencia y duplicidad de datos emplearemos la tcnica de normalizacin
para organizar los campos de datos en cada tabla. Sin entrar a desarrollar la teora que hay
detrs de la normalizacin, usaremos una serie de reglas que pueden aplicarse para
determinar si nuestro diseo tiene sentido.
1. Cada campo de una tabla debe contener un nico tipo de informacin. Esto
significa que deberamos dividir los campos complejos y evitar la repeticin de
grupos de informacin. Ejemplo: Sera conveniente separar en campos diferentes el
nombre y los apellidos de un cliente, o dividir la direccin del mismo en los campos
necesarios.
2. Claves principales. Cada tabla debe tener un nico identificador o clave
principal, que debe estar formado por uno o varios campos de la tabla. En una base
de datos relacional, cada uno de los registros de cualquier tabla debe ser identificado
de forma nica. Es decir, algn campo o combinacin de varios debe albergar un
valor nico para cada registro de la tabla. Este identificador es lo que denominamos
clave principal. Como regla general deberamos usar como clave principal el campo
ms corto que identifique a cada registro. No obstante es recomendable la creacin
de campos artificiales para ser usados como clave principal.
3. Dependencia funcional. Para cada valor nico de la clave principal, los valores de
las columnas de datos deben estar relacionados y deben describir completamente el
contenido de la tabla. Esta regla opera de dos formas:
o En primer lugar no debera haber en una tabla un dato que no sea relevante
del asunto o materia del que trata la tabla. Por ejemplo, aunque es necesaria
la informacin del cliente para cada pedido, los clientes seran un asunto
independiente y tendran su propia tabla.
o En segundo lugar los datos de la tabla deberan describir completamente la
materia de la que trata la tabla. Por ejemplo, un pedido podra ser enviado a
una direccin diferente a la del cliente, por lo que la adicin de la direccin
de envo a la tabla pedido hara que la informacin fuese mas completa.
Mas tcnicamente decimos que dados dos campos, A y B, se dice que B es
funcionalmente dependiente de A si para cada valor de A existe un valor de B, y
solo uno, asociado con el. A y B pueden ser compuestos, es decir pueden ser
conjuntos de campos en lugar de campos simples.
4. Independencia de los campos. Debe ser posible realizar cambios en cualquier
campo que no forme parte de la clave principal sin que para ello se vea afectado
cualquier otro campo. Si incluyramos la compaa de envo y su telfono en la
tabla de pedidos, y la compaa cambia su numero de telfono habra de ser
modificado en muchos registros.

Normalizacin de la base de datos

Diseo de las tablas
Una vez realizado este estudio llega el momento de crear las tablas, para ello colocaremos
en cada tabla aquellos campos del tipo Nuevo, teniendo cuidado de que en cada tabla no
haya ningn campo que se repita. Por ejemplo, en la tabla de pedidos no colocaremos el
cdigo del producto ya que en un pedido puede haber varios productos, para solucionar esto
crearemos una tabla auxiliar que llamaremos Detalles de pedidos, en la que incluiremos los
campos: clave del producto, PrecioUnidad, Cantidad y Descuento.
En nuestro ejemplo llegamos a la conclusin de que son necesarias seis tablas
Tabla Clientes
Nombre Tipo Tamao Otras propiedades
IdCliente clave
NombreCompaa
NombreContacto
CargoContacto
Direccin
Ciudad
Regin
CdPostal
Pas
Telfono
Fax

Tabla Compaas de envos
Nombre Tipo Tamao Otras propiedades
IdCompaaEnvos clave
NombreCompaa
Telfono

Tabla Detalles de pedidos
Nombre Tipo Tamao Otras propiedades
IdPedido clave
IdProducto clave
PrecioUnidad
Cantidad
Descuento

Tabla Empleados
Nombre Tipo Tamao Otras propiedades
IdEmpleado

clave
Apellidos

Nombre

Cargo

Tratamiento

FechaNacimiento

FechaContratacin

Direccin

Ciudad

Regin

CdPostal

Pas

TelDomicilio

Extensin

Foto

Notas

Jefe


Tabla Pedidos
Nombre Tipo Tamao Otras propiedades
IdPedido

clave
IdCliente

IdEmpleado

FechaPedido

FechaEntrega

FechaEnvo

FormaEnvo

Cargo

Destinatario

DireccinDestinatario

CiudadDestinatario

ReginDestinatario

CdPostalDestinatario

PasDestinatario


Tabla Productos
Nombre Tipo Tamao Otras propiedades
IdProducto clave
NombreProducto
CantidadPorUnidad
PrecioUnidad
Mtodo de dependencias funcionales
A continuacin vamos a ver un mtodo mecnico para disear las tablas de la base de datos
(normalizar).
Recordemos la definicin tcnica de dependencia funcional: dados dos campos, A y B, se
dice que B es funcionalmente dependiente de A si para cada valor de A existe un nico
valor de B, asociado con l.
Empezamos tomando aquellos campos que de una manera clara sern claves en alguna
tabla como por ejemplo el Idcliente. Para saber si un campo depende funcionalmente de
otro nos hacemos el siguiente razonamiento:
Si conozco el Idcliente, existe un nico apellido del cliente asociado a el?, SI,
luego los apellidos dependen funcionalmente del campo Idcliente. (Idcliente
apellidos )
Si conozco el IdPedido existe un nico Producto en el pedido asociado a el?, NO,
ya que un pedido puede no tener un nico producto, por lo tanto el producto no
depende funcionalmente de IdPedido.

Obtencin de todas las dependencias funcionales

Escribimos todas las dependencias funcionales.
IdPedido FechaPedido
IdPedido FechaEntrega
IdPedido FechaEnvo
IdPedido FormaEnvo
IdPedido Cargo
IdPedido IdCliente
IdPedido
NombreCompaa
IdPedido NombreContacto
IdPedido Direccin
IdPedido Ciudad
IdPedido Regin
IdPedido CdPostal
IdPedido Pas
IdPedido Destinatario
IdPedido
DireccinDestinatario
IdPedido
CiudadDestinatario
IdPedido
IdPedido, IdProducto
PrecioUnidad
IdPedido, IdProducto
Cantidad
IdPedido, IdProducto
Descuento

IdCliente
NombreCompaa
IdCliente
NombreContacto
IdCliente CargoContacto
IdCliente Direccin
IdCliente Ciudad
IdCliente Regin
IdCliente CdPostal
IdCliente Pas
IdCliente Telfono
IdCliente Fax

IdProducto
IdEmpleado Nombre
IdEmpleado Apellidos
IdEmpleado Cargo
IdEmpleado
TratamientoEmp
IdEmpleado
FechaNacimiento
IdEmpleado
FechaContratacin
IdEmpleado Direccin
IdEmpleado Ciudad
IdEmpleado Regin
IdEmpleado CdPostal
IdEmpleado Pas
IdEmpleado TelDomicilio
IdEmpleado Extensin
IdEmpleado Foto
IdEmpleado Notas
IdEmpleado Jefe

ReginDestinatario
IdPedido
CdPostalDestinatario
IdPedido PasDestinatario
IdPedido NombreProducto
IdPedido IdEmpleado
IdPedido
NombreEmpleado

NombreProducto
IdProducto
CantidadPorUnidad
IdProducto PrecioUnidad

IdCompaaEnvos
NombreCompaaEnvos
IdCompaaEnvos
Telfono

Notar que en el caso del PrecioVenta de un producto este depende a la vez del IdProducto
y del IdPedido, es decir va a tener una clave doble.
Esta relacin contiene todas las dependencias funcionales que yo he visto, aunque
posiblemente podran determinarse mas de las que aqu aparecen. A partir de ahora se trata
de simplificar hasta lograr una cobertura mnima, es decir que un campo no puede
depender funcionalmente mas que de una clave.

Para realizar el proceso de simplificar, nos basaremos en la siguiente propiedad:

Si tenemos que A B, y B C, se puede deducir la dependencia A C, siendo esta
ltima dependencia redundante (sobrante).

En nuestro ejemplo tenemos que IdPedido IdEmpleado, y IdEmpleado Nombre,
luego la expresin IdPedido Nombre, es redundante y podemos eliminarla.
Continuaremos este proceso de simplificacin hasta obtener una cobertura mnima en la
que aparezcan todos los campos una sola vez.

Simplificacin y obtencin de las tablas

Simplificamos tachando las sobrantes.
IdPedido FechaPedido IdPedido, IdProducto IdEmpleado Nombre
IdPedido FechaEntrega
IdPedido FechaEnvo
IdPedido FormaEnvo
IdPedido Cargo
IdPedido IdCliente
IdPedido
NombreCompaa
IdPedido NombreContacto
IdPedido Direccin
IdPedido Ciudad
IdPedido Regin
IdPedido CdPostal
IdPedido Pas
IdPedido Destinatario
IdPedido
DireccinDestinatario
IdPedido
CiudadDestinatario
IdPedido
ReginDestinatario
IdPedido
CdPostalDestinatario
IdPedido PasDestinatario
IdPedido NombreProducto
PrecioUnidad
IdPedido, IdProducto
Cantidad
IdPedido, IdProducto
Descuento

IdCliente
NombreCompaa
IdCliente
NombreContacto
IdCliente CargoContacto
IdCliente Direccin
IdCliente Ciudad
IdCliente Regin
IdCliente CdPostal
IdCliente Pas
IdCliente Telfono
IdCliente Fax

IdProducto
NombreProducto
IdProducto
CantidadPorUnidad
IdProducto PrecioUnidad

IdCompaaEnvos
IdEmpleado Apellidos
IdEmpleado Cargo
IdEmpleado
TratamientoEmp
IdEmpleado
FechaNacimiento
IdEmpleado
FechaContratacin
IdEmpleado Direccin
IdEmpleado Ciudad
IdEmpleado Regin
IdEmpleado CdPostal
IdEmpleado Pas
IdEmpleado TelDomicilio
IdEmpleado Extensin
IdEmpleado Foto
IdEmpleado Notas
IdEmpleado Jefe

IdPedido IdEmpleado
IdPedido
NombreEmpleado

NombreCompaaEnvos
IdCompaaEnvos
Telfono

Hacemos limpieza borrando los que se han tachado, y obtenemos las tablas de la base de
datos sin mas que definir una tabla por cada conjunto de dependencias funcionales de la
misma clave
Agrupamos por claves obteniendo las tablas.


Curso de MySQL: Cmo relacionar tablas con phpMyAdmin y
Workbench?
Hemos llegado a un punto de suma importancia en lo que concierne a la
estructura de una Base de datos; nos referimos al proceso de relacionar
tablas entre s, lo cual podramos decir que es como la esencia del Modelo
Relacional.



Antes de realizar o llevar a cabo el presente proceso en nuestras tablas,
debers haber sometido tu base de datos al procedimiento conocido como
Normalizacin, lo cual evitar problemas de redundancia e integridad en los
datos que almacenemos.
En esta parte del Curso de MySQL relacionaremos nuestras 2 tablas, las cuales
creamos en el captulo anterior:

En esta parte del curso, crearemos 2 tablas:




Una llamada tcontacto, la cual tendr los siguientes campos:

-id_contacto (INT), (PK, NN, AI)
-nombres (VARCHAR(40)), (NN)
-apellidos (VARCHAR(40)), (NN)
-email (VARCHAR(45))
-celular (VARCHAR(13))
-direccion (VARCHAR(45))
-sexo (VARCHAR(15))
-foto (BLOB)

Y la segunda tabla la llamaremos testudio_realizado, y contendr los
siguientes campos:

-idestudio_realizado (INT), (PK, NN, AI)
-descripcion (VARCHAR(70)), (NN)
-duracion (VARCHAR(20))
-fecha_finalizacion (DATE)
-termino (VARCHAR(5)), (NN)
hpMyAdmin:
Procederemos a abrir la aplicacin y podremos observar en la barra
lateral izquierda, que all se irn mostrando las bases de datos que
vayamos creando, localizaremos nuestra BD bdcontactos y daremos
clic sobre ella:




Ahora se desplegarn las tablas que tenemos creadas, damos clic sobre
la tabla donde ir nuestra llave fornea, en este caso
testudio_realizado:




Damos clic en la pestaa Estructura que se encuentra en la parte
superior de phpMyAdmin; luego se nos mostrarn los campos que
contiene nuestra tabla, y debajo de ellos encontraremos un enlace
llamado Vista de relaciones y damos clic sobre este:






Procederemos a ubicar el campo que se convertir en nuestra clave
fornea, en esta ocasin id_contacto, y damos clic en la lista
desplegable que se encuentra al lado de dicho campo; procedemos a
seleccionar la tabla de referencia junto con el campo que representa la
llave primaria de la misma:




Ahora, diligenciaremos el campo Nombre de la restriccin y le damos
un nombre a nuestra clave fornea, en este caso la llamaremos
tcontacto_testudior, ahora en las propiedades ON DELETE y ON
UPDATE seleccionaremos la opcin NO ACTION; y posteriormente
daremos clic en el botn Guardar:




Lo primero que tenemos que hacer, es establecer qu tipo de relacin existe
entre estas tablas; es decir, si de uno a uno, de varios a varios, o de uno a
varios. En este caso, estamos guardando informacin sobre personas y/o
contactos, y definimos que un contacto puede tener uno o ms estudios
realizados, en otras palabras la relacin sera de uno a varios. Por lo anterior la
llave principal de la tabla tcontacto pasara a la tabla
testudio_realizado y se convertira en fornea.
Ahora, para llevar esto a la prctica; procederemos a crear un campo en
nuestra tabla testudio_realizado, el cual se recomienda que tenga el mismo
nombre de la llave principal de la tabla tcontacto (opcional), y por obligacin
deber contener el mismo tipo de datos y con la misma longitud; teniendo en
cuenta esto, nuestro campo contendr las siguientes caractersticas:
id_contacto (INT(11))(NN).




Despus de tener listo todo, llevaremos a cabo lo que nos interesa; es decir,
relacionar y/o unir ambas tablas.

Explicacin por Videotutorial:



Explicacin por Foto-Tutorial:

MySQL Workbench:
Procederemos a abrir la aplicacin y nos dirigimos al men Database, y luego
damos clic en Query Database:




Aparecer una ventana en la cual daremos clic en el botn OK:




En la siguiente ventana que nos aparece, observaremos que en la barra lateral
izquierda, se ubicarn todas las Bases de datos que vayamos creando, ahora
ubicaremos la base de datos que creamos con anterioridad bdcontactos, y
daremos doble clic sobre la misma:






Como pudimos observar en la imagen anterior, se nos muestran tres carpetas,
pero slo nos centraremos en la que dice Tables, seguidamente daremos
doble clic sobre esta, e inmediatamente se desplegarn las tablas que hemos
creado anteriormente: tcontacto y testudio_realizado.



Procederemos a seleccionar la tabla donde ir la llave fornea; es decir,
testudio_realizado, damos clic derecho y escogemos la opcin Alter Table:


Saldr una nueva ventana, nos dirigiremos a la pestaa Foreign Keys,
ubicada en la parte inferior de esta, y daremos clic sobre ella:




Veremos un nuevo apartado, y en la columna Foreign Key Name digitaremos
el nombre de nuestra llave fornea, en este caso la llamaremos
tcontacto_testudior:




Luego, daremos clic en la columna Referenced Table, y se desplegar un
men de opciones, en el cual escogeremos el nombre de la tabla de donde
proviene la llave fornea, en este caso es tcontacto:




El siguiente paso a realizar, ser activar la casilla del campo que representa
nuestra llave fornea en la tabla sobre la cual nos encontramos actualmente;
es decir, id_contacto; seguidamente, en la columna Referenced Column
seleccionaremos la columna de la tabla tcontacto, la cual representa la llave
primaria de dicha tabla; es decir, id_contacto:




Ahora, en el rea de Foreign Key Options, en las propiedades de On Update
y en On Delete, dejaremos las opciones que estn por defecto; en este caso
NO ACTION. Hay que aclarar que esto depender de nuestras necesidades,
ya que dejando estas opciones que estn por defecto, lo que hacemos es que
si se intenta actualizar la llave fornea en la tabla de donde proviene; es
decir, en donde es llave principal, dicha accin no se permitir; igualmente, si
intentamos eliminar el registro que contiene la llave fornea en la tabla de
referencia; es decir, donde es llave principal, no se permitir eliminar dicho
registro; pero siempre y cuando hayan registros relacionados entre ambas
tablas:




Daremos clic en el botn Apply, y posteriormente clic en el botn Apply
SQL y despus en el botn Finish, de las ventanas que se nos muestran:








Por ltimo damos clic en el botn Close:





phpMyAdmin:
Procederemos a abrir la aplicacin y podremos observar en la barra lateral
izquierda, que all se irn mostrando las bases de datos que vayamos creando,
localizaremos nuestra BD bdcontactos y daremos clic sobre ella:




Ahora se desplegarn las tablas que tenemos creadas, damos clic sobre la
tabla donde ir nuestra llave fornea, en este caso testudio_realizado:




Damos clic en la pestaa Estructura que se encuentra en la parte superior de
phpMyAdmin; luego se nos mostrarn los campos que contiene nuestra tabla,
y debajo de ellos encontraremos un enlace llamado Vista de relaciones y
damos clic sobre este:






Procederemos a ubicar el campo que se convertir en nuestra clave fornea,
en esta ocasin id_contacto, y damos clic en la lista desplegable que se
encuentra al lado de dicho campo; procedemos a seleccionar la tabla de
referencia junto con el campo que representa la llave primaria de la misma:




Ahora, diligenciaremos el campo Nombre de la restriccin y le damos un
nombre a nuestra clave fornea, en este caso la llamaremos
tcontacto_testudior, ahora en las propiedades ON DELETE y ON UPDATE
seleccionaremos la opcin NO ACTION; y posteriormente daremos clic en el
botn Guardar:




Si deseas conocer la estructura de la Sentencia SQL necesaria para relacionar
tablas en MySQL Server, puedes visitar el siguiente enlace:
Sentencia SQL: Relacionar tablas

15.1. Panormica de InnoDB
InnoDB dota a MySQL de un motor de almacenamiento transaccional (conforme a ACID)
con capacidades de commit (confirmacin), rollback (cancelacin) y recuperacin de fallas.
InnoDB realiza bloqueos a nivel de fila y tambin porporciona funciones de lectura
consistente sin bloqueo al estilo Oracle en sentencias SELECT. Estas caractersticas
incrementan el rendimiento y la capacidad de gestionar mltiples usuarios simultneos. No
se necesita un bloqueo escalado en InnoDB porque los bloqueos a nivel de fila ocupan muy
poco espacio. InnoDB tambin soporta restricciones FOREIGN KEY. En consultas SQL, an
dentro de la misma consulta, pueden incluirse libremente tablas del tipo InnoDB con tablas
de otros tipos.
InnoDB se dise para obtener el mximo rendimiento al procesar grandes volmenes de
datos. Probablemente ningn otro motor de bases de datos relacionales en disco iguale su
eficiencia en el uso de CPU.
A pesar de estar totalmente integrado con el servidor MySQL, el motor de almacenamiento
InnoDB mantiene su propio pool de almacenamiento intermedio para tener un cache de
datos e ndices en la memoria principal. InnoDB almacena sus tablas e ndices en un espacio
de tablas, el cual puede consistir de varios ficheros (o particiones disco). Esto difiere de,
por ejemplo, el motor MyISAM, donde cada tabla se almacena empleando ficheros separados.
Las tablas InnoDB pueden ser de cualquier tamao, an en sistemas operativos donde el
tamao de los ficheros se limita a 2GB.
En MySQL 5.0, InnoDB viene incluido por defecto en las distribuciones binarias. El
instalador Windows Essentials configura a InnoDB como el tipo de base de datos MySQL
por defecto en Windows.
InnoDB se utiliza en muchos grandes sitios de bases de datos que necesitan alto
rendimiento. El famoso sitio de noticias de Internet Slashdot.org corre sobre InnoDB.
Mytrix, Inc. almacena ms de 1TB de datos en InnoDB, y otros sitios manejan una carga
promedio de 800 inserciones y actualizaciones por segundo en InnoDB.
InnoDB se publica bajo la misma licencia GNU GPL Versin 2 (de Junio de 1991) que
MySQL. Para ms informacin sobre el licenciamiento de MySQL, consulte
http://www.mysql.com/company/legal/licensing/.

sta es una traduccin del manual de referencia de MySQL, que puede encontrarse en
dev.mysql.com. El manual de referencia original de MySQL est escrito en ingls, y esta
traduccin no necesariamente est tan actualizada como la versin original.