Mostrando entradas con la etiqueta normalizacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta normalizacion. Mostrar todas las entradas

domingo, 9 de noviembre de 2014

Buenas tardes lectores, hoy les traigo un pdf del proceso de normalización de base de datos, se transformó casi en una costumbre el hecho de pasar todas las entradas finalizadas de un tema a un formato pdf agregando ajustes, correcciones y extras para deleite de nuestros lectores, la idea es que les sea más cómoda la lectura de entradas relevantes de forma ordenada.
Esto no quiere decir que todas las entradas del blog esté en formato pdf ni que las mejores lo estén, simplemente que los hilos de entrada más relevantes (como calidad de software, bases de datos, proximamente patrones de diseño, y programación, si lo están).

Sin más preambulos les dejo los temas que abarcan y las entradas relacionadas a un click de distancia.

Primera Forma Normal (1FN) (ver entrada relacionada)
Segunda Forma Normal (2FN) (ver entrada relacionada)
Tercera Forma Normal (3FN) (ver entrada relacionada)
Cuarta Forma Normal (4FN) (ver entrada relacionada)
Quinta Forma Normal (5FN) (ver entrada relacionada)


Un saludo lectores y espero les haya gustado la entrada del día de hoy.

lunes, 3 de noviembre de 2014

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.

sábado, 1 de noviembre de 2014

Buenas tardes, en esta entrada hablaremos de la FNBC (Forma Normal de Boyce-Codd), recomendamos la lectura de 1FN 2FN 3FN y el artículo inicial, para tener un panorama de lo que se habla en esta entrada.

La FNBC es una forma normal que se puede considerar como una extensión de la tercera forma normal, establece un requisito extra.

Una tabla se encuentra en FNBC si y solo si se encuentra en 3FN (por lo que también se encuentra en 2FN y 1FN), y cumple el siguiente requisito:

No deben existir dependencias funcionales no triviales.

Esto quiere decir que todos aquellos campos que tienen campos que dependan de ellos, son claves primarias.
En otras palabras que la tabla no tenga campos de este tipo sin ser clave primaria, ya que de lo contrario habría una dependencia transitiva, no obstante tenga mucho cuidado al modificar esto ya que puede al hacer claves primarias a campos de este estilo crear un conflicto con la 2FN suponiendo que no todos los campos sean dependientes del mismo o que con ese campo hayan otros campos que no dependan de las demás claves primarias.

Ésta entrada es bastante simple y corta ya que no hay mucho que agregar a la explicación de FNBC, es bastante sencilla y simplemente una extensión de la 3FN.

Un saludo y espero les guste la entrada, en futuras entradas hablaremos de 4FN y 5FN.

jueves, 23 de octubre de 2014

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.

lunes, 20 de octubre de 2014

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.

lunes, 6 de octubre de 2014

Buenas tardes a todos los lectores, hace mucho no publicaba nada, pero hoy decidí desarrollar y llevar adelante un nuevo pdf sobre programación orientada a objetos.


Hablaremos sobre varias cosas, además de una introducción para iniciados en el tema de la programación orientada a objetos hablaremos sobre la falencia de Singleton, y el error que representa, sobre Wrappers, mi property nunca puede faltar, sobre Factory en php, y sobre el gran problema que tienen hoy en día los framewroks (referido al gran error que tienen en el concepto de programación orientada a objetos)

miércoles, 25 de septiembre de 2013



Buenas tardes a todos, esto ya se va haciendo costumbre y como todos los días hago la publicación del día, continuando con el hilo de "El correcto diseño de bases de datos". Voy a charlar en esta publicación sobre los distintos grados de normalización, y sobre la primera forma normal (FN1). Además voy a recordarles un poco sobre lo previamente publicado hace unos días ("The Data Bases (Las bases de datos)") haciendo un resumen sobre lo que significaba el proceso de normalización.

Pero antes y como siempre voy a aclarar un par de cosas...

sábado, 21 de septiembre de 2013

Buenas tardes, hoy como todos los días y para no perder mi costumbre de "una publicación por día" voy a hablar un poco de bases de datos, se que venía haciendo publicaciones referentes a "El arte de programar" el hilo que tiene que ver con la programación de caracter industrial o profesional como quieran llamarle.
No obstante hoy voy a abrir un nuevo hilo "Diseño de bases de datos", que tratará la temática de como hacer una base de datos como la gente.
Voy a comenzar esta serie de publicaciones diarias hablando sobre el proceso de normalización, ¿qué es el proceso de normalización? ¿en que ayuda el proceso de normalización? ¿qué pasa si no lo aplico?
En proximas entradas me extenderé sobre las formas normales y luego pequeños tips para mejorar tu base de datos.

Pero antes, como siempre voy a aclarar...

Subscribete al RSS Follow me on Twitter!