CAPITULO 12 ENTIDADES Y NORMALIZACION ENTIDADES Una entidad, como definimos anteriormente, en algo sobre lo cual almacenamos datos. Puede ser un objeto tangible como un empleado, una parte, un cliente, una herramienta de una máquina, o una oficina. Puede ser intangible como un título de trabajo, un centro de beneficio, una asociación, una concesión financiera, una compra, un estimado, o una petición de seguro. Al analizar la información nosotros estudiamos las entidades de la empresa en cuestión. Una corporación típica tiene varios cientos de tipos de entidades. Su conjunto de tipos de entidades no cambia mucho con el tiempo a menos que la corporación se mueva a un tipo de negocio fundamentalmente distinto. Los tipos de entidades se muestran en un diagrama entidad-relación como se discutió en el Capítulo 7. Una entidad tiene diversos atributos que queremos registrar, tales como tamaño, valor, fecha, color, uso, código, dirección, calidad, código de performance, etc. A menudo en el procesamiento de datos tenemos en cuenta una colección de entidades similares, tales como empleados, y queremos registrar información sobre los mismos atributos de cada uno de ellos. Comúnmente un programador mantiene un registro sobre cada entidad, y un solo detalle los datos en cada registro se relaciona con cada atributo. Los registros similares son agrupados en archivos. El resultado, mostrado en fig.12.1 es un array de dos dimensiones. Dentro del Cuadro 12.1 está un conjunto de detalles de datos. Se muestra el valor de cada detalle de datos. Cada fila de detalles de datos se relaciona con una entidad particular. Cada columna contiene un tipo particular de detalle de datos, relacionándose con un tipo particular de atributo. En la parte superior del diagrama, fuera del cuadro, se escriben los nombres de los atributos. La columna que está más a la izquierda en el cuadro contiene los detalles de datos que identifican a la entidad. La entidad en este ejemplo es una persona, un empleado. El atributo referido como el identificador de la entidad es en este caso NUMERO DE EMPLEADO. Dicho array de dos dimensiones algunas veces es referido como un archivo plano. El uso de archivos planos data de los inicios del procesamiento de datos cuando el archivo podía haber estado en tarjetas perforadas. Cada tarjeta en un archivo o grupo de tarjetas tales como en fig.12.2 podía contener un registro, relacionado con una entidad. Ciertas tarjetas izquierda en el cuadro contiene los detalles de datos que identifican a la entidad. La entidad en este ejemplo es una persona, un empleado. El atributo referido como el identificador de la entidad es en este caso NUMERO DE EMPLEADO. Dicho array de dos dimensiones algunas veces es referido como un archivo plano. El uso de archivos planos data de los inicios del procesamiento de datos cuando el archivo podía haber estado en tarjetas perforadas. Cada tarjeta en un archivo o grupo de tarjetas tales como en fig.12.2 podía contener un registro, relacionado con una entidad. Ciertas columnas de tarjetas eran colocadas para cada tipo de detalle de datos, o atributo, y eran llamados un campo. Cuando las cintas magnéticas reemplazaron a las pilas de tarjetas y cuando los discos reemplazaron a las cintas magnéticas, muchos programadores mantenían su visión de los datos como que estaban organizados en archivos planos. REGISTROS DE ENTIDAD Al examinar los datos que necesitan ser almacenados en una corporación inicialmente pensaremos en esto como una colección de archivos planos como en Fig.12.1 o 12.2. Cada archivo plano contiene información sobre un tipo de entidad. Un registro en ese archivo contiene información sobre una ocurrencia de esa entidad. Por ejemplo, un registro CLIENTE contiene información sobre un CLIENTE. Nos referiremos a esto como un registro de entidad. El registro de entidad es una consideración lógica de los datos. Los datos pueden estar almacenados en una forma físicamente diferente dentro de una base de datos. El registro de entidad contiene datos sobre uno y sólo un tipo de entidad. Este contiene todos los atributos de esa entidad que son almacenados. Cuando usamos el término registro de entidad, entonces, no nos estamos refiriendo a ninguna vieja colección de detalles de datos sino más bien a un agrupamiento especial de los datos. Nos referimos a estos como datos normalizados y usamos el término cuarta forma normal, que explicaremos en este capítulo. NORMALIZACION DE LOS DATOS El término normalización de los datos se refiere a la forma en que los detalles de los datos son agrupados en estructuras de registro. La cuarta (o tercera) forma normal es un agrupamiento de datos diseñado para evitar anomalías y problemas que pueden ocurrir con los datos. El concepto se originó con las matemáticas de E.F.Codd, que se da en el Apéndice III. Con datos de cuarta forma normal, cada detalle de dato en un registro se refiere a una clave particular que únicamente identifica a ese dato. La clave en sí misma puede estar compuesta de más de un detalle de dato. Cada detalle de dato dentro del registro está identificado por la clave general, no sólo con parte de la clave. Ningún detalle de dato en el registro es identificable por otro detalle de dato en el registro que no sea parte de la clave. La simplicidad básica de la cuarta forma normal hace fáciles de comprender a los registros de datos, y más fáciles de cambiar cuando los datos están organizados en formas menos rigurosas. Formalmente agrupa los detalles de datos que están asociados con cada tipo de entidad (y también aquellos que están asociados con más de un tipo de entidad), y separa los detalles de datos que pertenecen a diferentes tipos de entidades. La cuarta forma normal protege de las anomalías que de otro modo pueden ocurrir. Permite que se establezcan reglas para controlar la desintegridad semántica en lenguajes de consulta. En la vida real los datos se encuentran en grupos de detalles de datos. Existen en facturas, facturas de peso, formas de impuesto, licencias de conducir, etc. Estos agrupamientos usualmente no están en una forma normalizada. No es de sorprender que los analistas de sistemas a menudo hayan implementado registros de computadoras que tampoco están normalizados. Sin embargo, los datos que no están normalizados pueden conducir a diversos problemas poco notorios en el futuro. La experiencia ha mostrado que cuando los datos del computador están organizados en cuarta forma normal, las estructuras de datos resultantes son más estables y capaces de acomodar el cambio. Cada atributo se relaciona con su propia entidad y no se confunde con atributos relacionados con entidades diferentes. Las acciones que crean y actualizan datos pueden entonces aplicarse con un simple diseño estructurado a un registro normalizado a la vez. En el momento de la escritura sólo una pequeña proporción de bases de datos existentes están normalizadas. Algunas corporaciones tienen varios años de experiencia de operación de estructuras de datos de cuarta (o tercera) forma normal. No hay duda de que se han beneficiado grandemente con este tipo de diseño, especialmente cuando se combina con otros pasos que son parte de una buena administración de los datos. Reaccionando a los beneficios percibidos, algunas corporaciones han incorporado en sus manuales de estándares de bases de datos el requisito de que todas las estructuras de bases de datos se diseñen en cuarta forma normal. La implementación física ocasionalmente puede desviarse de la cuarta forma normal si la selección se explora y documenta completamente. Usualmente, los datos normalizados son mejores en términos de requisitos de máquina así como en una estructuración lógica, pero no siempre éste es el caso. Algunas veces el diseñador físico encuentra conveniente desviarse de la cuarta forma normal. Entonces es necesario un compromiso. ¿Qué es preferible: un desempeño de máquina mejor en cierto modo, o una mejor protección de los costos de mantenimiento? Usualmente, los costos de mantenimiento potencial son los más altos. Para poner los datos en cuarta forma normal, se pueden usar cuatro pasos. Ponerlos en primera forma normal, luego en segunda, tercera y cuarta forma normal. El Cuadro 12.1 los resume. Las ideas básicas de esta normalización de datos son simples, pero las ramificaciones son muchas y poco claras, y varían del uso de un tipo de base de datos a otro. Es importante observar que la normalización describe la representación lógica de los datos, no la representación física. Existen múltiples formas de implementarlos físicamente. El Cuadro 12.2 proporciona la terminología usada en la discusión de los datos. CUADRO 12.1 La normalización de los datos Datos no normalizados (registros con grupos que se repiten) 1. Descomponer todas las estructuras de datos no planos en dos registros bidimensionales. Primera forma Normal (registros sin grupos que se repiten) 2. Para los registros cuyas claves tienen más de un detalle de dato, asegurarse que todos los demás detalles de datos sean dependientes de la clave completa. Dividir los registros, si es necesario, para lograr esto. Segunda Forma Normal (Todos los detalles de datos sin clave totalmente funcionalmente dependientes de la clave primaria) 3. Eliminar todas las dependencias transitivas dividiendo el registro, si es necesario, para lograr esto. Tercera Forma Normal (Todos los detalles de datos sin clave totalmente funcionalmente dependientes de la clave primaria e independientes unos de otros) 4. Eliminar cualquier dependencia condicional, dividiendo el registro, si es necesario, para lograr esto. Cuarta Forma Normal (una variante menor de la tercera forma normal, que a menudo se ignora) CUADRO 12.2 Vocabulario usado en la discusión de los datos (Ver también fig.12.1) El lector deberá distinguir claramente entre los términos tipo de dato y tipo de detalle de dato. Tipo de dato se refiere a los datos en sí (es decir, datos respecto a los datos). Los ejemplos de tipos de datos son entero, número racional, booleano, y cadena alfabética. Tipo de entidad se refiere a una determinada clase de entidades, tales como cliente, parte, cuenta, empleado, etc. Atributo se refiere a una característica de un tipo de entidad: por ejemplo, color, forma, fecha de embarque, tipo de cuenta, valor en dólares, etc. Cuando hablamos de tipo de detalle de dato nos referimos a un tipo de entidad o a un atributo. Detalle de dato expresa un atributo o identificador de entidad (un tipo especial de atributo) en forma que se puede computarizarse, algunas veces se describe como campo. Tipo de detalle de dato se refiere a una determinada clase de detalle de datos. Ejemplos de tipos de detalles de datos son número de cliente, número de cuenta, dirección, valor en dólares y color. Las entidades y detalles de datos son ejemplos de tipos de entidad y tipos de detalle de datos. Por ejemplo, DUPONT es un ejemplo del tipo de entidad cliente. ROJO es un ejemplo del atributo color. El detalle de dato 4789123 es un ejemplo del tipo de detalle de dato número de empleado. En la discusión de los datos algunas veces abreviamos. Decimos "entidad" cuando queremos indicar "tipo de entidad", "detalle de dato" cuando queremos indicar "tipo de detalle de dato", etc. "Tipo de dato" nunca se abrevia. PRIMERA FORMA NORMAL La primera forma normal se refiere a una colección de datos organizados en registros que no tienen grupos repetidos de detalles de datos dentro de un registro. En otras palabras, son archivos planos, matrices bidimensionales, de detalles de datos. Dicho archivo plano puede considerarse como una simple tabla bidimensional. Sin embargo, puede contener miles de registros. La mayoría de lenguajes de programación dan a los programadores la capacidad de crear y referirse a los registros que no son planos (esto decir, estos contienen grupos de detalles de datos que se repiten dentro de un registro). En COBOL se llaman tablas de datos. Pueden haber tablas de datos dentro de las tablas de datos -grupos que se repiten dentro de los grupos que se repiten. El siguiente registro en COBOL contiene dos grupos de datos, llamados BIRTH y SKILLS. BIRTH (nacimiento) no causa problemas porque ocurre sólo una vez en cada registro. SKILLS (experiencia) puede ocurrir varias veces dentro de un registro, por eso es una tabla de datos y el registro no está en primera forma normal. No es un registro plano bidimensional. Para normalizarlo, la tabla SKILLS deberá removerse y colocarse en un registro separado, por lo tanto: El registro inferior tiene una clave concatenada EMPLOYEE# + SKILLCODE. No podemos conocer SKILLYEARS (el número de años de experiencia que un empleado ha tenido con una habilidad determinada) a menos que conozcamos EMPLOYEE# (el número del empleado a quien esto se refiere) y SKILLCODE (la habilidad en cuestión). En general, un registro que no es plano se normaliza convirtiéndolo en dos o más registros planos. Si los registros normalizados de arriba fuesen implementados en un CODASYL, DL/1, u otro sistema de administración de base de datos no relacional, no podríamos repetir el detalle de dato EMPLOYEE# en el registro inferior. Un enlace con el registro superior implicaría esta clave: Una base de datos relacional emplearía un registro SKILLS separado (relación) con una clave EMPLOYEE + SKILLCODE; evita por tanto mecanismos de puntero en la representación lógica de los datos. Aquí no estamos interesados en cómo se realiza la implementación física,sino en la representación lógica general de los datos. Necesitamos analizar y hacer una tabla de los recursos de información de una empresa y cómo son usados. Graficamos el registro inferior con su clave completamente concatenada para que pueda estar aislada y únicamente identifique los datos en el registro. DEPENDENCIA FUNCIONAL Al intentar graficar las relaciones entre detalles de datos, el diseñador debe conocer cuáles detalles de datos son dependientes de cuáles otros. La frase funcionalmente dependiente se define como sigue: El detalle de dato B de un registro R es funcionalmente dependiente del detalle de dato A de R si, en todo momento, cada valor en A no tiene más de un valor en B asociado con éste en el registro R. Decir que B es funcionalmente dependiente de A es equivalente a decir que A identifica a B. En otras palabras, si conocemos el valor de A, podemos encontrar el valor de B asociado con éste. Por ejemplo, en un registro de empleado, el detalle de dato SALARY es funcionalmente dependiente de EMPLOYEE#. Para un EMPLOYEE# existe un SALARY. Para encontrar el valor de SALARY (salario) en una base de datos, normalmente Ud iría por EMPLOYEE#. Este último es una clave que identifica al atributo SALARY. Graficaremos una dependencia funcional con una línea que tiene una pequeña barra (como una "l") sobre ésta, por lo tanto: EMPLOYEE#-----+-SALARY Indica que un ejemplo de SALARY está asociado con cada EMPLOYEE#. Considerar el registro para la entidad EMPLOYEE. Las dependencias funcionales en este registro son como sigue: EMPLOYEE# es dependiente de EMPLOYEE-NAME EMPLOYEE-NAME SALARY PROJECT# COMPLETION-DATE es dependiente de EMPLOYEE# es dependiente de EMPLOYEE-NAME o EMPLOYEE# es dependiente de EMPLOYEE-NAME o EMPLOYEE# es dependiente de EMPLOYEE-NAME, EMPLOYEE# o PROJECT#. EMPLOYEE# no es funcionalmente dependiente de SALARY porque más de un empleado podría tener el mismo salario. Igualmente, EMPLOYEE# no es funcionalmente dependiente de PROJECT#, pero COMPLETION-DATE sí. Ningún otro detalle de dato en el registro es completamente dependiente de PROJECT#. Podemos graficar estas dependencias funcionales como sigue: Un detalle de dato puede ser funcionalmente dependiente de un grupo de datos en lugar de un solo detalle de dato. Considerar, por ejemplo, el siguiente registro, que muestra cómo los programadores utilizan su tiempo: Se muestran en la red los campos que constituyen la clave primaria (identificador único). TOTAL-HOURS-WORKED es funcionalmente dependiente de la clave concatenada (PROGRAMMER#,PACKAGE#). Las dependencias funcionales en este registro pueden graficarse como sigue: DEPENDENCIA FUNCIONAL COMPLETA puede decirse que un detalle de dato o una colección de detalles de datos, B, de un registro R es totalmente funcionalmente dependiente de otra colección de detalles de datos, A, del registro R si B es funcionalmente dependiente del conjunto de A pero no de ningún subconjunto de A. Por ejemplo, en el registro de arriba, TOTAL-HOURS-WORKED es totalmente funcionalmente dependiente de la clave concatenada (PROGRAMMER#,PACKAGE#) porque se refiere a cuántas horas ha trabajado un determinado programador en un determinado paquete. Ni PROGRAMMER# por separado ni PACKAGE# por separado identifican a TOTAL-HOURSWORKED. TOTAL-HOURS-WORKED, sin embargo, es el único detalle de dato que es totalmente funcionalmente dependiente de la clave concatenada. PROGRAMMER-NAME es totalmente funcionalmente dependiente de PROGRAMMER#, y PACKAGE-NAME es totalmente funcionalmente dependiente de PACKAGE#. Las líneas con barras de arriba hacen claras las dependencias. SEGUNDA FORMA NORMAL Ahora estamos en posición de definir la segunda forma normal. Primero una simple definición: Cada atributo en un registro es funcionalmente dependiente de la clave entera de ese registro. Donde la clave consista de más de un detalle de dato, el registro no puede estar en segunda forma normal. El registro de arriba con la clave PROGRAMMER#+PACKAGE# no está en segunda forma normal porque TOTAL-HOURS-WORKED depende de la clave entera, mientras PROGRAMMER-NAME y PACKAGE-NAME dependen cada uno de sólo un detalle de dato en la clave. Igualmente, el siguiente registro no está en segunda forma normal: Fig.12.3 Conversión a segunda forma normal Un ejemplo de este registro Para convertir los registros de arriba en segunda forma normal, lo dividimos en dos registro, por lo tanto: Un ejemplo del par de registros de arriba: Existen pocos problemas que pueden resultar de este registro que no está en segunda forma normal: 1. No podemos ingresar detalles sobre un proveedor hasta que el proveedor entregue una parte. Si el proveedor no entrega una parte, no existe clave. 2. Si un proveedor temporalmente tiene que dejar de entregar cualquier parte, el borrado del último registro que contiene ese SUPPLIER# también borrará los detalles del proveedor. Normalmente sería conveniente que se conserve SUPPLIER-DETAILS. 3. Tenemos problemas cuando intentamos actualizar detalles. Debemos buscar todo registro que contenga a ese proveedor como parte de la clave. Si un proveedor entrega muchas partes, será necesaria una actualización más redundante de los detalles del proveedor. Estos tipos de irregularidades pueden eliminarse dividiendo el registro en dos registros en segunda forma normal, como se muestra en fig.12.3. Sólo PRICE es totalmente funcionalmente dependiente de la clave concatenada, por tanto todos los demás atributos se llevan a un registro separado a la izquierda, que sólo tiene a SUPPLIER-NUMBER como su clave. El dividir a segunda forma normal es el tipo de división que el crecimiento natural de la base de datos tiende a forzar, por tanto esto también podría anticiparse cuando recién se arregla la base de datos. En general, todo detalle de dato en un registro será dependiente de la clave entera; de lo contrario, se llevará a un registro separado. La fig.12.3 ilustra la división del registro anterior en registros en segunda forma normal. CLAVES CANDIDATAS La clave de un registro normalizado debe tener las siguientes propiedades: 1. Identificación única. Para toda ocurrencia del registro la clave debe identificar únicamente al registro. 2. No redundancia. Ningún detalle de datos en la clave puede descartarse sin destruir la propiedad de identificación única. Algunas veces ocurre que más de un detalle de dato o conjunto de detalles de datos podría se la clave de un registro. Tales elecciones alternativas se denominan claves candidatas. Una clave candidata deberá designar la clave primaria. Graficaremos las dependencias funcionales para las claves candidatas que no son la clave primaria debajo del registro, por lo tanto: En esta ilustración EMPLOYEE-NAME es considerado la clave candidata-una alternativa para EMPLOYEE#. Generalmente no se hace ya que dos empleados podrían tener el mismo nombre. Sólo EMPLOYEE# es verdaderamente único. La posible existencia de claves candidatas complica las definiciones de segunda y tercera forma normal. Una definición más comprensiva de segunda forma normal es: Un registro R está en segunda forma normal si está en primera forma normal y todo detalle de dato no principal de R es totalmente funcionalmente dependiente de cada clave candidata de R. En el registro EMPLOYEE anterior, las claves candidatas sólo tienen un detalle de dato, y por tanto el registro siempre está en segunda forma normal porque los detalles de datos no principales deben ser totalmente dependientes de las claves candidatas. Cuando las claves candidatas consisten de más de un detalle de datos, una registro en primera forma normal no puede estar en segunda forma normal. TERCERA FORMA NORMAL Un registro que está en segunda forma normal puede tener otro tipo de anomalía. Puede tener un detalle de dato que no sea una clave sino que identifique otros detalles de datos. A esto se llama una dependencia transitiva. Las dependencias transitivas pueden causar problemas. El paso de poner los datos en tercera forma normal elimina las dependencias transitivas. Suponer que A,B y C son los tres detalles de datos o diferentes colecciones de detalles de datos de un registro R. Si C es funcionalmente dependiente de B y B es funcionalmente dependiente de A, entonces C es funcionalmente dependiente de A. Si el mapeo inverso no es simple (es decir, si A no es funcionalmente dependiente de B o B no es funcionalmente dependiente de C), se dice que C es transitivamente dependiente de A. En una diagrama C es transitivamente dependiente de A si La conversión a tercera forma normal elimina esta dependencia transitiva dividiendo el registro en dos, por tanto: El siguiente registro no está en tercera forma normal porque COMPLETION-DATE es dependiente de PROJECT#. Uno pocos problemas podrían resultar de este registro que no está en tercera forma normal: 1. Antes de que algún empleado sea reclutado para un proyecto, la fecha de cumplimiento del proyecto no puede registrarse porque no existe ningún registro EMPLOYEE. 2. Si todos los empleados deben abandonar el proyecto, por lo tanto el proyecto no tiene empleados hasta que se recluten a otros, todos los registros que contienen la fecha de cumplimiento se borran. Esto puede considerarse como una ocurrencia improbable, pero en otros tipos de archivos un peligro similar de pérdida de la información puede ser menos improbable. 3. Si se cambia la fecha de cumplimiento, será necesario buscar todos los registros que contienen la fecha de cumplimiento, y actualizarlos. Una simple definición de tercera forma normal es: Un registro que está en segunda forma normal y cada atributo es funcionalmente dependiente de la clave y nada más que la clave. Una definición más formal que incorpora claves candidatas es como sigue: Un registro R está en tercera forma normal si está en segunda forma normal y todo detalle de dato no principal de R no es transitivamente dependiente de cada clave candidata de R. La fig.12.4 muestra la conversión del registro EMPLOYEE de arriba a su tercera forma normal. La conversión a tercera forma normal produce un registro separado para el registro entidadnormalizado. Por ejemplo, la fig.12.4 produjo un registro separado para la entidad PROJECT. Generalmente, este registro normalizado sería necesario. Necesitamos datos almacenados separadamente para cada entidad. fig.12.4 Conversión a tercera forma normal Un ejemplo de este registro Para convertir el registro de arriba a tercera forma normal lo dividimos en dos registros, por tanto: Un ejemplo del par de registros de arriba: ALMACENAMIENTO Y PERFORMANCE El concepto de normalización se aplica a todas las bases de datos. La experiencia ha mostrado que los registros de un sistema CODASYL, los segmentos de un sistema DL/l, o el grupo de detalles de datos en otros sistemas pueden beneficiarse al ser normalizados. Se escuchan objeciones ante la normalización en terrenos donde se requiere más almacenamiento y más tiempo de máquina. Una estructura de cuarta forma normal usualmente tiene más registros después de todas las divisiones descritas anteriormente. ¿No es esto peor desde el punto de vista de hardware? No necesariamente. En verdad, a pesar que existen más registros, estos casi siempre toman menos almacenamiento. La razón es que usualmente ningún registro de cuarta forma normal tiene mucha redundancia de valores. Comparar los registros en fig.12.3. Aquí los registros que no están en segunda forma normal se convierten a segunda forma normal mediante la división. Se verá que la parte inferior sombreada de Fig.12.4 tiene menos valores de SUPPLIER-NAME y SUPPLIER-DETAILS. Esta reducción no parece muy dramática en una ilustración tan pequeña. Si hubieran miles de proveedores y miles de partes, y muchos atributos de ambos, la reducción hubiese sido espectacular. Nuevamente, comparar las partes sombreadas de Fig.12.4. Aquí un registro es convertido a tercera forma normal mediante la división. El número de valores de datos se reduce. Existen menos valores de COMPLETION-DATE registrados después de la división. Una vez más, si hubieran muchos empleados, muchos proyectos, y muchos atributos de aquellos proyectos, la reducción hubiese sido dramática. DEPENDENCIAS CONDICIONALES Usualmente, el proceso de normalización se detiene en la tercera forma normal. Existen dos puntos poco claros que podrían resultar en una etapa adicional de normalización. Primero, si la clave primaria (identificador único) tiene tres o más campos con dependencias de múltiples valores dentro de la clave, puede ser necesaria una etapa adicional para aclarar. Segundo, un registro en tercera forma normal podría tener una dependencia condicional dentro de sí, y ésta se elimina dividiendo el registro nuevamente. Considerar el siguiente registro con la clave primaria CUSTOMER-NUMBER: STATE-TAX existe sólo para clientes pertenecientes al estado de la compañía de embarque, por decir, Vermont. Para la mayoría de clientes no existe tarifa estatal porque están fuera del estado. La existencia del campo es condicional. El registro por lo tanto puede dividirse para que STATE-TAX esté en un archivo separado (relativamente pequeño): El enlace de CUSTOMER-NUMBER a STATE-TAX se denomina una dependencia condicional. La eliminación de las dependencias condicionales algunas veces se denomina la cuarta etapa de normalización. Se muestra en el último paso en Fig.12.1. La conversión a tercera forma normal casi siempre reduce la cantidad de almacenamiento usado, a menudo drásticamente. ¿Qué sucede con el tiempo de máquina y accesos? A menudo éste es menor después de la normalización. Antes de la normalización muchos aspectos de los datos se confunden y deben leerse todos a la vez. Después de la normalización estos se separan, por lo tanto se lee un registro pequeño. Además, debido a que existe menos redundancia de valores en la tercera forma normal, existe menor actualización duplicada de valores redundantes. Suponer que el proyecto x posterga su fecha de cumplimiento (lo que hace todas las semanas!). En el registro en la parte superior de Fig.12.4 la fecha de cumplimiento tiene que cambiarse siete veces, en la versión de tercera forma normal sólo tiene que cambiarse una vez. Un argumento similar se aplica para SUPPLIER-NAME y SUPPLIER-DETAILS en Fig.12.3. El argumento tendría más fuerza si los ejemplos tuvieran cientos de empleados, miles de proveedores, y muchos atributos que tengan que ser actualizados. Sin embargo existen excepciones a esto. En raras ocasiones un diseñados puede diseñar conscientemente registros que no estén en tercera forma normal por razones de performance. La normalización se relaciona con la estructura lógica de los datos, no necesariamente la estructura física. DESINTEGRIDAD SEMANTICA Una razón adicional para usar datos normalizados es que ciertas interrogantes de las bases de datos pueden llevar a problemas cuando los datos no están claramente estructurados. Una interrogante, tal vez, ingresada con un lenguaje de interrogación de base de datos puede aparecer como válida, pero en verdad tiene aspectos ilógicos algunas veces referidos como desintegridad semántica. Cuando los datos están en tercera forma normal, pueden idear reglas para evitar la desintegridad semántica o advertir al usuario sobre su interrogante. ACLARAR EL PENSAMIENTO RESPECTO A LOS DATOS La normalización es una ayuda para aclarar el pensamiento sobre los datos. Es un método formal de separar los detalles de datos que se relacionan con diferentes entidades. Un registro en cuarta forma normal tiene la siguiente estructura clara y simple: Las líneas de dependencia funcional parten de la clave primaria. No existen dependencias escondidas que no se relacionen con la clave. Si la clave es concatenada, todos los detalles de datos son dependientes de la clave entera. Podemos dar una ligera definición de cuarta forma normal, que tiene la ventaja de ser fácil de recordar: Todo detalle de dato en un registro que es dependiente de la clave, la clave completa, y nada más que la clave. Si un analista de sistemas recuerda esta definición (comprendiendo de que no es rigurosa como las anteriores de este capítulo), rápidamente puede marcar y modificar registros que no están en cuarta forma normal. Debe estar lo suficientemente familiarizado con esto para que esté alerta cada vez que vea registros que no estén en tercera forma normal. Este agrupamiento simple y claro es fácil de implementar y usar. Habrán complicaciones de almacenamiento en el futuro si se usan estructuras de registros más complejas. Para el administrador de base de datos, la normalización es una ayuda para la precisión. Una base de datos normalizada puede crecer y evolucionar naturalmente. Las reglas de actualización son directas. Un tipo de registro en cuarta forma normal puede tener registros sumados a éste o puede tener registros borrados sin los problemas que podrían ocurrir con tipos de registros no normalizados. La estructuración en cuarta forma normal proporciona una visión simple de los datos a los programadores y usuarios, y hace menos probable que ejecuten operaciones no válidas. La fig.12.5 da una ilustración simplificada de los tres principales pasos para lograr datos normalizados. La fig.12.6 ilustra la progresión a cuarta forma normal. UN EJERCICIO SUGERIDO Probablemente la mejor forma para que un usuario del procesamiento de datos se convenza del valor de la normalización sería tomar una sección de sus archivos y escribir qué registros en tercera forma normal serían usados para representarlos. Un grupo de analistas de sistemas debería entonces listar todos los cambios importantes que podrían ocurrir con los archivos a medida que el procesamiento de datos va evolucionando, y ver cuántos de estos cambios necesitarían restructurar los registros de tal forma que los programas de aplicación previamente escritos tuvieran que ser cambiados. Compare esto con qué reprogramación sería necesaria si los mismos cambios fuesen aplicados a los registros existentes. Examinando las bases de datos existentes nuestra experiencia ha sido que una y otra vez éstas no están normalizadas. Esto se traduce en problemas para el futuro. A menos que ésta sea la política de manejo consciente para crear datos normalizados, el diseño ha estado lejos de estos principios. UN EJEMPLO DE NORMALIZACION Considerar un registro ORDER con la siguiente estructura no normalizada: ORDER (número de orden, fecha de la orden, número de cliente, nombre del cliente, dirección del cliente, estado de exportación, número de impuesto, ((número de producto, nombre del producto, cantidad ordenada, precio del producto, total de productos)), total de ordenes) La aplicación de los cuatro pasos de normalización para este ejemplo se ilustra en fig.12.6. La aplicación de la regla de la primera forma normal (remover los grupos que se repiten) crea dos registros: ORDER y ORDER-PRODUCT. La clave primaria es creada para ORDER# y PRODUCT#. La segunda forma normal remueve el nombre del producto del registro ORDER PRODUCT hacia un nuevo registro: PRODUCT. El nombre del producto es totalmente dependiente del número de productos; éste sólo es parcialmente dependiente de la clave primaria (combinada o compuesta) de ORDER PRODUCT:ORDER# +PRODUCT#. La tercera forma normal remueve los detalles del cliente del registro ORDER hacia un registro separado CUSTOMER. El nombre y dirección del cliente son totalmente dependientes del número del cliente; no son dependientes del todo de la clave primaria de ORDER (es decir, Order#). (Un cliente no cambiará su nombre y dirección con cada nueva orden-a menos que tenga la intención de no pagarla!) Los cuatro registros resultantes en fig.12.6-ORDER, CUSTOMER, ORDER-PRODUCT, y PRODUCT-están en tercera forma normal. El paso final en fig.12.6 elimina la dependencia condicional que hace que exista un número de impuesto para los clientes domésticos pero no para los clientes extranjeros. PROCEDIMIENTO En el Cuadro 12.3 se da una descripción detallada de los procedimientos para la modelación de datos. Fig.12.6 CUADRO 12.3 Una descripción del procedimiento para la modelación de datos. CREAR UN MODELO DE DATOS DETALLADO La modelación detallada de los datos aborda un área de negocios a la vez. A pesar de que aquí se describe como una actividad auto-contenida ésta necesita ser una parte integral del procedimiento de Análisis del Area de Negocios. Ver Cuadro 11.2 Abajo se describen las revisiones del proceso de modelación que algunas veces son referidas como ANALISIS DE ESTABILIDAD. El objetivo es hacer el modelo de datos tan estable como sea posible para que pueda soportar cambios importantes en los procedimientos corporativos. Los modelos de datos estables han tenido el efecto de reducir drásticamente los costos de mantenimiento del programa. El procedimiento que se da abajo puede ser modificado con un Diagramador de Acción para satisfacer las necesidades de la situación particular. Preparación Designar al profesional de la modelación de datos para que conduzca la actividad. Si existe internamente un profesional de modelación de datos. Hacerlo responsable de la cumplimiento del modelo a tiempo. De lo contrario Emplear a un consultor capacitado en la modelación de datos. Hacerlo responsable de la cumplimiento del modelo a tiempo. Designar a uno o más profesionales internos para que se conviertan en expertos en modelación de datos. Designar a un profesional interno para que se haga cargo del trabajo del consultor y que sea responsable del modelo. Asegurarse que estén instaladas las herramientas necesarias y trabajar en Instalar una herramienta de modelación de datos que sintetice y normalice múltiples tipos de datos. Usar una herramienta basada en la enciclopedia (la usada en las etapas anteriores de la ingeniería de la información) para formar un gran diccionario de la empresa, almacén, y herramienta de coordinación. La herramienta que hace la síntesis y normalización preferentemente debe ser parte del taller de trabajo basado en la enciclopedia. Formar un comité de usuarios finales Seleccionar participantes que sean usuarios finales. Los usuarios finales seleccionados deberán ser: inteligentes, creativos, tener buenas métodos de comunicación con los demás, tener deseos de comprender las técnicas de los sistemas de información, tener gran conocimiento de sus áreas de negocios. Dar a los participantes un curso de un día sobre los principios básicos de las técnicas de bases de datos. Libro: James Martin, An End-User's Guide to Database, Prentice Hall. Documentar una convención para asignar nombre a los detalles de datos. Modelación de datos de arriba hacia abajo. Seleccionar los tipos de entidades para esta área de negocios para el modelo entidad-relación ISP. Ingresar las claves primarias para estos tipos de entidades. Agregar tipos de entidades de intersección donde sea conveniente (con asistencia automatizada). Agregar todos los atributos que puedan ser identificados. Asegurarse que los agrupamientos de atributos estén en Cuarta Forma Normal. Mejorar este modelo de datos con las técnicas de síntesis y revisión del usuario descritas abajo. Síntesis de los Datos LOS SIGUIENTES PASOS SE HACEN ITERATIVAMENTE HASTA QUE SE COMPLETE EL MODELO Identificar todos los posibles tipos de datos del usuario. Capturar todos los documentos que van a provenir de los sistemas. Capturar todos los documentos que serán entradas para los sistemas. Evaluar todos los requerimientos de información identificados durante el ISP. Ver Cuadro 2.1 Determinar mediante discusión con los usuarios finales qué tipos de datos quieren obtener de los sistemas, ahora y en el futuro. Determinar de los analistas de sistemas si están apareciendo nuevos requerimientos de registros o documentos. Evaluar los archivos existentes, bases de datos, o diccionarios que se relacionan con estos datos. Planificar si los archivos o bases de datos existentes van a coexistir con los nuevos sistemas o serán convertidos. Si van a coexistir, planear qué datos son necesarios en los nuevos sistemas para formar un puente con los viejos sistemas. ¿Van a coexistir los archivos del paquete de aplicación o las bases de datos junto con los nuevos sistemas? Si es así, planear qué datos son necesarios en los nuevos sistemas para formar un puente con los paquetes. Realizar lo siguiente para todas las consideraciones de los usuarios anteriores Inspeccionar cada entrada Emplear la convención de asignación de nombres. Inspeccionar cada entrada para ver si puede simplificarse. Revisar si ya existe en el modelo cualquiera de los detalles de dato de entrada bajo un nombre diferente o bajo una forma ligeramente diferente. Si es así, asegurarse que esta redundancia sea eliminada. Para cada detalle de dato revisar que ningún detalle de dato dentro del modelo tenga el mismo nombre. Asegurarse de que las claves concatenadas estén correctamente representadas en la entrada al proceso de síntesis. Asegurarse de que todos los atributos ingresados sean dependientes de TODA la clave lo que los identifica. Asegurarse de que todos los atributos ingresados como entrada no contengan dependencias transitivas (que no existan claves escondidas). Cuestionar la validez de todos los enlaces que representan las reglas del negocio, como si se opusieran a las propiedades naturales de los datos. ¿Podrían cambiarse estas reglas en el futuro? Cuestionar cualquier enlace con una cardinalidad "l" si éste podría convertirse en una cardinalidad "de muchos" en el futuro. Ingresar las consideraciones en la herramienta de síntesis. Crear una entrada al diccionario para documentar el significado de cada detalle de dato. Revisar el modelo sintetizado. Revisar con el comité de usuarios el listado del diccionario de los datos asegurándose que todos los usuarios finales estén de acuerdo con las definiciones de los detalles de datos. Revisar con el comité de usuarios el modelo de datos para asegurarse que sus requerimientos de datos pueden obtenerse de éste. Revisar con el comité de usuarios, sugerir ideas sobre los posibles usos futuros de los datos. Para cualquier uso en que el modelo no sirva, crear una nueva entrada al proceso de síntesis. Descripción Sugerir ideas significa que un grupo de personas creativas intente producir una corriente de ideas sin inhibición. Una regla para una sesión de sugerencia de ideas es que no puede haber crítica implicada por hace una sugerencia poco práctica o estúpida. La sesión intenta generar tantas ideas como sean posibles. Al final de la sesión sólo ciertas ideas serán registradas para su posible uso. Examinar todos los campos de atributos dentro del modelo para ver si podrían convertirse en la clave primaria en el futuro. Completar el mapeo inverso de cualquier enlace entre claves para identificar cualquier posible enlace MUCHOS-CON-MUCHOS. Crear una clave concatenada extra para tener cuidado con cualquier posible intersección de datos futura. Si existen claves candidatas dentro del modelo de datos, asegurarse que se mantengan como claves candidatas en el futuro. Utilizar un rápido rediseño computarizado después de hacer cualquier cambio para mantener el interés de los usuarios finales. Asegurarse de que la modelación de los datos se integre al proceso BAA. Ver Cuadro 11.2