Normalización de bases de datos (Parte 1)

Uno de los trabajos más exigentes en lo que se refiere a las bases de datos se orienta a su adecuado diseño y, en caso de que ya exista, en su limpieza (que lleva muchísimo tiempo). Existe una miríada de libros publicados respecto al diseño de bases de datos, pero aquí nos enfocaremos en la normalización. La normalización es un proceso de refinamiento de las estructuras de la base de datos de manera que se pueda mejorar la rapidez con la que pueden accederse a los datos, así como mejorar su integridad. Esto es un proceso meticuloso y, a veces, laborioso. En muchas ocasiones se requiere decidir entre tener integridad en la base de datos y rapidez en el acceso.

Ya de por sí la creación de una base de datos trae consigo descubrir los elementos que se requieren para, luego, crear un conjunto de tablas que los contenga. La definición de campos y tablas establecerán la estructura de la base de datos. Esta estructura afectará el desempeño de las aplicaciones. Algunos diseños podrían mejorar la velocidad de acceso, como colocar toda la información relacionada en un solo lugar. Sin embargo, puede diseñarse la base de datos para mejorar la integridad de los datos que contiene, como por ejemplo colocar los datos de facturas en una tabla y los domicilios de los clientes en otra. Lo anterior evitaría que sean eliminados los domicilios de los clientes en caso de eliminar alguna factura. En fin, que una base de datos bien normalizada debe encontrar el punto de equilibrio entre rapidez e integridad.

Las tablas de alta velocidad de acceso tienen pocas relaciones y tienen varios campos en un solo registro (a veces, repetidos). Las pocas relaciones procesan las modificaciones, inserciones y eliminaciones de una manera ágil. Los campos repetitivos facilitan la carga de grandes cantidades de datos en una sola instrucción SQL sin tantos JOIN que obliguen a localizar datos en tablas adicionales vinculadas.

Por otro lado, cuando una base de datos se genera con la integridad como prioridad, suele tener muchas tablas pequeñas. Cada una de las tablas pueden tener varios índices que se utilizan para vincular a otras tablas. Una base de datos fundamentada en la integridad difícilmente agregará datos incorrectos sin que la base de datos se queje de ello. Lo anterior, claro está, consumirá ciclos de reloj valiosos, pero la base de datos procurará mantenerse íntegra.

Una base de datos bien, bien normalizada redundará en una cimentada lógica que hasta lleva de la mano al código que la accede. Las tablas bien normalizadas se comprenden con mayor facilidad con sólo verlas y ello facilitará la creación de los procedimientos requeridos para su acceso, así como hacer las modificaciones que sean pertinentes. La regla de oro sería la siguiente: si se le dificulta trabajar con alguna tabla, es altamente probable que requiera de un mayor trabajo de normalización.

Utilicemos un archivo en el que trabajaremos para normalizar: el de los códigos postales de México. La oficina de correos de México ofrece una versión en modo de texto donde vienen poco más de 145 mil registros con los códigos postales y las poblaciones en la República Mexicana. Esa tabla se encuentra en el siguiente URL: https://www.correosdemexico.gob.mx/SSLServicios/ConsultaCP/CodigoPostal_Exportar.aspx.

Si abrimos la tabla en el bloc de notas de Windows (o cualquier otro lector de TXT que soporte archivos grandes) notaremos una andanada de datos que parten, en la primera columna, del número de código postal, y otros datos más. Si bien los datos están en orden de código postal, será bueno proceder a interpretar qué nos estamos encontrando.

1. La primera línea del archivo es una advertencia que no entra en el formato. Debe omitirse al hacer la conversión.
2. La segunda línea del archivo tiene los nombres de los campos. Existe cierta consistencia en los nombres, pero determinaremos qué significan los nombres:
1. d_codigo: (Texto) El código postal del asentamiento. (Nota: Todo lo que empieza con d_ parece significar "Descripción").
2. d_asenta: (Texto) El nombre del asentamiento que se relaciona con el código postal. Cabe destacar que puede haber más de un asentamiento vinculado a un código postal.
3. d_tipo_asenta: (Texto) El tipo de asentamiento que es (colonia, pueblo, unidad habitacional, etcétera) de acuerdo con el catálogo de SEPOMEX.
4. D_mnpio: (Texto) El nombre del municipio al que pertenece el asentamiento y el código postal (de acuerdo con el INEGI de marzo de 2013).
5. d_estado: (Texto) El nombre del Estado o Entidad Federativa al que pertenecen el municipio, el asentamiento y el código postal (de acuerdo con el INEGI de marzo de 2013).
6. d_ciudad: (Texto) Ésta es un tanto redundante en muchos casos. Sin embargo, se refiere a la ciudad. En muchas ocasiones "ciudad" y "mnpio" son equivalentes. En otras, como en la Ciudad de México, "ciudad" y "Estado" son equivalentes. A decir verdad, poca utilidad le veo a este campo pero en muchas ocasiones se pregunta al solicitar domicilios postales en México. Sin embargo, está basado en el catálogo de SEPOMEX.
7. d_CP: (Texto) Ésta es el código postal de la Administración de Correos que reparte en el asentamiento indicado.
8. c_estado: (Numérico) Éste es el código del Estado. Es un número único de acuerdo con INEGI marzo 2013.
9. c_oficina: (Numérico) Éste es el código de la oficina que está cerca de los códigos postales indicados. Es un tanto redundante con d_CP, aunque d_CP es un valor de texto.
10. c_CP: (Numérico) A éste lo veo como un campo redundante pues, en la tabla, carece absolutamente de datos. Aquí, deduzco, debería estar en formato numérico el código postal contenido en d_codigo, pero en la tabla no tiene valor alguno.
11. c_tipo_asenta: (Numérico) Aquí está el código único del asentamiento indicado en d_asenta, de acuerdo con el catálogo de SEPOMEX.
12. c_mnpio: (Numérico) Aquí está el código único del Municipio por Estado indicado en d_mnpio y está de acuerdo con INEGI marzo 2013. Al tener códigos por Estado, la unicidad es únicamente en la Entidad federativa que le corresponde.
13. id_asenta_cpcons: (Numérico) Éste es un identificador único del asentamiento, pero la unicidad está a nivel municipal (es decir, hay números repetidos). 
14. d_zona: (Texto) Aquí se encuentra la descripción del tipo de zona (urbana, semiurbana, rural, etcétera). No se incluye un campo c_zona con el código de la zona.
15. c_cve_ciudad: (Numérico) Éste es el campo que contiene el código único de la Ciudad contenida en d_ciudad de acuerdo con el catálogo de SEPOMEX. 
3. Las siguientes más de 145 mil líneas contienen los datos asociados con estos campos.
4. Los campos están separados por una barra vertical (|).

Hay algunas situaciones en los nombres que ya desmenuzaremos en el transcurso de los siguientes textos de la serie "Normalización de bases de datos". Por el momento, la tarea es obtener el archivo y escudriñar sus valores. Iremos viendo cómo normalizarlo para tener una base de datos consistente.

Cabe hacer notar que estas formas de normalización también pueden servir para bases de datos que no tienen motores nativos de relacionamiento (NoSQL), como ISAM (Método de Acceso Secuencial Indizado, por sus siglas en inglés) o archivos planos de acceso aleatorio. Lo más seguro es que la lógica del relacionamiento, en caso de necesitarse, se tenga que integrar a mano.¡Nos seguimos leyendo!