Está en la página 1de 12

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 2
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 3
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 5
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.
2 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.
3 Los campos en blanco de una columna se pueden representar por el valor
NULL.
4 La base de datos debe contener ciertas tablas del sistema cuyas columnas
describan la estructura de la propia base de datos.
5 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.
6 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.
7 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.
8y9 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

20/10/2010 6
COORDINACION DE BASES DE DATOS

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.
10 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.
11 El lenguaje de bases de datos debe ser capaz de manipular datos distribuidos
localizados en otros sistemas informticos.
12 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 Entidad-


Relacin 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 E-
R 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

También podría gustarte