Diseño y normalización de bases de datos relacionales

( sistemas / sql )

Diseñando la BD

Para diseñar una base de datos se parte de la recolección de atributos o campos que va a tener, y de la definición de sus tipos de dato. La manera más profesional es realizando el análisis de requisitos con todas las personas que van a hacer uso de los datos. Pero por experiencia ya sabéis que esto se hace muy a ojo: os piden realizar una aplicación y según los requisitos de la aplicación hacéis el diseño de la BD. El primer método está más estandarizado, y suele ser más lento pero a cambio es improbable que el diseño salga mal. El segundo es más rápido porque directamente se piensa en las tablas y sus datos sobre la marcha. Se utiliza principalmente en la metodología de programación conocida como "programación extrema" y en las demás de la familia "desarrollo ágil de software"; y es más propenso a fallos de diseño, proporcionalmente inversos al tiempo que se dedique a su definición y valoración (más tiempo, menos probabilidad de fallos).

Normalizando la BD

La normalización es un método de análisis de BD para conseguir una BD relacional, que respete la integridad referencial, y que no tenga redundancia de datos. Se divide en formas normales, y aunque hay un montón y es toda una ciencia, explicaré por encima las 3 primeras ya que el nivel 3 es suficientepara la mayoría de casos. Hay que destacar que la normalización se puede hacer a nivel completo de la BD, o a nivel de tablas o esquemas. La técnica es la misma: analizar el conjunto de campos y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de facturación podemos partir de los datos del cliente añadiendo la clave del cliente, y según vayamos normalizando nos saldrán todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irán saliendo otras tablas subordinadas si acaso.

Las reglas de Codd

Además de la normalización hay unas reglas, las reglas de Codd, que ayudan a diseñar una BD relacional perfecta (desde el punto de vista de Codd, claro) que merece la pena estudiarlas pues son casi de lógica común y nos harán la vida más fácil en todos los sentidos. La idea de estas reglas surgió porque la normalización no era suficiente para que una BD fuera relacional, consistente e independiente. Hay ocasiones en las que los diseñadores de las BD confeccionan la BD para satisfacer necesidades lógicas y funcionales de una aplicación, por ejemplo almacenando los datos en un formato que luego la aplicación se encarga de transformar. Esto es bastante típico cuando el diseñador es el programador de la aplicación, y lo hace por comodidad o falta de conocimiento. La moraleja es que una BD debe ser independiente de la aplicación, y si lo pensáis bien es mejor así. Según las reglas de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (típicamente SQL), y las restricciones en los datos deben ser propiedad de la BD(no vale controlar la entrada desde la aplicación). Con esto conseguiremos que mediante el SQL no se puedan realizar operaciones que hagan que la aplicación no funcione (introduciendo datos en un formato inesperado para la aplicación, por ejemplo), y entre otras cosas, que si tenemos que realizar informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que parsear nada ni realizar consultas sobre consultas.

Normalizando la BD: primera forma normal (1FN)

Se podría decir que al aplicarla hay que asegurarse de que:

Normalizando la BD: segunda forma normal (2FN)

Una tabla está en segunda forma normal siempre que esté en primera forma normal y todos sus atributos (campos) dependan totalmente de la clave candidate sin ser parte de ella. Viene a ser que, si un campo de la tabla no depende totalmente de una clave única (que pueden ser compuestas), debe sacarse fuera con la parte de la clave principal de la que es dependiente.

Ejemplo

Incorrecto

lineas_pedido

IDClienteIDProductoCantidadNombre_producto
29 42 1 Zapatillas deportivas de tenis
46 9 5 Balón reglamentario de baloncesto
204 42 1 Zapatillas deportivas de tenis
144 10 1 Zapatillas deportivas de rugby

Correcto

lineas_pedido

IDClienteIDProductoCantidad
29 42 1
46 9 5
204 42 1
144 10 1

productos

IDProductoNombre_producto
9 Balón reglamentario de baloncesto
10 Zapatillas deportivas de rugby
42 Zapatillas deportivas de tenis

Como vemos en la tabla "lineas_pedido" del ejemplo incorrecto, la única clave candidata es IDCliente + IDProducto, ya que en conjunto son únicas en la tabla (podríamos tener un IDLinea_pedido único también, pero aún así esos dos campos segurían siendo una clave candidata). El campo Cantidad es dependiente de la clave candidata, pues el cliente ha pedido de ese producto una cantidad determinada de artículos, pero el nombre en cambio es dependiente sólo del producto, no del cliente. Si dejaramos esa tabla como está, tendríamos por una parte una redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla de productos, y además podrían darse inconsistencias de datossi cambiamos el nombre del producto en un registro... ¿cuál sería el nombre real del producto 42 si en varios registros tiene un nombre distinto?

Conclusiones

Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves candidatas (compuestas), que identifican de manera única el registro; comprobar que los campos que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el segundo paso puede ayudar preguntarse lo siguiente: ¿puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el análisis esto requiere un mínimo de agudeza, pues puede que casualmente el valor de un campo se repita para una parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en cantidades de 5) pero sabemos que no es dependiente de ella. Por último, aclarar que hay ocasiones en las que el análisis no tiene que ser tan cerrado, ya que a veces las apariencias engañan. Un ejemplo de ello es una tabla de facturas que tiene el nombre, dirección, NIF, y demás datos del cliente: a simple vista esos datos están duplicados y dependen del cliente y no de la factura, pero resulta que esos datos deben permanecer ahí pues fiscalmente debemos saber a qué datos se emitió una factura; esos datos son realmente dependientes de la factura, no del cliente. Si no los incluyéramos en la tabla de facturas, al modificar el registro del cliente en la tabla de clientes no sabríamos a qué datos fiscales se emitió la factura. Así que una vez más, hay que utilizar un poco de ingenio y no aplicar normas como una máquina y sin pensar.

Normalizando la BD: tercera forma normal (3FN)

Una tabla está en tercera forma normal siempre que esté en segunda forma normal (y por consiguiente en primera) y todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen únicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta: ningún campo que no sea parte de la clave candidata puede depender de otro campo que no sea la clave candidata.

Ejemplo

Incorrecto

carga_diaria

IDServidorFechaIDServicioNombre_servicioCarga
21 2009-01-14 1 Oracle 100
21 2009-01-15 9 MySQL 100
21 2009-01-16 22 Apache 85
34 2009-01-14 3 PostgreSQL 74
34 2009-01-15 22 Apache 58
34 2009-01-16 22 Apache 67
66 2009-01-14 9 MySQL 98
66 2009-01-15 22 Apache 94
66 2009-01-16 1 Oracle 10g 84

Correcto

carga_diaria

IDServidorFechaIDServicioCarga
21 2009-01-14 1 100
21 2009-01-15 9 100
21 2009-01-16 22 85
34 2009-01-14 3 74
34 2009-01-15 22 58
34 2009-01-16 22 67
66 2009-01-14 9 98
66 2009-01-15 22 94
66 2009-01-16 1 84

servicios

IDServicioNombre_servicio
1 Oracle
9 MySQL
22 Apache
3 PostgreSQL
22 Apache
22 Apache
9 MySQL
22 Apache
1 Oracle 10g

Imaginad que una tabla se encarga de registrar el primer servicio que más carga los servidores cada día. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha son la clave candidata, pues identifican de manera única los registros. Analizando vemos que el IDServicio, que no es un campo primario, depende únicamente de la clave candidata, y que la carga también. Pero resulta que el Nombre_servicio depende de esa clave candidata pero también depende del IDServicio, pues con el IDServicio podemos averiguar qué Nombre_servicio tiene el registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el IDServicio para que sea la clave principal pues es el campo del que depende. Y con este ejemplo vemos qué fácil es librarnos de las inconsistencias de no cumplir la tercera forma normal, y de la redundancia de datos. Si no hubieramos normalizado tendríamos que en un registro el IDServicio 22 es Apache y nadie nos asegura que en otro el IDServicio 22 también lo sea pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un histórico de 500 servidores durante 1000 días, tendríamos 500 mil registros con un campo innecesario que estaría duplicadomuchísimas veces.

Diseñando la BD sobre la marcha

Si en vuestro desempeño habitual del trabajo os encontráis con que no podéis aplicar, de una manera formal y detallada, la normalización a la hora de diseñar BD, no os alarméis pues le pasa a mucha gente. Lo que puede ocurrir es que nos quede una BD no relacional, y eso es siempre negativo, pero a base de experiencia iréis adquiriendo una soltura y capacidad analítica automáticas. La normalización, al basarse en reglas lógicas, se puede memorizar muy fácilmente y al final forma parte del instinto del diseñador: no necesitaréis bolígrafo y papel para ver que una tabla no está normalizada. De hecho cuando sepáis que datos necesita la aplicación pensaréis directamente en las tablas que saldrán.

Primero, documentarse

Lo más importante para diseñar la BD sobre la marcha es tener la mente amplia, conocer las bases de la normalización, y dejarse aconsejar por los expertos. Todo esto de las BD relacionales no es nuevo y hay muchos gurús (Codd, Edgar Frank Codd, es el padre de todos) que os pueden ayudar a entender qué características debe cumplir una BD para ser relacional. De modo que si no sabéis del tema, lo mejor es que os olvidéis de las malas enseñanazas que tengáis imbuidas: una BD con muchas tablas no está mal diseñada (una con pocas es más probable que sí lo esté); llevarse el código del cliente a todas las tablas (lo necesiten o no) no es la forma de tener una BD relacional; guardar los datos serializados en un campo no te hace la vida más fácil; tener un campo que hace referencia a una tabla unas veces y a otra en otras ocasiones no es un buen diseño (un campo referencial sólo puede referenciar a una tabla, así que usad la generalización en esas situaciones).

Errores habituales

Un error habitual a la hora de usar este método de diseño es tener un campo referencial que admite valores nulos o vacíos (típico clave_referencia 0 cuando no referencia a nada). Si la BD es relacional, un campo referencial tiene que apuntar a otro registro en la BD. A veces tenemos un campo IDPadre que hace referencia a un mismo registro de la tabla, o vale 0 cuando el registro es padre en sí... pero lo correcto en una relación reflexiva(una tabla relacionada consigo misma) que da lugar a otro tabla que contiene el IDHijo y el IDPadre; consultando esa tabla podemos saber si un registro es hijo (tiene entradas con su ID en IDHijo) o padre (su ID está en algún IDPadre) y sacar todos los hijos de un padre.

Consejos

Otro buen consejo, que no está limitado a este método de diseñar, es tener en cuenta el tamaño de las tablas en cuanto a longitud de fila (en bytes). De hecho recuerdo que me hablaron de una regla de diseño de BD que decía que una tabla no debía contener más de X campos... y bueno, siempre es discutible pero es más óptimo que la longitud de la fila no sea muy larga, sobre todo en las tablas que se consultan con frecuencia. Es una práctica muy recomendada que si tenemos campos grandes, tipo TEXT o BLOB, saquemos esos datos a otra tabla para que las búsquedas y JOIN generales que no necesiten ese campo sean más rápidas. Hay que tener en cuenta que el sistema de gestión de BD (SGBD) en ocasiones no puede optimizar las consultas y necesita escanear por completo la tabla, o tiene que volcarla a la memoria física o virtual. En definitiva: recordad que una BD relacional no puede ser dependiente de la aplicación, sino al revés. Así que olvidaros de diseñarla pensando qué es lo mejor para la aplicación, y pensad qué es lo correcto para que sea más óptima y sencilla de manejar independientemente del cliente que la maneje (aplicación, consultas directas, herramientas de informe...).


Artículo escrito por Eloy Bote Falcón, publicado originalmente en php-hispano.net

Modificado el 18 Abril, 2015
Creado el 30 abril, 2010
   

Compartiendo conocimiento desde 1995 - I.M.D. I.M.D.