COORDINACIN DE BASES DE DATOS

INTRODUCCIN A LAS BASES DE DATOS RELACIONALES

El 18 de abril del 2003 falleci el Dr. Edgar Frank Codd, a la edad de 79 aos, vctima de un ataque al corazn. Tal vez nunca usted escuch, conoci o supo del Dr. Codd, pero lo ms probable es que usted a diario utilice cotidianamente tecnologa derivada de las teoras que este brillante matemtico y cientfico de la computacin desarrollo a lo largo de su vida. Nacido en Inglaterra, la mayor parte de su vida la pas en los Estados Unidos trabajando y desarrollando sus ideas que culminaron en una serie de informes tcnicos acerca de una nueva manera de organizar y acceder a los datos. A partir de estos trabajos public en 1970 el artculo A Relational Model of Data for Large Shared Data Banks, lo que podra traducirse como Un modelo de datos relacional para grandes bancos de datos compartidos. Codd propuso que los sistemas de bases de datos deberan presentarse a los usuarios con una visin de los datos organizados en estructuras llamadas relaciones, definidas como conjuntos de filas y columnas, y no como series o secuencias de objetos, con lo que el orden no es importante. Por lo tanto, detrs de una relacin puede haber cualquier estructura de datos compleja que permita una respuesta rpida a una variedad de consultas. Este reconocido matemtico revoluciono el mundo de la Bases de Datos cuando con su modelo relacional tipo tabular sustituyo a los modelos tipo jerrquico y tipo redes aceptados hasta ese entonces. Su modelo intento simplificar la complejidad de las bases de datos hasta ese momento, eliminando las estructuras explicitas padre / hijo por una representacin de los datos ms sencilla de tablas en fila / columna de valores de datos.
53

COORDINACION DE BASES DE DATOS

Un poco de historia.
Cuando la gestin de las bases de datos se populariz durante los aos de 1960, 1970 y 1980 emergieron un puado de modelos de datos populares. Cada uno de estos primeros modelos de datos tenan ventajas y desventajas que jugaron papeles importantes en el desarrollo del modelo de datos relacional. En muchos sentidos el modelo de datos relacional represent un intento de simplificar los modelos de datos anteriores.

SISTEMA DE GESTIN DE ARCHIVOS Antes de la introduccin de los sistemas de gestin de bases de datos (DBMS) todos los datos permanentemente almacenados en un sistema informtico, tales como la nmina y los registros de contabilidad, se almacenaban en archivos individuales. Un sistema de gestin de archivos, generalmente era proporcionado por el fabricante del computador como parte del sistema operativo, este llevaba la cuenta de los nombres y las ubicaciones de los archivos. El sistema de gestin de archivos bsicamente careca de un modelo de datos; no se saba nada acerca de los contenidos internos de los archivos. Para el sistema de gestin de archivos, un archivo que contuviera un documento de procesamiento de texto y un archivo que contuviera datos de nminas parecan igual. El conocimiento acerca del contenido de un archivo (que datos tuviese y como estn organizados) estaba incorporado a los programas de aplicacin que utilizaban el archivo (programas estos antiguos comparables con lo que se desarrollan en estos momentos con los llamados software anfitriones). Los problemas de mantener grandes sistemas basados en este tipo de archivos condujo a finales de la dcada de 1960 al desarrollo de sistemas de gestin de bases de datos, o sea DBMS. La idea detrs de estos sistemas era sencilla: tomar la definicin de los contenidos de un archivo y la estructura de los programas individuales, y almacenarla, junto con los datos, en una base de datos. Utilizando la informacin de la base de datos, el DBMS que la controlaba podra tomar un papel mucho ms activo en la gestin de los datos y en los cambios que se les pudiesen hacer a la estructura de la base de datos.

BASES DE DATOS JERARQUICAS Naci en base a aquellos requerimientos en donde exista una relacin directa entre los datos de tipo jerrquica. Por ejemplo, se puede tomar a un auto, ste se puede ir descomponiendo en partes que a su vez se descomponen ms y ms otras partes cada vez a mayor nivel de profundidad y complejidad.

20/10/2010

COORDINACION DE BASES DE DATOS Si un fabricante de automviles decida producir 10.000 unidades de un modelo de auto y 5.000 unidades de otro modelo, necesitaba conocer cuantas piezas pedir a sus proveedores. El producto, un auto, tena que descomponerse en ensamblajes (motor, carrocera, chasis, sistema elctrico, etc.) que a su vez se descompona en subensamblajes (caja, vlvulas, alternador, etc.) y as cada vez a descomposiciones ms profundas hasta llegar hasta las partes ms bsicas. El manejo de estas listas de piezas, conocida por lo general como una cuenta de materiales, era todo un gran trabajo a la medida de los computadores de la poca. La cuenta de materiales para un producto tena una estructura jerrquica natural, para almacenar este tipo de estructura se desarroll el modelo jerrquico. En este modelo, cada registro de la base de datos representa una pieza especfica. Los registros tenan relaciones padre / hijo, que ligaban cada pieza a una subpieza de orden superior, y as sucesivamente. Por ejemplo, la diodera era hija del alternador, y alternador a su vez hijo del sistema elctrico. En este modelo para poder acceder a los datos de la base de datos se podra: Hallar a una pieza en particular en funcin de su nmero, por ejemplo la puerta izquierda. Primero descender desde la cabeza (auto) o padre al primer hijo (Carrocera) En carrocera descender ahora hacia la puerta izquierda (hijo a su vez de la carrocera).

Este modelo se caracterizaba por parecerse a lo que es un organigrama o una especie de rbol genealgico. La recuperacin de los datos en una base de datos tipo jerrquica requera, por lo tanto, navegar a travs de los registros, movindose hacia arriba, hacia abajo, o hacia los lados de un registro de la misma familia cada vez. El IMS fue el software de manipulacin ms popular para este tipo de Bases de Datos. . BASES DE DATOS TIPO REDES La estructura sencilla de una base de datos jerrquica se converta en una desventaja cuando los datos se iban haciendo cada vez ms complejos, voluminosos y asociativos. Para manejar aplicaciones tales como el procesamiento de pedidos, se desarroll un nuevo modelo de datos en red. El modelo de datos en red extenda al modelo jerrquico permitiendo que un registro participara en mltiples relaciones padre / hijo, ya no perteneca a una misma familia. Estas relaciones eran conocidas como conjuntos en el modelo en red.

20/10/2010

COORDINACION DE BASES DE DATOS Para un programador acceder a una base de datos en red era similar a acceder a una base de datos jerrquica, por ejemplo se poda: Hallar a un registro padre especfico mediante una clave (por ejemplo, mediante un nmero de cliente). Descender al hijo en un conjunto en particular (El primer pedido remitido por este cliente). Moverse lateralmente de un hijo al siguiente dentro del conjunto (La orden siguiente remitida por el mismo cliente). Ascender desde un hijo a su padre en otro conjunto (El vendedor que acepto el pedido).

Una vez ms el programador tenia que recorrer la base de datos registro a registro, especificando esta vez que relacin recorrer adems de indicar la direccin. Aunque mejoraban al modelo jerrquico, aunque las bases de datos en red tambin resultaban muy rgidas. Las relaciones de conjunto y la estructura de los registros tenan que ser especificados de antemano. Modificar la estructura de la base de datos requera tpicamente de la reconstruccin de la base de datos completa. Tanto las bases de datos jerrquicas como las de red eran herramientas para programadores, pero cuando, por ejemplo, se necesitaba conocer cual es el producto ms popular o ms vendido dentro de una base de datos de ventas, un programador tenia que escribir un programa que recorriera su camino a travs de toda la base de datos para poder obtener la informacin deseada. La codificacin de las peticiones para informes por lo general duraba con frecuencia semanas o meses y para el momento en que el programa estaba escrito la informacin que se entregaba ya no mereca la pena, haba perdido su oportunidad y validez. El IDMS fue el software de manipulacin ms popular para este tipo de Bases de Datos.

El Modelo Relacional de Bases de Datos

El modelo relacional de bases de datos hace nfasis en que el usuario de un sistema relacional slo debe preocuparse por el qu consultar y no en el cmo son o fueron concebidas las estructuras de almacenamiento (lo que ahora se conoce como modelo fsico), esto quiere decir que no hacia falta ser un programador para poder manipular la Base de Datos desde el punto de vista de un usuario final. An hoy se consideran validas las afirmaciones de Codd tales como: Los usuarios futuros de grandes bancos 20/10/2010 4

COORDINACION DE BASES DE DATOS de datos deben ser protegidos de tener que saber cmo estn organizados los datos en la mquina (la representacin interna. []. las actividades de los usuarios en sus terminales y la mayora de los programas de aplicacin no deberan verse afectados cuando se cambia la representacin interna de los datos o incluso cuando se cambian algunos aspectos de la representacin externa. Se necesitar cambiar la representacin de los datos a menudo como resultado de los cambios en el trfico de las consultas, actualizaciones e informes y como consecuencia del crecimiento natural en los tipos de informacin almacenada. Las desventajas de los modelos jerrquicos y en red condujo a un intenso inters en el nuevo modelo de datos relacional cuando fue escrito por el Dr. Codd en 1970. El modelo relacional era en realidad un intento de simplificar la estructura de las bases de datos. Puede parecer extrao, pero las ideas de Codd no fueron recibidas con los brazos abiertos en IBM, donde realizaba sus labores de investigacin, segn afirma Harlwood Kolsky, un fsico y antiguo compaero de Codd; fue un enfoque revolucionario, recuerda Kolsky. El nuevo enfoque de Codd, basado en la teora matemtica de conjuntos, no tuvo eco inmediato en IBM, que prefiri a IMS, un producto al que se le haba invertido una fuerte cantidad de esfuerzo y dinero. Un grupo de la Universidad de Berkeley en California, liderado por Michael Stonebreaker, crey en la idea del modelo relacional y obtuvo financiamiento para desarrollar un sistema, el Ingres, cuya primera versin se present en 1974 y fue el primer manejador relacional de bases de datos funcional. Esto tuvo como consecuencia que IBM reaccionara poniendo en marcha otro sistema relacional, el System R con caractersticas de multiusuario y un lenguaje de consulta estructurado, el SEQUEL que luego pasara a llamarse SQL (Structured Query Language). Para entonces Larry Ellison, un empresario del Valle del Silicn, haba tomado ventajas de los escritos de Codd para crear un nuevo producto y una nueva empresa que hasta la fecha se conoce como Oracle. En 1985 Codd public sus famosas 12 reglas sobre el modelo relacional de bases de datos, un resumen de sus caractersticas fundamentales. Es preciso resaltar que todava hoy algunas de estas reglas son de difcil implementacin para los fabricantes de manejadores de bases de datos relacionales. Adems de ser considerado como el padre del modelo relacional, Codd tambin incursion en el modelo multidimensional de anlisis de datos conocido como OLAP (On Line Analytical Processing) y en 1993 Codd y algunos de sus colegas publicaron las 12 reglas para OLAP. A lo largo de su vida, el Dr. Codd recibi innumerables reconocimientos. En 1981, la ACM (Association for Computer Machinery), otorg a Codd el Premio Turing, considerado uno de los ms prestigiosos en el campo de la informtica. Muchos de sus compaeros y seguidores han contribuido, y siguen hacindolo, a fortalecer el modelo el cual es, es por muchos, el ms utilizado actualmente como sistema de bases de datos.

20/10/2010

COORDINACION DE BASES DE DATOS Desgraciadamente, la definicin prctica de base de Datos Relacional resultaba mucho menos clara que la definicin matemtica precisa recogida en el artculo de Codd de 1970. Los primeros sistemas de gestin de bases de datos relacionales fallaron en implementar algunas partes clave del modelo de Codd, y es solo ahora cuando definitivamente estn encontrando su acomodo en productos comerciales. Conforme el concepto relacional creca en popularidad, muchas bases de datos que se llamaban as mismas relacionales no lo eran del todo. En respuesta a la corrupcin del trmino RELACIONAL, el Dr. Codd escribi un artculo en 1985 estableciendo 12 reglas a seguir para cualquier base de datos que se llamara verdaderamente relacional. Las doce reglas de Codd han sido aceptadas desde entonces como la definicin de un DBMS verdaderamente relacional. Un concepto bsico de Base de Datos Relacional es: Base de Datos en donde todos los datos visibles al usuario estn organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan sobre estas tablas Regla 1. La definicin esta destinada especficamente a eliminar estructuras tales como los punteros incorporados en una base de datos jerrquica o en red. Un DBMS relacional puede representar relaciones padre / hijo pero estas se representan estrictamente para los valores contenidos en las tablas de las bases de datos.
54

LAS 12 REGLAS DE CODD. 1 Una Base de Datos Relacional es aquella en donde todos los datos visibles al usuario estn organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan sobre estas tablas. El nombre de la tabla localiza la tabla correcta, el nombre de la columna encuentra la columna correcta y el valor de la clave primaria encuentra la fila que contiene un dato individual de inters. Los campos en blanco de una columna se pueden representar por el valor NULL. La base de datos debe contener ciertas tablas del sistema cuyas columnas describan la estructura de la propia base de datos. Utilizacin de un lenguaje de bases de datos relacional, tal como el SQL. El lenguaje debe ser capaz de soportar todas las funciones bsicas de un DBMS. Creacin y utilizacin de vistas, que no son ms que tablas virtuales utilizadas para dar a diferentes usuarios de una base de datos diferentes vistas de su estructura y de sus requerimientos. Naturaleza orientada a conjuntos de una base de datos relacional. Requiere que las filas sean tratadas como conjuntos en operaciones de insercin, supresin y actualizacin. La regla esta diseada para prohibir implementaciones que solo soporten la modificacin o recorrido fila a fila de la base de datos. Aslan al usuario o al programa de aplicacin de la implementacin de bajo nivel de las bases de datos. Especifican que las tcnicas de acceso a 6

3 4 5 6

8y9

20/10/2010

COORDINACION DE BASES DE DATOS

10

11 12

almacenamiento especficas utilizadas por el DBMS, e incluso los cambios a las estructuras de las tablas en la base de datos, no deberan afectar a la capacidad del usuario de trabajar con los datos. El lenguaje de bases de datos debera soportar las restricciones de integridad que restringen los datos que puedan ser introducidos en las bases de datos y las modificaciones que pueden ser efectuadas en stas. El lenguaje de bases de datos debe ser capaz de manipular datos distribuidos localizados en otros sistemas informticos. Impide que en la base de datos pudieran subvertir su estructura relacional y su integridad.

LA ESENCIA DEL MODELO La estructura fundamental del modelo relacional es la relacin, es decir una tabla bidimensional constituida por filas (tuplas) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la entidad encontrar sitio en una tupla de la relacin, mientras que los atributos de la relacin representan las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, podr definirse una relacin llamada "Personas", cuyos atributos describen las caractersticas de las personas. Cada tupla (fila registro) de la relacin "Personas" representar una persona concreta. Por ejemplo, la relacin Personas (RFC, nombre, apellido, sexo, estado_civil, fecha_nacimiento) es apenas una definicin de la estructura de la tabla, es decir su nombre y la lista de atributos que la componen. Si esta estructura se llena con datos, entonces tendremos una lista de valores individuales para cada tupla, atributo por atributo. Aunque una relacin es ms conocida como tabla, las tuplas como filas y los atributos como columnas, en este escrito usaremos la terminologa original y de donde se deriva el nombre del modelo. Las tuplas en una relacin son un conjunto en el sentido matemtico del trmino, es decir una coleccin no ordenada de elementos diferentes. Para distinguir una tupla de otra, se recurre al concepto de "llave primaria", o sea un atributo o conjunto de atributos que permiten identificar unvocamente una tupla en una relacin (en el ejemplo, el atributo RFC cumple con esta funcin). Naturalmente, en una relacin puede haber ms combinaciones de atributos que permitan identificar unvocamente una tupla ("llaves candidatas"), pero entre stas se elegir una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el valor nulo (que significa un valor no determinado), en tanto que ya no permitiran identificar una tupla concreta en una relacin. Esta propiedad de las relaciones y de sus llaves primarias se conoce como integridad de las entidades. Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El dominio indica qu valores pueden ser asumidos por una columna de la relacin. A menudo un dominio se define a travs de la declaracin de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es posible 20/10/2010 7

COORDINACION DE BASES DE DATOS definir dominios ms complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacin "Personas" podemos definir un dominio por el cual los nicos valores vlidos son 'M' y 'F'; o bien para el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren vlidas slo las fechas de nacimiento despus del uno de enero de 1960. No se debe confundir relacin con el mismo trmino usado en el modelado de EntidadRelacin que se usa para describir las asociaciones que existen entre entidades.
55

El motor de datos se ocupar de controlar que en los atributos de las relaciones se incluyan slo los valores permitidos por sus dominios. Caracterstica fundamental de los dominios de una base de datos relacional es que sean "atmicos", es decir que los valores contenidos en los atributos no se puedan separar en valores de dominios ms simples. Ms formalmente se dice que no es posible tener atributos con valores mltiples (multivaluados). La normalizacin, o sea la razn y uso de las formas normales, es evitar la repeticin innecesaria de datos (redundancia). Una solucin a este problema es repartirlos en varias relaciones y utilizar referencias por valor entre ellas. Este es un ejemplo tpico de que la tupla de una relacin, digamos de Empleados, no deba repetir toda la informacin de su departamento, sino que debe utilizar una referencia por valor a la tupla de la relacin Departamento, donde estn todos estos datos. Este procedimiento ahorra espacio de almacenamiento, optimiza el rendimiento y, al eliminar la redundancia, impide modificaciones parciales o incompletas que podran dar lugar a inconsistencias. Existen hasta 6 formas normales pero, en la prctica, se adopta generalmente hasta la tercera forma normal. Junto con el modelo, el Dr. Codd tambin propuso el lgebra relacional, un lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para obtener otra relacin resultado, sin que cambien las relaciones originales. Tanto los operandos como los resultados son relaciones, por lo que la salida de una operacin puede ser la entrada de otra operacin. Esto permite anidar expresiones del lgebra del mismo modo que se pueden anidar las expresiones aritmticas. Codd originalmente propuso ocho operandos pero slo cinco son fundamentales: restriccin, proyeccin, producto cartesiano, unin y diferencia, que permiten realizar la mayora de las operaciones de obtencin de datos. Los operadores no fundamentales son la concatenacin (join), la interseccin y la divisin, que se pueden expresar a partir de los cinco operadores fundamentales. La restriccin y la proyeccin son operaciones unarias porque operan sobre una sola relacin. El resto de las operaciones son binarias porque trabajan sobre pares de relaciones. Partiendo del clculo relacional, el Dr. Codd desarroll el primer lenguaje relacional llamado ALPHA el cual form el fundamento para el desarrollo subsecuente de lenguaje SQL (original SEQUEL). Otros lenguajes relacionales de consulta, tales como el QBE, se basaron en el lgebra relacional definida por el Dr. Codd. Durante las fases de desarrollo del modelo relacional, el comit ANSI/SPARC de 1975 defini la separacin en tres niveles de los sistemas manejadores de bases de datos: 20/10/2010 8

COORDINACION DE BASES DE DATOS externo, conceptual e interno que vinieron a redundar en lo que ahora se conoce como subesquema externo, esquema lgico y esquema fsico. En otras palabras: los modelos conceptuales, lgico y fsico. Sin embargo, fue el Dr. Codd quien estableci los fundamentos para esta separacin con conceptos tales como la independencia lgica y fsica de los datos (reglas 8 y 9), de independencia, integridad y distribucin (reglas 10 y 11). Como consecuencia, el acrnimo para Query by Example.
56

A partir de Codd el mundo de las bases de datos cambi para siempre. A partir del modelo relacional el usuario no tendra porqu preocuparse de los aspectos tcnicos de la base de datos: simplemente sus necesidades de informacin se satisfaran de acuerdo a su perspectiva de los datos, Igualmente, los programadores de aplicaciones no tendran que lidiar con el modelo fsico, asunto exclusivo del administrador de la base de datos (DBA) quien, si as lo determinara conveniente en aras de un mejor rendimiento, podra modificar el modelo fsico de datos sin afectar al modelo lgico.

EL MODELO ENTIDAD RELACION Y EL ESQUEMA EN ESTRELLA En la medida que el modelo relacional gan aceptacin en la industria surgieron nuevas ideas y propuestas. En la dcada de 1990 hubo un fuerte impulso en pro de la tecnologa del data warehousing. Como ocurre frecuentemente con la adopcin de nuevos paradigmas, se registr tambin un considerable ndice de fracasos. La cuestin fue cmo implementar un data warehouse? De las soluciones emprendidas resaltaron: a) El modelado Entidad-Relacin (E-R) donde las entidades representan relaciones normalizadas (por lo general, en tercera forma normal); y b) El esquema en estrella (E-E), donde las entidades se modelan en tablas con hechos y dimensiones. La regla para una relacin normalizada dice: todos los atributos no llave de una relacin dependen slo y exclusivamente de la llave. Por definicin, el atributo o atributos que componen la llave no tienen valores duplicados; en consecuencia, los atributos no-llave, dependientes por completo de la llave, tampoco. Debido a esta dependencia no existe redundancia en las relaciones. As, en una base de datos completamente normalizada, es suficiente para el diseador declarar restricciones al manejador sustentadas en la llave, lo cual garantiza la integridad y consistencia de la base de datos. Por contraste, el esquema en estrella se fundamenta en una tabla de hechos que contiene uno o ms datos que en lo posible deben ser aditivos o mensurables y una o ms tablas de dimensiones. La llave primaria de la tabla de hechos es una concatenacin de las llaves primarias de cada una de las dimensiones. Los hechos, con frecuencia datos agregados, pueden pensarse como medidas tomadas de la interseccin de todas las dimensiones. El propsito de establecer restricciones especficas en las consultas. A partir del esquema en estrella pueden derivarse cubos para su anlisis con herramientas OLAP. La construccin de una base de datos bajo este esquema requiere de una rgida 20/10/2010 9

COORDINACION DE BASES DE DATOS definicin de hechos y dimensiones (muchas veces sin atender las reglas de normalizacin) que anticipen la consulta de datos bajo patrones preestablecidos. Supuestamente bajo el E-E se logran mejores tiempos de respuesta y los usuarios comprenden mejor los alcances del modelo. El principal problema con el E-E es la rigidez de su diseo que no permite el descubrimiento de nuevas relaciones: cualquier visin de los datos no prevista es imposible; adems, el usuario debe conocer todas las dimensiones de los datos que desea explorar. Si son requeridos otros hechos y dimensiones la estrella tiene que ser remodelada y recargada o generarse una nueva. Esto consume tiempo y recursos, e inhibe el descubrimiento de nuevos patrones de informacin que pueden ser relevantes para la organizacin (minera de datos). Ms an, si hechos y dimensiones son desnormalizados (grupos repetitivos) estamos ante una aberracin del modelo relacional al permitir redundancia y en riesgo de perder la integridad de la base de datos puesto que las restricciones sobre las llaves en las relaciones no tienen validez para mantenerla. En este contexto, el manejador es incapaz de garantizar la integridad, y si no podemos mantener la integridad y la consistencia de la base de datos en un E-E de qu manera podemos afirmar que los datos almacenados son correctos? Una peligrosa aproximacin a las consecuencias de la Ley de Murphy: si se permite que ocurra, ocurrir. Por esta razn los diseadores de un E-E, en el mejor de los casos y cuando lo hacen, tienen que construir software de mantenimiento para cada base de datos en E-E a fin de contar con un medio para demostrar su exactitud, una labor onerosa y no exenta de riesgos perfectamente evitable con otro tipo de soluciones. El modelado E-R, modela los datos de acuerdo a la manera en que se asocian unos con otros y, conforme crecen los desafos de la organizacin, los datos no necesitan reacondicionarse para nuevas y desconocidas relaciones. Aqu tenemos la flexibilidad y belleza del autntico modelo relacional. El modelado E-R proporciona el sustento para la naturaleza transaccional de cualquier data warehouse permitiendo el verdadero anlisis exploratorio ejemplificado por la minera de datos. Un modelo E-R es para toda la organizacin y cualquier relacin posible dentro de la misma tambin es posible dentro del mimso modelo. Es oportuno enfatizar que un data warehouse abarca desde el proceso de recoleccin, administracin y distribucin de los datos, no slo visiones agregadas y predefinidas. Por lo tanto, los sistemas de informacin deben sustentarse en un ambiente capaz y flexible para todo tipo de consultas, sea para el anlisis complejo, o as como tambin para el nivel de detalle y de agregado de datos. En este escenario, simple y sencillamente el E-E no soporta los requerimientos a largo plazo de la organizacin como un todo. Un data warehouse sustentado en el E-E no permite al usuario expandir su entendimiento de las asociaciones entre los datos, cambiar la forma en que se visualiza la organizacin, penetrar en anlisis ms avanzados y/o la generacin de tipos de datos emergentes. Se dice que el modelado ER es muy complejo como para que los usuarios lo entiendan, suponiendo, por contraste, que el E-E es fcil de entender. El asunto aqu es que las capas lgica y fsica de cualquier modelado de bases de datos no tienen por que ser conocidas por el usuario.

20/10/2010

10

COORDINACION DE BASES DE DATOS El acceso a una base de datos, por ejemplo la consulta, debe drsele al usuario en funcin de metadatos, herramientas profesionales y aplicaciones a la medida. Dicho de otra forma, en sus propios trminos y respetando las reglas del negocio. El hacer partcipe obligado al usuario de la jerga tcnica (e. g., cubos, hipercubos, hechos, dimensiones, relaciones, asociaciones, llaves, etc.) es desviar a la informtica de su funcin principal, un ejercicio de petulante auto complacencia que no valdra la pena siquiera mencionar de no ser por su negativo impacto en la relacin con el usuario final y, en ltima instancia, en la misin y visin organizacionales. Otro argumento a favor del E-E es que las tablas desnormalizadas en hechos y dimensiones al ser consultadas tienen un mejor tiempo de respuesta que en un que en un modelado E-R con tablas normalizadas. Aqu lo que se observa es un caso tpico de confusin de las capas lgica y fsica. El proceso de normalizacin, por definicin, incrementa el nmero de tablas lgicas. Similarmente el E-E, que en rigor es un modelo E-R (degenerado), tambin es un modelo lgico. Pero el rendimiento de cualquier manejador de bases de datos no descansa en la capa lgica sino en la fsica. El manejador debe ser capaz de permitir las modificaciones y afinaciones que sean necesarias en la capa fsica sin que se vea alterada la capa lgica; en otro caso, tendremos un producto que no cumple con uno de los fundamentos principales del modelo relacional: la independencia lgica y fsica de los datos. Se dice tambin que el modelado E-R es confuso y difcil de navegar. A esto respondemos: descubrir la esencia de los datos y presentarlos al usuario como los necesita es deber ineludible de cualquier buen modelador e implica una ardua labor de comprensin y descubrimiento donde el usuario es el actor principal. Si somos negligentes en esta labor estaremos por un lado menospreciando a los usuarios y por otro desaprovechando las oportunidades que ofrece la organizacin. Sin duda los usuarios necesitan de informacin tpica, predefinida, agregada, con cortes bien explcitos para su consulta y reacomodo a conveniencia es decir, anlisis multidimensional de datos. Para muchos diseadores el E-E ha sido la solucin. No obstante, el modelado multidimensional de los datos puede hacerse en la capa lgica, sin comprometer la integridad y consistencia de la base de datos. Las vistas, que son relaciones lgicamente definidas, sirven para este propsito al ocultar los detalles del modelo y presentando los datos conforme a cualquier contexto en particular o necesidad. Por medio de vistas es posible representar las estructuras multidimensionales que sean requeridas y ser reaprovechadas por cualquier aplicacin, herramienta profesional o como entrada a una verdadera base de datos multidimensional, tecnologa desarrollada para el propsito de cubos e hipercubos. Puesto que una vista es una representacin lgica, significa que puede rpida y fcilmente modificarse sin tener que alterar los datos. Comprese lo anterior con el E-E donde es inevitable el esquema conceptual, el lgico y el fsico, el software de mantenimiento y extraccin, los costosos procesos de agregacin y carga, amn de su 20/10/2010 11

COORDINACION DE BASES DE DATOS administracin y, por si fuera poco, el dispendioso e innecesario almacenamiento en disco. Las vistas son fundamentales en el modelo relacional, aunque los proveedores comerciales tienen diferentes implementaciones con objeto de mejorar su eficiencia: as, se habla de vistas materializadas (Oracle) o vistas indizadas (SQL Server) a fin de que, despus de una primera ejecucin, las siguientes tengan un ptimo tiempo de respuesta. La combinacin de las relaciones originales y de las vistas es un explosivo ambiente capaz de potenciar a los usuarios para la creacin de consultas cada vez ms complejas, generando ms informacin y conocimiento. Y todo lo anterior sin comprometer ni el modelo, ni los datos almacenados, ni los recursos de almacenamiento, ni de la necesidad de software adicional, ni de onerosos procesos de actualizacin y mantenimiento! Cuando el E-E ofrezca algo parecido ser un placer su revisin. Para terminar este asunto, afirmamos que la construccin de un gran nmero de bases de datos modeladas en E-E es un mal concebido intento para dar contexto a las bases de datos relacionales y un cuento de nunca acabar pues, por cada necesidad de informacin, el fantico de este enfoque propondr una nueva estrella. Tambin, es revelador del desconocimiento que se tiene sobre el modelo relacional y sus alcances. La supuesta y aparente carencia de contexto del modelo relacional es precisamente donde descansa su inmenso poder. De hecho, a partir de una base de datos normalizada es posible extraer cualquier contexto de su contenido. En otras palabras, la informacin que se requiera, cuando se requiera y donde se requiera. El modelo relacional de bases de datos con sus relaciones normalizadas es una solucin simple y elegante para satisfacer las ms diversas condiciones de consulta y extraccin de datos e informacin. El Dr. Codd, al recibir el premio Turing en 1981, declar que una verdadera base de datos relacional puede estar al alcance de los no programadores,En otro momento, hizo la siguiente reflexin: es importante recordar que las bases de datos se establecen para beneficio de los usuarios finales, y no para los programadores de aplicaciones quienes actan como intermediaros para las necesidades actuales de procesamiento de datos. Sabias palabras!

20/10/2010

12