Normalización de bases de datos – Una mirada práctica I
Hago un parón en nuestra serie de artículos sobre Medidas de seguridad para aplicaciones Access para hablar sobre algo que a la gente le suele costar bastante, aún siendo excelentes programadores. La normalización de bases de datos.
Se supone que siendo programador, uno no debería preocuparse por estas cosas, nuestro analista o diseñador nos debería dar el trabajo ya hecho, pero este es un blog de Access y supongo que si no hay medios para montar Oracle o SQL Server, tampoco va a haber un analista.
Hay excelentes artículos y publicaciones en la red sobre este tema pero esta vez quiero darle una visión práctica, algo que cree automatismos a la hora de empezar a diseñar una base de datos, algo que nos dé un punto de partida para nuestro diseño. Si queréis profundizar más en este tema (os lo aconsejo, de un buen diseño depende una futura buena aplicación) os dejo un unos enlaces interesantes:
- Normalización de Bases de datos – Wikipedia
- Ejemplo de normalización
- Ejemplo muy completo y con las formas normales superiores (FBNC, 4ª y 5ª)
En este artículo en cambio, quiero mostrar una manera sencilla de llegar hasta la 3ª forma normal (3ª FN), que en la gran mayoría de los casos será suficiente para eliminar redundancia y facilitar la actualización y eliminación en cascada de nuestros datos.
Además, si profundizamos un poco, nos daremos cuenta que en la mayoría de los casos (se que esto es arriesgado, pero es la realidad) si está en 3ª forma normal, también está en 4ª y 5ª. Intentaré explicar de forma sencilla los pasos a seguir para transformar nuestro modelo a tablas y que estas tablas se encuentren ya en 3ª forma normal (una mezcla entre normalización y transformación del modelo E/R)
Como no quiero entrar ni en el modelo entidad/relación (ni en el modelo relacional), ni empezar a pasar una por una por todas las formas normales, utilizaré un lenguaje más «coloquial», aunque a veces coincida con el técnico. Vamos con algo (poco) de teoría antes de empezar (basada en el modelo E/R más que en el relacional):
Entidades, atributos y relaciones en una base de datos
El concepto de entidad en una base de datos es bastante sencillo de entender en general, pero el tema se complica cuando introducimos atributos ya que hay veces que éstos pasan a ser entidades por sí mismos. Vamos con la Wikipedia:
Una Entidad representa una “cosa” u «objeto» del mundo real con existencia independiente, es decir, se diferencia unívocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.
Es decir, generalmente una entidad se convertirá en una tabla de nuestra base de datos que tendrá una serie de atributos. Volvemos a la Wikipedia:
Los atributos son las características que definen o identifican a una entidad. Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que considere más relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.
La clave para poder llegar a unas tablas normalizadas es empezar con un buen diseño conceptual, es decir, intentar hacernos un esquema de las entidades que van a formar nuestra base de datos (que posteriormente se transformarán en tablas).
Ese proceso mental no es algo que fácilmente se pueda plasmar en un artículo de este estilo, simplemente os aconsejo sentaros con vuestro cliente, lápiz y papel y a dibujar entidades. Muchas veces ese diseño inicial se irá modificando al plasmar nuestro universo en nuestra base de datos, pero es importante dedicar tiempo a este paso, sobre todo porque ayuda a aclarar ideas entre el diseñador y el cliente.
Una vez tengamos bien definidas las entidades (futuras tablas), tenemos que decidir junto con nuestro cliente los atributos que va a tener cada entidad. Generalmente la frase que yo le digo al cliente es la siguiente:
Piensa en lo que tú necesitas para tu gestión interna pero sin olvidarte de lo que te van a pedir, desde otros departamentos, tus propios clientes y tus responsables.
Para mí los sistemas de gestión de bases de datos resultan interesantes para una empresa debido a 2 motivos principales:
- Gestión y organización de la información propia (lo que tú necesitas)
- Elaboración de informes de resultados (lo que te van a pedir)
Así que es importante tener claro lo que necesitamos y lo que nos van a pedir de cada entidad, es decir, un diseño correcto de atributos de las entidades. Así que o alargáis la reunión de antes y sacáis punta al lápiz o puede que dentro de unos meses os acordéis de esta frase…
Cuando nos sentemos delante de la pantalla deberíamos de tener por lo menos un mapa con nuestras entidades, los atributos de cada una de ellas y una descripción general del modelo que vamos a plasmar en nuestra base de datos. Esto no quiere decir que vaya a ser un modelo cerrado, todos sabemos que siempre hay que introducir «pequeñas» modificaciones, pero también sabemos que cuanto más «pequeñas» sean, mejor.
En el siguiente artículo empezaremos directamente con la transformación de nuestro modelo a tablas, intentando que directamente estén (por lo menos) en 3ª forma normal.
Serie de artículos
- Normalización de bases de datos – Una mirada práctica II
- Normalización de bases de datos – Una mirada práctica III
- Normalización de bases de datos – Una mirada práctica IV
Arkaitz Arteaga
Latest posts by Arkaitz Arteaga (see all)
- Access: Encriptar contraseñas con SHA-256 utilizando biblioteca de clases .NET con C# - 4 mayo, 2014
- Rendimiento de Access contra backend Access en servidor de archivos remoto. Cuarta parte. - 27 abril, 2014
- Rendimiento de Access contra backend Access en servidor de archivos remoto. Aclaración. - 21 abril, 2014
- Utilizar biblioteca de clases .NET en Access. Tercera aproximación a la Interoperabilidad COM - 14 abril, 2014
- Vincular tablas en Access con Visual Basic - 11 abril, 2014
Una respuesta a Normalización de bases de datos – Una mirada práctica I
Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.
Muy interesante el artículo, pero tengo una duda, si hay que eliminar la redundancia de datos. Significa que si en mi tabla Trabajador tengo un campo que es Estado y tiene dos valores: Activo e Inactivo. Igual debo crear una tabla Estado que tenga dos valores:
1-Activo
2-Inactivo
Y en la tabla trabajador solo coloco el valor del Estado??
Esa sería la manera correcta??