P5 Cap 21

21.
1 INTRODUCCI6N
Nota: David McGoveranfue el autor original de estecap{tulo.
Los sistemasde apoyo para la toma de decisionesson sistemasque ayudanen el analisisde
infonnaci6n de negocios.Su prop6sitoes ayudara la administraci6nparaque "marquetendencias,
sefialeproblemasy tome... decisionesinteligentes" [21.7]. Los orfgenesde dichos sistemas-in-
vestigaci6nde operaciones,teorfasde administraci6ncientificas o basadasen comportamiento,y
control de procesosestadisticos- seremontana finalesde los afioscuarentay principios de los cin-
cuenta,mucho antesde que las computadorasexistieran.La idea basicaera, y por supuestosigue
siendo,recolectardatosoperacionalesdel negocio(veael capftulo 1) y reducirlosa una fonna que
pudieraser usadaparaanalizarel comportamientodel mismo y modificarlos de una manerainteli-
gente.Por supuesto,por razonesmuy obvias,la reducci6nde los datosen esosprimerosdfaseracasi
minima, involucrabageneralmenteun poco masque producir simplesinfonnes de resUmenes.
A fmalesde los afiossesentay principiosde los setenta,los investigadoresde Harvardy del MIT
comenzarona promoverel uso de computadorasparaque ayudaranen el procesode toma de deci-
siones[21.23]. Al principio, dicho uso estuvolimitado (principalmente)a la automatizaci6nde las
tareasde generaci6nde infonnes, aunqueen ocasionestambien se proporcionaronherramientas
analfticasalgo rudimentarias[21.2], [21.3], [21.6] [21.26]. Esosprimerossistemasde c6mputofue-
ron conocidosinicialmentecomosistemasde decisionespara la administracion, y posterionnente
tambienseles llam6 sistemasde informacion para la administracion. Sin embargo,preferimosel
terrninomasmodemosistemasde apoyopara la tomade decisiones,ya que en buenamedida,todos
los sistemasde infonnaci6n -que incluyen, por ejemplo, a los sistemasOLTP (procesamientode
transaccionesen lfnea)- puedeno debenser consideradoscomo "sistemasde infonnaci6n parala
administraci6n"(a fin de cuentas,todos estaninvolucradoscon y afectanla administraci6nde los
negocios).En las siguientespartes,nos mantendremoscon el terrninomasmodemo.
Los afios setentatambien vieron el desarrollo de varios lenguajes de consulta, y alrededor
de dichos lenguajesseconstruyeronvarios sistemaspersonalizadosde apoyo para la toma de de-
cisiones(desarrolladospor las propiasempresas).Fueron implementadosusandogeneradoresde
infonnes, talescomo el RPG, o productospara la recuperaci6nde datos,talescomo Focus,Data-
trieve y NOMAD. Estos sistemasfueron los primeros que perrnitieron a los usuariosfinales de-
bidamente entrenadosacceder directamente a los almacenesde datos de la computadora; es
decir, perrnitieron que tales usuarios fonnularan consultasrelacionadascon el negocio basan-
doseen esosalmacenesde datos,y ejecutaranesasconsultasdirectamentesin tener que esperar
ayuda del departamentode procesamientode datos.
Por supuesto,losalmacenesde datosque acabamosde mencionareranen su mayorfaarchivos
simples;la mayoriade los datosde negociosen esetiempo seguardabanen dichosarchivos,o posi-
694
Cap£tulo 21 / Apoyo para la toma de decisiones 695
blementeen basesde datosno relacionales(los sistemasrelacionalestodavfaseencontrabanen el

campode la investigaci6n).Por 10general,incluso en esteultimo caso,los datostenfanque serex-
trafdosde la basede datosy copiadoshaciaarchivosantesde queun sistemade apoyoparala toma
de decisionespudiera tener accesoa ellos. No fue sino hastaprincipios de los ochentacuando se
empezarona usar las basesde datosrelacionales,en lugar de los archivossimplespara apoyo a la
toma de decisiones.De hecho,el apoyoparala toma de decisiones,las consultasad hoc y la elabo-
raci6n de informes estuvieronentrelos primeros usoscomercialesde la tecnologfarelacional.
Aunque en la actualidadlos productosSQL estandisponibles ampliamente,la idea del pro-
cesamiento de extracciones --es decir, copiar los datos del ambiente operacional a otro am-
biente--- sigue siendomuy importante;permite que los usuariosoperende cualquier forma sobre
los datos extrafdos sin interferir con el ambienteoperacional.y por supuesto,la raz6n para rea-
lizar tales extraccioneses, muy a menudo, el apoyo para la toma de decisiones.
Debe quedarclaro en la breve historia anterior, que el apoyo para la toma de decisionesen
realidadno espartede la tecnologfade basede datospor sf misma.En su lugar,esun usode esatec-
nologfa (aunquemuy importante)0 para ser masprecisos,son varios usosdistintos, pero entrela-
zados.Los usosen cuesti6nrecibenlos nombresde data warehouse,data mart, almacende datos
operacionales,OIAP (procesamientoanal{ticoen l{nea),basesde datosmultidimensionalesy mine-
r{a de datos(entreOtrOS). Trataremostodosestostemasen las seccionesquevienena continuaci6n.
Precauci6n: Le comentamosinmediatamenteque algo que tienen en comun todas estas
areases que irara vez siguen buenosprincipios de disefio 16gico! La prIlctica del apoyo para la
toma de decisioneslamentablementeno es tan cientffica como deberfa;en realidad, a menudo
se hace a la medida.En particular, tiende a ser manejadamucho mas por consideracionesffsicas
que por 16gicas(y ademIls,la diferencia entrelos asuntosffsicos y los 16gicosestaa menudomuy
difusa en el ambientede apoyo para la toma de decisiones).En parte por estasrazones,en este
capftulo usamosSQL y no Tutorial D como basepara nuestrosejemplos, y usamosla termino-
logfa SQL "mas general"de filas, columnasy tablasen lugar de nuestraterminologfapreferida de
tuplas,atributosy valores,y variablesde relaci6n(varrels).Tambien,usamoslos rerminosesquema
16gicoy esquemafisico como sin6nimos para 10que en el capftulo 2llamamos el esquemacon-
ceptual y el esquemaintemo, respectivamente.
Por 10tanto, el plan del capftulo es el siguiente. En la secci6n 21.2 tratamos determinados
aspectosdel apoyo para la toma de decisionesque han motivado ciertas prIlcticas de disefio que
creemosque estanun poco equivocadas.La secci6n21.3 describenuestropropio enfoquepreferido
paralidiar con esosaspectos.Luego, la secci6n21.4 examinael temade la preparaci6nde datos(es
decir, el procesode poner los datosoperacionalesen una forma que puedaserutil paralos prop6si-
tos del apoyopara la toma de decisiones);tambienconsiderabrevementelos "a1macenes de datos
operacionales".La secci6n21.5 trata los data warehouses,los datamartsy los "esquemasdimen-
sionales".La secci6n21.6 explora el OLAP (procesamientoanalfticoen linea) y las basesde datos
multidimensionales.La secci6n21.7 tratala minerfade datos.La secci6n21.8 presentaun resumen.
21.2 ASPECTOS DEL APOYO p ARA LA TOMA DE DECISIONES

Las basesde datos de apoyo para la toma de decisionesmuestrandetenninadascaracteristicas
especiales,de las cuales sobresaleesta: la base de datos es principalmente (aunqueno total-
mente) de solo lectura. Por 10general,la actualizaci6nque se da estalirnitada a operacionesde
carga o actualizacionesperi6dicas(y esasoperacionesestandorninadas,asu vez, por INSERTs
-Ios DELETEs se realizan muy ocasiona1mente y los UPDATEs casi nunca).Nota: En algunas
ocasionessehacenactualizacionesen detenninadastablas de trabajo auxiliares, pero el proceso
696 Parte Temas adicionai
de apoyo para la toma de decisioneS nonnal, casi nunca actualiza la propia base de datoS de apoyo
para la toma de decisiones.
Tambien vale la pena sefialar las siguientes caracteristicas adicionales de las bases de datos
de apoyo para la toma de decisiones (en la secci6n 21.3 regresaremos a este punto para ampliarlo ).
Observe que las tres primeras son de naturaleza 16gica y las tres ultimas son ffsicas.
.Se tiende a usar las co1urnnas en combinaci6n.
.Por 10 general, no preoCUpa la integridad (se SUponeque 10SdatoS Son correctos cuando se
cargan por primera vez y no son actualizados posterionnente).
.Las claves incluyen frecuentemente un componente temporal (vea el capftulo 22).
.La base de datos tiende a ser grande (especialmente cuando se acumulan 10Sdetalles de las
transacciones* de negocios a 10 largo del tiempo, y Con frecuencia asf sucede).
.La base de datoS tiende a estar muy indexada.
.La base de d~toS involucra frecuentemente varioS tipoS de redundancia controlada (vea el
capftulo I).
Las consultas de apoyo para la toma de decisiones presentan tambien caracteristicas espe-
ciales yen particular, tienden a ser bastante complejas. Estos Son algunos de 10StipoS de Com-
plejidades que pueden presentarse:
.Complejidad de expresiones 16gicas: Las consultas de apoyo para la toma de decisiones a
menudo invo1ucran expresiones complejas en la clliusula WHERE; las cuales son diffciles de
escribir, diffciles de comprender y diffciles de manejar adecuadamente por el sistema. (En par-
ticular, 10Soptimizadores clasicoS tienden a ser inadecuados, debido a que estan disefiadoS
para evaluar s01amenteuna cantidad limitada de estrategias de acceso.) Un problema Comun
es que las consultas invo1ucran al tiempo; por 10 general, 10Ssistemas actuales no proporcio-
nan un buen soporte para, por ejemplo, consultas que preguntan por las filas que tienen un
valor maximo de marca de tiempo dentro de un periodo especificado (de nuevo, vea el capf-
tu10 22). Si hay alguna junta inv01ucrada, dichas consultas llegan rapidamente a ser muy Com-
plejas. Por supuesto, en todos eSOSCasoSel resultado neto es un bajo rendimiento.
.Complejidad de juntas: Las consultas de apoyo para la toma de decisiones requieren frecuen-
temente acceso a muchas clases de hechoS. Por consecuencia, en una base de datoS disefiada
adecuadamente --es decir completamente nonnalizada- dichas consultas inv01ucran, por 10
general, a muchas juntas. Desafortunadamente, la tecn010gfa para el procesarniento de juntas
nunca ha 10grado mantenerse al paso ante las demandas siempre crecientes de las consultas de
apoyo para la toma de decisiones. t Por 10tanto,loS disefiadores a menudo optan por desnorma-
* Aquf, y a 10largo de estecapftulo, distinguimos entre las transaccionesde negocios (por ejemplo, la venta
de un producto) y las transaccionesen el sentido de la parte IV de este libro, y usaremossiempre el califi-
cador "negocios" cuando en realidad queramosreferirnos a una transaccion de negocios (a menos que el
contexto haga obvio el significado).
tEl escritor (McGoveran), mientras trabajabaen los primeros sistemasde apoyo para la toma de decisiones
en 1981, observo que una junta de tres tablas de tamafio moderadopodrfa llevarse facilmente varias horns.
Por 10general,ias juntas de cuatro 0 seistablas eran consideradasdemasiadocostosas.En la actualidad, las
juntas de seisa diez tabias muy grandesson comunes,y por 10general la tecnologfa funciona bien. Sin em-
bargo, todavfa es facii (y no inusuai) generarconsultasquejunten mas tablas de las que la tecnoiogfa puede
manejar razonabiemente.Las consuitasquejuntan mas de doce tablas pueden!legar a ser rapidamenteuna
aventura, iY atin asf, es comtin encontrar requerimientospara dichas consuitas!
Cap£tulo 21 Apoyo para la toma de decisiones 697
lizar la base de datos "prejuntando" detenninadas tablas. Sin embargo, como vimos en el capf-
tulo 12 (en la secci6n 12.5), este enfoque rara vez es exitoso, ocasiona generalmente tantos
problemas como los que resuelve. Ademas, el deseo de evitar juntas tambien puede conducir
al uso ineficiente de las operaciones relacionales, recuperando una gran cantidad de datos y rea-
lizando el procesarniento de juntas dentro de la aplicaci6n en lugar de hacerlo en el DBMS.
.Complejidad de funci6n: Las consultas de apoyo para la toma de decisiones involucran fre-
cuentemente funciones estadfsticas y matematicas. Pocos productos soportan tales funciones.
Por consecuencia, a menudo es necesario dividir una consulta en una secuencia de otras con-
sultas mas pequefias, las cuales luego son ejecutadas en forma intercalada con procedimientos
escritos por el usuario que calculan las funciones deseadas. Este enfoque tiene la consecuen-
cia desafortunada de que tal vez sea necesario recuperar grandes cantidades de datos; por su-
puesto tambien hace que la consulta general sea mucho mas diffcil de escribir y comprender.
.Complejidad analuica: Las preguntas de negocios rara vez son respondidas con una sola
consulta. No s61o es diffcil para los usuarios escribir consultas de gran complejidad, sino
que las limitaciones que tienen las implementaciones de SQL pueden impedir el procesa-
miento de una de estas consultas. Una forma de reducir la complejidad de dichas consultas
es (de nuevo) dividirla en una serie de otras consultas mas pequefias y guardar los resulta-
dos intermedios en tablas auxiliares.
Todas las caracterfsticas anteriores, tanto las de las bases de datos de apoyo para la toma de de-
cisiones como las de las consultas de apoyo para la toma de decisiones, dan pie a un fuerte enfasis
sobre el disefio para el rendimiento, en especial el rendimiento de la inserci6n por lotes y la recu-
peraci6n ad hoc. Sin embargo, nuestra posici6n (en la cual ahondaremos en la siguiente secci6n) es
que esta situaci6n s61o debe afectar al disefio fisico de la base de datos y no al disefio 16gico. Sin
embargo, por desgracia (como sefialamos en la secci6n 21.1) los fabricantes y usuarios de los sis-
temas de apoyo para la toma de decisiones a menudo fallan al distinguir adecuadamente entre los
aspectos 16gicos y los fisicos;* de hecho, con frecuencia olvidan por completo el disefio 16gico.
Como consecuencia, los intentos para manejar las diversas caracterfsticas que explicamos anterior-
mente tienden a ser ad hoc y conducen frecuentemente a dificultades insuperables al tratar de balan-
cear los requerimientos de correcci6n, mantenimiento, rendimiento, escalabilidad y utilidad.
21.3 DISENo DE BASES DE DATOS DE APOYO

PARA LA TOMA DE DECISIONES
Como aflfffiamos anteriormente en este libro (en particular en la introduccion a la parte ill),
nuestraposicion es que el disefio de basede datos siempre debe ser realizado en al menos dos
etapas,primero la logica y luego la ffsica:
a. El disefio logico debe ser realizadoprimero. En estaetapa,el enfoqueestaen la correcci6n
relacional: las tablas debenrepresentarrelaciones adecuadasy por 10tanto garantizar que
las operacionesrelacionales funcionen tal como se indica y no produzcanresultados sor-
*Los especialistasde datawarehousesy de OLAP tiendena ser especialmenteculpablesen esto;argumentan

frecuentementequeel disefiorelacionalessimplemente"err6neo" paraapoyara la tomade decisiones,diciendo
que el modelo relacionales incapazde representarlos datosy que debeser dejadode lado. Tales argumentos
casi siemprese debena una Callapara distinguir entreel modelo relacionaly su implementaci6nfisica.
698 Parte v / Temas adicionales
prendentes.Los dominios (tipos) debenserespecificados,suscolumnasdefinidasy las depen-

denciasentre columnas(DFs, etcetera)debenser identificadas.A partir de estainfonnacion
es posible continuar con la nonnalizacion y definir las restriccionesde integridad.
b. Segundo,el disefio ffsico debe surgir a partir del disefio logico. Por supuesto,en estaetapa
el punto de atencion esta puesto sobre la eficiencia y el rendimiento del almacenamiento.
En principio es perrnisible cualquier acomodoffsico de los datos, siempre y cuando exista
una transfonnacion que conservela infonnacion entre los esquemas16gicoy ffsico, y que
pueda ser expresadaen el algebrarelacional [2.5]. Observeen particular, que la existencia
de una transfonnaci6n de estasimplica que existen vistas relacionales del esquemaffsico
que 10hacenver similar al esquemalogico y viceversa.
Por supuesto,el esquema16gicopuedecambiar posterionnente(por ejemplo, para acomo-
dar nuevos tipos de datos 0 nuevas--{) recientementedescubiertas- dependencias)y tal cam-
bio requerira naturalmenteun cambio correspondienteen el esquemaffsico. Dicha posibilidad
no nos concieme aquf. Lo que nos concieme es la posibilidad de que el esquemaffsico pueda
cambiar mientras no cambie el esquema16gico.Por ejemplo, supongamosque la junta de las
tablas VP (envfos) y P (partes)es, por mucho, el patron de accesodominante. Entoncestal vez
queramos"prejuntar" las tablas VP y P al nivel ffsico y por 10tanto, reducir los costosde E/S y
dejunta. Sin embargo,el esquema16gicodebepermanecersin cambio, si es que sedesealograr
la independenciaffsica de datos.(Por supuesto,el optimizador de consultasnecesitaraestarcon-
scientede la existencia de la "prejunta" guardaday usarla adecuadamentesi queremosobtener
los beneficios de rendimiento necesarios.)Ademas,si el patr6n de accesocambiaposterionnente
a uno dominado por accesosa tablas individuales en lugar de juntas, debemosteller la posibili-
dad de cambiar nuevamenteel esquemaffsico para que las tablas VP y P estende nuevo ffsica-
mente separadassin ningun efecto en el nivel16gico.
De 10anterior debe quedar claro que el problema de proporcionar independenciaffsica de
los datos es basicamenteel problema de soportar la actualizacion de vistas (excepto que, como
sucedecon el problema de la actualizacion fragmentadaque vimos en el capftulo 20, se mani-
fiesta por sf mismo en un punto diferentede la arquitecturageneraldel sistema).Ahora, en el capf-
tulo 9 vimos que en teorfa, todas las vistas relacionalesson actualizables.Por 10tanto, en teorfa,
si el esquemaffsico esta derivado a partir del esquemalogico en la fonna que describimos an-
terionnente, se lograra la maxima independencia ffsica de los datos. Cualquier actualizacion
expresadaen terrninos del esquemalogico seratraducible automaticamenteen otra expresadaen
terrninos del esquemaffsico y viceversa,y los cambios al esquemaffsico no requeriran cambios
al esquema16gico.Nota: De paso, comentamosque la unica razon para hacer tales cambios al
esquemaffsico deberaser la de mejorar la eficiencia de almacenamiento0 de rendimiento.
Sin embargo,desafortunadamentelos productos SQL actualesno soportanadecuadamente
la actualizacion de vistas. Por consecuencia,el conjunto de esquemasffsicos perrnisibles esta
considerablemente(e innecesariamente)limitado en esosproductos. Para ser mas especfficos,
si (a) consideramoslastablasbaseen el nivellogico como vistas,y las versionesguardadasde esas
"vistas" en el nivel ffsico como tablas base,entonces(b) el esquemaffsico debe ser tal que el
producto en cuestion puedaimplementar todaslas actualizacioneslogicamenteposibles en esas
"vistas" en terrninosde esas"tablasbase".Nota: En la practicatal vez seaposible simular el meca-
nismo de actualizacion de vistas adecuadopor medio de procedimientosalmacenados,procedi-
mientosdisparados,middleware0 algunacombinacionde ellos. Sin embargo,dichastecnicasestan
fuera del alcancedel presentecapftulo.
:ap(tulo 21 / Apoyo para la toma de decisiones 699
Disefio logico
Las reglas del disefio 16gico no dependen del uso que se pretenda dar a la base de datos, ya que
se aplican las mismas reglas sin tomar en cuenta los tipos de aplicaciones. Por 10 tanto, en par-
ticular no debe haber diferencia si esas aplicaciones son operacionales (OL TP) o de apoyo para
la toma de decisiones; de cualquier forma, es necesario seguir el mismo procedimiento de disefio.
Entonces, volvamos a ver las tres caracteristicas 16gicas de las bases de datos de apoyo para la
toma de decisiones que identificamos casi al iniciode la secci6n 21.2 y consideremos sus im-
plicaciones para el disefio 16gico.
.Combinaciones de columnasy muy pocas dependencias

Las consultasde apoyoparala toma de decisiones-y las actualizaciones,cuandosonaplica-
bles- con frecuenciatratana las combinacionesde columnascomo una unidad,10que signi-
fica que las columnascomponentesnuncason accedidasen fonna individual (DIRECCION
es un ejemplo obvio). Acordemos referimos a dicba combinacion de columnas como una
columna compuesta.Entonces, desdeun punto de vista de disefio logico, itales columnas
secomportancomo si de becbono fueran compuestas! Parasermasespecfficos,seaCC una
columna compuestay seaC alguna otra columna de la rnisma tabla. Entonces las depen-
denciasque involucran a C y a los componentesde CC se reducen a dependenciasque in-
volucran a C y CC por sf rnismas.Lo que es mas, las dependenciasque involucran a los
componentesde CC y a ninguna otra columna, son irrelevantes y simplementepuedenser
ignoradas. El efecto neto es que la cantidad total de dependenciasse reduce y el disefio
logico se vuelve mas sencillo, con menoscolumnas y posiblementebastamenostablas.
Nota; Sin embargo,es convenienteque mencionemosque el soportecompleto y ade-
cuado para las columnascompuestasno es trivial y sebasaen el soportede tipos definidos
por el usuario. Paramayoresexplicaciones,vea la referencia [21.11] y los capftulos 5 y 25.
.Las restricciones de integridad en general
Como ya explicamos, (a) las basesde datos de apoyo para la toma de decisionesson prin-
cipalmente de solo lectura y (b) la integridad de 10sdatos se verifica al cargar (0 actualizar)
la basede datos y a menudo suponemosque no tiene sentido declarar restriccionesde inte-
gridad en el esquemalogico. Sin embargo,esteno es el caso.Aunque es cierto que las res-
tricciones nunca van a ser violadas (si la base de datos en realidad es de solo lectura), no
debemosdesestimarel valor semdnticode esasrestricciones.Como vimos en el capitulo 8
(seccion 8.10), las restriccionessirven para definir el significado de las tablas y el signifi-
cado de toda la basede datos.Por 10tanto, declarar las restriccionesproporciona un medio
para decirle a los usuarios 10que significan los datos y por 10tanto, les ayuda en su tarea
de fonnular consultas.Ademas,la declaracionde restriccionestambien puedeproporcionar
infonnacion crucial al optirnizador (vea la explicacion de optimizaci6n semdnticaen el ca-
pftulo 17, seccion 17.4).
Nota; Declararciertasrestriccionesen ciertosproductosSQL, ocasionala creacionauto-
maticade deterrninadosindicesy otrosmecanismosde cumplirnientoasociados,un hecboque
puedeincrementar significativamente el costo de las operacionesde carga y actualizacion.
Este hecbo, a su vez, puede servir para motivar a los disefiadoresa evitar la declaracionde
restricciones.Sin embargo, el problema se deriva nuevamentede una confusion entre los
asuntoslogicos y fisicos; debe ser posible especificar restriccionesde integridad en fonna
700 Parte v Temas adicionales
declarativa al nivel16gico y expresar en fonna independiente 10Smecanismos de cumpli-

miento Correspondientes al nivelftsico. Sin embargo, por desgracia 10Sproductos SQL ac-
tuales no diferencian adecuadamente entre 10SdoS niveles (ademlls, rara vez reconocen el
valor semantico de las restricciones).
.Claves temporales
Por 10 general, las bases de datos operacionales inv01ucran s610 datos actuales. Por el Con-
trario, las bases de datos de apoyo para la toma de decisiones inv01ucran por 10 general datos
hiStOriCOSy por 10tanto, tienden a poner marcas de tiempo en la mayoria 0 en todoS 10Sdatos.
Por consecuencia, las claves de dichas bases de datos incluyen frecuentemente c01umnas
de marc as de tiempo. Por ejemplo, considere nuestra base de datos usual de proveedores y
partes. Suponga que necesitamos extender la tabla para mostrar el mes particular (I a 12)
en el que sucedio cada envfo. Entonces la tabla de envfoS VP puede verse Como muestra la
figura 21.1. Observe que la columna adicional IDM ("ID de mes") es parte de la clave en
esta version extendida de la tabla VP. Observe ademlls que las consultas que inv01ucran a
VP ahora deben ser fonnuladas muy cuidadosamente para evitar el acceso a datos con mar-
cas de tiempo diferentes (a menoS que ese acceso sea exactamente 10 que se desea, por
supuesto). Tratamos brevemente estos temas en la seccion 21.2; y el capftulo 2210S trata a
profundidad.
Nota: Agregar c01umnas de marca de tiempo a una clave puede 1levarnos a la necesi-
dad de un disefio nuevo. Por ejemplo, suponga (algo artificialmente ) que la cantidad de cada
envfo esta deterrninada por el mes en el que sucede el envfo (loS datos de ejemplo de la
figura 21.1 Son consistentes con esta restricci6n). Luego, la version modificada de la tabla
VP satisface la dependencia funcional IDM ~ CANT y por 10 tanto, no estll en la quinta
-ni siquiera en la tercera- fonna nonnal; por 10 tanto, debe ser nonnalizada adicional-
mente Como 10 indica la figura 21.2. Por desgracia, 10Sdisefiadores de apoyo para la toma
de decisiones rara vez se preoCUpan por tomar en cuenta tales dependencias inducidas.
VP v# P# IDM CANT
V1 P1 3 300
V1 P1 5 100
V1 P2 1 200
V1 P3 7 400
V1 P4 1 200
V1 P5 5 100
V1 P6 4 100
V2 P1 3 300
V2 P2 9 400
V3 P2 6 200
V3 P2 8 200
V4 P2 1 200
V4 P4 8 200
V4 P5 7 400
V4 P5 11 400
Figura 21.1 Valores de ejemplo para la tabla VP incluyendo IDs de mes.

:apitulo 21 / Apoyo para la toma de decisiones 701
CANT-MENSUAL IDM CANT
1 200
2 600
3 300
4 100
5 100
6 200
7 400
8 200
9 400
10 100
11 400
12 50
Figura 21.2 Contraparte normalizada de la figura 21.1
Disefto fisico
En la secci6n21.2 dijimos quelas basesde datos de apoyo para la toma de decisionestienden a
sergrandesy fuertemente indexadas,e involucran diversostipos de redundanciacontrolada. En
esta subsecci6ntrataremosbrevementeestascuestionesde disefio ffsico.
Primero consideramosel partido (tambienconocido comofragmentacion).El partido repre-
sentaun ataqueal problema de la "base de datos grande"; divide una tabla dadaen un conjunto
departiciones ofragmentos separadosparaefectosde almacenarnientoffsico (vea la explicaci6n
sobre fragmentaci6n en el capftulo 20). Dichas particiones puedenmejorar significativamente
el manejo y la accesibilidadde la tabla en cuesti6n.Por 10general,a carlapartici6n se le asignan
determinadosrecursosde hardwaremas 0 menosespecfficos(por ejemplo, disco, CPU) y por 10
tanto, se rninirniza la competenciapor dichos recursosentre las particiones.Las tablasson parti-
das horizontalmente* por medio de unafuncion de particion, la cual toma valores de colurnnas
seleccionadas(la clave de particion) como argumentosy regresaun numero o direcci6n de par-
tici6n. Por 10general,dichasfuncionessoportanla partici6n por rango,por dispersi6nyen ronda,
entre otros tipos (vea el comentario a la referencia [17.58] en el capftulo 17).
Ahora pasemosal indexado. Por supuesto,es bien conocido que el uso del tipo adecuadode
indice puedereducir drasticamentela F/S. La mayorfa de los primeros productos SQL propor-
cionabansolamenteun tipo de indice, el8ibol B, pero a travesde los afiossehan tenido otros tipos
disponibles,en especialen conexi6n con las basesde datosde apoyo para la toma de decisiones;
estosincluyen a los indicesde mapade bits, dispersion,multitabla, logicos y funcionales, asfcomo
a los indices de 8ibol B en sf. Comentaremosbrevementecadauno de estostipos.
.indices de tirbol B. Los indices de 8ibol B proporcionan accesoeficiente para consultasde
alcance(a menos que la cantidad de filas accedidasllegue a ser demasiadogrande).La ac-
tualizaci6n de 8iboles B egrelativamenteeficiente.
*El partido vertical, aunquepudiera ser ventajoso,no es muy usado,ya que la mayoria de 10Sproductosno
10SODOrta.
.indices de mapa de bits. Supongamosque la tabla indexadaT contiene n filas. Entoncesun

fndice de mapade bits sobrela columna C de la tabla T, guardaun vector de n bits para cada
valor que estaen el dominio de C, y enciendeel bit correspondientea la fila R cuando esa
fila contiene el valor aplicable en la columna C. Estos indices son eficientes para las con-
sultasque involucran conjuntos de valores,aunquellegan a sermenoseficientes cuandolos
conjuntos se vuelven demasiadograndes.Observeen particular que varias operacionesre-
lacionales (juntas, uniones, restriccionesde igualdad, etcetera)puedenser realizadascom-
pletamente dentro de los indices, por medio de operacioneslogicas simples (AND, OR,
NOT) sobre los vectoresde bits; el accesoa los datos actualesno es en absoluto necesario
sino bastaque setiene que recuperarel resultadofinal. La actualizacionde indices de mapa
de bits es relativamente ineficiente.
.indices de dispersion (tambien conocidos como direccionamiento de dispersion 0 simple-
mente dispersion [hashing]). Los indices de dispersion son eficientes para accedera filas
especificas(no rangos). El costo de la computaciones lineal para la cantidad de filas, siem-
pre y cuando la funcion de dispersi6n no necesiteser extendida para acomodarvalores de
clave adicionales.La dispersiontambienpuedeser usadapara implementarjuntas de mane-
ra eficiente, tal como 10describimosen el capitulo 17.
.indices multitabla (tambien conocidoscomo Indicesdejunta ). Una entradade indice multi -
tabla contieneesencialmenteapuntadoresbacia fllas de varias tablas,en lugar de solo bacia
filas de una tabla. Dicbos indices puedenmejorar el rendimientode las juntas y el proceso
de verificacion de las restriccionesde integridad de lasmultitablas (es decir, de la basede
datos).
.indices logicos (por 10general, mejor conocidos como indices de expresion). Un indice
logico indica para que filas de una tabla especifica,una expresionlogica especifica (que in-
volucra columnasde la tabla en cuestion)da como resultadoverdadero. Dicbos indices son
particularmentevaliosos cuandola expresionlogica relevantees un componentecomun de
las condiciones de restriccion.
.indicesfuncionales. Un indice funcional indexa las filas de una tabla no con baseen los va-
lores de esasfilas, sino con baseen el resultadodelllamado a alguna funcion especificada
sobre esosvalores.
Ademas de todo 10 anterior, ban sido propuestosvarios tipos de indices hloridos (combi-
nacionesde los anteriores).El valor de dicbos ht'bridoses dificil de caracterizaren terminos ge-
nerales.Tambien se ban propuestouna enorme cantidad de tipos de indices especializados(por
ejemplo, tirboles R, que estanpensadospara manejar datos geometricos).En este libro, no in-
tentaremosrealizar la enormetareade describir todosestostipos de indices; parauna explicacion
amplia, vea por ejemplo la referencia [25.27].
Por ultimo, pasemosal asuntode la redundancia controlada. La redundanciacontrolada
es u.naberrarnientaimportanteparareducir la E/S y minimizar la contienda.Como explicamosen
el capitulo 1,Jaredundanciaestacontroladacuandoes administradapor el DBMS y estaoculta
para los usuarios.(Observeque, por definicion, la redundanciaque es controladaadecuadamente
en el nivel fisico es invisible en el nivel16gico, y por 10tanto, no tiene efecto sobre la correc-
ci6n de esenivellogico.) Hay dos tipos amplios de estaredundancia:
.El primero implica mantenercopias exactas,0 replicas, de los datos basicos.Nota: Lo que
puedeser consideradocomo una forma de replicaci6n menosambiciosa,la administracion
de copias,tambien es ampliamentesoportada(vea mas adelante).
Capitula 21 / Apaya para la tama de decisianes 703
.El segundo implica mantener datos derivados ademlis de los datos blisicos, muy frecuente-
mente en la forma de tablas de resumen o de columnas calculadas o derivadas.
Trataremos cada uno de estos por separado.

En el capftulo 20 (secciones 20.3 y 20.4) explicamos los conceptos basicos de la replicacion
(vea especialmente la subsecci6n "Propagaci6n de la actualizaci6n" en la secci6n 20.4); aquf sim-
plemente repetiremos algunos puntos sobresalientes de esas explicaciones y haremos algunos cOo
mentarios adicionales. Recuerde primero que la replicaci6n puede ser s£ncrona o as£ncrona:
.En el caso s{ncrono, si se actualiza una replica dada, todas las demas replicas del mismo frag-
mento de datos tambien se actualizan dentro de la misma transacci6n; 10 que implica que
(desde unpunto de vista 16gico) s610existe una versi6n de los datos. La mayorfa de los pro-
ductos implementan la replicaci6n sfncrona por medio de procedimientos disparados (posi -
blemente ocultos y manejados por el sistema). Sin embargo, la replicaci6n sfncrona tiene la
desventaja de que impone una sobrecarga sobre todas las transacciones que actualizan cual-
quier replica (tambien puede haber problemas de disponibilidad).
.En el caso as{ncrono, las actualizaciones a una replica son propagadas hacia las demlis en
algun momento posterior, no dentro de la misma transacci6n. Pot 10tanto, la replicaci6n asfn-
crona presenta un retardo de tiempo, 0 latencia, durante el cual es posible que las replicas
no sean identicas (y por 10 tanto, el termino "replica" ya no es muy adecuado, debido a que
ya no estamos hablando de copias exactas). La mayorfa de los productos implementan la
replicaci6n asfncrona leyendo la bitacora de transacciones 0 una cola estable de actualiza-
ciones que necesiten ser propagadas.
La ventaja de ia replicaci6n asfncrona es que la sobrecarga de replicaci6n esta desaco-
plada con relaci6n a la transacci6n de actualizaci6n, la cual puede ser de "misi6n crftica" y
altamente sensible al rendimiento. La desventaja es que los datos pueden llegar a ser incon-
sistentes (en cuanto a como son vistos por el usuario); es decir, la redundancia puede ser
mostrada a traves del nivel16gico, 10 que significa en terminos estrictos que el termino "re-
dundancia controlada" ya no es muy adecuado.*
Hacemos notar que al menos en el mundo commercial,el termino "replicaci6n" ha llegado a

significar principalmente (de hecho, casi exclusivamente) replicaci6n as{ncrona en particular
(como dijimos en el capftulo 20).
La diferencia basica entre replicaci6n y adrninistracion de copias es la siguiente. Con la re-
plicaci6n, las actualizaciones para una replica son (tarde 0 temprano) propagadas "automliticamen-
te" hacia todas las demas. Por el contrario, con la administraci6n de copias no hay tal propagaci6n
automlitica; en su lugar, las copias de datos son creadaSy mantenidas por medio de algUn proceso
por lotes --0 en segundo plano-- que esta desacoplado en el tiempo con respecto a las transacciones
de actualizaci6n. La administraci6n de copias es generalmente mas eficiente que la replicaci6n, ya
*Observe tambien que las replicas puedenlIegar a ser inconsistentesen fonnas que son diffciles de evitar
y de componer. En particular, es posible presentarconflictos sobre el orden en que las transaccionesson
aplicadas.Por ejemplo, dejemosque la transacci6nTi inserte una fila en la replica RX, que la transacci6n
T2 luego borre esa fila y que RY seauna replica de RX. Si las actualizacionesson propagadashacia RY,
pero lIegan a RY en orden inverso (por ejemplo, a causade retardosen las rutas), T2 encuentraque no hay
fila que borrar y luego TI inserta la fila. El efecto real es que RY contiene la fila yen cambio, RX no la
tiene. La administraci6n de conflictos y el cumplimiento de la consistenciaa traves de replicas son proble-
mas diffciles que est.1nfuera del alcancede este libro.
que es posible copiar grandescantidadesde datosde una sola vez. La desventajaes que la mayor
partedel tiempo las copiasno son identicasa los datosbasicos;ademas,los usuariosdeben(por 10
general)estarconscientesde en que momentoban sido sincronizadas.Por 10general,la administra-
cion de copiassesimplifica al requerirque las actualizacionesseanaplicadasde acuerdocon algUn
tipo de esquemade "copia primaria" (vea el capitulo 20).
El otro tipo de redundancia que aqui consideramosson las COlumDascalculadas y las
tablas de resumeD. Estas construccionesson particularmente importantes en el contexto del
apoyo a la toma de decisiones,ya que se usan para guardar valores de datos precalculados(es
decir, valores que son calculadosa partir de otros datos guardadosen algun otro lugar de la base
de datos).Paraser mas especificos,dicbasconstruccionesevitan la necesidadde volver a calcu-
lar dicbos valores cada vez que seanrequeridosen alguna consulta. Una columna calculada es
aquella cuyo valor en cualquier fila dada se deriva (de cierta forma) a partir de otros valores de
la misma fila.* Una tabla de resumenes una tabla que guardatotales(surnas,promedios,cuentas,
etcetera)de valores que estanen otras tablas. Con frecuencia, dicbos totales son precalculados
para varios agruparnientosdiferentesde los mismos datosde detalle (vea la secci6n21.6). Nota:
Si las colurnnas calculadasy las tablas de resumen van a ser en verdad ejemplaresde redun-
dancia controlada, entoncesdebenestar completamenteocultas ante los usuarios; sin embargo,
en los productos actualesusualmenteno es asi.
Las tablasde resumeny las colurnnascalculadassonimplementadascasi siemprepor medio
de procedimientosdisparadosque son administradospor el sistema,aunquetambien puedenser
implementadaspor medio de c6digo de procedimientosescrito por el usuario.El primer enfoque
permite mantenerla consistenciaentre los datosbasicosy los derivados (siemprey cuando am-
bos seanactualizadosen la misma transacci6n,10cual puede 0 no ser el caso; incluso si 10es,
observeque un alto nivel de aislarnientopuedesercrucial para obteneresaconsistencia).Es mas
probable que el segundoenfoque expongainconsistenciaante el usuario.
Errores cornunes de disefio
En esta subsecci6n cornentarernos breyernente algunas prlicticas de disefio que son communesen el
ambiente de apoyo para la torna de decisiones y que seguirnos considerando poco conyenientes:
.Filas duplicadas. Los disefiadores de apoyo para la torna de decisiones dicen con frecuencia
que sus datos simplernente no tienen un identificador Unico y que por 10 tanto, tienen que per-
mitir duplicados. Las referencias [5.3] y [5.6] explican en detalle por que los duplicados son
un error; aqui simplernente cornentamos que el "requerimiento" surge debido a que el esquerna
ffsico no se deriya a partir de un esquema 16gico (el cual probablernente nunca se cre6). Obser-
yamos tambien que en tales disefios, las filas tienen a rnenudo significados no uniformes (en
especial si esta presente cualquier nulo); es decir, no todas son ejernplares del misrno predica-
do (yea el capftulo 3, secci6n 3.4, y tambien el capftulo 18). Nota: En ocasiones, los duplica-
dos se permiten incluso deliberadamente, en especial cuando el disefiador tiene una formaci6n
orientada a objetos (yea el ultimo parrafo de la secci6n 24.2 en el capftulo 24).
*En fonna alterna, el valor calculado podria ser derivado a partir de los valores de varias filas de la rnisma
tabla o de otras tablas. Sin embargo, dicho enfoque implica que la actualizaci6n de una fila podria requerir
que tambien se actualizaranmuchasotras filas; en particular, esto puedeteller un efecto muy negativo sobre
las operacionesde carga y actualizaci6n.
Capitulo 21 Apoyo para la tomade decisiones 705
.Desnormalizacion y prdcticas relacionadas. En un esfuerzoerroneopara eliminar juntas y

reducir la E/S, a menudo los disefiadoresprejuntan tablas, introducen columnas derivadas
de diversos tipos, etcetera.Dichas prlicticas puedenser aceptablesen el nivel ffsico, pero
no si son detectablesen el nivellogicoo
.Esquemas de estrella. Con mucha frecuencia,los "esquemasde estrella" (tarnbien conoci-
dos como esquemasdimensionales)sonel resultadode intentar "tomar atajos" en una tecnica
adecuadade disefio. Es poco 10que se puedeganarcon esosatajosoCon frecuencia afectan
el rendirniento y la tlexibilidad conforme crece la basede datos,y la resoluci6n de tales di-
ficultades por medio del redisefio ffsico fuerza tambien a hacer cambiosen las aplicaciones
(ya que en realidadlos esquemasde estrella son esquemasftsicos,aunqueestenexpuestos
a las aplicaciones)oEl problema general yace en la naturalezaad hoc del disefio. Nota:
Trataremoslos esquemasde estrella con mayor detalle en la seccion21.5.
.Nulos. Los disefiadorestratan frecuentementede ahorrar espacioperrnitiendo nulos en las
columnas (estetruco puede funcionarsi la columna en cuestion es de alglin tipo de dato de
longitud variable y el producto en cuesti6n representaa los nulos en dichas columnas por
medio de cadenasvaclasen el nivel ffsico). Sin embargo,por 10generaldichos intentos son
err6neos.No s610es posible (y necesario)hacer un disefio que -en primer lugar- evite
los nulos [18.20], sino que los esquemasresu1tantesproporcionan a menudo una mejor efi-
ciencia de almacenarnientoy un mejor rendirniento de E/So
.Diseflo de tablas de resumen.La cuesti6ndel disefio 16gicode tablasde resumenes con fre-
cuencia ignorada, 10 que da lugar a una redundancia no controlada y a dificultades para
mantenerla consistenciaoComo consecuencia,los usuariospuedenllegar a confundirsecon
respectoal significado de los datosde resumeny a la manerade formular consultasque los
involucren. Para evitar tales problemas,todas las tablas de resumenen el rnismo nivel de
agregacion(0 sea,de totales;vea la seccion21.6) debenserdisefiadascomo si formaran una
basede datospor derechopropio. Luego podemosevitar deterrninadosprob1emasde actuali-
zacion ciclica (a) prohibiendo que las actualizacionesabarquenvarios nive1esde agregaci6n
y (b) sincronizandolas tablas de resumenal hacer siempre las agregaciones(totalizar) del
nivel de detalle hacia arriba.
."Varias rutas de navegacion". A menudo, los disefiadoresde apoyo para la toma de deci-
sionesy los usuariosdicen (incorrectamente)que hay una "multiplicidad de rotas de nave-
gacion" hacia alglin dato deseado,cuando en realidad quieren decir que los rnismos datos
puedenser alcanzadospor medio de varias expresionesrelacionalesdiferentes.A veceslas
.expresiones en cuestion en realidad son equivalentes,como en el casode -por ejemplo--
A JOIN (B JOIN C) y (A JOIN B) JOIN C (vea el capltulo 17); en ocasionessonequivalen-
tes solo debido a que hay algunarestricci6nde integridad que haceque en efecto seaas! (de
nuevo vea el capltulo 17); en ocasiones,ino son equivalentesen absoluto! Como ejemplo
de estoUltimo, supongaque las tablasA, B y C tienen una columna comlin K; entonces,"se..
guir la rota de K desdeA hacia B y por 10tanto, hacia C" en realidad no es (generalmente)
10rnismo que "seguir la rota de K directarnentedesdeA hacia C"o
Es c1aroque los usuariospuedenllegar a confundirse en tales casosy no estarseguros
de que expresi6n usar 0 de si habrli alguna diferencia 0 no en el resultado. Por supuesto,
parte de este problema s610puede ser resuelta mediante una ensefianzaadecuadapara el
usuario. Otra parte puedeserresueltasi el optirnizador hace su trabajo adecuadamente.Sin
embargo, otra parte se debe a que los disefiadoresperrniten redundanciasen el esquema
logico 0 perrniten que los usuariosaccedandirectamenteal esquemaffsico, y esaparte del
prob1emasolo puedeser resueltamedianteuna prlictica de disefio adecuada.
En resumen,creemosque muchasde las dificultadesde diseiio que supuestamente sepresen-

tan por los requerimientospara el apoyo a la toma de decisiones,puedenser resueltassiguiendo
un enfoquedisciplinado. Ademas,muchasde estasdificultades son causadaspor no seguir este
enfoque(aunquees convenienteaiiadir que a vecesse agravanpor problemascon SQL).
21.4 PREPARACI6N DE LOS DA TOS

Muchas de lascuestionesque rodeana los sistemasde apoyopara la toma de decisiones,serefie-
ren en primer lugar a las tareasde obtenery prepararlos datos.Los datosdebenser extra{dosde
diversasfuentes,limpiados, transformadosy consolidados,cargadosenla basede datosde apoyo
para la toma de decisionesy luego actualizadosperi6dicamente.Cadauna de estasoperaciones
involucra sus propias consideracionesespeciales.*Las exarninamosuna por una y luego con-
cluimos la secci6ncon una breve explicaci6n de los almacenesde datos operacionales.
Extraccion
La extracci6n es el proceso de capturar datos de las bases de datos operacionales y otras fuentes.
Hay muchas herramientas disponibles para ayudar en esta tarea, incluyendo herramientas pro-
porcionadas por el sistema, programas de extracci6n personalizados y productos de extracci6n
comerciales (de prop6sito general). El proceso de extracci6n tiende a ser intensivo en E/S y por
10 tanto, puede interferir con las operaciones de misi6n crucial; por esta raz6n, este proceso a me-
nudo es realizado en paralelo (es decir, como un conjunto de subprocesos paralelos) yen un nivel
fisico. Sin embargo, dichas "extracciones fisicas" pueden ocasionarproblemas para el procesa-
miento subsecuente, ya que pueden perder infonnaci6n -en especial infonnaci6n de vinculos-
que esta representada de alguna manera fisica (por ejemplo, por apuntadores 0 por contigiiidad
fisica). Por esta raz6n, los programas de extracci6n proporcionan en ocasiones un medio para
preservar dicha infonnaci6n introduciendo numeros de registro secuenciales y reemplazando
apuntadores por 10 que en realidad son valores de clave extema.
Limpieza
Pocas fuentes de datos controlan adecuadamente la calidad de los datos. Por consecuencia, los
datos requieren frecuentemente de una limpieza (por 10general, por lote) antes de que puedan ser
introducidos en la base de datos de apoyo para la toma de decisiones. Las operaciones de lim-
pieza tfpicas incluyen el Ilenado de valores faltantes, la correcci6n de errores tipograficos yotros
de captura de datos, el establecimiento de abreviaturas y formatos estandares, el reemplazo de
sin6nimos por identificadores estandares, etcetera. Los datos que son err6neos y que nopueden
ser limpiados, seran reemplazados. Nota: En ocasiones, la informaci6n obtenida durante el pro-
ceso de limpieza puede ser usada para identificar la causa de los errores en el origen y por 10
tanto, mejorar la calidad de los datos a traves del tiempo.
*De paSo,comentarnosque estasoperacionesa menudopuedenbeneficiarsede las posibilidades en el nivel

de conjunto de 10Ssistemasrelacionales,aunqueen la practica rara vez 10hacen.
Capftulo 21 / Apoyo para la toma de decisiones 707
Transformaci6n y consolidaci6n
Aun despues haber sido limpiados, es probable que los datos todavfa noesten en la forma en que se
requieren para el sistema de apoyo para la torna de decisiones y por 10 tanto, deberan ser transfor-
mados adecuadarnente. Por 10 general, la forma requerida sera un conjunto de archivos, uno por
cada tabla identificada en el esquema ffsico; como resultado, la transformacion de los datos puede
involucrar la division o la combinaci6n de registros fuente de acuerdo a 10 que hemos explicado en
el capftulo 1 (secci6n 1.5). Nota: A veces, los errores de datos que no fueron corregidos durante la
limpieza son encontrados durante el proceso de transformaci6n. Como dijimos antes, por 10general
cualquier dato incorrecto es rechazado. (Tambien, igual que antes, la informacion obtenida como
parte de este proceso puede ser usada, en ocasiones, para mejorar la calidad de la fuente de datos.)
La transformacion es particularmente importante cuando necesitan mezclarse varias fuentes
de datos, un proceso al que se llama consolidaci6n. En estos casos, cualquier vfncu10 implfcito
entre datos de distintas fuentes necesita volverse explfcito (introduciendo valores de datos explf-
citos). Ademas, las fechas y horas asociadas con el significado que tienen los datos en los negocios,
necesitan ser mantenidas y correlacionadas entre fuentes; un proceso llamado "sincronizacion
en el tiempo" [jcita textual!].
Por razones de rendirniento, las operaciones de transformacion se realizan frecuentemente
en paralelo. Pueden ser intensivas tanto en FlS como en CPU .
Nota: La sincronizaci6n en el tiempo puede ser un problema diffcil. Por ejemplo, suponga
que queremos encontrar el promedio de las ganancias por cliente y por vendedor en cada trimestre.
Suponga que los datos del cliente contra las ganancias son mantenidos por trimestre fiscal en una
base de datos de contabilidad, yen cambio, los datos del vendedor contra el cliente son mantenidos
por trimestre de calendario en una base de datos de ventas. De manera clara, necesitamos fusionar
los datos de las dos bases de datos. La consolidaci6n de clientes es facil, involucra simplemente
la coincidencia de IDs de clientes. Sin embargo, la cuestion de la sincronizaci6n de tiempo es
mucho mas diffcil. Podemos encontrar las ganancias de cliente por trimestre,fiscal (a partir de
la base de datos de contabilidad), pero no podemos decir que vendedores fueron responsables
de cuales clientes en ese momento y, a fin de cuentas, no podemos encontrarlas ganancias de
clientes por trimestre de calendario.
Carga
Los fabricantes de DBMS ban puesto considerable importancia en la eficiencia de las operaciones
de carga. Para los prop6sitos actuales, consideramos que las "operaciones de carga" incluyen (a)
el movimiento de los datos transformados y consolidados bacia la base de datos de apoyo para
la toma de decisiones, (b ) la verificacion de su consistencia (es decir, verificacion de integridad) y
(c ) la construccion de cualquier fndice necesario. Comentaremos brevemente cada paso:
a. Movimiento de datos. Por 10general, los sistemas modemos proporcionan berramientas de car-
ga en paralelo. En ocasiones formatearan previamente los datos para darles el formato fisico
intemo requerido por el DBMS de destino antes de la carga real. (Una tecnica altema que pro-
porciona gran parte de la eficiencia de las cargas preformateadas es cargar los datos en tablas
de trabajo que se asemejan al esquema de destino. La verificacion de la integridad necesaria
puede ser realizada en esas tablas de trabajo [ vea el parrafo b] y luego usar los INSERTs en el
nivel de conjunto para mover los datos desde las tablas de trabajo bacia las tablas de destino.)
b. Verificaci6n de integridad. La mayor parte de la verificacion de integridad de los datos a
ser cargados puede ser realizada antes de la carga real, sin bacer referencia a los datos que
708 Parte v Temasadicionales
ya est8n en la base de datos. Sin embargo, ciertas restricciones no pueden verificarse sin exa-
minar la base de datos existente; por ejemplo, una restricci6n de unicidad tendra que ser veri-
ficada, por 10 general, durante la carga real (0 por lotes despues de que se haya terminarlo la
carga).
c. Construcci6n de indices. La presencia de indices puede hacer significativamente lento el
proceso de carga, debido a que la mayorfa de los productos actualiza los indices conforrne
carla fila es insertada en la tabla subyacente. Por esta raz6n, en ocasiones es buena idea eli -
minar los indices antes de la carga y luego volverlos a crear .Sin embargo, este enfoque no
vale la pena cuando la proporci6n de los nuevos datos (con respecto a los existentes) es pe-
quefia, ya que el costo de crear un indice no se compensa con el tamafio de la tabla a indexar.
Ademas, la creaci6n de un indice grande puede estar sujeta a errores de asignaci6n irrecupera-
bles, y entre mas grande sea el indice, es mas probable que ocurran tales errores. Nota: La
mayorfa de los productos DMBS soportan la creaci6n de indices en paralelo en un esfuerzo
para agilizar los procesos de carga y de construcci6n de indices.
Actualizacion
La mayoria de las bases de datos de apoyo para la toma de decisiones (aunque no todas) re-
quieren una actualizacion peri6dica de los datos para mantenerlos razonablemente vigentes. La
actualizaci6n involucra por 10 general una carga parcial, aunque algunas aplicaciones de apoyo
para la toma de decisiones requieren la elirninaci6n de 10 que hay en la base de datos y una recar-
ga completa. La actualizaci6n involucra todos los problemas que estan asociados con la carga,
pero tambien es probable que deba realizarse rnientras los usuarios estan accediendo a la base
de datos. Yea el capitulo 9, secci6n 9.5, y tambien las referencias [9.2] y [9.6].
Almacenes de datos operacionales

Un ODS (almacen de datos operacionales) es una "colecci6n de datos actuales--0 casi actua-
les- integradosy vollitiles (es decir actualizables)" que estanorientadosa un tema [21.19]. En
ottas palabras,es un tipo especialde basede datos.El tennino orientado a un tema significa que
los datos en cuesti6n tienen que ver con alguna areatematica especffica (por ejemplo, clientes,
productos,etcetera).Un almacende datosoperacionalespuedeser usado(a) como un areattan-
sitoria para la reorganizaci6nffsica de los datos operacionalesexttafdos, (b) para proporcionar
informes operacionalesy (c) para apoyar la toma de decisionesoperacionales.Tambien puede
servir (d) como un punto de consolidaci6n si es que los datos operacionalesprocedende varias
fuentes.Por 10tanto,los ODSs sirven para muchosprop6sitos.Nota: Debido a que no acumulan
datoshist6ricos (por 10general),no crecendemasiado;por otto lado, estangeneralmentesujetos
a una actualizaci6n muy frecuente, 0 incluso continua, a partir de fuentes de datos operaciona-
Ies:* Los problemasde sincronizaci6n en el tiempo (vea la subsecci6nanterior "ttansformaci6n
y consolidaci6n") pueden ser atacadossatisfactoriamentedentto de un ODS si la actualizaci6n
es suficientementefrecuente.
* A veces,para esteprop6sito se usa la replicaci6n asincronadesdelas fuentes de datos operacionaleshacia

el ODS. De esta forma, los datos con frecuencia puedenactualizarseen cuesti6n de minutos.
Capitula 21 / Apoya para la tama de decisianes 709
21.5 DA TAW AREHOUSES y DATA MARTS
Por 10general,10Ssistemasoperacionalestienen requerimientosde rendimiento estrictos,cargas

de trabajo predecibles,pequefiasunidadesde trabajo y una alta utilizaci6n. Por el contrario, 10S
sistemasde apoyo parala toma de decisionestienen por 10generalrequerimientosde rendimien-
to variantes,cargasde trabajo impredecibles,grandesunidadesde trabajo y utilizaci6n erratica.
Estas diferencias puedenhacer que seamuy dificil combinar el procesamientooperacionaly el
de apoyo para la toma de decisionesdentro de un solo sistema, en especial Con relaci6n a la
planeaci6nde la capacidad,la administraci6nderecursosy el perfeccionamientodel rendimiento
del sistema.Por estasrazones,en generallos administradoresde sistemasoperacionalesestan
poCodispuestosa perrnitir actividadesde apoyo para la toma de decisionesen sussistemas;esta
es la causadel familiar enfoquedel sistemadoble.
Nota: Comentamosadicionalmenteque esto no siempre fue asi; 10Sprimeros sistemasde
apoyo para la toma de decisionesfueron ejecutadosen 10Ssistemasoperacionalespero Conuna
baja prioridad, 0 durantela llamada "ventanapor 10tes".Con recursosde computaci6n suficien-
tes,existenvariasventajasde estearreglo,y tal vez la masobvia es que evita todaslas operaciones
(posiblemente costosas) de copiado de datos, reformateo y transferencia (etcetera) requeri-
daspor el enfoquedel sistemadoble.De hecho,el valor de la integraci6nde las actividadesopera-
cionalesy de apoyo para la torna de decisionesestallegando a ser cadavez mas reCOnoCido. Sin
embargo,mas detalles de tal integraci6n estanfuera del alcancede este capitulo.
A pesardel parrafo anterior (al menosal momentode la publicaci6n de estelibro ), permane-
ce el hecho de que 10SdatoSde apoyo para la toma de decisionesnecesitanpor 10 general ser
recolectadosa partir de una variedad de sistemasoperacionales(a menudo dispares)y ser man-
tenidos en un almacen de datoSpropio en unaplataforma independiente.Ese almacen de datoS
separadoses un data warehouse.
Data warehouses
AI igual que los almacenes de datos operacionales (y los data marts, vea la siguiente subsecci6n),
un data warehouse es un tipo especial de base de datos. Al parecer, el termino se origin6 a fmales
de los ochenta [21.13], [21.17], aunque el concepto es de alguna manera mas antiguo. Lareferen-
cia [21.18] define un data warehouse como "un almacen de datos orientado a un tema, integrado,
no volcitil y variante en el tiempo, que soporta decisiones de administraci6n" (donde el termino no
voltitil significa que una vez que los datos han sido insertados, no pueden ser cambiados, aunque
si pueden ser borrados). Los data warehouses surgieron por dos razones: primero, la necesidad de
proporcionar una fuente unica de datos limpia y consistente para prop6sitos de apoyo para la toma
de decisiones; segundo, la necesidad de hacerlo sin afectar a los sistemas operacionales.
Por definici6n, las cargas de trabajo del data warehouse estan destinadas para el apoyo a la toma
de decisiones y por lo tanto, tienen consultas intensivas (con actividades ocasionales de inserci6n
por lotes); asimismo, los propios data warehouses tienden a ser bastante grandes (a menudo mayo-
res que 500GB y con una tasa de crecimiento de hasta el 50 por ciento anual). Por consecuencia,
es dificil-aunque no imposible- perfeccionar el rendimiento. Tambien puede ser un problema la
escalabilidad. Contribuyen a ese problema (a) los errores de disefio de la base de datos (que trata-
mos en la subsecci6n final de la secci6n 21.3), (b) el uso ineficiente de los operadores relacionales
(que mencionamos brevemente en la secci6n 21.2), (c) la debilidad en la implementaci6n del mo-
delo relacional del DBMS, (d) la falta de escalabilidad del propio DBMS y (e) los errores de disefio
arquitect6nico que limitan la capacidad e imposibilitan la escalabilidad de la platafonna. Los pun-

tos (d) y (e) estan fuera del alcance de este libro; por el contrario, ya hemos explicado los puntos (a)
y (b) en este capitulo, y el punto (c) se trata ampliamente en otras partes dellibro.
Data marts
Por 10 general, los data warehouses estan hechos para proporcionar una fuente de datos unica
para todas las actividades de apoyo para la toma de decisiones. Sin embargo, cuando los data
warehouses se hicieron populares (a principio de los afios noventa) pronto fue evidente que los
usuarios a menudo realizaban amplias operaciones de informes y analisis de datos sobre un sub-
conjunto relativamente pequefio de todo el data warehouse. Asimismo, era muy probable que los
usuarios repitieran las mismas operaciones sobre el mismo subconjunto de datos cada vez que
era actualizado. Ademlls, algunas de esas actividades -por ejemplo, analisis de pron6sticos,
simulaci6n, modelado de datos de negocios del tipo "que pasarfa si..."- involucraban la crea-
ci6n de nuevos esquemas y datos con actualizaciones posteriores a esos nuevos datos.
De manera obvia, la ejecuci6n repetida de tales operaciones sobre el mismo subconjunto de
todo el almacen no era muy eficiente; por 10 tanto, pareci6 obviamente una buena idea construir
algun tipo de "almacen" limitado de prop6sito general que estuviera hecho a la medida de ese
prop6sito. Ademas, en algunos casos seria posible extraer y preparar los datos requeridos di-
rectamente a partir de las fuentes locales, 10 que proporcionaba un acceso mas rllpido a los datos
que si tuvieran que ser sincronizados con los demlls datos cargados en todo el data warehouse.
Dichas consideraciones condujeron al concepto de data marts.
De hecho, hay alguna controversia sobre la definici6n precisa del termino data mart. Para
nuestros prop6sitos podemos definirlo como "un almacen de datos especializado, orientado a un
tema, integrado, vollltil y variante en el tiempo para apoyar un subconjunto especffico de deci-
siones de administraci6n". Como puede ver, la principal diferencia entre un data mart y un data
warehouse es que el data mart es especializado y voltitil. Por especializado queremos decir que
contiene datos para dar apoyo ( solamente ) a un area especffica de analisis de negocios; por voltitil
queremos decir que los usuarios pueden actualizar los datos e incluso, posiblemente, crear nuevos
datos (es decir, nuevas tablas) para algun prop6sito.
Hay tres enfoques principales para la creaci6n de un data mart:
.Los datos pueden ser simplemente extrafdos del data warehouse; de hecho, sigue un enfo-
que de "divide y venceras" sobre la carga de trabajo general de apoyo para la toma de decisio-
nes, a fin de lograr un mejor rendimiento y escalabilidad. Por 10 general, los datos extrafdos
son cargados en una base de datos que tiene un esquema ffsico que se parece mucho al sub-
conjunto aplicable del data warehouse; sin embargo, puede ser simplificado de alguna mane-
ra gracias a la naturaleza especializada del data mart.
.A pesar del hecho de que el data warehouse pretende proporcionar un "punto de control uni-
co", un data mart puede ser creado todavfa en forma independiente (es decir, no por medio de
la extracci6n a partir del data warehouse). Dicho enfoque puede ser adecuado si el data ware-
house es inaccesible por alguna raz6n, digamos razones financieras, operacionales 0 inc1uso
polfticas (0 puede ser que ni siquieraexista todavfa el data warehouse; vea el siguiente punto ).
.Algunas instalaciones han seguido un enfoque de "primero el data mart", donde los data
marts son creados conforme van siendo necesarios y el data warehouse general es creado,
finalmente, como una consolidaci6n de los diversos data marts.
'apitulo 21 Apoyo para la toma de decisiones 711
Los ultimos dos enfoquessufrenposiblesproblemasde desacoplosemantico.Los datamarts

independientesson particularmente susceptiblesa tales problemas, debido a que no hay forma
obyia de yerificar los desacoplossemanticoscuandolas basesde datossondisefiadasen formain-
dependiente.Por 10general,la consolidacionde datamarts en datawarehousesfalla, a menosque
(a) seconstruyaprimero un esquemalogico unico parael datawarehousey (b) los esquemaspara
los data marts indiyiduales se deriyen despuesa partir del esquemadel data warehouse.(Por
supuesto,el esquemade esteultimo punto puedeeyolucionar -suponiendo que se siganbuenas
practicas de disefio-- para incluir el tema de cadanueyo data mart conforme seanecesario.)
Una nota sobre el diseno de data marts: Una decision irnportante que hay que tomar en el
disefio de cualquier basede datosde apoyo para la toma de decisioneses la granularidad de la
rnisma. Aquf el terrnino granularidad se refiere al niyel mas bajo de agregacionde datosque se
mantendraen la basede datos.Ahora bien, la mayoria de las aplicacionesde apoyo para la toma
de decisionesrequeriran tarde 0 temprano accesoa datos detallados y por 10tanto, la decision
serafacil para el data warehouse.Paraun data mart puedesermasdiffcil. Laextraccion de gran-
des cantidadesde datos detallados del data warehouse,y su almacenarnientoen el data mart,
puede ser muy ineficiente si ese niyel de detalle no se necesitacon mucha frecuencia. Por otro
lado, en algunasocasioneses diffcil establecerdefinitiyamente cual es el niyel mas bajo de agre-
gacion que en realidad se necesita.En dichos casos,los datos detalladospueden ser accedidos
directamentedesdeel datawarehousecuandosenecesiten,manteniendoen el datamart los datos
que de alguna maneraya fueron agregados.AI rnismo tiempo, generalmenteno se hacela agre-
gacion completa de los datos,debido a que las diyersasformas en las que puedenser agregados,
generarfancantidadesmuy grandesde datos de resumen.Trataremoseste punto con mayor de-
talle en la seccion21.6.
Un punto adicional: Debido a que los usuarios de los data marts emplean frecuentemente
deterrninadasherrarnientasanalfticas,el disefio ffsico a menudo estadeterrninado,en parte,por
las herrarnientasespecfficasa usar (yea la explicacion de "ROLAP contra MOLAP" en la sec-
cion 21.6). Estacircunstanciadesafortunadapuedeconducir a "esquemasdimensionales"(trata-
dos acontinuacion) que n~son soportadospor las buenaspracticas dedisefio relacional.
Esquemas djmensionales
Suponga que queremos recolectar un historial de las transacciones de negocios para efectos de
analisis. Como indicamos en la secci6n 21.1, los primeros sistemas de apoyo para la toma de de-
cisiones mantenian generalmente ese historial como un archivo simple, el cual podia ser acce-
dido mas tarde por medio de unaexploraci6n secuencial. Sin embargo, conforme el volumen de
los datos se incrementa, 1lega a ser cada vez mas necesario apoyar la busqueda con el acceso di-
recto a ese archivo desde varias perspectivas diferentes. Por ejemplo, tener la posibilidad de en-
contrar todas las transacciones de negocios que involucran a un producto en particular o todas
las transacciones de negocios que suceden dentro de un periodo en particular o todas las transac-
ciones de negocios que se refieren a un cliente en particular.
Un metodo de organizaci6n que soporta este tipo de acceso fue 1lamado base de datos "mul-
ticatalogo".* Para continuar con nuestro ejemplo, dicha base de datos consistirfa en un gran
archivo central de datos que contUviera los datos de las transacciones de negocios,junto con tres
archivos de "catalogo" individuales para productos, periodos y clientes, respectivamente. Dichos
*No tiene nadaque ver con los catalogosen el sentido que tiene el tenninoen lasbasesde datos mode
712 Parte v / Temas adiciona(es
arcJiivosde cataIogoseparecena los indices dado que contienenapuntadoreshacia los registros

que 'estanen el archivo de datos; sin embargo, (a) las entradaspueden ser colocadas en los
archivos explfcitamentepor el usuario ("mantenimiento del cataIogo") y (b) los archivos pueden
contenerinformacion suplementaria(por ejemplo, la direccion del cliente) que luego puede ser
eliminada del archivo de datos. Observe que por 10 generallos archivos del cataIogo son pe-
quefios en comparacioncon el archivo de datos.
Esta organizacion es mas eficiente en terminos de espacioy FJSque el disefio original (el
cual involucra un solo archivo de datos). Observe en particular, que la informacion sobre pro-
ductos,periodos y clientes del archivo central de datosahora sereducea solo identificadores de
producto, periodo y cliente.
Cuando se emula este enfoque en una base de datos relacional, el archivo de datos y los
archivosde cataIogoseconviertenen tablas(imagenesde los archivoscorrespondientes); los apun-
tadoresque estanen los archivos de cataIogose convierten en claves primarias en las tablasque
son imagen de estosarchivos,y los identificadoresque estanen el archivo de datos seconvierten
en claves extemas en la tabla que es imagen del archivo de datos. Por 10 general, estasclaves
primarias y extemas estan indexadas.Bajo tal arreglo, a la imagen del archivo de datos se le
llama tabla de hechosy a las imagenesde los archivos de cataIogoseles llama tablas de dimen-
si6n. Al disefio general se le menciona como esquema dimensional, 0 de estrella, debido a la
forma en que aparececuando es trazado como diagrama de entidad-vinculo (donde la tabla de
hechosestarodeadapor y conectadaa las tablas de dimension). Nota: En la seccion21.6 expli-
camos la razon de la terminologia de "dimension".
A manerade ejemplo, modifiquemos nuevamentela basede datosde proveedoresy partes;
esta vez para mostrar el periodo de tiempo particular en que sucediocada envio. Identificamos
a los periodos mediante un identificador de periodo de tiempo (PT#) e introducimos otra tabla
PT para relacionar esosidentificadores con los periodos de tiempo correspondientes.Entonces
la tabla de envios VP modificada y la nuevatabla de periodosPT puedenversecomo muestrala
figura 21.3.* En la terrninologiadel esquemadeestrella,la tabla VP esla tabla de hechosy la tabla
PT es una tabla de dimension (y tambien 10son la tabla de proyeedoresV y la tabla de partesP;
vea la figura 21.4). Nota: Le recordamosnuevamenteque en el capitulo 22 trataremosen detalle
la cuestion general del manejo de datos para periodos de tiempo.
Por 10general,consultaruna basede datos con esquemade esl:rellainvolucra el uso de las
tablasde dimensionparaencontrartodaslas combinacionesde clave extemaque sonde interes,y
luego el uso de esascombinacionesparaaccedera la tabla de hechos.Suponiendoque los accesos
a las tablasde dimensiony el subsecuenteaccesoa la tabla de hechosestanintegradosen una sola
consulta,la mejor forma para implementaresaconsultaes,por 10general,por medio de 10que se
llama unajunta de estrella. La 'junta de estrella" es una tfstrategiaespecificade implementacion
de junta; difiere con respectoa las estrategiasusuales,en que comienzadeliberadamentecalcu-
lando un producto cartesiano(concretamenteel producto cartesianode las tablas de dimension).
Como vimos en el capitulo 17, optimizadoresde consultastratangeneralmentede evitar el caIculo
de productoscartesianos[17.54], [17.55]; sin embargo,en estecasola formacion en primer lugar
del producto de las tablasde dimension,mucho maspequefias,y luego la utilizacion del resultado
para realizar busquedasbasadasen indice sobrela tabla de hechoses casi siempremas eficiente
que cualquier otra estrategia.De esto deducimosque los optimizadoresoriginales requierenalgo
de reingenieriapara manejareficientementelas consultasde esquemade estrella.
*Las columnas DESDE y BASTA de la tabla JYf contienen datos del tipo marca de tiempo. Por razonesde
simplicidad, en la figura no mostramoslos valores realesde las marcas de tiempo, sino que en su lugar, los
representamossimb61icamente.
VP PT
Figura 21.3 Tabla de hechos de ejemplo (VP) y tabla de dimension (PI).
Figura 21.4 Esquema de estrella para proveedores y partes (con periodos).
Ahora, en estemomento tal vez sepreguntecual es la diferencia entre un esquemade estre-

lla y 10que considerariarnoscomo un disefio relacional adecuado.De hecho,un esquemade es-
trella simple, como el que acabarnosde explicar, puedelucir muy similar (y hastaidentico) a un
buen disefio relacional. Sin embargo,desafortunadarnente, hay varios problemascon el enfoque
del esquemade estrella en general:
I. En primer lugar, es ad hoc (esta basadoen intuici6n en lugar de en principios). Esta falta
de disciplina hace que sea dificil carnbiar el esquemade manera adecuadacuando (por
ejemplo) se afiadennuevos tipos de datos a la basede datos o cuando carnbian las depen-
dencias.De hecho,los esquemasde estrella se construyenfrecuentementemediantela sim-
ple edici6n de un disefio anterior, y esedisefio anterior, a su vez, seconstruyegeneralmente
medianteprueba y error.
714 Partl Temas adicionalj
2. Los esquemasde estrella en realidad son ffsicos y no 16gicos,aunquesehabla de ellos como

si fueran 16gicos.El problema es que en realidad en el enfoque del esquemade estrella no
hay concepto de disefio 16gicopara distinguirlo con respectoal disefio fisico.
3. El enfoque del esquemade estrella no siempreda como resultadoun disefio fisico legitimo
(es decir, uno que conservetoda la informaci6n en un disefio 16gicorelacionalmentecorrec-
to). Esta limitaci6n se hacemas aparenteconforme el esquemaes mas complejo.
4. Debido a que hay muy poca disciplina, los disefiadoresincluyen a menudo varios tipos de
hechosdiferentesen la tabla de hechos.Como consecuencia,las filas y columnasde la tabla
de hechosno tienen (por 10general)una interpretaci6n uniforme. Lo que es mas,porlo ge-
neral ciertas columnas s610se aplican a determinadostipos de hechos,10que implica que
las columnas en cuesti6n debenpermitir nulos. y conforme son incluidos mas y mas tipos
de hechos,la tabla se hace cada vez mas dificil de mantenery comprender,y el accesose
hacecadavez menoseficiente. Por ejemplo, podriamos decidir modificar la tabla de envios
para llevar la cuenta de las compras de partes y tambien de los envios de partes.Entonces
necesitariamosalglin tipo de columna "indicadora" para que nos mostrara cuales filas CO-
rrespondena las comprasy cualesa los envios. Por el contrario, un disefio adecuadocrearia
una tabla de hechosdistinta para cadatipo de hecho distinto.
5. De nuevo,debido a la falta de disciplina, las tablasde dimensi6ntambienpuedenllegar a ser
no uniformes. Por 10generalesteerror sucedecuandola tabla de hechoses usadapara man-
tener datosque serefieren a diferentesniveles de agregaci6n.Por ejemplo, podriamos (err6-
neamente)afiadir filas a la tabla de enviosparaque mostraranlas cantidadestotalesde partes
para cadadia, cadames,cadatrimestre, cadaafio e incluso, el gran total a la fecha. Observe
primero que estecambio ocasionaque las columnaspara elidentificador de periodo (PT#)
y la cantidad (CANT) de la tabla VP tengan significados no uniformes. Supongaahora que
las columnasDESDE y HAST A de la tabla de dimensi6nPT sonreemplazadaspor una com-
binaci6n de columnasANo, MES, DfA, etcetera.EntoncesesascolumnasANo, MES, DfA,
etcetera,debenahorapermitir nulos. Tambien esprobableque senecesiteuna columna indi-
cadorapara que indique el tipo de periodo aplicado.
6. Con frecuencia,las tablas de dimensi6n no estannormalizadaspor completo.* El deseode
evitar juntas conduce frecuentementea los disefiadoresa agrupar en esastablas informa-
ci6n distinta, que seriamejor mantenerseparada.En el casoextremo, las columnasa las que
simplemente se tiene accesoen conjunto, son mantenidasjuntas en la misma tabla de di-
mensi6n. Debe quedarclaro que seguir tal "disciplina" extrema, y no relacional, conducira
con seguridada una redundanciasin control y probablementeincontrolable.
Finalmente, comentamosque una variante del esquemade estrella es el esquemade copo
de nieve, el cual normaliza las tablas de dimensi6n. De nuevo, el nombre esta derivado de la
*Este es un consejode un libro sobredata warehouses:"[Resistase] a la norrnalizacion...Los esfuerzospara

norrnalizar cualquiera de las tablas en una base de datos dimensional, solamentepara ahorrar espacio de
disco, son una perdida de tiempo... Las tablas de dimension no deben ser norrnalizadas...Las tablas de di-
mension norrnalizadasdestruyenla habilidad para navegar" [21.21].
Cap(tulo 21 / Apoyo para la toma de decisiones 715
forma en que luce el esquemacuandoes trazadocomo un diagramade entidad-vfnculo. Los ter-

minos esquemade constelaci6ny esquemade ventisca (0 de tonnenta de nieve) tambien se ban
usadorecientementecon los significados obvios (l,?).
" "
21.6 PROCESAMIENTO ANALITICO EN LINEA
El tennino OLAP ("procesamiento analftico en linea") fue acufiado en un articulo escrito por
Arbor Software Corp. en 1993 [21.10], aunque (como sucede con el tennino "data warehouse")
el concepto es mucho mas antiguo. Puede ser definido como "el proceso interactivo de crear,
mantener, analizar y elaborar informes sobre datos" y es usual afiadir que los datos en cuesti6n
son percibidos y manejados como si estuvieran almacenados en un "arreglo multidimensional".
Sin embargo, decidimos explicar primero las ideas en tenninos de tablas convencionales estilo
SQL, antes de entrar en el tema de la representaci6n multidimensional como tal.
El primer punto es que el procesamiento analftico requiere invariablemente, algun tipo de
agregaci6n de datos, por 10general en muchas formas diferentes (es decir, de acuerdo con muchos
agrupamientos diferentes). De hecho, uno de los problemas fundamentales del procesamiento
analftico es que la cantidad de agrupamientos posib1es llega rapidamente a ser muy granOOy los
usuarios deben considerarlos todos o casi todos. Ahora bien, por supuesto que los lenguajes rela-
cionales soportan tal agregaci6n, pero cada consulta individual en un lenguaje de estos produce
como resultado una sola tabla (y todas las filas de esa tabla tienen la misma forma y el mismo
tipo de interpretaci6n). Por 10 tanto, para obtener n agrupamientos distintos se requieren n con-
sultas distintas y n tablas de resultados distintas. Por ejemplo, considere las siguientes consultas
sobre la base de datos usual de proveedores y partes:
I. Obtener la cantidad total de envfos.

2. Obtener lascantidades totales de envfos por proveedor.
3. Obtener las cantidadestotales de envfos por partes.
4. Obtener las cantidadestotales de envfos por proveedor y parte. Nota: Por supuesto,la can-
tidad "total" para un proveedor dado y una parte dadaes simplementela cantidadreal para
eseproveedor y parte. El ejemplo serfamas realista si usaramos,en vez de ello, la basede
datosde proveedores,partesy proyectos.Sin embargo,nos mantendremoscon proveedores
y partespor razonesde simplicidad.
Supongamosque s6lo hay dos partes,PI y P2, y que la tabla de envios luce deesta fOnni
VP P# CANT
V1 P1 300
V1 P2 200
V2 P1 300
V2 P2 400
V3 P2 200
V4 P2 200
Parte v Temas adicionales
Entonces estas son las fonnulaciones* SQL de las cuatro consultas y sus resultados
pondientes:
I. SELECT SUM(CANT) AS CANTOT 2. SELECT v#,

FROM VP SUM(CANT) AS CANTOT
GROUP BY () ; FROM VP
GROUP BY (V#) ;
SELECT P#, 4. SELECT v#, P#,

SUM(CANT) AS CANTOT SUM(CANT) AS CANTI
FROM VP FROM VP
GROUP BY (P#) ; GROUP BY (V#, P#) ;
Las desventajas de este enfoque son obvias: la formulaci6n de tantas consultas similares,
pero distintas, es tediosa para el usuario, y la ejecuci6n de todas esas consultas -pasando una
y otra vez por los mismos datoses probablemente bastante costosa en tiempo de ejecuci6n.
Por 10 tanto, parece que vale la pena tratar de encontrar una forma (a) de solicitar varios niveles
de agregaci6n en una sola consulta y por 10tanto, (b ) ofrecer a la implementaci6n la oportunidad de
calcular todas esas agregaciones de manera mas eficiente (es decir, en un solo paso). Dichas con-
sideraciones son la motivaci6n que hay tras las opciones GROUPING SETS, ROLLUP y CUBE
de la clausula GROUP BY. Nota: Dichas opciones ya son soportadas en varios productos comer-
ciales. Tambien estan incluidas en SQL3 (yea el apendice B).
La opci6n GROUPING SETS permite al usuario especificar con exactitud que agru-
pamientos especificos van a ser realizados. Por ejemplo, la siguiente instrucci6n SQL representa
una combinaci6n de las consultas 2 y 3 :
SELECT
v#, P#, SUM
(CANT)AS CANTOT
FROM VP
GROUPBY GROUPINGSETS( (V#), (P#) ) ;
Aqui la clausula GROUP BY esta pidiendo efectivamente al sistema que ejecute dos consultas,
una donde el agrupamiento sea por V# y otra en la que sea por P#. Nota: Los parentesis inte-
*Tal vez debieramosdecir "fonnulaciones seudoSQL", ya que el SQlJ92 no pennite que los operandosde
GROUP BY estenencerradosentreparentesis,ni pennite queGROUP BY no tengaoperandos(aunquela omi-
si6n completade la clausulaGROUP BYes l6gicarnenteequivalentea la especificaci6nde una sin operandos).
'av[tulo 21 Apoyo para la toma de decisiones 717
riores en realirlad no son necesariosen esteejemplo, ya que carlauno de los "conjuntos de agru-
pamiento" involucra solo una columna, pero los mostramospor razonesde claridad.
Ahora bien, la idea de agruparde estamaneravariasconsultasdiferentesen una sola instruc-
cion puedeser inobjetable por simisma (aunquetenemosque decir que prefeririamos atacareste
temamuy generalen una forma aun masgeneral,sistematicay ortogonal). Sin embargo,por des-
gracia jel SQL continua agrupandolos resultadosde estasconsultaslogicamentedistintasen una
sola tabla de resultados!* En el ejemplo, esatabla de resultadosluce asi:
I -~-
v# CANTOT
V1 nulo 500
V2 nulo 700
V3 nulo I 200
V4 200
nulo P1 600
nulo P2 1000
Ahora bien, esteresultadopuedeserViStocomo una tabla (una tabla SQL, de algunaforma),

pero diffcilmente es una relacion. Observeque las filas de proveedor (las que tienen nulos en la
posici6n P#) y las filas de partes(las que tienennu10Sen la posici6n V#) tienen interpretaciones
muy diferentesy el significado de 10Svalores de CANTOT varfa segunaparezcaen una fila de
proveedor o en una fila de parte. Entonces,l,cual es el predicado para esta "relaci6n"?
Observamostambien que 10Snulos en esteresultadoconstituyen otro tipo de "informaci6n
faltante". En realidad no significan "valor desconocido"ni "valor no aplicable", pero 10que sig-
nifican exactamentees muy confuso. Nota: SQL proporciona al menos una forma para distin-
guir esos nuevos nulos con respecto a OtrOStipoS, pero 10Sdetalles son tediosos y fuerzan al
USUariohacia un tipo de pensamientode fila por fila. Aquf omitimos esosdetalles,pero puede
obtener alguna idea de 10que estciimplfcito a partir del siguiertteejemplo (que indica c6mo po-
drfa aparecerrealmenteen la prcicticael ejemplo de GROUPING SETS que mostramosanterior-
mente):
SELECT CASE GROUPING (V#) vea la referencia a CASE en el apendice A
WHEN 1 THEN '?????
ELSE V#
AS V#,
CASE GROUPING (P#) yea la referencia a CASE en el apendice A
WHEN 1 THEN '1!!1!
ELSE P#
AS P#,
SUM(CANT) AS CANTOT
FROM VP
GROUP BY GROUPING SETS ( (V#) P#)
Regresemos especfficamente a GROUP BY. Las otras dos opciones de GROUP BY

(ROLLUP y CUBE) son abreviaturas para ciertas combinaciones de GROUPING SETS.
Primero, veamos ROLLUP. Considere la siguiente consulta:
*Esta linica tabla puede ser consideradacomo una "uni6n extema" -tambien, una forma extremadamente
rara de uni6n extema- de esosresultados.Debe quedarclaro, por 10que dijimos en el capitulo 18, que aun
en su forma menosrara, la "uni6n extema" no es una operaci6nrelacional respetable.
718 Parte v { Temas adicionales
SELECT V#, P#, SUM(CANT) AS CANTOT

FROM VP
GROUP BY ROLLUP ( V#, P# ) ;
Aqui la clausula GROUP BYes 16gicamenteequivalente a la siguiente:
GROUP BY GROUPING SETS ( (V#,P#), (V#), (
En otras palabras,la consulta es una formulacion SQLcombinada de las consultas4, 2 y El

resultado se ye de estaforma:
El tennino ROLLUP se deriva del becboque (en el ejemplo) las cantidadesban sido "enro-
lladas" para cada proveedor (es decir, enrolladas "en toda la dimension de proveedor"; vea la
subsecci6n"Basesde datosmultidimensionales"que siguea continuacion).En general,GROUP
BY ROLLUP (A, B, ..., 2) -aproximadamente, "enrollar en toda la dimension A "- significa
"agrupar por todas las combinacionessiguientes":
( A, B, z )
( A, B,
( A, B
( A )
Observeque hay muchos"enrollar en toda la dimensi6nA " distintos, en general(dependede que

otras columnas son mencionadasen la lista de ROLLUPs separadoscon comas). Observetam-
bien que GROUP BY ROLLUP (A, B)y GROUP BY ROLLUP (B, A) tienen significados dife-
rentes; es decir, GROUP BY ROLLUP (A, B) no es simetrico enA y B.
Pasemosahora a CUBE. Considerela siguienteconsulta:
SELECT v#, P#, SUM(CANT ) AS CANTOT

FROM VP
GROUP BY CUBE ( V#, P# ) ;
Aqui la clausula GRQUP BYes 16gicamenteequivalente a la siguiente:
GROUP BY GROUPING SETS (V#,P#), (V# (P#), ()

Cap(tulo 21 Apoyo para la toma de decisiones 719
!~
En otras palabras, la consulta es una fonnulaci6n SQL combin"a~dg~i~~9ri~i
nales 4, 3, 2 y 1. El resultado se ye de esta fonna:
El tennino CUBE poco util, se deriva del hecho de que en la tenninologfa OLAP (0 al
menosmultidimensional), los valores de datos pueden ser percibidos como si estuvieranalma-
cenadosen las celdas de un arreglo multidimensional 0 hipercubo. En el caso que estamos
viendo (a) los valores de datos son cantidades,(b) el "cubo" es de dos dimensiones: una di-
mensi6n de proveedoresY una dimensi6n de partes (iY el "cubo" es bastante pIano!) Y por
supuesto,(c) esasdos dimensionesson de tamafiosdesiguales(por 10que el "cubo" ni siquiera
es un cuadrado,sino un rectangulogeneral).De cualquierforma, GROUP BY CUBE (A, B, ...,2)
significa "agrupar por todos los subconjuntosposibles del conjunto {A, B, ..., Z} ".
Una clliusula GROUP BY dada puede incluir cualquier mezcla de especificaciones
GROUPING SETS, ROLLUP Y CUBE.
Tabulaciones cruzadas
Con frecuencia, los productos OLAP desplieganlos resultadosde las consultasno como tablas
estilo SQL sino como tabulaciones cruzadas (abreviado "tabcruz"). Considerenuevamentela
consulta 4 ("obtener el total de envios por proveedor y parte"). Esta es una representaci6n
tabcruz del resultadode esaconsulta.Dicho seade paso,observeque mostramoslas cantidades
de la parte PI para los proveedoresV3 y V4 (correctamente)como cero; por el contrario, SQL
diria que estascantidadesdeben ser nulos (vea el capitulo 18). De hecho, la tabla que produce
SQL en respuestaa la consulta 4 ino contiene filas para (V3, PI) ni para (V4, PI)! Como con-
secuenciade esto, la producci6n de la tabcruz a partir de la tabla no es completamentetrivial.
Podemosdecir que estatabcruzesuna forma mascompactay legible de representarel resul-

tado de la consulta 4. Ademas, se parecemas a una tabla relacional. Sin embargo, observeque
la cantidad de columnas en esa "tabla" dependede los datos reales; para ser mas especfficos,
hay una columna para cada tipo de parte (y por 10tanto, la estructurade la tabcruz y el signifi-
cado de las filas'~dependen de los datosreales). Por 10tanto, una tabcruz no es una relaci6n sino
un i1ifi;Jrme;
para ser mas especificos,un informe que tiene el formato de un arreglo simple. (Las
relacionestienen I,Inpredicado que puedededucirsea partir de los predicadosde las relaciones
de las cualesestan'derivadas;por el contrario, el "predicado" de una tabcruz-si es que en gene-
ral p9demos decir 9ue existe- no puede deducirse de los predicadosde las relaciones de las
cualese,staderivada. sino que, como ha visto, dependede los valores de los datos.)
,Confrecuen~a decimos que las tabcruz como la que acabamosde mostrar, tienen dos
dimensi~es: e!):.e~ecaso proveedoresy partes. Las dimensiones son tratadascomo si fueran
variahjeslntle"pendientes;entonces,las "celdas" de intersecci6ncontienenlos valoresde las varia-
bits dependientescorrespondientes.Parauna explicaci6n masa fondo, vea la subsecci6n"Bases
de datos multidimensionales" que sigue.
Este es otro ejemplo de tabcruz que representael resultadodel ejemplo anterior de CUBE:
200
400
200
200
000 600
La columna del extremo derecho contiene totales de filas (es decir, los totales para el
proveedor indicado en todas las partes) y la fila inferior contiene totales de columnas (es decir,
los totales para la parte indicada en todos los proveedores).La celda de la parte inferior derecha
contieneel gran total, que es el total de fila de todos los totales de columna y el total de columna
de todos los totales de fila.
Bases de datos multidimensionales

Hastaahorahemosestadodandopor hecho que nuestrosdatosOLAP estanalmacenadosen una
basede datos SQL convencional (aunquehemosmencionadola terminologfa y los conceptosde
las basesde datos "multidimensionales" unas cuantasveces). De hecho, hemos estadodescri-
biendo tacitamente 10 que en ocasionesse llama ROlAP ("OLAP relacional"). Sin embargo,
mucha gente creeque el MOlAP ("OLAP multidimensional") es una mejor forma. En esta sec-
ci6n daremosun vistazo mas cercanoal MOLAP .
El MOLAP involucra una base de datos multidimensional, que es una basede datos en la
cuallos datosestanalmacenadosconceptualmenteen las celdasde un arreglo multidimensional.
(Nota: Decimos almacenados"conceptualmente", pero de hecho, la organizaci6n fisica de
MOLAP tiende a ser muy similar a la organizaci6n 16gica.)El DBMS que 10 soporta se llama
DBMS multidimensional. Como un ejemplo simple, los datospodrfan estarrepresentadoscomo
un arreglo de tres dimensionesque correspondena productos, clientes y periodos, respectiva-
mente; cada valor individual de celda podrfa representar la cantidad total del producto in-
dicado, vendido al cliente indicado en el periodo indicado. Como ya dijimos, las tabcruz de la
subsecci6nanterior tambien puedenser consideradascomo dichos arreglos.
Ahora bien, en un cuerpode datosbien comprendido,todos los vfnculos serfanconocidosy
las "variables" involucradas(no las variablesen el sentidousualde los lenguajesde programaci6n)
podrian ser clasificadas en tenninos generalescomo dependientes o independientes. En ter-

minos del ejemplo anterior, producto, cliente y periodo serian las variables independientes,
mientras que cantidad seria la unica variable dependiente.De forma mas general,las variables
independientesson aquellascuyos valoresdetenninanen conjunto los valoresde las variablesde-
pendientes (de forma similar a como en terminos relacionales, una clave candidata es un con-
junto de columnas cuyos valores determinan los valores de otras columnas). Por 10tanto, las
variables independientesforman las dimensionesdel arregl0 con el que estan organizadoslos
datos y forman un esquemade direccionamiento para ese arreglo;* y los valores de la varia-
ble dependiente-que constituyen los datos reales- pueden entoncesser almacenadosen las
celdasde esearreglo.Nota: La diferencia entrelos valoresde las variablesindependientes(0 "di-
mensionales")y los valores de las variablesdependientes(0 .'no dimensionales")secaracterizan
en ocasionescomo ubicaci6n contra contenido.
Por desgracia,la caracterizaci6nanterior de las basesde datos multidimensionales es en
cierta forma demasiadosimplista, ya que la mayoria de los cuerposde los datos no estanbien
entendidos.Ademas, estaes la raz6n principal por la que queremosanalizar en primer lugar los
datos:para lograr una mejor comprensi6n.Con frecuenciala falta de comprensi6nes tan grande
que ni siquiera sabemosde antemanocualesvariables son independientesy cuales son depen-
dientes; a menudo las variables independientesson seleccionadascon baseen las creenciasac-
tuales(esdecir, hip6tesis)y entoncessepruebael arregloresultanteparaver que tan bien funciona
(vea la secci6n21.7). Dicho enfoque involucrara claramentemuchasiteracionesy tanteos.Por
tales razones,el sistemageneralmentepennitira intercambiar las variables dimensionalesy no
dimensionales,una operaci6nconocidacomopivoteo. Otras operacionessoportadasincluiran la
transposici6n de arreglos y el reordenamientodimensional.Tambien habraformas de afiadir di-
mensiones.
A prop6sito, a partir de la descripci6n anteriar debe quedarclaro que las celdasdel arreglo
estaranfrecuentementevacfas y por 10tanto, los arreglos seranpoco densos.Por ejemplo, su-
pongaque el productop no fue vendido al cliente c duranteel periodo t. Entoncesla celda (c,p,t)
estaravacfa (0 en el mejor caso,contendracero). Los DBMSs multidimensionales soportandi-
versastecnicaspara el almacenamientode arreglos poco densosen alguna forma mas eficiente
(comprimida).t Ademas,esasceldasvacfascorrespondena "informaci6n faltante" y por 10tanto,
los sistemasdeben proporcionar algun soportecomputacional para ellas; 10cual (desafortuna-
damente)10hacengeneralmenteen forma similar a SQL. Observeque el hechode que una celda
estevacfa puedesignificar que la informaci6n es desconocida,que no ha sido capturada,que no
es aplicable 0 muchascosasmas (vea nuevamenteel capftulo 18).
Con frecuencia, las variables independientesestan relacionadasenjerarqufas, las cuales
detenninan las formas en que es posible/agregarlos datos dependientes.Por ejemplo, hay una
jerarqufa temporal que relaciona segu?doscon minutos, con horas, con dfas, con semanas,con
meses,con afios.Como otro ejemplo,puedehaberunajerarqufaque relacionepartescon conjuntos
ensambladoscon componentes,con tableros,con productos.A menudolos propios datospueden
*Por 10 tanto, las celdas del arreglo son referidas simb6licamente, en lugar de hacerlo por medio de los
subindices numericos que estan asociadosmas convencionalmentecon los arreglos.
tObserve el contrastecon los sistemasrelacionales.En una analogia relacional adecuadapara el ejemplo,
no tendriamos una fila (c,p,t) con una "celda" vacia, sino que simplemente no tendriamos una fila (c,p,t).
Por 10tanto, no sepresentael conceptode "arreglos poco densos"o "tablas poco densas",por 10que no hay
necesidadde manejar tecnicasde compresi6n inteligentes.
722 Parte v Temas icionales
seragregadosen muchasformas diferentes(es decif, las mismasvariablesindependientespueden

pertenecera variasjerarquiasdiferentes). El sisternaproporcionaraoperadorespara"subir" y "bajar"
por dichasjerarquias; donde subir significa if de un nivel menor de agregaci6nhacia uno mas
alto y bajar significa 10 contrario. Tambien existen muchas otras operacionespara manejar
dichasjerarquias (por ejemplo, una operaci6n para reacomodarlos niveles de jerarquia).
Nota: Existe una diferencia sutil entre "subif" y "enrollar", que es la siguiente:"enrollar" es
la operaci6npara crear los agruparnientosy agregacionesdeseadas;"subif" es la operaci6npara
accedera esasagregaciones.Un ejemplo para "bajar" podria ser:dadas las cantidadestotales de
env(os,obtener las cantidadestotalespara cadaproveedor individual. Por supuesto,es necesario
tener (0 poder calcular) los datosmas detalladosparapoder respondera una solicitud de estas.
Por 10 general, los productos multidimensionales tambien proporcionan una variedad de
funcionesestadisticasy matematicaspara ayudaren la formulaci6n y pruebade las hip6tesis (por
ejemplo, los vinculos hipoteticos). Tambien seproporcionanherrarnientasde visualizaci6n y de
informes paraque ayudenen estastareas.Sin embargo,por desgraciatodaviano existeun lenguaje
de consultamultidimensional estandar,aunqueseestanrealizandoinvestigacionesparadesarro-
lIar un calculo sobreel cual puedaestarbasadoun estandar[21.27]. Asirnismo, no existe algo si-
rnilar a la teoria de la normalizaci6nquepudieraservif como basecientffica parael diseiio debases
de datos multidimensionales.
Cerramosestasecci6ncomentandoque algunosproductoscombinan los enfoquesROLAP
y MOLAP en el HO1AP ("OLAP hlorido"). Hay muchascontroversiassobre cual de estostres
enfoqueses el "mejor" y aqui poco podemosdecif para ayudar a resolver esacontroversia.* Sin
embargo,en terrninosgeneraleslos productosMOLAP proporcionan calculos masrapidos pero
soportancantidadesde datos mas pequeiiasque los productos ROLAP (con 10que llegan a ser
menoseficientesconformeseincrementala cantidadde datos)yen cambio,los productosROLAP
proporcionancaracteristicasde escalabilidad,concurrenciay adrninistraci6nque son mas madu-
ras que las de los productos MOLAP .
21.7 MINERiA DE DA TOS

La miDeria de datos puede describirse como "anlllisis de datos exploratorio". El prop6sito es bus-
car patrones interesantes en los datos, patrones que pueden usarse para especificar la estrategia
del negocio o para identificar comportamientos fuera de 10 comun (por ejemplo, un incremento
subito en la actividad de una tarjeta de credito puede indicar que la tarjeta ha sido robada). Las
herramientas de minerfa de datos aplican tecnicas estadfsticas a una gran cantidad de datos al-
macenados para buscar tales patrones. Nota: Aquf es necesario enfatizar la palabra graD. Las
bases de datos para minerfa de datos frecuentemente son extremadamente grandes, yes impor-
tante que los algoritmos sean escalables.
*Sin embargo,hay algo que debemosdecir. A menudose afirma que "las tablas son planas" (esdecir, de dos
dimensiones);en cambio, .'los rlatosrealesson multidimensionales" y por 10tanto, las relacionesson inade-
cuadascomo baseparaOLAP .Pero dar estosargumentosiesconfundir las tablasy las relaciones!Como vimos
en el capltulo 5, las tablasson s610inuigenesde relacionesy no relacionescomo tales.Y aunquees cierto que
esasimagenesson de dos dimensiones,las relacionesno 10son; en su lugar son n dimensionales,donden es
el grado. Paraser masprecisos,carlatupla en una relaci6n con n atributosrepresentaun punto en un espacio
n dimensionaly la relaci6n como un todo, representaun conjunto de dichos puntos.
VENTAS
Figura 21.5 "a tabla VENTAS.
Considerela tabla VENTAS (ique no es muy grande!) de la figura 21.5, la cual muestrain-
formaci6n con respectoa ciertas transaccionesde ventasde un negocio al menudeo.* AI nego-
cio le gustarfarealizar un antilisis de canasta de mercado sobre estos datos (donde el terrnino
"canasta de mercado" se refiere al conjuntt>de productos compradosen una sola transacci6n)
para descubrir de ese modo que, por ejemplo, es probable que un cliente que compra zapatos
tambien compre calcetinescomo parte de la misma transacci6n.Esta correlaci6n entre zapatosy
calcetineses un ejemplo de una regia de asociaci6n; puedeser expresada(en rerrninosgenera-
les) de la siguiente forma:
FORALL
tx ( ZapatosE tx =.. Calcetines E tx )
(Donde "Zapatos E tx" es la regia antecedente,"Calcetines E tx" es la regia consecuentey tx

abarcatodas las transaccionesde ventas.)
Presentan1os algo de tenninologfa. AI conjunto de todas las transaccionesde ventas en el
ejemplo sele 1lan1ala poblacion. Cualquier regIa de asociaciontiene un nivel de soporte y un ni-
vel de confianza.El soporte es el fragmento de la poblacion que satisfacela regIa. La confianza
es la fraccion de esaparte de la poblacion en la cual, si se satisfaceel antecedente,tan1biense
satisfaceel consecuente.(Observeque el antecedentey el consecuentepueden involucrar cada
uno cualquier cantidad de productos diferentes y no necesariamenteuno solo.) A manera de
ejemplo considereestaregIa:
FORALL
tx ( Calcetines E tx =~ CorbatasE tx r
Dados los datos de ejemplo de la figura 21.5, la poblaci6n es 4, el soparte es 50 par ciento y la
confianza es del 66.67 por ciento.
*Observe que (a) la clave es {TX#, PRODUCTO}; (b) la tabla satisfacelas DFs TX# -7 CLIENTE#y TX#
-7 MARCA DE TIEMPO, y por 10tanto, no estaeoFNBC; (c) una versi6n de la tabla en la cualla columna
PRODUCTO tuviera valores de relaci6n (y TX# fuera la clave) estaria en FNBC y podria ser m~sadecuada
para el tipo de exploraci6n involucrada en estecaso (pero tal vez no serfa adecuadapara otros tipos).
Podemosdescubrir reglas de asociacionmas generalesa partir de agregacionesadecuadas

de los datosdados.Por ejemplo, el agrupamientopor cliente nos permitiria probar la validez de
reglas tales como "si un cliente compra zapatoses probable que tambien compre calcetines,
aunqueno necesariamenteen la misma transaccion".
Tambien podemosdefinir otros tipos de reglas. Por ejemplo, una regIa de correlacion de
secuenciapodrfaserusadaparaidentificar patronesde compraa 10largo del tiempo ("si un cliente
compra zapatoshoy, esprobableque comprecalcetinesdentro de los cinco dias siguientes").Una
regIa de clasificacion podria serusadapara ayudara decidir si seotorga un credito ("si un cliente
tiene ingresos superioresa $75,000 anuales,es probablementeun buen sujeto de credito") y asf
sucesivamente.AI igual que las reglas de asociacion,las reglasde correlacion de secuenciay de
clasificacion tambien tienen un nivel de soportey un nivel de confianza.
La minerfa de datoses un tema inmensopor derechopropio [21.1] yes claro que aquf no es
posible entrar en mucho detalle. Por 10tanto, nos contentamoscon una breve descripcion final
sobrela maneraen que esposible aplicar las tecnicasde minerfa de datosen una version extendida
de los proveedoresy partes.Primero (en ausenciade otrasfuentesde informacion) podrfamosusar
la induccion neural paraclasificar a los proveedoresde acuerdocon su especialidad(por ejemplo,
sujetadorescontra partesde motor) y la prediccion de valor para predecir cu3.1esson los provee-
doresque tienen mayor probabilidadde proporcionardeterminadaspartes.Luego podrfamosusar
el agrupamientodemogrdficopara asociarlos cargosde envio con la ubicacion geograficapara
asignar, por 10tanto,los proveedoresa las regionesde envfos.El descubrimientode asociacionpo-
drfa serusadoentoncesparadescubrirque determinadaspartessonadquiridaspor 10generalen un
solo envfo; el descubrimientodel patron secuencialpara descubrirque los envios de sujetadores
estanseguidosgeneralmentede envios de partesde motor; y el descubrimientode la secuenciade
tiempo similar para descubrirque hay cambios cuantitativosestacionalesen los envios de deter-
minadaspartes(algunosde esoscambiossucedenen otofio y otros en primavera).
21.8 RESUMEN
HemoS examinado el USOde la tecnologfa de base de datos para efectos del apoyo a la toma de
decisiones. La idea basica es recolectar datos operacionales y reducirlos a una forma que pueda
ser utilizada para que la adrninistraci6n entienda y modifique el comportarniento de la empresa.
Primero identificamos ciertos aspectoSde 10Ssistemas de apoyo para la torna de decisiones que
los apartan de 10Ssistemas operacionales. El punto principal es que la base de datos es en su mayo-
ria (aunque no totalmente) de solo lectura. Las bases de datos de apoyo para la toma de decisiones
tienden a ser muy grandes y altamente indexadas -e involucran una gran cantidad de redun-
dancia controlada (en especial en la forma de replicacion y agregaciones precalculadas)--, las
claves tienden a involucrar un Componente temporal y las consultas tienden a ser complejas. Como
consecuencia de tales consideraciones, existe un enfasis en el diseiio para el rendimiento; estamos
de acuerdo con el enfasis, pero creemoS que no debemos permitir que interfiera Con las buenas prac-
ticas de disefio. El problema es que en la practica, 10Ssistemas de apoyo para la torna de decisiones
no distinguen adecuadamente (por 10 general) entre las consideraciones logicas y las ilSicas.
Despues explicamos 10 que esta involucrado en la preparaci6n de 10Sdatos operacionales
para el apoyo a la toma de decisiones. Vimos las tareas de extraccion, limpieza, transformacion
y consolidacion, carga y actualizacion. Tambien mencionamoS brevemente a 10Salmacenes
de datos operacionales, que pueden ser usados (entre otras cosas) Como area transitoria durante
el procesode preparaci6nde datos.Tambien puedenser usadospara proporcionar servicios de

apoyo para la toma de decisionessobre datos actuales.
Luego consideramoslos data warehouses y los data marts; un data mart puede ser con-
sideradocomo un datawarehouseespecializado.Explicamos la idea basicade los esquemasde
estreUa, en los cuales los datos estan organizadoscomo una gran tabla de hechos central y
varias tablas de dimensiou mucho maspequefias.En situacionessimples,un esquemade estrella
no es distinguible con respectoa un esquemanormalizado cllisico; sin embargo, en la prlictica
los esquemasde estrella se apartande los principios de disefio clasicosen varias formas, siempre
por razonesde rendimiento. (De nuevo,el problemaesque por naturaleza,los esquemasde estre-
lla en realidad son mas ffsicos que 16gicos.)Tambien mencionamosla estrategiade implementa-
ci6n de junta conocida como junta de estrella y una variante del esquemade estrella Uamada
esquemade copo de nieve.
Luego enfocamosnuestraatenci6nen el OLAP. Tratamoslas caracterfsticasGROUPING
SETs, ROLLUP y CUBE de SQL (todassonopcionesde la cl1iusulaGROUP BY y proporcionan
formas para solicitar varias agregacionesdistintasdentro de una sola consultaSQL). Observamos
que SQL (desafortunadamente, en nuestraopini6n) agrupalos resultadosde esasagregacionesdis-
tintas en una sola "tabla" que contienegran cantidadde nulos. Tambien sugerimosque en la prac-
tica, los productosOLAP podrian convertir dichas"tablas" en tablas cruzadas (arreglossimples)
para efectosde presentaci6n.Luego dimos un vistazo a las basesde datos multidimensionales
en las cuales los datos estan almacenados,conceptualmente, no en tablas sino en un arreglo
multidimensional0 hipercubo. Las dimensionesde dicho arreglo representanvariables indepen-
dientes y las celdas contienen valores de las variables dependientes correspondientes.Por 10
general,las variablesindependientesestanrelacionadasen diversasjerarquias, las cualesdeter-
minan la forma en que los datosdependientespuedenser agrupadosy agregados.
Por ultimo consideramosla mineria de datos. Aqui la idea b1isicaes que debido a que los
datosde apoyo para la toma de decisionescon frecuenciano son muy bien entendidos,podemos
usar el poder de la computadorapara que nos ayude a descubrir patronesen los datos. Conside-
ramos brevementevarios tipos de reglas -de asociacion, clasificacion y correlacion de se-
cuencia- y tratamoslas nociones asociadasde niveles de soporte y de confianza.
E}ERCICIOS
21.1 l,Cuales son algunos de los puntos principales de diferencia entre las bases de datos de apoyo
para la toma de decisiones y las operacionales? l,Por que lasaplicaciones de apoyo para la toma de
decisiones y las aplicaciones operacionales utilizan generalmente almacenes de datos diferentes?
21.2 Resuma los pasos involucrados en la preparaci6n de datos operacionales para el apoyo a la toma
de decisiones.
21.3 Distinga entre la redundancia controlada y la no controlada. De algunos ejemplos. l,Por que es
importante la redundancia controlada en el contexto del apoyo para la toma de decisiones? l,Que
sucede si, en vez de ello, la redundancia no es controlada?
21.4 Distinga entre data warehouses y data marts.
21.5 l,Que entiende usted por el termino esquema de estrella?
21.6 Por 10general, los esquemasde estrella no estan completamente normalizados. l,Cual es la justi -
ficaci6n para esta situaci6n? Explique la metodologia mediante la cual son disefiados dichos esquemas.
21.7 Explique la diferencia entre ROLAP y MOLAP.
21.8 l.En cuantas formas es posible resumir los datos si estan caracterizados por cuatro dimensiones,
donde cada una de ellas pertenece a una jerarquia de agregaci6n de tres niyeles (par ejemplo, ciudad,
region, estado)?
21.9 Utilice la base de datos de proyeedores, partes y proyectos (yea el ejercicio 4.1 del capitulo 4)
para expresar 10 siguiente como consultas SQL:
a. Obtener la cantidad de enyios y las cantidades promedio de enyios para proYeedores,partes y pro-
yectos considerados en pares (es decir, para cada par V#-P#, cada par P#-y# y cada par y#- V#).
b. Obtener las cantidades maxima y minima de enyios para cada proyecto, para cada combinaci6n
de proyecto y parte, yen general.
Co Obtener las cantidades de enYios totales enrolladas "en toda la dimensi6n de proyeedor" y "en
toda la dimensi6n de parte". Precauci6n: Aqui hay una trampa.
do Obtener las cantidades de enyio promedio par proyeedor, por parte, par combinaciones de pro-
Yeedor/parte yen general.
En cada caso, muestre el resultado SQL que se produciria tomando 10sdatos de ejemplo de la figura
4.5 (0 aigunos datos de ejemplo que usted proparcione). Tambien muestre esosresultados como tablas
cruzadas.
21.10 Casi ai principio de la secci6n 21.6, mostramos una yersi6n simple de la tabla VP que contiene
solamente seis filas. Suponga que la tabla incluye ademas la siguiente fila (10 que significa que ital
yez! existe el proyeedor V5 pero actualmente no proparciona partes):
I V5 I nulo I nulo I
Explique las implicaciones para todas las diyersas consultas SQL que mostramos en la secci6n 21.6.
21.11 l.Significa 10 rnismo el terrnino dimensional en las frases "esquema dimensional" y "base de
datos multidimensional"? Explique su respuesta.
21.12 Considere el problema del analisis de canasta de mercado. Indique un aigoritmo mediante el
cual sea pasible descubrir las reglas de asociaci6n que tienen niyeles de soporte y de confianza ma-
yores que 10Slirnites especificados. Sugerencia: Si alguna combinaci6n de productos "no es intere-
sante" debido a que sucede en muy pocas transacciones de Yentas, entonces 10 rnismo es cierto para
todos los superconjuntos de esa combinaci6n de productoso
REFERENCIAS y BIBLIOGRAFiA
21.1 Pieter Adriaans y Do1f Zantinge: Data Mining. Reading, Mass.: Addison-Wesley (1996).
Aunque es descrito como una panor3mica en el nivel ejecutivo, este libro es en realidad una in-
troducci6n bastante detallada (y buena) al tema.
21.2 S. Alter: Decision Support Systems: Current Practice and Continuing Challenges. Reading,
Mass.: Addison-Wesley (1980).
21.3 J. L. Bennett (ed.): Building Decision Support Systems.Reading, Mass.: Addison- Wesley ( 1981).
21.4 M. J. A. Berry y G. Linoff: Data Mining Techniquesfor Marketing, QTY, and Customer Support.
Nueva York, N.Y.: McGraw-Hill (1997).
Es una buena explicaci6n sobre 10Smetodos de la mineria de datos y su valor para aspectos se-
leccionados de 10Snegocios.
21.5 J. B. Boulden: Computer-Assisted Planning Systems.Nueva York, N.Y.: McGraw-Hill (1975).
Este primer texto trata muchas de las preocupaciones que posteriormente fueron reunidas bajo
el encabezado de apoyo para la toma de decisiones. Como 10 dice el tftulo, el enfasis esta en la
planeaci6n de la administraci6n en el sentido clasico.
21.6 R. H. Bonczek, C. W. Holsapple y A. Whinston: Foundations of Decision Support Systems.

Orlando, PIa.: Academic Press (1981).
Es uno de los primeros textos en promover un enfoque disciplinado para los sistemas de ~poyo
para la toma de decisiones. Enfatiza los papeles del modelado (en el sentido general de mode-
lado empfrico y matematico) y la ciencia de la administraci6n.
21.7 Charles J. Bontempo y Cynthia Maro Saracco: Database Management: Principles and Products.
Upper Saddle River, N.J.: Prentice-Hall (1996).
21.8 P. Cabena, P. Hadjinian, R. Stadler, J. Verhees y A. Zanasi: Discovering Data Mining: From
Concept to Implementation. Upper Saddle River, N.J.: Prentice-Hall (1998).
21.9 C. L. Chang: "DEDUCE-A Deductive Query Language for Relational Data Bases", en C. H.
Chen (ed.), Pattern Recognition and Artificial Intelligence. Nueva York, N .Y .: Academic Press( 1976).
21.10 E. F. Codd, S. B. Codd y C. T. Salley: "Providing OLAP (Online Analytical Processing) to
User-Analysts: An IT Mandate", disponible con Arbor Software Corp. (1993).
Como mencionamos en el cuerpo del capitulo, este articulo es el origen del termino "OLAP" (aun-
que no del concepto). Es interesante observar que casi al comienzo, el articulo establececateg6ri-
camente que "la necesidadexistente NO es de otra tecnologia de base de datos sino, en su lugar, de
robustas...herramientasde analisis". iDespuescontinua describiendo y argumentandosobre la nece-
sidad de otra tecnologia de basede datos!, con una nueva representaci6nconceptual de datos, nuevos
operadores(para actualizaci6n y tambien para recuperaci6n), soporte multiusuarios (incluyendo ca-
racteristicas de seguridad y concurrencia), nuevas estructuras de almacenamiento y nuevas carac-
teristicas de optimizaci6n; en otraspalabras, un nuevo modelo de datos y un nuevo DBMS.
21.11 C. J. Date: "We Don't Need Composite Columns", en C. J. Date, Hugh Darwen y David Mc-
Goveran, Relational Database Writings 1994-1997. Reading, Mass.: Addison-Wesley (1998).
El titulo de este articulo se refiere al hecho de que en el pasado se ha intentado (sin exito) intro-
ducir soporte para columnas compuestas, sin basarlo en el soporte para los tipos definidos por el
usuario. Si se proporciona soporte adecuado para los tipos definidos por el usuario, las colum-
nas compuestas "saldran bien".
21.12 Barry Devlin: Data Warehousefrom Architecture to Implementation. Reading, Mass.: Addi-
son-Wesley (1997).
21.13 B. A. Devlin y P. T. Murphy: "An Architecture for a Business and Information System", IBM
Sys. J. 27, No.1 (1988).
Es el primer articulo publicado que define y usa el termino "almacen de informaci6n".
21.14 Herb Edelstein: Data Mining: Products and Markets. Potomac, Md.: Two Crows Corp. (1997).
21.15 T. P. Gerrity, Jr.: "The Design of Man-Machine Decision Systems: An Application to portfo-
lio Management", Sloan Management Review 12, No.2 (invierno, 1971).
Es uno de los primeros articulos sobre los sistemas de apoyo para la toma de decisiones. Describe
un sistema para dar apoyo a los administradores de inversiones en la administraci6n de portafo-
lios de acciones.
21.16 Jim Gray, Adam Bosworth, Andrew Layman y Hamid Pirahesh: "Data Cube: A Relational
Aggregation Operator Generalizing Group-By, Cross- Tab, and Sub-Totals", Proc. 12th IEEE Int.
Conf. on Data Engineering, Nueva Orleans, La. (febrero, 1996).
Es el articulo que sugiere por primera vez la adici6n de opciones tales como CUBE a la clausula
GROUP BY de SQL.
21.17 W. H. Inmon: Data Architecture: The Information Paradigm. Wellesley, Mass.: QED Infor-
mation Sciences (1988).
Trata el origen del concepto data warehouse y c6mo luciria un data warehouse en la practica. El
termino "data warehouse" apareci6 por primera vez en este libro.
21.18 W. H. Inmon: Building the Data Warehouse. Nueva York, N.Y.: Wiley (1992).
Es el primer libro dedicado a los data warehouses. Define el termino y trata los problemas prin-
cipales involucrados en el desarroUo de un data warehouse. Su preocupaci6n principal es la
justificaci6n del concepto y los asuntos operacionales y de disefio ffsico.
21.19 W. H. InmonyR. D. Hackathorn: Using the Data Warehouse.Nueva York,N.Y.: Wiley(1994).
Es una explicaci6n para usuarios y administradores del data warehouse. At igual que otros libros
sobre el tema, se concentra en asuntos ffsicos. Trata en detalle el concepto de almacen opera-
cional de datos.
21.20 P. G. W. Keen y M. S. Scott Morton: Decision Support Systems;An Organizational perspec-
tive. Reading, Mass.: Addison-Wesley (1978).
Este texto clasico es uno de los primeros -si es que no el primero-- en tratar explfcitamente el
apoyo para la toma de decisiones. La orientaci6n es con relaci6n al comportamiento y trata
el analisis, disefio, implementaci6n, evaluaci6n y desarroUo de sistemas de apoyo para la toma
de decisiones.
21.21 Ralph Kimball: The Data Warehouse Toolkit. Nueva York, N.Y.: John Wiley & Sons (1996).
Es un libro practico. Como 10sugiere el subtftulo "Tecnicas practicas para la construcci6n de data
warehouses dimensionales", el enfasis esta centrado en los asuntos pragmaticos y no te6ricos.
La suposici6n tacita es que en esencia, no existe diferencia entre los niveles 16gico y ffsico del
sistema. Por supuesto, esta suposici6n eS completamente valida para los productos actuales;
sin embargo, sentimos que serfa mejor tratar de mejorar la situaci6n en lugar de simplemente
aprobarla.
21.22 J. D. C. Little: "Models and Managers: The Concept of a Decision Calculus", Management
Science 16, No.8 (abril, 1970).
Este artfculo presenta un sistema (Brandaid) disefiado para apoyar decisiones de productos, pro-
mociones, precios y publicidad. El autor identifica cuatro criterios para el disefio de modelos para
apoyar la toma de decisiones de la administraci6n: robustez, facilidad de control, simplicidad y
compleci6n de los detaUesrelevantes.
21.23 M. S. Scott Morton: "Management Decision Systems: Computer-Based Support for Decision
Making", Harvard University, Division of Research, Graduate School of Business Administration
(1971).
Este es el articulo clasico que present6 el concepto de los sistemas de decisiones para la adminis-
traci6n, Uevandoclaramente el apoyo para la toma de decisiones al campo de los sistemasbasados
en computadora. Se construy6 un "sistema de decisiones para la administraci6n" especffico para
coordinar la planeaci6n de la producci6n para equipo de lavanderfa. Luego fue sometido a pruebas
cientfficas con administradores de ventas y de producci6n como usuarios.
21.24 K. Parsaye y M. ChigneU: Intelligent Database Tools and Applications. Nueva York, N.Y.:
Wiley (1993).
Este libro parece ser el primero dedicado a los principios y tecnicas de la minerfa de datos
(aunque se refiere al tema como "bases de datos inteligentes").
21.25 A. Pirotte y P. Wodon: "A Comprehensive Formal Query Language for a Relational Data
Base", R.A.I.R.O. Informatique/Computer Science 11, No.2 (1977).
21.26 R. H. Sprague y E. D. Carlson: Building Effective Decision Support Systems.Englewood Cliffs,
N.J.: Prentice-Hall (1982).
Es otro texto clasico.
21.27 Erik Thomsen: 01AP Solutions: Building Multi-Dimensional Information Systems. Nueva
York, N.Y.: Wiley (1997).
Es uno de los primeros libros sobre OLAP y tal vez el mas completo. Se concentra en la com-
prensi6n de los conceptos y metodos de anaIisis usando sistemas multidimensionales. Es un
intento serio para inyectar algo de disciplina en un tema confuso.
21.28 R. Uthurusamy: "From Data Mining to Knowledge Discovery: Current Challenges and Future
Directions", en U. M. Fayyad, G. Piatetsky-Shapiro, P. Smyth y R. Uthurusamy (eds.): Advances in
Knowledge Discovery and Data Mining. Cambridge, Mass.: AAAI Press/MIT Press (1996).
RESPUEST AS A EJERCICIOS SELECCIONADOS
21.8 Hay ocho (= 23) posibles agrupamientos para cada jerarquia y por 10 tanto, la cantidad total de
posibilidades es 84= 4,096. Como ejercicio adicional, tal vez quiera considerar 10 que implica usar
SQL para obtener todos estos resumenes.
21.9 Con respecto a las consultas SQL mostramos solamente las clausulas GROUP BY:
GROUP BY GROUPING SETS (V#,P#), (P#,V#), (V#,V#
GROUP BY GROUPING SETS v#, (V#,P#)
La trampa es que la consulta es ambigua; el tennino (por ejemplo) "enrollado en toda la dimen-
si6n de proveedor" tiene muchos significados posibles. Sin embargo, una interpretaci6n posible
del requerimiento conducir1i a una cl1iusula GROUP BY como esta:
GROUP BY ROLLUP (V#), ROLLUP (P#)
do GROUP
BY CUBE( V#. P# )
Omitimos las tablas de resultados SQL. Respecto de las tabcruz, debe quedar claro que no son una
forma muy buena para desplegar un resultado que involucra mas de dos dimensiones (y entre mas di-
mensiones hay, peor se pone). Por ejemplo, una de estas tabcruz -que corresponde a GROUP BY
V#, P#, Y#- podria verse como esto (en parte):
En pocas palabras: los encabezadosestan amontonados y los aJTeglosson poco densos.

P5 Cap 21

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

P5 Cap 21

Cargado por

Copyright:

Formatos disponibles

21.

blementeen basesde datosno relacionales(los sistemasrelacionalestodavfaseencontrabanen el

21.2 ASPECTOS DEL APOYO p ARA LA TOMA DE DECISIONES

21.3 DISENo DE BASES DE DATOS DE APOYO

*Los especialistasde datawarehousesy de OLAP tiendena ser especialmenteculpablesen esto;argumentan

prendentes.Los dominios (tipos) debenserespecificados,suscolumnasdefinidasy las depen-

.Combinaciones de columnasy muy pocas dependencias

declarativa al nivel16gico y expresar en fonna independiente 10Smecanismos de cumpli-

Figura 21.1 Valores de ejemplo para la tabla VP incluyendo IDs de mes.

CANT-MENSUAL IDM CANT

Figura 21.2 Contraparte normalizada de la figura 21.1

.indices de mapa de bits. Supongamosque la tabla indexadaT contiene n filas. Entoncesun

Trataremos cada uno de estos por separado.

Hacemos notar que al menos en el mundo commercial,el termino "replicaci6n" ha llegado a

Errores cornunes de disefio

.Desnormalizacion y prdcticas relacionadas. En un esfuerzoerroneopara eliminar juntas y

En resumen,creemosque muchasde las dificultadesde diseiio que supuestamente sepresen-

21.4 PREPARACI6N DE LOS DA TOS

*De paSo,comentarnosque estasoperacionesa menudopuedenbeneficiarsede las posibilidades en el nivel

Almacenes de datos operacionales

* A veces,para esteprop6sito se usa la replicaci6n asincronadesdelas fuentes de datos operacionaleshacia

21.5 DA TAW AREHOUSES y DATA MARTS

Por 10general,10Ssistemasoperacionalestienen requerimientosde rendimiento estrictos,cargas

arquitect6nico que limitan la capacidad e imposibilitan la escalabilidad de la platafonna. Los pun-

Los ultimos dos enfoquessufrenposiblesproblemasde desacoplosemantico.Los datamarts

arcJiivosde cataIogoseparecena los indices dado que contienenapuntadoreshacia los registros

Figura 21.3 Tabla de hechos de ejemplo (VP) y tabla de dimension (PI).

Figura 21.4 Esquema de estrella para proveedores y partes (con periodos).

Ahora, en estemomento tal vez sepreguntecual es la diferencia entre un esquemade estre-

2. Los esquemasde estrella en realidad son ffsicos y no 16gicos,aunquesehabla de ellos como

*Este es un consejode un libro sobredata warehouses:"[Resistase] a la norrnalizacion...Los esfuerzospara

forma en que luce el esquemacuandoes trazadocomo un diagramade entidad-vfnculo. Los ter-

I. Obtener la cantidad total de envfos.

I. SELECT SUM(CANT) AS CANTOT 2. SELECT v#,

SELECT P#, 4. SELECT v#, P#,

Ahora bien, esteresultadopuedeserViStocomo una tabla (una tabla SQL, de algunaforma),

Regresemos especfficamente a GROUP BY. Las otras dos opciones de GROUP BY

SELECT V#, P#, SUM(CANT) AS CANTOT

Aqui la clausula GROUP BYes 16gicamenteequivalente a la siguiente:

GROUP BY GROUPING SETS ( (V#,P#), (V#), (

En otras palabras,la consulta es una formulacion SQLcombinada de las consultas4, 2 y El

Observeque hay muchos"enrollar en toda la dimensi6nA " distintos, en general(dependede que

SELECT v#, P#, SUM(CANT ) AS CANTOT

Aqui la clausula GRQUP BYes 16gicamenteequivalente a la siguiente:

GROUP BY GROUPING SETS (V#,P#), (V# (P#), ()

Podemosdecir que estatabcruzesuna forma mascompactay legible de representarel resul-

Bases de datos multidimensionales

podrian ser clasificadas en tenninos generalescomo dependientes o independientes. En ter-

seragregadosen muchasformas diferentes(es decif, las mismasvariablesindependientespueden

21.7 MINERiA DE DA TOS

Figura 21.5 "a tabla VENTAS.

(Donde "Zapatos E tx" es la regia antecedente,"Calcetines E tx" es la regia consecuentey tx

Podemosdescubrir reglas de asociacionmas generalesa partir de agregacionesadecuadas

el procesode preparaci6nde datos.Tambien puedenser usadospara proporcionar servicios de

21.6 R. H. Bonczek, C. W. Holsapple y A. Whinston: Foundations of Decision Support Systems.

RESPUEST AS A EJERCICIOS SELECCIONADOS

GROUP BY GROUPING SETS (V#,P#), (P#,V#), (V#,V#

GROUP BY GROUPING SETS v#, (V#,P#)

GROUP BY ROLLUP (V#), ROLLUP (P#)

En pocas palabras: los encabezadosestan amontonados y los aJTeglosson poco densos.

También podría gustarte