NORMALIZACIÓN III

                                                                         Aplicaciones

La normalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la normalización, podría crear las tablas basándose en estos grupos.

El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de normalización, siempre será bien Invertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir, para cortar y pegar sus columnas de datos para generar el informe que quiere su jefe.

Otra ventaja de la normalización de su base de datos es el consumo de espacio. Una base de datos normalizada puede ocupar menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco

NORMALIZACIÓN II

                                                                             CUARTA FORMA NORMAL (4FN)

   Ocurre esta forma normal cuando una tabla está en forma normal de Boyce Codd y toda dependencia multivaluada es una dependencia funcional.

Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y y X,Z reproducen sin perder información lo que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN

                                          QUINTA FORMA NORMAL (5FN)

Es la más compleja y polémica de todas. Polémica pues no está claro en muchas ocasiones que sea una solución mejor que el no llegar a este nivel de normalización. Fue definida también por Fagin.

Es raro encontrarse este tipo de problemas cuando la normalización llega a 4FN. Se deben a restricciones muy concretas.

o    Ejemplo:

o Indican códigos de material suministrado por un proveedor y utilizado en un determinado proyecto.

o   Si ocurre una restricción especial como por ejemplo: Cuando un proveedor nos ha suministrado alguna vez un determinado material, si ese material aparece en otro proyecto, haremos que el proveedor nos suministre también ese material para ese proyecto.

o  Eso ocurre en los datos como el proveedor número 1 nos suministró el material número 1 para el proyecto 2 y en el proyecto 1 utilizamos el material 1, aparecerá la tupla proveedor 1, material 1 y proyecto 1.

o    La dependencia que produce esta restricción es lejana y se la llama de reunión. Para esa restricción esta división en tablas sería válida:

o    Esa descomposición no pierde valores en este caso, sabiendo que si el proveedor nos suministra un material podremos relacionarle con todos los proyectos que utilizan ese material.

o    Resumiendo, una tabla no está en quinta forma normal si hay una descomposición de esa tabla que muestre la misma información que la original.

NORMALIZACIÓN I

                                                                Aplicaciones

Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.

¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.

Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal". Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.

Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.

TEORÍA DE NORMALIZACIÓN

                                                            Diccionario de Datos

Un Diccionario de Datos es una forma de documentación para el diseñador de bases de datos. Su utilidad básica se describe en las siguientes funciones:

1. Describir el propósito de la BD y quiénes serán sus usuarios.

2. Documentar las especificaciones detrás de la BD misma: en qué dispositivo estará almacenada, cuál será el tamaño estándar de la BD junto con sus archivos lógicos (aquellos que almacenan información sobre operaciones en algunos sistemas de gestión de BD).

3. Almacenar código fuente de SQL referente a la instalación y desinstalación de la BD, incluida también documentación respecto al uso de herramientas de importar/exportar.

4. Proveer una detallada descripción de cada tabla dentro de la BD y explicar su propósito en términos de procesos de negocios.

5. Documentar la estructura interna de cada tabla, incluyendo todos sus campos y sus tipos de datos con comentarios, todos los índices y todas las vistas.

6. Contener todo el código fuente SQL para todos los procedimientos y triggers.

7. Describir reglas como pueden ser el uso de valores no nulos, valores únicos.

Algunos programas CASE auxilian al diseñador de BD en la creación y mantenimiento de un Diccionario de Datos.

                                                             Normalización

Es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.

Primera Forma Normal

La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. La normalización ayuda a clarificar la base de datos y a organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, sólo tenemos que entender los objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños.

Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.

Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayoría de los problemas de lógica. Podemos insertar un registro sin un exceso de datos en la mayoría de las tablas.

Tercera Forma Normal

Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.

Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se insertan o borran registros. Cada columna en una tabla está identificada de manera única por la llave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

MODELO DE DATOS E/R

                                                           Tecnica de Aplicaciones

1.      Define el contenido exacto de cada archivo de datos.

2.      Son detalladas las características de todos los datos que serán almacenados en cada tabla definida en el RDM.

3.      Debe ser realizado un relevamiento detallado para definir cada dato.

4.      Obtener el menor número posible de datos en cada tabla.

5.      Esos datos deben ser suficientes para capturar todas las entradas.

6.      También deben ser suficientes para derivar todas las salidas (informaciones necesarias).

7.      Se debe visitar el lugar en donde las entidades y sus datos son “utilizados”.

8.      El usuario debe participar y debe comprometerse con estas definiciones.

9.      Se Debe definir el dominio y la regla de validación para cada dato.

10.  Para cada dato de cada archivo se debe definir:
a.       Nombre del dato
b.      Descripción del dato
c.       Tipo de dato
d.      Calificador del tipo de dato (Ej.: extensión)
e.        Formato del dato
f.        Dominio
g.       Reglas de validación
h.       Origen del dato
i.         Responsabilidad por el dato

11.  En cada tabla se debe definir:
a.       Llave-primaria
b.      Llaves-foráneas
c.       Llaves-secundarias

12.  Para el RDM como un todo se debe analizar:
a.       Nombres lógicos
b.      Nombres físicos (nombres código)
c.       Sinónimos
d.      Homónimos
e.       Estructuras de datos embutidas
f.       Llaves múltiplas
g.      Reglas de Validación (a nivel de datos, tablas y relaciones)

Semana 9

                                                           Atributos y Dominios

1.-Atributos:

Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.

Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos sobre un mismo dominio.

Los atributos pueden ser simples o compuestos:

*Atributo simple: Es un atributo que tiene un solo componente, que no se puede dividir en partes más pequeñas que tengan un significado propio.

*Atributo compuesto: Es un atributo con varios componentes, cada uno con un significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente mediante un óvalo.

Los atributos también pueden clasificarse en:

* Atributo monovalente: Es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la que pertenece.

*Atributo polivalente: Es aquel que tiene varios valores para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es .
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente deben pertenecer a la misma entidad o relación.


2.-Dominio:

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".

   *El valor NULL no forma parte del dominio

   *Todos los atributos tienen un solo dominio que nunca cambia
 
   *Los dominios son diferentes entre ellos

   *Podemos especificar los operadores válidos para manipular los valores del dominio.

   * Ningún SGBD lo implementa SQL no tiene dominios.

   *Cada dominio tiene un nombre diferente

   *Hay dos clases de dominios:

           -Simples: atributo simple Entero, string, carácter, boolear (true / falso), real.

          - Compuesto: Combinación de simples.

Los dominios restringir las comparaciones (entre dominios diferentes. Ej.: entre edades) y las operaciones extrañas.

Ejemplo:Deportista. Edad es del dominio EDAD

             Deportista. Peso es del dominio PESO

Los dominios se encuentran definidos en el diseño de la BD (Los dominios se han de definir en la base de datos, sino se han de definir aparte. Especificaremos lo máximo posible).

Semana 8

Recursivas:

Modelan las situaciones en que dos entidades del mismo conjunto se relacionan entre sí.

Es necesario especificar el rol de cada entidad en la relación.

Entidades Asociativas:

La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.

La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

Dependencias Funcionales:

Son restricciones de integridad sobre los datos. Conocer las dependencias funcionales en el momento del diseño de la base de datos permite crear mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.

 A veces es fácil encontrar dependencias en un esquema. Esto es un indicador de un mal modelo entidad-relación o de una mala conversión a relacional.

Por ejemplo, sea Película (título, año, estudio, presidente, fono presidente). Digamos que “título” es llave de la relación (determina todo). Sin embargo, notemos que el presidente de un estudio se puede determinar conociendo el estudio y el año (idealmente). Luego, estudio, año! presidente.

Además, es claro que presidente! fono presidente.La relación “Película” fue mal modelada desde un principio. En un modelo entidad-relación, “Película”, “Estudio” y “Presidente” habrían sido entidades distintas, luego relaciones distintas en el modelo relacional.