Normalización de bases de datos (Parte 3): Segunda forma de normalización (2NF)

En el anterior de la serie vimos la Primera forma de normalización (1NF). Hoy nos enfocaremos en la Segunda forma de normalización (2NF) de una base de datos, misma que, como ya indiqué, fue presentada por el Dr. Codd en 1971. Para que una base de datos cumpla con la 2NF debe satisfacer dos condiciones:

1. Que cumpla con la 1NF
2. Que no exista dependencia parcial

Para entender qué es esto de la dependencia parcial, primero vamos a comprender qué es una dependencia.

Dependencia

La dependencia está totalmente relacionada con el concepto de Clave principal o Llave primaria (o Primary Key). Como es sabido en las bases de datos, una Clave principal es un campo que identifica de manera única a cada registro de una tabla. La idea de una Clave principal es que sea única, que no se repita en la tabla y que sirva como identificador exclusivo de un registro. Por ejemplo, si tenemos una tabla:

IDCliente es el campo que se usa para identificar de manera única a cada uno de los clientes. Incluso, si tenemos nombres repetidos, como en el caso de Víctor Pérez López, sabremos que son clientes diferentes porque tienen identificadores de clientes diferentes. Aunque esa lógica podría no parecer suficiente para el razonamiento humano, podemos darnos cuenta que tenemos un Víctor Pérez López en Tamaulipas y otro en la Ciudad de México. De hecho, el RFC nos permite tener aún más claro que se trata de dos personas diferentes.

Ahora bien, fijemos nuestra atención en la famosa Clave principal. Lo único que necesito saber es el número de la Clave principal y todas las demás columnas dependerán de ella; es decir, cada valor de campo se puede obtener obtenga de una clave principal dada. Ésa es la Dependencia, misma que también se conoce como Dependencia Funcional: La obtención de una serie de valores de campo a partir de una clave principal dada.

Dependencia parcial

La dependencia parcial es el resultado de analizar qué otra columna podría fungir como Clave principal y analizar si las otras columnas dependen de ella. Pongamos en perspectiva la siguiente tabla:

Si nos damos cuenta, ésta es una tabla simplista de productos, donde se pone el fabricante, el modelo y el nombre completo del modelo. Tanto el Fabricante, como el Modelo como el ModeloCompleto corresponden a la definición de un modelo establecido por las Clave principal compuesta por Fabricante+Modelo. Es decir, un producto tiene un Fabricante y un Modelo. Sin embargo, el campo PaisFabricante sólo le pertenece a una parte de la Clave principal, que es Fabricante. Es decir, PaisFabricante no debería estar en esta tabla, porque, en definitiva, sólo es parcialmente dependiente. Es a esto a lo que se refiere la 2NF: Que no existan las dependencias parciales.

La forma más simple de que esta tabla no tenga problemas de dependencias parciales, es poner el campo PaisFabricante en una tabla llamada, digamos, Fabricantes, de la siguiente forma:

De esta forma, tanto la tabla de Productos como la tabla de Fabricantes no tienen dependencias parciales. Por añadidura, el campo "Fabricante" fungiría como "Clave externa", "Clave foránea" o "Foreign Key" (FK), que funge como vínculo entre la tabla de productos y la tabla de fabricantes.

Tabla de Códigos postales

En el caso de nuestra tabla de códigos postales, existen algunos problemas importantes con el diseño de la tabla. Claramente, no existe un índice único en la tabla y, por ende, no es posible determinar a ciencia cierta un campo único que funja como Clave principal. Es decir, los códigos postales se repiten, los identificadores de municipios también por estar establecidos por Entidad Federativa, y los identificadores de los asentamientos, como están establecidos por municipios, también se repiten. Así, existen dos formas de crear una Clave principal en este caso: 1) Agregar un campo donde se almacene la Clave principal o 2) Generar una clave principal con una combinación de campos. Para este ejemplo, nos orientaremos a la segunda opción y, así, mantendremos la tabla inalienada.

Los campos elegidos para ello son, precisamente, tres de los cuatro que mencionamos: c_estado, c_mnpio e id_asenta_cpcons. Con estos tres generamos una Clave principal bien explícita y unívoca. Con una búsqueda donde incluyamos el Estado, el Municipio y el Asentamiento, podremos encontrar cada uno de los elementos de la tabla. Esto, también, nos permitirá tener bien claro cómo hacer que esta tabla cumpla con 2NF. Curiosamente, los códigos postales (d_codigo) como tales podrían sólo fungir como un índice con duplicados que nos permita localizar qué asentamientos hay en determinado código postal, pero no serían parte de la Clave principal pues, por si mismos, no agregan valor a la identificación única.

Cualquier campo que esté en esta tabla debería depender de los tres campos que hemos definido como Clave principal. Así, analicemos:

• d_codigo: Es el código postal y depende, por completo, a la Clave principal (un código postal pertenece a un Estado, un municipio y un asentamiento).
• d_asenta: El nombre del asentamiento claramente pertenece a la Clave principal. Por lo tanto, éste deberá permanecer en esta tabla.
• d_tipo_asen: El tipo de asentamiento sólo depende del asentamiento. Por ende, éste es un claro candidato para ser escindido en otra tabla.
• d_mnpio: El nombre del municipio sólo depende del municipio. Éste es otro claro candidato para ser escindido en otra tabla.
• d_estado: El nombre del Estado sólo depende del Estado. Nuevamente, es otro claro candidato para ser escindido en otra tabla.
• d_ciudad, d_CP: Estos campos no los vamos a tocar por ahora.
• c_estado: Éste sería el vínculo entre el Estado o Entidad federativa que se refiere y esta tabla. Además, es parte de la Clave principal y, también, fungiría como Clave externa. 
• c_oficina, c_CP: Estos campos no los vamos a tocar por ahora.
• c_tipo_asenta: Aquí claramente se define el tipo de asentamiento. Sin embargo, su inclusión en esta tabla es importante porque es el vínculo (Clave externa) entre la descripción del tipo de asentamiento y su clave. Así que este campo deberá estar en ambas tablas. Con este campo podríamos responder a la pregunta en esta tabla: ¿Cuántos asentamientos hay de tipo x?
• c_mnpio: Como el anterior, su inclusión en esta tabla esta tabla es importante pues hace un vínculo (Clave externa) entre el nombre del municipio y su clave. Con este campo podríamos responder a la pregunta en esta tabla: ¿Cuántos asentamientos hay en el municipio x? Además, forma parte de la clave principal.
• c_idasenta_cpcons: Es parte de la Clave principal, y es identificador único en el municipio para el asentamiento.
• d_zona, c_cve_ciudad: No vamos a tocar estos campos por el momento.

Así, para que esta tabla cumpla con 2NF hay que escindir tres campos: d_estado, d_tipo_asen, d_mnpio. Así, las tablas quedarían de la siguiente forma (se muestra sólo un extracto de cada una):

Tabla de códigos postales 2NF

Tabla de Estados 2NF

Tabla de municipios 2NF

Tabla de tipos de asentamientos 2NF

Cabe hacer notar que al escindir los Estados, los municipios y los tipos de asentamientos, también se generan datos únicos. Por ejemplo, Ciudad de México en Estados sólo aparece una vez, Tecate en Municipios, también, etcétera. En la tabla de Municipios la Clave Principal se forma de c_estado y c_mnpio, pero, también, c_estado es una Clave externa que vincula a Estados con Municipio. Esto agrega certidumbre al diseño de la base de datos al no tener datos repetidos y procurar que sólo se encuentren en la tabla aquellos elementos que pertenecen por completo a la Clave principal.

Con todo, aún quedan algunos campos que como que no cuadran mucho en la tabla principal. Con la 3NF veremos qué procede. ¡Nos seguimos leyendo!