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.

sábado, 8 de noviembre de 2014

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!

miércoles, 5 de noviembre de 2014

En entradas anteriores vimos Factory Method, y en esta entrada veremos Abstract Factory un patron creacional que amplía el rango de Factory Method. También vimos ObjectPool y una introducción a los patrones de diseño.

Recomiendo leer como minimo el Factory Method para que les sea más sencillo el Abstract Factory.

Si vemos la explicación del Factory Method notaremos que es útil para la creación de objetos de clases subtipos de una en particular, pero si quicieramos tener más de un tipo de clase principal, deberíamos hacer uso de un patrón que lo soporte.

Podemos ver en wikipedia como se explica que si nosotros trabajaramos con botones, dependiendo de la plataforma tendríamos un gran tipo de objeto para botones en linux y uno para botones en windows, si nosotros quicieramos crear objetos de ambos tipos con un factory necesitaríamos utilizar este patrón.

La solución para este problema es simple, si vemos el código de ejemplo de la publicación de Factory Method veremos que la factoría nos permitía crear objetos del tipo de EjemploConcreto, ahora si quicieramos además poder crear de tipode clases OtroEjemploConcreto, bastaría con crear métodos factory para cada clase en particular.

podemos ver el código aquí:

http://pastebin.com/V0HS6fU2

y un diagrama del Abstract Factory extraído de wikipedia:


Un saludo para todos! espero que les haya gustado la entrada y nos veremos la próxima!

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.

domingo, 2 de noviembre de 2014

En una de las entradas anteriores hablamos sobre Patrones de diseño, realizamos una introducción simple y ahora hablaremos sobre el Factory Method, un patrón creacional.

Sugiero ver el patrón anterior, el ObjectPool que incluye una explicación de los patrones creacionales y su razón de ser.

El factory method es un patrón de diseño creado para resolver el problema que sucita a la hora de crear instancias de muchos subtipos de clases que tengan particularidades, los detalles que incluyen pueden resultar innecesarios para el cliente que implemente dichas clases, de modo que se engloba el proceso de construir las instancias en una clase constructora.

Pueden ver un ejemplo del factory method en php en el siguiente enlace:


Espero que les haya gustado la idea, pd: la imagen fue sacada de wikipedia.

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.