CAPITULO 12 ENTIDADES Y NORMALIZACION ENTIDADES

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