Normalización en base de datos 🧷

Si eres desarrollador, tarde o temprano te vas a tener que enfrentar a diseñar una base de datos SQL.

Te explico lo mínimo que tendrías que tener en cuenta para diseñar una base de datos SQL con buen rendimiento.

En este artículo te explicaré lo que a mí me hubiera gustado que me contaran cuando diseñé mi primera base de datos SQL 🤝

Las 5 reglas al diseñar una base de datos SQL

La normalización básicamente es un conjunto de reglas para diseñar una base de datos SQL a las que se conocen como formas y que entre otras cosas buscan evitar la redundancia de datos.

Mi recomendación es que normalices tu base de datos hasta la tercera forma o regla.

Hasta la fecha me he enfrentado a multitud de bases de datos de distintos motores con muchísimos datos (más de 300 datos por minuto) y no he tenido la necesidad de ir más allá.

Por el motivo anterior explicaré sólo las 3 primeras reglas o formas.

Primera Forma Normal (1FN)

Me apoyaré en la siguiente tabla, que es un listado de portátiles, para explicar las reglas o formas.

La primera forma nos habla de:

Atomicidad

Si hacemos la suposición de que el átomo es indivisible es a ésto a lo que se refiere. Tienes que dividir la información en campos hasta dicha información no se pueda dividir más.

Si aplicamos la regla de atomicidad nos fijamos que podemos separar la información de la tabla original, por ejemplo, sacando del nombre el fabricante y añadiéndolo como un nuevo campo.

Índice o clave (primary key)

El índice, campo clave o primary key será un campo único para cada item o fila de la tabla.

Este campo nos permitirá realizar búsquedas muy rápidas.

No tiene por qué ser una sola columna, pueden ser varias columnas las que formen el índice. Lo que siempre se tiene que respetar es que sea único para cada fila.

Para este índice es muy común usar un campo auto incrementable, de forma que el motor de la base de datos se encarga de ir completando al añadir una nueva fila.

Número de campos fijos

Tienes que buscar que el número de campos o columnas sea fijo.

Imagina que en la tabla original nos entra un portátil igual pero con un disco duro SSD de 1T, ello nos obligaría a añadir una nueva columna o campo en nuestra tabla.

Esto no es correcto, lo correcto sería crear una nueva tabla con los distintos discos duros que pueda tener el portátil y referenciarla con su índice a nuestra tabla original, así 👇

De esta forma, cuando aparezca un portátil con un disco duro diferente a los que tenemos en la base de datos será suficiente con añadirlo a la tabla de TiposDiscoDuro

Ahora referenciamos la nueva tabla con la tabla original.

⚫ Segunda Forma Normal (2FN)

La segunda regla o forma nos dice muy resumidamente que evitemos la duplicidad de datos.

Si te fijas, en la tabla estamos viendo datos repetidos, como el fabricante y el nombre, te los coloreo para que te des cuenta 🧐

¿Cómo hacemos para evitar los datos duplicados? Fácil, creamos una nueva tabla para el fabricante (que tendrá asociado el país) y otra para el nombre del portátil

Nuestra base de datos iría quedando así 👇

⚫ Tercera Forma Normal (3FN)

La tercera regla o forma nos dice básicamente que eliminemos los campos que no dependen del índice o clave.

Aquí tenemos que ir a la tabla de Fabricante y fijarnos...

Con los datos que estamos manejando, no se le ve mucho sentido a sacar una tabla para los países, pero... qué ocurre si queremos meter muchos más portátiles de otras marcas con los mimos países que ya están, por ejemplo LENOVO (CHINA)...

En este caso se nos comenzarán a repetir los países y es posible que queramos en un futuro hacer una búsqueda por países.

Así que creo una nueva tabla de países

La tabla de Fabricante quedaría:

Resumen

Resumiendo, hemos pasado de la base de datos (tabla) original

A una base de datos normalizada a la tercera forma

Hasta luego 🖖