Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

DESARROLLO FISICO DE LA DESNORMALIZACION

En esta

seccin

presentaremos ejemplos de las

11 tcnicas de

desnormalizacin descritas anteriormente. La pregunta que siempre habr que tener en la mente cuando lea esta informacin es si los posibles beneficios obtenidos cuando se desnormaliza realmente superan al coste aadido debido al esfuerzo adicional de codificacin y documentacin. Con frecuencia la desnormalizacin se ejecuta para obtener beneficios en el rendimiento de las funciones de generacin de informes. Sin embrago, habremos de tener siempre presente que desnormalizacin reduce el

rendimiento desde la perspectiva del proceso de transacciones, de esta forma , habr que evaluar qu es mejor para nosotros, acelerar la generacin de informes o disminuir el rendimiento de las transacciones.

El

mtodo

ideal

para

realizar

la

desnormalizacin

es

utilizando

desencadenadores. Si puede permitirse el lujo de esperar para realizar actualizaciones en modo diferido, entonces podr desarrollar un OLAP para este tipo de sistemas de informacin y no tendr que sacrificar la integridad de su diseo OLTP con el fin de mejorar el rendimiento de la generacin de informes. En nuestra opinin, no deber desnormalizarce los sistemas de generacin de informes para mejorar las prestaciones.

TCNICAS DE DESNORMALIZACIN
Hemos identificado 11 tipos de de desnormalizacin que pueden ser necesarios para facilitar el cdigo o por motivos de rendimiento. Describiremos cada una de estas tcnicas y mostraremos ejemplos.

Campos total redundante

Utilizaremos el escenario definido por las rdenes de compra simple y detallada para el ejemplo del campo total. Por desgracia, este ejemplo cae en el tema de la tabla de mutacin, salvo que creemos una tercera que duplique la tabla OC_DTL.

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

Suponga que queremos obtener cantidades en dlares divididas por segundo por orden de compra. Podremos satisfacer este requisito aadiendo una columna X-CANT a la tabla OC. Esta columna se actualizar con el valor total en dlares de la OC si mas que sumar los valores individuales en dlares de cada OC_DTL asociada con una OC determinada. Para el presente ejemplo, hemos creado tres tablas OC, OC_DTL y X_OC_DTLy un desencadenador AIU_X_OC_DTL para la tabla X_OC_DTL, tal y como se muestra en el cdigo siguiente:

CREATE TABLE OC ( OC_ID NUMBER (10) NOTNULL, DESCR_TXT VARCHAR2 (100) NOTNULL, DIREC_ID_COM_TO NUMBER (10) NOTNULL, DIREC_ID_FACT_TO NUMBER (10) NOTNULL, CTCT_ID NUMBER (10) NOTNULL, VENDEDOR_ID NUMBER (10) NOTNULL, X_CANT NUMBER (10,2) NOTNULL ) / CREATE TABLE OC_DTL ( OC_ID NUMBER (10) NOTNULL, OC_DTL_ID NUMBER (10) NOTNULL, ARTIC_ID NUMBER (10) NOTNULL, ORDEN_CANT NUMBER (10,2) NOTNULL, ORDEN_PRC NUMBER (10,2) NOTNULL ) / CREATE TABLE X_OC_DTL ( OC_ID NUMBER (10) NOTNULL, OC_DTL_ID NUMBER (10) NOTNULL, ARTIC_ID NUMBER (10) NOTNULL, ORDEN_CANT NUMBER (10,2) NOTNULL, ORDEN_PRC NUMBER (10,2) NOTNULL ) / CREATE TABLE OR REPLACE TRIGGER AIU_OC_DTL AFTER INSERT OR UPDATE ON X_OC_DTL FOR EACH ROW DECLARE CURSOR C1 IS SELECT ORDEN_CANT * ORDEN_PRC X_CANT_OC_DTL FROM X_OC_DTL WHERE OC_ID =:NEW.OC_ID; X_CANT_OC OC.X_CANT%TYPE :=0;

BEGIN FOR C1_REC IN C1 LOOP X_CANT_OC :=X_CANT_OC + C1_REC.X_CANT_OC_DTL; END LOOP; UPDATE OC SET X_CANT =X_CANT_OC WHERE OC_ID =:NEW.OC_ID; END; /

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

El principal inconveniente de este caso es que debemos crear una tercera una tercera tabla, X_OC_DTL, lo que no es muy prctico de cara a la desnormalizacin. El principal inconveniente es el almacenamiento adicional de una tabla del mismo tamao que la tabla OC_DTL. Aunque es cierto que el espacio de almacenamiento en disco es relativamente barato; esta forma de actuar dificulta la administracin del sistema.

Cualquier modificacin a la estructura de la tabla OC_DTL, tambin deber propagarse ala tabla X_OC_DTL. Podemos evitar el tema de la tabla mutante si

calculamos y actualizamos la OC de cada registro de la aplicacin en lugar d e hacerlo en el servidor.

Empleo de mays. Para el desarrollo de ndices

La comparacin de cadenas de texto es realmente un problema de difcil resolucin. Cuando se comparan direcciones es fcil encontrarse con distintas variedades de una misma palabra. Por ejemplo, AVDA, Avda, Avenida, AVENIDA y otras variaciones adicionales tienen el mismo significado y se refieren a lo mismo, pero las comparaciones dirn que no, salvo que previamente manipule las cadenas de texto para mejorar la consistencia.

Utilizar un algoritmo como el que describimos anteriormente en este capitulo tiene mucho sentido. Analizar cada cadena de texto en busca de entradas comunes y sustituirles por un formato uniforme permite realizar bsquedas seguras, por desgracia, las cadenas de texto pueden ser ms complicadas de lo que inicialmente hemos podido suponer. Por ejemplo, en la direccin avenida del parque de las avenidas ,120, Madrid, 28027 nos encontramos dos veces con la palabra avenida. Deber ser capaz de identificar el formato uniformen sus datos de origen antes de intentar encontrar un coincidencia para poder tener una mnima probabilidad de xito. En otras palabras deber conocer que la referencia a la calle solo ocurrir en los primeros caracteres de la

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

direccin, o alguna otra regla similar... en caso contrario, no garantizar que la localizacin se realice de forma correcta. Podr llevar acabo esta lgica en un desencadenador en la tabla en la que se almacena la cadena de texto. Solo interactuar con datos en el registro, por lo que no se encontrar con el problema de la tabla mutante la siguiente asignacin
:NEW.X_DIR_TXT :=UPPER(cadena _ texto)

Es la parte sencilla de la tarea. La parte complicada es la lgica de bsqueda. No hay muchas empresas que deseen llevar adelante esta tarea.

Columnas adicionales de claves externas en el lugar al que no pertenecen

Agregar nuevas claves externas puede, ciertamente aumentar la velocidad en la elaboracin de informes. El inconveniente es la complejidad aadida del modelo de datos. El modelo de datos mostrado en la figura 18.1 indica una relacin implcita entre Detalle de Reclamaciones y Grupo mediante Reclamacin, Pliza, Coste y Plan. Por desgracia, la unin de varias tiende a formar cuello de botella desde el punto de vista del rendimiento. El cdigo ejemplo 18.2 muestra esta tcnica.
CREATE TABLE GRP ( GRP_ID NUMBER (10) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR2 (40) NOT NULL) / CREATE TABLE PLAN ( PLAN_ID NUMBER (10) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR2 (40) NOT NULL, GRP_ID NUMBER (10) NOT NULL REFERENCES GRP (GRP_ID)) / CREATE TABLE COSTE ( COSTE_ID NUMBER (10) NOT NULL PRIMARY KEY, CANT NUMBER (10,2) NOT NULL, PLAN_ID NUMBER (10) NOT NULL REFERENCES PLAN (PLAN_ID)) / CREATE TABLE POLIZA ( POLIZA_ID NUMBER (10) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR2 (40) NOT NULL COSTE_ID NUMBER (10) NOT NULL REFERENCES COSTE (COSTE_ID)) /

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

CREATE TABLE RECLAM ( RECLAM_ID NUMBER (10) NOT NULL PRIMARY KEY, PACIENTE_APELL VARCHAR2 (40) NOT NULL, PACIENTE_NOMBP VARCHAR2 (40) NOT NULL, POLIZA_ID NUMBER (10) NOT NULL, REFERENCES POLIZA (PLIZA _ ID), CREAR _ FECHA DATE) / CREATE TABLE RECLAM_DTL ( RECLAM_ID NUMBER (10) NOT NULL, REFERENCES RECLAM (RECLAM_ID), RECLAM_DTL_ID NUMBER (3) NOT NULL, DESCR_TX VARCHAR2 (40), DIAGNOSIS_CD VARCHAR2 (10), GPR_ID NUMBER (10) NOT NULL REFERENCES GRP (GRP_ID)) /

Podemos evitar la unin de las seis tablas definiendo una clave externa desde RECLAM_DTL a GRUPO, como demuestran las instrucciones en negrita del Cdigo ejemplo 18.2 Otra opcin seria convertir al identificador nico de cada una de estas tablas en una clave concatenada. De esta forma, podr informar de los Detalles de las Reclamaciones mediante Reclamacin, Pliza, Coste, Plan o Grupo, y su consulta solo tendr que acceder a Reclamacin Detallada y, opcionalmente, a una o mas de otras tablas, si en la consulta solicitada se comprueba que solo se podr obtener informacin adicional de una de estas tablas. El cdigo correspondiente a esta opcin se muestra en el Cdigo ejemplo 18.3.

CREATE TABLE GRP ( GRP_ID NUMBER (10) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR2 (40) NOT NULL) / CREATE TABLE PLAN ( PLAN_ID NUMBER (10) NOT NULL, DESCR_TX VARCHAR2 (40) NOT NULL, GRP_ID NUMBER (10) NOT NULL REFERENCES GRP (GRP_ID), PRIMARY KEY (PLAN_ID, GRP_ID)) / CREATE TABLE COSTE ( COSTE_ID NUMBER (10) NOT NULL, CANT NUMBER (10,2) NOT NULL, PLAN_ID NUMBER (10) NOT NULL, GRP_ID NUMBER (10) NOT NULL, PRIMARY KEY (COSTE_ID, PLAN_ID, GRP_ID), FOREING KEY (PLAN_ID, GRP_ID)

Sistema de Bases II
REFERENCES PLAN (PLAN_ID, GRP_ID)) /

Desarrollo Fsico - Desnormalizacin

CREATE TABLE POLIZA ( POLIZA_ID NUMBER (10) NOT NULL, DESCR_TX VARCHAR2 (40) NOT NULL, COSTE_ID NUMBER (10) NOT NULL, PLAN_ID NUMBER (10) NOT NULL, GRP_ID NUMBER (10) NOT NULL, PRIMARY KEY (PLIZA_ID, COSTE_ID, PLAN_ID, GRP_ID), FOREING KEY (COSTE_ID, PLAN_ID, GRP_ID) REFERENCES COSTE (COSTE_ID, PLAN_ID, GRP_ID)) / CREATE TABLE RECLAM ( RECLAM_ID NUMBER (10) NOT NULL, PACIENTE_APELL VARCHAR2 (40) NOT NULL, PACIENTE_NOMBP VARCHAR2 (40) NOT NULL, CREAR _ FECHA DATE, POLIZA_ID NUMBER (10) NOT NULL, COSTE_ID NUMBER (10) NOT NULL, PLAN_ID NUMBER (10) NOT NULL, GRP_ID NUMBER (10) NOT NULL, PRIMARY KEY (RECLAM_ID, PLIZA_ID, COSTE_ID, PLAN_ID, GRP_ID), FOREING KEY (PLIZA_ID, COSTE_ID, PLAN_ID, GRP_ID) REFERENCES POLIZA (PLIZA _ ID, COSTE_ID, PLAN_ID, GRP_ID)) / CREATE TABLE RECLAM_DTL ( RECLAM_ID NUMBER (10) NOT NULL, RECLAM_DTL_ID NUMBER (3) NOT NULL, DESCR_TX VARCHAR2 (40),

DIAGNOSIS_CD VARCHAR2 (10), POLIZA_ID NUMBER (10) NOT NULL, COSTE_ID NUMBER (10) NOT NULL, PLAN_ID NUMBER (10) NOT NULL, GRP_ID NUMBER (10) NOT NULL, PRIMARY KEY (RECLAM_ID, RECLAM_DTL_ID, PLIZA _ ID, COSTE _ ID, PLAN_ID, GRP_ID), FOREING KEY (RECLAM_ID, PLIZA _ ID, COSTE _ ID,

Sistema de Bases II
PLAN_ID, GRP_ID), REFERENCES RECLAM (RECLAM_ID, PLIZA _ ID, COSTE_ID, PLAN_ID, GRP_ID)) /

Desarrollo Fsico - Desnormalizacin

Como puede ver, la concatenacin de claves primarias puede hacer que sus requisitos de almacenamiento de datos se vayan por las nubes. Realizando un cuidadoso anlisis, podr determinar la ruta ptima para su proyecto. Columnas redundantes para el histrico Podr desarrollar las columnas redundantes para el histrico en la misma forma que utilizamos la tcnica de la desnormalizacin para las columnas adicionales de claves externas no necesitara informacin adicional. Escritura de tablas de detalle Esta aproximacin es similar a la clave externa adicional y a las columnas redundantes para las tcnicas del historial, aunque en este caso una clave externa redundante es una clave externa de la tabla maestra ( al contrario de ser una clave primaria de la tabla maestra). De nuevo, esta forma de actuar sirve para facilitar la elaboracin de informes, aunque dificultara la comprensin del modelo. Violaciones de la primera forma normal Violar la primera forma normal implica que esta codificando una regla del sistema que su empresa suele tener almacenada en la estructura de la base de datos. Una decisin tal como esta no deber tomarse a la ligera. El cdigo ejemplo 18.4 indica que la actual estrategia presupuestaria de esta empresa se lleva a cabo por trimestres. Pero que ocurrir si esta divisin temporal cambia en el futuro? Una modificacin de esta magnitud exigira cambios sustanciales en la base de datos, en todas las aplicaciones (por ejemplo, formularios e informes) y en cualquier interfaz que intercambia informacin con esta base de datos. Estos inconvenientes son lo suficientemente costosos y no se pueden tomar a la ligera.
CREATE TABLE PRESUP ( PRESUP_ID NUMBER (10) NOT NULL, DESCR_TXT VARCHAR2 (100) NOT NULL, CUENT_CD VARCHAR2 (20) NOT NULL, / CREATE TABLE PRESUP_DTL ( PRESUP_ID NUMBER (10) NOT NULL, TRM1_CANT NUMBER (10, 2) NOT NULL, TRM2_CANT NUMBER (10, 2) NOT NULL, TRM3_CANT NUMBER (10, 2) NOT NULL, TRM4_CANT NUMBER (10, 2) NOT NULL,

Codigo ejemplo 18.4

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

Por el contrario podemos llevar a cabo un modelo mas flexible que pueda acomodar con el tiempo las modificaciones que tengan lugar sobre la estructura del presupuesto. Esta aproximacin exigir nuevas estructuras de datos que utilizaremos para definir la estructura presupuestaria.

Columnas sobrecargadas Para desarrollar el ejemplo de la subdivisin geogrfica tendremos que definir dos tablas, PAS y ST_PROV, tal y como se muestra en el cdigo ejemplo 18.5.
CREATE TABLE PAS ( PAS_ID NUMBER (10) NOT NULL PRIMARY KEY, DESCR_TXT VARCHAR2 (50) NOT NULL) / CREATE TABLE ST_PROV ( PAS_ID NUMBER (10) NOT NULL REFERENCES PAS (PAS_ID), ST_PROV_ID NUMBER (10) NOT NULL, DESCR_TXT VARCHAR2 (50) NOT NULL, ESTADO_YN VARCHAR2 (1) NOT NULL)/

Cdigo ejemplo 18.5

La columna DESCR_TXT perteneciente a la tabla DT_PROV almacena los nombres de estados y provincias. En principio, no est claro que un valor determinado contenido en la columna DESCR_TXT de la tabla ST_PROV sea un estado o una provincia si no se consulta tambin el contenido de la columna ESTADO_YN, que indica si un determinado registro se ha definido como ESTADO O PROVINCIA.

Columnas Multiatributos

Un lugar muy normal en donde ocurre este tipo de desnormalizacin es en el caso de los identificadores de inventario. En ocasiones, el identificador nico de un elemento se encuentra almacenado en una nica columna, pero, en realidad, puede descomponerse en varios componentes, tales como el nmero de almacn, tipo de elemento y nmero de elemento. En lugar de introducir estos valores de datos distintos en una nica columna, recomendamos descomponerlos de manera individual. Ciertamente, esta forma de actuar simplifica la lectura del modelo y los valores se podrn seguir mostrando juntos

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

para satisfacer las preferencias del usuario, tal y como se muestra en el cdigo ejemplo 18.6.

CREATE TABLE ARTIC ( ARTIC_ID NUMBER (10) NOT NULL, PRIMARY KEY, DESCR_TX VARCHAR2 NOT NULL) / INSERT INTO ARTIC (ARTIC_ID, DESCR_TX) VALUES (0113561111, WIDGET) /

Cdigo ejemplo 18.6

El cdigo ejemplo 18.6 utiliza la columna ARTIC_ID para almacenar una cadena combinada que contiene el tipo del elemento (por ejemplo, 011 caracteres 1-3), el identificador del elemento (por ejemplo, 1111 caracteres 7-10).

Esta forma de actuar presenta un par de problemas. En primer lugar, los usuarios de este sistema deben saber lo que significa 011, porque el sistema no almacena una descripcin para este cdigo. En segundo lugar, consultar las ventas de artculos por tipo de artculo es una tarea que no puede ser indexada, porque tendr que analizar el tipo empleo de la funcin SUBSTR, que, de manera inherente, ignora los ndices. En tercer lugar, qu ocurrira si su elemento fuera reclasificado como algn otro tipo de artculo o fuera almacenado en algn otro almacn en el futuro? Estos cambios exigiran la actualizacin de la clave primaria, un extremo bastante inconveniente.

La forma ms correcta de trabajar ser normalizar cuando vea este tipo de escenarios y est convencido de que su estructura puede cambiar y, probablemente pueda, cambiar en el futuro. Las estructuras mostradas en el Cdigo ejemplo 18.7 seran seguras.
CREATE TABLE ALAC ( ALMAC_CD VARCHAR2 (4) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR (50) NOT NULL) / CREATE TABLE ARTIC_TIPO ( ARTIC_TIPO_CD VARCHAR2 (3) NOT NULL PRIMARY KEY, DESCR_TX VARCHAR2 (50)) / CREATE TABLE ARTIC ( ARTIC_CD VARCHAR2 (3) NOT NULL, DESCR_TX VARCHAR2 (50) NOT NULL, ALMAC_CD VARCHAR2 (4) NOT NULL REFERENCES ALCAM (ALMAC_CD), ARTIC_TIPO_CD VARCHAR2 (3) NOT NULL

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

REFENBRENCES ARTIC_TIPO (ARTIC_TIPO_CD)

/ Cdigo ejemplo 18.7

Este ejemplo, identificara de manera nica los artculos utilizando el cdigo de artculo, no la combinacin de cdigo de artculo, cdigo de almacn y cdigo de tipo de artculo. De esta forma, se permitira que el tipo de artculos o el almacn cambien con el tiempo. Si est convencido que estos valores no van a cambiar con el tiempo, podr seguir utilizando este diseo y , simplemente, modificar la clave primaria de la tabla ARTIC para incluir los cdigos de almacn y de tipo de artculo. De esta forma, obtendr el texto descriptivo de los tipos de almacenes y artculos, y garantizar que la combinacin de estos tres campos representa un nico artculo.

Naturalmente, existen datos que nunca necesitarn este tipo de descomposicin. El tpico ejemplo son los cdigos postales. Muchos de nosotros no somos concientes de que, en la mayora de los pases, el cdigo postal esta realmente formado por varios cdigos de menor extensin. En realidad, la mayora de nosotros nunca nos hemos preocupado por este hecho. Lo que realmente interesa en la mayora de los sistemas es el cdigo postal completo; por tanto, no requiere una normalizacin como suceda en el ejemplo del artculo que hemos analizado anteriormente. Conclusin:

Cada uno de los sistemas de desnormalizacin que hemos comentado aqu, con la excepcin de la primera forma normal (que no se ha recomendado), comienzan con un a base de datos en la tercera forma normal plenamente normalizada a la que se agrega una columna redundante. Se trata de un concepto clave para obtener buenos modelos, ya que ayuda a mantener un esquema conceptualmente claro. Todo lo que hemos tenido que hacer es agregar al modelo sin sacrificar ni su flexibilidad ni su claridad conceptual. Agregando trozos que han sido claramente identificados como desnormalizados gracias a las convenciones de denominacin utilizadas, generando una documentacin cuidadosa que indiquen de donde vienen dichos campos y plasmando estos mediante desencadenadores de base de datos, obtendremos lo mejor de ambos mundos: Un modelo claro y tericamente correcto y un rendimiento adecuado.

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

Funcionaria siempre esta forma de trabajar? No. Para los grandes sistemas bancarios de elevado nmero de transacciones, grandes sistemas comerciales al por menor, sistemas de reservas de lneas areas, o cualquier otro sistema que tenga que almacenar miles de transacciones por segundo, debern sacrificarse ciertas correcciones tericas para alcanzar el rendimiento adecuado. Esta forma de proceder deber utilizarse como ltima alternativa. Los beneficios de un modelo de datos ntido son su facilidad de mantenimiento y la facilidad con la que los nuevos grupos de diseadores lo entendern.

Sistema de Bases II

Desarrollo Fsico - Desnormalizacin

CONTENIDO

DESARROLLO FISICO DE LA DESNORMALIZACION

TECNICAS DE DESNORMALICACION

CAMPOS TOTAL REDUNDANTE EMPLEO DE MAYUSCULAS COLUMNAS REDUNDANTES PARA HISTORICO ESCRITURA DE TABLAS DE DETALLE VIOLACIONES DE PRIMERA FORMA NORMAL COLUMNAS SOBRECARGADAS COLUMNAS MULTIATRIBUTOS

1 3 7 7 7 8 8