¿Porqué respiramos? Respirar es algo normal que hacemos sin pensar. Parpadeamos sin darnos cuenta. Pues lo mismo debería pasar cuando vas a crear una tabla en una base de datos. ¿Cual es el primer campo que se añade a toda tabla? … Si NO has pensado una Clave Primaria auto numérica y auto incrementable, mejor será que esfuerces en no dejar de respirar.
Como todo en nuestro mundo puede ser que no nos interese, para un caso muy particular, una clave primaria de este tipo, pero no se me ocurre en el momento de escribir esto ningún ejemplo.
El proceso de normalizar una base de datos es un proceso complejo, sobre todo si ya está creada y te toca mantenerla. Sin embargo, si vas a crear una nueva base de datos, o vas a añadir una tabla a una base de datos ya creada, acuérdate del auto numérico.
Es algo que había a aprendido mucho antes de empezar a trabajar. No se porqué pero esa “buena práctica” de la normalización es una de las pocas cosas que he aprendido y no he olvidado cuando estudié álgebra relacional.
He tenido que lidiar con mucha gente a la que se le presuponen estos conocimientos y, al no tenerlos, se entran en unas discusiones que rozan, o superan, lo esotérico. Cuando me paro a pensar en las cosas que he tenido que escuchar en estas reuniones …
En fin, que me ha dado por buscar en la wikipedia y aquí están las ventajas que supone tener un modelo de base de datos normalizado:
- Evitar la redundancia de los datos.
-
Evitar problemas de actualización de los datos en las tablas
-
Proteger la integridad de los datos.
Podéis leer el artículo completo aquí.
Después de la corta experiencia que llevo, he de decir que otra ventaja de tener un modelo normalizado es la adaptabilidad de un modelo normalizado.
Lo más normal es que un modelo no cambie muy ha menudo, sin embargo, cuando cambia, y NO tienes un modelo normalizado hay que empezar a redundar datos por ejemplo. Sin embargo, al tener un modelo normalizado todo es mucho más fácil.
No se me ocurre un ejemplo que no sea de mi propia experiencia, por lo que no puedo ponerlo ya que no quiero herir sentimientos de antiguos compañeros.
Así que sólo os queda aceptar este mandato como si fuese un mesías: “Tabla que crees, tabla que tendrá una clave primaria numérica, única y auto incremental“.
¿Se os ocurren más ventajas de tener un modelo de base de datos normalizado que no venga en los libros?
Juan María Laó Ramos. (sígueme en twitter @juanlao)
juanlao 
Normalizar está bien, aunque probablemente deberás desnormalizar más de una vez para tener mejor rendimiento. Pero lo que me ha llamado la atención es que hables de claves primarias (una única columna ID por lo que se ve en el diagrama) autonuméricas, yo diría que eso no tiene nada que ver con la normalización o al menos no es requisito.
LikeLike
Gracias Yuri, efectivamente, en algunas ocasiones desnormalizar puede servir para tener un mejor rendimiento.
Lo de las claves primarias es una “buena práctica” que, por lo menos a mi, me ayuda a tener modelos normalizados desde un primer momento.
LikeLike
Sin embargo, hay que estudiar y ver si realmente esa desnormalización es para mejorar el rendimiento, o es que el modelo no es del todo correcto. Es decir, si hay que desnormalizar, siempre pienso que hay algo que no huele del todo bien, ya que si hay que desnormalizar para mejorar el rendimiento suele significar que el modelo normalizado no está del todo concorde a las reglas del negocio que se ha modelado.
LikeLike
Es bueno tener un campo numerico identidad para selecionar univocamente un registro, pero disiento que sea la clave principal de una tabla, bajo mi entender, la clave principal debe ser lo que define univocamente un registro. por ejemplo, en una tabla de personal, el DNI, que no se repite para ninguna persona, un campo autonumérico permitiría repetir las mismas personas al tener distintos Id autonum´ricos.
LikeLike
Hola tonofede:
Yo diferencio entre Clave principal(sólo puede haber una por tabla, id autonumérico) y clave única (dni de una persona). De esta manera al referenciar en otra tabla un registro concreto tienes el id autonumérico, autoincremental y único que lo insertas como clave ajena. cosa que no te recomendaría hacer con un campo DNI por ejemplo, ya que estarías duplicando datos (DNI). Además, los motores de base de datos son más rápidos buscando un número en una tabla (id) que un string (dni) en una tabla.
Espero que te sirva.
LikeLike
A mi entender, el que no se repitan los DIs es tema de validación, en la practica es mucho mejor tener una clave de este tipo, pues es mejor indexar por una columna numerica (lo que conlleva mayor velocidad en busqueda) que por una columna de string.
En cuanto al tema del autonumerico es útil en escenarios centralizados, pero hacer una consolidacion de bases de datos distribuidas que utlicen en sus tablas Ids autonumericos es muy muy complicado y es un escenario en el que se deberia optar por generar los Ids y no autogenerarlos.
LikeLike
Cuando haces una búsqueda de un DNI lo haces, precisamente por DNI, no por un numerico incremental.
Y la duplicidad se da incluso como clave foránea si tienes el DNI o tu autonumérico.
Apoyo a Tonofede en su comentario. el autoincremental te sirve para identificar de manera unica un registro, pero si ya tienes un campo que cumple esa característica, es el candidato ideal para clave primaria.
LikeLike