Bases de datos: Quinta forma normal

En esta entrada hablaremos sobre la quinta forma normal, 5FN. Recomiendo por supuesto la lectura de las publicaciones anteriores 4FN y la publicación inicial del hilo de bases de datos aquí.

En entradas anteriores hablamos sobre el proceso de normalización, su importancia, hablamos sobre los 5 niveles anteriores (incluyendo el FNBC o BCFN), y hoy hablaremos sobre el último de los niveles, también quiero agregar que como el anterior, solo debe ser utilizado en caso de que la situación lo requiera.

Ésta no es tan complicada como la 4FN de hecho es bastante sencilla de explicar y se establece de la siguiente manera, una tabla se encuentra en 5FN si y solo si, se encuentra en 4FN y cumple el siguiente requisito:

• No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por claves candidatas.

En otras palabras, cualquier relación de dependencia que haya en la tabla debe estar compuesta por un campo o un grupo de campos que sean clave primaria, y el resto de los campos no clave primaria dependan de los campos anteriores.

Por lo que no puede existir una relación de dependencia en la que no haya una clave primaria y sean simples campos, esto también está apoyado por la 3FN donde se prevee el problema de la dependencia transitiva.

Espero que hayan comprendido hasta éste punto las 6 formas normales (incluyendo la de B-C), quiero agregar como sugerencia la lectura del artículo de wikipedia de normalización.

Saludos!
Soy amante de la programación, me gusta ver y crear cosas nuevas... Me gusta el metal, rock, y también daftpunk jajaja

Read More

Bases de datos: Cuarta forma normal

En ésta entrada trataré de explicar de forma lo más simple posible la cuarta forma normal, 4FN que es bastante dificil de explicar, recomiendo por supuesto la lectura de entradas anteriores del tema FNBC, 3FN, 2FN, 1FN y la publicación introductoria al tema de hace un año.

La 4FN está relacionada con la dependencia multivalor, ésta es aquella dependencia que ocurre con los distintos valores que puede tener un campo y que depende de un valor de un campo x.

Esto es, cuando un campo tiene un valor x, otro campo puede tener alguno de muchos valores que dependan de ese valor de ese campo.

Una tabla está en 4FN si y solo si, la misma se encuentra en 3FN, además cumple con el siguiente requisito:

Para cada una de sus dependencias múltiples no funcionales, asumiendo X como el campo de único valor -cuyo dependiente campo es Y (de múltiples valores)-, éste campo X es clave candidata o grupo de claves candidatas.

En otras palabras tomando la idea de dependencia funcional multivalor, aquel campo con el valor que puede resultar en la dependencia de varios posibles de otro campo, es una clave primaria, o grupo de claves primarias.

Cuando un campo tiene un valor x, otro campo puede tener alguno de muchos valores que dependan de ese valor de ese campo, la tabla estaría en 4FN si el campo del valor x es una clave primaria o conjuntos de claves.

Por supuesto esta forma normal solo será útil cuando existan dependencias funcionales multivalor.

Un saludo, espero que se entienda, me haya explicado bien, y espero les agrade la entrada, para nuevas entradas puedes estar atento al blog, donde seguro la próxima será la 5FN y luego pretendo hablar sobre unas reglas de normalización escritas por Codd.
Soy amante de la programación, me gusta ver y crear cosas nuevas... Me gusta el metal, rock, y también daftpunk jajaja

Read More

Bases de datos: Tercera forma normal

Buenas tardes lectores, en esta entrada hablaremos sobre la tercer forma normal, del proceso de normalización. Recomiendo completamente la lectura de las entradas anteriores Primera forma normal, Segunda forma normal y la entrada de hace casi un año que comenzaba éste hilo de entradas aquí.

Recordemos que el proceso de normalización es un proceso sumamente importante que preve problemas futuros con una base de datos cuando la misma adquiera gran cantidad de registros. El proceso consta en verificar y diseñar las distintas tablas para que cumplan los requisitos de cada uno de los niveles (hasta el nivel que queramos llegar), cuando todas las tablas cumplen los requisitos de un nivel, se dice que la base de datos está en ese nivel, de lo contrario hablamos que tales tablas están en ese nivel.

La tercera forma normal es para muchos el final del camino, ya que a no ser que hablemos de una gran base de datos de gran importancia y que pueda darse el caso que se necesiten los demás niveles, la mayoría de las bases de datos que se ven terminan sus tablas en 3FN.

Una tabla está en 3FN si y solo si se encuentra en 2FN, y cumple con las siguientes características:

No existe ninguna dependencia funcional transitiva entre los campos que no son clave.

Primero explicaremos qué es una dependencia funcional transitiva, recordemos que hay campos que dependen de otros, y que en las FN anteriores los campos debían depender de la clave primaria.

La dependencia funcional transitiva ocurre cuando un campo B depende un campo A, y un campo C depende de un campo B, de modo que se asume que el campo C depende transitoriamente del campo A.

A  B  C, B depende de A, C depende de B, entonces C depende de A.

Veamos la siguiente tabla con los siguientes campos:

fecha_nacimiento, edad, conducir

fecha de nacimiento es la clave primaria en nuestra tabla, vemos que con la fecha de nacimiento podemos conocer la edad, y con la edad podemos saber si tiene la suficiente para poder conducir, entonces podemos deducir solo con la fecha de nacimiento si puede conducir o no, esto es una dependencia funcional transitiva.

De modo que una tabla que tenga dependencias de este tipo no está en 3FN, en cambio si la tabla no tiene dependencias transitivas entonces está en 3FN.

Podemos observar claramente si un campo tiene dependencias de este tipo observando que, si un campo que no es clave primaria, depende de otro campo que no es clave primaria, entonces es muy probable que haya una dependencia transitiva (asumiendo que el segundo campo que no es clave primaria si tenga una dependencia sobre una clave primaria.)

Un saludo para todos y espero les haya gustado la entrada. Sigan al tanto para ver nuevas entradas al respecto.

Read More

Bases de datos: Segunda forma normal

En ésta entrada hablaremos sobre la segunda forma normal en el proceso de normalización de bases de datos. Puedes leer la Primera forma normal, si no la haz leído te recomiendo hacerlo.

Continuamos entonces con el hilo de bases de datos haciendo referencia al proceso de normalización, algo que es casi fundamental a la hora de diseñar una base de datos es tener en cuenta el tema de normalización.

La segunda forma normal hace referencia a la dependencia funcional absoluta, sobre todo cuando haya más de una clave primaria, habíamos visto que para estar en 1FN era necesario que todos los campos sean directamente dependientes de la clave primaria.

Primero, una tabla está en 2FN si y solo si la misma se encuentra en 1FN y cumple con el siguiente requisito:

los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).

Esto quiere decir, que si tienes dos claves primarias, es necesario que cada campo de la tabla que no sea clave primaria dependa de todas las claves primarias, si un campo solo depende de una o algunas (pero no todas) las claves primarias ese campo es erróneo.

Imaginemos una tabla con los siguientes campos:

id_proyecto dni_empleado horas_trabajadas nombre_empleado

(donde dni_empleado e id_proyecto son claves primarias)
como podrán apreciar, las horas trabajadas en el proyecto son dependientes del id del proyecto y del dni del empleado, no podemos saber las horas trabajadas únicamente teniendo el id_proyecto o el dni_empleado, ya que no podremos saber con uno solo de esos cuantas horas trabajó en ese proyecto, por lo que ese campo es correcto, depende de todas las claves primarias de la tabla y no tiene dependencias parciales, pero veamos el campo nombre_empleado, el mismo es erróneo, ya que depende del dni_empleado pero no tiene ninguna dependencia con id_proyecto (no tiene nada que ver el nombre de un empleado con el id de un proyecto) de modo que ese campo no debe estar en esa tabla para que esa tabla esté en 2FN, ya que tiene dependencias parciales.

Un saludo para todos los lectores y espero les haya gustado la explicación breve y simple de 2FN, sigan pendiente del blog para ver las siguientes formas normales.

Read More

Bases de datos: Primera forma normal

En ésta entrada explicaré la primera forma normal para que sus bases de datos queden normalizadas y sean de calidad. Pero antes quiero enlazar la entrada inicial de éste hilo de entradas, hace ya casi un año estaba publicando la primera entrada de éste hilo y no es hasta hoy que puedo continuarlo, ahora que terminé las entradas referentes al Arte de Programar (al menos hasta el momento) puedo dedicar nuevas entradas a cosas importantes también como lo es crear una base de datos normalizada.

Les recomiendo ver ésta entrada del año pasado para tener un panorama de lo que hablaremos aquí.

No obstante comenzaré haciendo la introducción, y es que si hablamos de normalización usted debe comprender la importancia de normalizar su base de datos, cuando usted diseña un sistema x, y diagrama la base de datos, es probable que cometa una cierta cantidad de errores estúpidos que lo lleven a tener una base de datos inestable, inconsistente, y con varios problemas.

Normalizar la base de datos es como comprar un seguro a largo plazo, con una base de datos normalizada usted se asegura que en un futuro no tendrá problemas típicos de las bases de datos, cuando usted tenga la base de datos rellena de datos.

Tenga en cuenta la importancia de normalizar la base de datos al comienzo antes de tener datos cargados, y es que si luego tenemos la base de datos rellena de registros, hacer cambios puede conllevar la ardua tarea de alterar una cantidad significativa de registros, por lo que llevará a un costo muy superior al que puede tener normalizar la base de datos de entrada.

Para poder comprenderlo puede ver la imagen del post, notará que hay niveles de normalización, y cuanto más superior sea el nivel de normalización de la base de datos mejor será su base de datos.

El primer nivel es el 1FN. Debe saber que cuando hablamos de normalizar la base de datos, nos referimos a normalizar cada una de las tablas de la base de datos, y todas estas reglas o formas normales son para procesarlas en tablas particulares.

Una tabla está en 1FN si y solo si:

Una tabla está en Primera Forma Normal si:

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria única.
• La clave primaria no contiene atributos nulos.
• Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Analicemos un poco lo que quiere decir, el primer punto, los atributos son atómicos, significa que un campo no posee varios valores, solo posee uno y solo un valor, y que ese valor no puede ser dividido en dos campos, en otras palabras con un ejemplo sencillo, podemos decir que un campo "Nombre y Apellido" no es atómico ya que cuenta con dos valores tales como el nombre y el apellido, y puede ser dividido en dos campos, uno llamado nombre y el otro llamado apellido.

El segundo punto hace referencia a que la tabla tiene una clave primaria que es clave primaria porque si valor no se puede repetir y es único, lo que quiere decir es que no habrá dos registros con el mismo valor para ese campo llamado clave primaria.

El tercer punto es bastante obvio, la clave primaria no puede contener un valor nulo, como puede pasar en otros campos, en la clave primaria no puede haber un valor nulo, tiene que haber un valor x.

El cuarto punto hace referencia a que cada campo debe estar basado en la clave primaria, en otras palabras, supongamos que tengo una tabla usuarios y yo pongo de clave primaria color de pelo, y el resto de los campos son dni, nombre, apellido, etc. esto sería completamente erróneo, ya que por el color de pelo no puedo deducir el nombre, el apellido y el dni de la persona, en cambio si pusiera de clave primaria DNI, esto sería correcto ya que el nombre, el apellido y el color de pelo se puede obtener basándose en el DNI, entonces todos los demás campos están identificados por esa clave primaria.

Esto es, a grandes rasgos, los requisitos que debe tener una tabla para conciderarse estar en 1FN.

Cada forma normal tiene un objetivo, el objetivo de esta forma normal es eliminar los valores repetidos dentro de una Base de Datos.

Un saludo para todos los lectores y espero les agrade la entrada.

Read More