Basese de Datos y SQL

Generalidades: Definiciones Pgina 1 de 2
Generalidades Modelo de datos Modelo relacional El modelo E/R SQL
Generalidades: Definiciones Informticas
Definiciones Informticas
Caf
Aporta ms sabidura a los programadores y les permite ver con los ojos cerrados.
Ciencia
1. Si es verde o se mueve es la biologa.
2. Si no rentabiliza tu dinero, es la ciencia de los negocios.
3. Si huele mal es la qumica.
4. Si no funciona, es la ciencia informtica
Ciencia Informtica
Ciencia de la computadora y de su desprecio por la economa, la matemtica y la
economa.
Usuario
Perifricos de la computadora que intentan, equipados con un hardware defectuoso y
una interface deficiente, mediante un sistema operativo inmaduro dotado de un
programa mediocre diseado por programadores incompetentes, resolver problemas
que no se plantearan de no ser por la computadora.
Actualizacin: undefined
http://www.lobocom.es/ 15/11/2002
Leyes de Murphi aplicables al diseo
Bases de datos-Modelo de datos-Leyes de Murphi
Desde luego hay que reconocer que: "si algo puede fallar fallar" y adems "lo har
de la forma que ms destrozos haga". A continuacin voy a exponer un extracto de
las leyes de Murphi aplicadas a la informtica.
1. Si algo puede salir mal, saldr mal.

1. Nada es tan fcil como parece
2. Todo lleva ms tiempo del que usted piensa
3. Si existe la posibilidad de que varias cosas vayan mal, la que cause ms
perjuicios ser la nica que vaya mal.
4. Si usted intuye que hay cuatro posibilidades de que una gestin vaya mal
y las evita, al momento aparecer espontneamente una quinta
posibilidad
5. Cuando las cosas se dejan a su aire, suelen ir de mal en peor
6. Cuando se ponga a hacer algo, se dar cuenta que hay otra cosa que
debera haber hecho antes
7. Cualquier solucin entraa nuevos problemas
8. Es intil hacer cualquier cosa a prueba de tontos, porque los tontos son
muy ingeniosos
9. La naturaleza siempre est de parte de la imperfeccin oculta
10. La madre Naturaleza es muy lagartona
2. Nadie por si mismo, puede hacer las cosas lo suficientemente bien
3. Siempre hay una forma ms sencilla de hacerlo
4. Lo que va mal, por lo general, tiene aspecto de funcionar bien
5. Cuando se ha detectado y corregido un error, se suele descubrir que no era un
error
6. Si un experimento funciona, es que algo ha ido mal
7. No importa cul sea el resultado previsto. Siempre habr alguien impaciente
por:
{ Malinterpretarlo;
{ imitarlo,
{ creer que ha sido a causa de su teora favorita
8. Si pide ayuda a alguien no sabr ver el error. Cualquiera que le eche un
vistazo, sin que usted o pida, lo ver inmediatamente
9. La probabilidad de que suceda algo es inversamente proporcional a lo que
quiera que suceda
10. Si funciona la modificacin de un programador a un programa ya existente, es
probable que no sea lo quieren los usuarios
11. Los usuarios no saben realmente lo que quieren, pero saben con certeza lo que
no quieren
12. Al diseador se le notificar que es necesario modificar el diseo despus - y
slo despus - de que haya terminado el anlisis. (A menudo, es denominada
como ley de "Y nos lo dicen ahora!").
13. Cualquier programa, cuando funciona, es que se ha quedado antiguo
14. Cualquier programa cuesta ms caro y se necesita ms tiempo
15. Si un programa es til, habr que cambiarlo
16. Si un programa es intil, habr que demostrarlo
17. Cualquier programa se expandir hasta ocupar toda la memoria del ordenador
18. La complejidad de un programa aumenta hasta que supera la capacidad del
programador que debe revisarlo
19. Si una instalacin de comprobacin funciona perfectamente bien, todos los
sistemas posteriores funcionarn mal
20. El error ms terrible de un programador slo se detectar cuando lleve, por lo
menos, seis meses de funcionamiento
21. Si se ha diseado el editor de entrada de tal forma que rechace entradas
nocivas, siempre habr algn idiota que descubra el mtodo para que se cuelen
datos que no deben
22. El nico lenguaje que conocen bien todos los programadores es el de los
profanos
23. Los ordenadores no son fiables, pero los seres humanos lo son menos an
24. Cualquier sistema que dependa de la fiabilidad humana, no es fiable
25. Si aade mano de obra a un proyecto informtico que va retrasado, se retrasa
todava ms.
26. Construya un sistema que pueda utilizar hasta un tonto y slo lo querrn
utilizar los tontos
http://www.lobocom.es/~claudio/gen004.htm 15/11/2002
Data Warehousing: Introduccin
Bases de datos-SQL-Funciones-Data Warehousing-Introduccin
Desde que se inici la era de la computadora, las organizaciones han usado los datos
desde sus sistemas operacionales para atender sus necesidades de informacin.
Algunas proporcionan acceso directo a la informacin contenida dentro de las
aplicaciones operacionales. Otras, han extrado los datos desde sus bases de datos
operacionales para combinarlos de varias formas no estructuradas, en su intento por
atender a los usuarios en sus necesidades de informacin.
Ambos mtodos han evolucionado a travs del tiempo y ahora las organizaciones
manejan una data no limpia e inconsistente, sobre las cuales, en la mayora de las
veces, se toman decisiones importantes.
La gestin administrativa reconoce que una manera de elevar su eficiencia est en

hacer el mejor uso de los recursos de informacin que ya existen dentro de la
organizacin. Sin embargo, a pesar de que esto se viene intentando desde hace
muchos aos, no se tiene todava un uso efectivo de los mismos.
La razn principal es la manera en que han evolucionado las computadoras, basadas

en las tecnologas de informacin y sistemas. La mayora de las organizaciones
hacen lo posible por conseguir buena informacin, pero el logro de ese objetivo
depende fundamentalmente de su arquitectura actual, tanto de hardware como de
software.
El data warehouse, es actualmente, el centro de atencin de las grandes

instituciones, porque provee un ambiente para que las organizaciones hagan un
mejor uso de la informacin que est siendo administrada por diversas aplicaciones
operacionales.
Un data warehouse es una coleccin de datos en la cual se encuentra integrada la

informacin de la Institucin y que se usa como soporte para el proceso de toma de
decisiones gerenciales. Aunque diversas organizaciones y personas individuales
logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que
existen muchas dificultades potenciales.
Reunir los elementos de datos apropiados desde diversas fuentes de aplicacin en un

ambiente integral centralizado, simplifica el problema de acceso a la informacin y
en consecuencia, acelera el proceso de anlisis, consultas y el menor tiempo de uso
de la informacin.
Las aplicaciones para soporte de decisiones basadas en un data warehousing,

pueden hacer ms prctica y fcil la explotacin de datos para una mayor eficacia del
Data Warehousing: Introduccin Pgina 2 de 2
negocio, que no se logra cuando se usan slo los datos que provienen de las
aplicaciones operacionales (que ayudan en la operacin de la empresa en sus
operaciones cotidianas), en los que la informacin se obtiene realizando procesos
independientes y muchas veces complejos.
Un data warehouse se crea al extraer datos desde una o ms bases de datos de

aplicaciones operacionales. La data extrada es transformada para eliminar
inconsistencias y resumir si es necesario y luego, cargadas en el data warehouse. El
proceso de transformar, crear el detalle de tiempo variante, resumir y combinar los
extractos de datos, ayudan a crear el ambiente para el acceso a la informacin
Institucional. Este nuevo enfoque ayuda a las personas individuales, en todos los
niveles de la empresa, a efectuar su toma de decisiones con ms responsabilidad.
La innovacin de la Tecnologa de Informacin dentro de un ambiente data

warehousing, puede permitir a cualquier organizacin hacer un uso ms ptimo de
los datos, como un ingrediente clave para un proceso de toma de decisiones ms
efectivo. Las organizaciones tienen que aprovechar sus recursos de informacin para
crear la informacin de la operacin del negocio, pero deben considerarse las
estrategias tecnolgicas necesarias para la implementacin de una arquitectura
completa de data warehouse.
Data Warehousing: Teora
Funciones-Data Warehousing-Aspectos Tericos
1. Introduccin al Concepto Data

Warehousing
Data warehousing es el centro de la arquitectura para los sistemas de informacin en
la dcada de los '90. Soporta el procesamiento informtico al proveer una plataforma
slida, a partir de los datos histricos para hacer el anlisis. Facilita la integracin de
sistemas de aplicacin no integrados. Organiza y almacena los datos que se
necesitan para el procesamiento analtico, informtico sobre una amplia perspectiva
de tiempo.
Un Data Warehouse o Depsito de Datos es una coleccin de datos orientado a

temas, integrado, no voltil, de tiempo variante, que se usa para el soporte del
proceso de toma de decisiones gerenciales.
Se puede caracterizar un data warehouse haciendo un contraste de cmo los datos

de un negocio almacenados en un data warehouse, difieren de los datos
operacionales usados por las aplicaciones de produccin.
Base de Datos Operacional Data Warehouse

Datos Operacionales Datos del negocio para Informacin
Orientado a la aplicacin Orientado al sujeto
Actual Actual + histrico
Detallada Detallada + ms resumida
Cambia continuamente Estable
El ingreso de datos en el data warehouse viene desde el ambiente operacional en

casi todos los casos. El data warehouse es siempre un almacn de datos
transformados y separados fsicamente de la aplicacin donde se encontraron los
datos en el ambiente operacional.
2 Sistemas de Informacin
Los sistemas de informacin se han dividido de acuerdo al siguiente esquema:
Sistemas Estratgicos, orientados a soportar la toma de decisiones, facilitan la
labor de la direccin, proporcionndole un soporte bsico, en forma de mejor
informacin, para la toma de decisiones. Se caracterizan porque son sistemas sin
carga peridica de trabajo, es decir, su utilizacin no es predecible, al contrario de
los casos anteriores, cuya utilizacin es peridica.
Destacan entre estos sistemas: los Sistemas de Informacin Gerencial (MIS),

Sistemas de Informacin Ejecutivos (EIS), Sistemas de Informacin Georeferencial
(GIS), Sistemas de Simulacin de Negocios (BIS y que en la prctica son sistemas
expertos o de Inteligencia Artificial - AI).
Sistemas Tcticos, diseados para soportar las actividades de coordinacin de

actividades y manejo de documentacin, definidos para facilitar consultas sobre
informacin almacenada en el sistema, proporcionar informes y, en resumen, facilitar
la gestin independiente de la informacin por parte de los niveles intermedios de la
organizacin.
Destacan entre ellos: los Sistemas Ofimticos (OA), Sistemas de Transmisin de

Mensajera (Correo electrnico y Servidor de fax), coordinacin y control de tareas
(Work Flow) y tratamiento de documentos (Imagen, Trmite y Bases de Datos
Documentales).
Sistemas Tcnico - Operativos, que cubren el ncleo de operaciones tradicionales

de captura masiva de datos (Data Entry) y servicios bsicos de tratamiento de datos,
con tareas predefinidas (contabilidad, facturacin, almacn, presupuesto, personal y
otros sistemas administrativos). Estos sistemas estn evolucionando con la irrupcin
de censores, autmatas, sistemas multimedia, bases de datos relacionales ms
avanzadas y data warehousing.
Sistemas Interinstitucionales, este ltimo nivel de sistemas de informacin recin

est surgiendo, es consecuencia del desarrollo organizacional orientado a un
mercado de carcter global, el cual obliga a pensar e implementar estructuras de
comunicacin ms estrechas entre la organizacin y el mercado (Empresa Extendida,
Organizacin Inteligente e Integracin Organizacional), todo esto a partir de la
generalizacin de las redes informticas de alcance nacional y global (INTERNET),
que se convierten en vehculo de comunicacin entre la organizacin y el mercado,
no importa dnde est la organizacin (INTRANET), el mercado de la institucin
(EXTRANET) y el mercado (Red Global).
Sin embargo, la tecnologa data warehousing basa sus conceptos y diferencias entre
dos tipos fundamentales de sistemas de informacin en todas las organizaciones: los
sistemas tcnico - operacionales y los sistemas de soporte de decisiones. Este ltimo
es la base de un data warehouse.
2.1 Sistemas Tcnico - Operacionales

Como indica su nombre, son los sistemas que ayudan a manejar la empresa con sus
operaciones cotidianas. Estos son los sistemas que operan sobre el
"backbone" (columna vertebral) de cualquier empresa o institucin, entre las que se
tiene sistemas de ingreso de rdenes, inventario, fabricacin, planilla y contabilidad,
entre otros.
Debido a su volumen e importancia en la organizacin, los sistemas operacionales

siempre han sido las primeras partes de la empresa a ser computarizados. A travs
de los aos, estos sistemas operacionales se han extendido, revisado, mejorado y
mantenido al punto que hoy, ellos son completamente integrados en la organizacin.
Desde luego, la mayora de las organizaciones grandes de todo el mundo,

actualmente no podran operar sin sus sistemas operacionales y los datos que estos
sistemas mantienen.
2.2 Sistemas de Soporte de Decisiones

Por otra parte, hay otras funciones dentro de la empresa que tienen que ver con el
planeamiento, previsin y administracin de la organizacin. Estas funciones son
tambin crticas para la supervivencia de la organizacin, especialmente en nuestro
mundo de rpidos cambios.
Las funciones como "planificacin de marketing", "planeamiento de ingeniera" y

"anlisis financiero", requieren, adems, de sistemas de informacin que los soporte.
Pero estas funciones son diferentes de las operacionales y los tipos de sistemas y la
informacin requerida son tambin diferentes. Las funciones basadas en el
conocimiento son los sistemas de soporte de decisiones.
Estos sistemas estn relacionados con el anlisis de los datos y la toma de

decisiones, frecuentemente, decisiones importantes sobre cmo operar la empresa,
ahora y en el futuro. Estos sistemas no slo tienen un enfoque diferente al de los
operacionales, sino que, por lo general, tienen un alcance diferente.
Mientras las necesidades de los datos operacionales se enfocan normalmente hacia

una sola rea, los datos para el soporte de decisiones, con frecuencia, toma un
nmero de reas diferentes y necesita cantidades grandes de datos operacionales
relacionadas.
http://www.lobocom.es 15/11/2002
Son estos sistemas sobre los que se basa la tecnologa data warehousing.
3 Caractersticas de un Data Warehouse

Entre las principales se tiene:
{ Orientado al tema
{ Integrado
{ De tiempo variante
{ No voltil
3.1 Orientado a Temas

Una primera caracterstica del data warehouse es que la informacin se clasifica en
base a los aspectos que son de inters para la empresa. Siendo as, los datos
tomados estn en contraste con los clsicos procesos orientados a las aplicaciones.
En la Figura N 1 se muestra el contraste entre los dos tipos de orientaciones.
El ambiente operacional se disea alrededor de las aplicaciones y funciones tales

como prstamos, ahorros, tarjeta bancaria y depsitos para una institucin
financiera. Por ejemplo, una aplicacin de ingreso de rdenes puede acceder a los
datos sobre clientes, productos y cuentas. La base de datos combina estos
elementos en una estructura que acomoda las necesidades de la aplicacin.
En el ambiente data warehousing se organiza alrededor de sujetos tales como

cliente, vendedor, producto y actividad. Por ejemplo, para un fabricante, stos
pueden ser clientes, productos, proveedores y vendedores. Para una universidad
pueden ser estudiantes, clases y profesores. Para un hospital pueden ser pacientes,
personal mdico, medicamentos, etc.
La alineacin alrededor de las reas de los temas afecta el diseo y la

implementacin de los datos encontrados en el data warehouse. Las principales
reas de los temas influyen en la parte ms importante de la estructura clave.
Las aplicaciones estn relacionadas con el diseo de la base de datos y del proceso.
En data warehousing se enfoca el modelamiento de datos y el diseo de la base de
datos. El diseo del proceso (en su forma clsica) no es separado de este ambiente.
Las diferencias entre la orientacin de procesos y funciones de las aplicaciones y la

orientacin a temas, radican en el contenido de la data a escala detallada. En el data
warehouse se excluye la informacin que no ser usada por el proceso de sistemas
de soporte de decisiones, mientras que la informacin de las orientadas a las
aplicaciones, contiene datos para satisfacer de inmediato los requerimientos
funcionales y de proceso, que pueden ser usados o no por el analista de soporte de
decisiones.
Otra diferencia importante est en la interrelacin de la informacin. Los datos

operacionales mantienen una relacin continua entre dos o ms tablas basadas en
una regla comercial que est vigente. Las del data warehouse miden un espectro de
tiempo y las relaciones encontradas en el data warehouse son muchas. Muchas de
las reglas comerciales (y sus correspondientes relaciones de datos) se representan
en el data warehouse, entre dos o ms tablas.
3.2 Integracin
El aspecto ms importante del ambiente data warehousing es que la informacin
encontrada al interior est siempre integrada.
La integracin de datos se muestra de muchas maneras: en convenciones de

nombres consistentes, en la medida uniforme de variables, en la codificacin de
estructuras consistentes, en atributos fsicos de los datos consistentes, fuentes
mltiples y otros.
El contraste de la integracin encontrada en el data warehouse con la carencia de

integracin del ambiente de aplicaciones, se muestran en la Figura N 2, con
diferencias bien marcadas.
A travs de los aos, los diseadores de las diferentes aplicaciones han tomado sus
propias decisiones sobre cmo se debera construir una aplicacin. Los estilos y
diseos personalizados se muestran de muchas maneras.
Se diferencian en la codificacin, en las estructuras claves, en sus caractersticas

fsicas, en las convenciones de nombramiento y otros. La capacidad colectiva de
muchos de los diseadores de aplicaciones, para crear aplicaciones inconsistentes, es
fabulosa. La Figura N 2 mencionada, muestra algunas de las diferencias ms
importantes en las formas en que se disean las aplicaciones.
Codificacin. Los diseadores de aplicaciones codifican el campo GENERO en varias

formas. Un diseador representa GENERO como una "M" y una "F", otros como un
"1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y
"femenino".
No importa mucho cmo el GENERO llega al data warehouse. Probablemente "M" y

"F" sean tan buenas como cualquier otra representacin. Lo importante es que sea
de cualquier fuente de donde venga, el GENERO debe llegar al data warehouse en un
estado integrado uniforme.
Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicacin,
donde ha sido representado en formato "M" y "F", los datos deben convertirse al
formato del data warehouse.
Medida de atributos. Los diseadores de aplicaciones miden las unidades de

medida de las tuberas en una variedad de formas. Un diseador almacena los datos
de tuberas en centmetros, otros en pulgadas, otros en millones de pies cbicos por
segundo y otros en yardas.
Al dar medidas a los atributos, la transformacin traduce las diversas unidades de

medida usadas en las diferentes bases de datos para transformarlas en una medida
estndar comn.
Cualquiera que sea la fuente, cuando la informacin de la tubera llegue al data

warehouse necesitar ser medida de la misma manera.
Convenciones de Nombramiento. El mismo elemento es frecuentemente referido

por nombres diferentes en las diversas aplicaciones. El proceso de transformacin
asegura que se use preferentemente el nombre de usuario.
Fuentes Mltiples. El mismo elemento puede derivarse desde fuentes mltiples. En

este caso, el proceso de transformacin debe asegurar que la fuente apropiada sea
usada, documentada y movida al depsito.
Tal como se muestra en la figura, los puntos de integracin afectan casi todos los
aspectos de diseo - las caractersticas fsicas de los datos, la disyuntiva de tener
ms de una de fuente de datos, el problema de estndares de denominacin
inconsistentes, formatos de fecha inconsistentes y otros.
Cualquiera que sea la forma del diseo, el resultado es el mismo - la informacin

necesita ser almacenada en el data warehouse en un modelo globalmente aceptable
y singular, aun cuando los sistemas operacionales subyacentes almacenen los datos
de manera diferente.
Cuando el analista de sistema de soporte de decisiones observe el data warehouse,

su enfoque deber estar en el uso de los datos que se encuentre en el depsito,
antes que preguntarse sobre la confiabilidad o consistencia de los datos.
3.3 De Tiempo Variante
Toda la informacin del data warehouse es requerida en algn momento. Esta
caracterstica bsica de los datos en un depsito, es muy diferente de la informacin
encontrada en el ambiente operacional. En stos, la informacin se requiere al
momento de acceder. En otras palabras, en el ambiente operacional, cuando usted
accede a una unidad de informacin, usted espera que los valores requeridos se
obtengan a partir del momento de acceso.
Como la informacin en el data warehouse es solicitada en cualquier momento (es

decir, no "ahora mismo"), los datos encontrados en el depsito se llaman de "tiempo
variante".
Los datos histricos son de poco uso en el procesamiento operacional. La informacin

del depsito por el contraste, debe incluir los datos histricos para usarse en la
identificacin y evaluacin de tendencias. (Ver Figura N 3).
El tiempo variante se muestra de varias maneras:
1. La ms simple es que la informacin representa los datos sobre un horizonte

largo de tiempo - desde cinco a diez aos. El horizonte de tiempo representado
para el ambiente operacional es mucho ms corto - desde valores actuales
hasta sesenta a noventa das.
Las aplicaciones que tienen un buen rendimiento y estn disponibles para el
procesamiento de transacciones, deben llevar una cantidad mnima de datos si
tienen cualquier grado de flexibilidad. Por ello, las aplicaciones operacionales
tienen un corto horizonte de tiempo, debido al diseo de aplicaciones rgidas.
2. La segunda manera en la que se muestra el tiempo variante en el data
warehouse est en la estructura clave. Cada estructura clave en el data
warehouse contiene, implcita o explcitamente, un elemento de tiempo como
da, semana, mes, etc.
El elemento de tiempo est casi siempre al pie de la clave concatenada,
encontrada en el data warehouse. En ocasiones, el elemento de tiempo existir
implcitamente, como el caso en que un archivo completo se duplica al final del
mes, o al cuarto.
3. La tercera manera en que aparece el tiempo variante es cuando la informacin
del data warehouse, una vez registrada correctamente, no puede ser
actualizada. La informacin del data warehouse es, para todos los propsitos
prcticos, una serie larga de "snapshots" (vistas instantneas).
Por supuesto, si los snapshots de los datos se han tomado incorrectamente,
entonces pueden ser cambiados. Asumiendo que los snapshots se han tomado
adecuadamente, ellos no son alterados una vez hechos. En algunos casos
puede ser no tico, e incluso ilegal, alterar los snapshots en el data warehouse.
Los datos operacionales, siendo requeridos a partir del momento de acceso,
pueden actualizarse de acuerdo a la necesidad.
3.4 No Voltil
La informacin es til slo cuando es estable. Los datos operacionales cambian sobre
una base momento a momento. La perspectiva ms grande, esencial para el anlisis
y la toma de decisiones, requiere una base de datos estable.
En la Figura N 4 se muestra que la actualizacin (insertar, borrar y modificar), se

hace regularmente en el ambiente operacional sobre una base de registro por
registro. Pero la manipulacin bsica de los datos que ocurre en el data warehouse
es mucho ms simple. Hay dos nicos tipos de operaciones: la carga inicial de datos
y el acceso a los mismos. No hay actualizacin de datos (en el sentido general de
actualizacin) en el depsito, como una parte normal de procesamiento.
Hay algunas consecuencias muy importantes de esta diferencia bsica, entre el

procesamiento operacional y del data warehouse. En el nivel de diseo, la necesidad
de ser precavido para actualizar las anomalas no es un factor en el data warehouse,
ya que no se hace la actualizacin de datos. Esto significa que en el nivel fsico de
diseo, se pueden tomar libertades para optimizar el acceso a los datos,
particularmente al usar la normalizacin y desnormalizacin fsica.
Data Warehousing: Proyecto
Data Warehousing-Realizacin de un proyecto
1. Organizacin
La planificacin es el proceso ms importante que determina la clase de tipo de
estrategias data warehousing que una organizacin iniciar.
1.1 Factores en la Planificacion de un Data Warehouse

No existe una frmula de garanta real para el xito de la construccin de un data
warehouse, pero hay muchos puntos que contribuyen a ese objetivo.
A continuacin, se indican algunos puntos claves que deben considerarse en la

planificacin de un data warehouse:
Establecer una asociacin de usuarios, gestin y grupos
Es esencial involucrar tanto a los usuarios como a la gestin para asegurar que el
data warehouse contenga informacin que satisfaga los requerimientos de la
empresa.
La gestin puede ayudar a priorizar la fase de la implementacin del data

warehouse, as como tambin la seleccin de herramientas del usuario. Los usuarios
y la gestin justifican los costos del data warehouse sobre cmo ser "su ambiente"
y est basado primero en lo esperado y segundo, en el valor comercial real.
Seleccionar una aplicacin piloto con una alta probabilidad de xito
Una aplicacin piloto de alcance limitado, con un reembolso medible para los
usuarios y la gestin, establecer el data warehouse como una tecnologa clave para
la empresa. Estos mismos criterios (alcance limitado, reembolso medible y beneficios
claros para la empresa) se aplican a cada fase de la implementacin de un data
warehouse.
Construir prototipos rpida y frecuentemente
La nica manera para asegurar que el data warehouse rena las necesidades de los
usuarios, es hacer el prototipo a lo largo del proceso de implementacin y an ms
all, as como agregar los nuevos datos y/o los modelos en forma permanente. El
trabajo continuo con los usuarios y la gestin es, nuevamente, la clave.
Implementacin incremental
La implementacin incremental reduce riesgos y asegura que el tamao del proyecto

permanezca manejable en cada fase.
Reportar activamente y publicar los casos exitosos
La retroalimentacin de los usuarios ofrece una excelente oportunidad para publicar

los hechos exitosos dentro de una organizacin. La publicidad interna sobre cmo el
data warehouse ha ayudado a los usuarios a operar ms efectivamente puede
apoyar la construccin del data warehouse a lo largo de una empresa.
La retroalimentacin del usuario tambin ayuda a comprender cmo evoluciona la

implementacin del data warehouse a travs del tiempo para reunir requerimientos
de usuario nuevamente identificados.
1.2 Estrategias para el Desarrollo de un Data Warehouse

Antes de desarrollar un data warehouse, es crtico el desarrollo de una estrategia
equilibrada que sea apropiada para sus necesidades y sus usuarios.
Las preguntas que deben tenerse en cuenta son:
z Quin es el auditorio?
z Cul es el alcance?
z Qu tipo de data warehouse debera construirse?
Existe un nmero de estrategias mediante las cuales las organizaciones pueden

conseguir sus data warehouses.
Primera
Establecer un ambiente "data warehouse virtual", el cual puede ser creado por:
z Instalacin de un conjunto de facilidades para acceso a datos, directorio de

datos y gestin de proceso.
z Entrenamiento de usuarios finales.
z Control de cmo se usan realmente las instalaciones del data warehouse.
z Basados en el uso actual, crear un data warehouse fsico para soportar los
pedidos de alta frecuencia.
Segunda
Construir una copia de los datos operacionales desde un sistema operacional nico y
posibilitar al data warehouse de una serie de herramientas de acceso a la
informacin.
Esta estrategia tiene la ventaja de ser simple y rpida. Desafortunadamente, si los

datos existentes son de mala calidad y/o el acceso a los datos no ha sido
previamente evaluado, entonces se puede crear una serie de problemas.
Tercera
Finalmente, la estrategia data warehousing ptima es seleccionar el nmero de

usuarios basados en el valor de la empresa y hacer un anlisis de sus puntos,
preguntas y necesidades de acceso a datos.
De acuerdo a estas necesidades, se construyen los prototipos data warehousing y se

prueban para que los usuarios finales puedan experimentar y modificar sus
requerimientos.
Una vez se tenga un consenso general sobre las necesidades, entonces se consiguen
los datos provenientes de los sistemas operacionales existentes a travs de la
empresa y/o desde fuentes externas de datos y se cargan al data warehouse.
Si se requieren herramientas de acceso a la informacin, se puede tambin permitir

a los usuarios finales tener acceso a los datos requeridos usando sus herramientas
favoritas propias, o facilitar la creacin de sistemas de acceso a la informacin
multidimensional de alta performance, usando el ncleo del data warehouse como
base.
En conclusin
No se tiene un enfoque nico para construir un data warehouse que se adapte a las
necesidades de las empresas, debido a que las necesidades de cada una de ellas son
diferentes, al igual que su contexto.
Adems, como la tecnologa data warehousing va evolucionando, se aprende cada

vez ms y ms sobre el desarrollo de data warehouses, que resulta en que el nico
enfoque prctico para al almacenamiento de datos es la evolucin de uno mismo.
1.3 Estrategias para el Diseo de un Data Warehouse

El diseo de los data warehouses es muy diferente al diseo de los sistemas
operacionales tradicionales. Se pueden considerar los siguientes puntos:
1. Los usuarios de los data warehouses usualmente no conocen mucho sobre sus
requerimientos y necesidades como los usuarios operacionales.
2. El diseo de un data warehouse, con frecuencia involucra lo que se piensa en
trminos ms amplios y con conceptos del negocio ms difciles de definir que
en el diseo de un sistema operacional. Al respecto, un data warehouse est
bastante cerca a Reingeniera de los Procesos del Negocio (Business Process
Reengineering).
3. Finalmente, la estrategia de diseo ideal para un data warehousing es
generalmente de afuera hacia adentro (outside-in) a diferencia de arriba hacia
abajo (top-down).
A pesar que el diseo del data warehouse es diferente al usado en los diseos
tradicionales, no es menos importante. El hecho que los usuarios finales tengan
dificultad en definir lo que ellos necesitan, no lo hace menos necesario. En la
prctica, los diseadores de data warehouses tienen que usar muchos "trucos" para
ayudar a sus usuarios a "visualizar" sus requerimientos. Por ello, son esenciales los
prototipos de trabajo.
1.4 Estrategias para la Gestion de un Data Warehouse

Los data warehouses requieren una comercializacin y gestin muy cuidadosa. Debe
considerarse lo siguiente:
1. Un data warehouse es una inversin buena slo si los usuarios finales

realmente pueden conseguir informacin vital ms rpida y ms barata de lo
que obtienen con la tecnologa actual.
Como consecuencia, la gestin tiene que pensarse seriamente sobre cmo
quieren sus depsitos para su eficaz desempeo y cmo conseguirn llegar a
los usuarios finales.
2. La administracin debe reconocer que el mantenimiento de la estructura del
data warehouse es tan crtico como el mantenimiento de cualquier otra
aplicacin de misin crtica.
De hecho, la experiencia ha demostrado que los data warehouses llegarn a ser
rpidamente uno de los sistemas ms usados en cualquier organizacin.
3. La gestin debe comprender tambin que si se embarcan sobre un programa
data warehousing, se crearn nuevas demandas sobre sus sistemas
operacionales, que son:
{ Demandas para mejorar datos
{ Demandas para una data consistente
{ Demandas para diferentes tipos de datos, etc.
2 Desarrollo
2.1 Porque Construir Bloques de Data Warehouse?
Para ampliar un negocio, se necesita que la informacin sea comprensible. Para
muchas compaas, esto significa un gran data warehouse que muestre, junto a los
datos no filtrados y dispersos, nuevas formas creativas de presentacin.
Las herramientas para capturar y explorar los datos al detalle evolucionan, as como
nuestra capacidad para encontrar las formas de explotar los datos recolectados.
En los ltimos 10 aos se han combinado dos factores para ayudar a la difusin de
los data warehouses. Ellos son:
1. Se ha reconocido los beneficios del procesamiento analtico en lnea (On Line

Analytical Processing - OLAP), ms all de las reas tradicionales de marketing
y finanzas.
Las organizaciones saben que los conocimientos inmersos en las masas de
datos que rutinariamente recogen sobre sus clientes, productos, operaciones y
actividades comerciales, contribuyen a reducir los costos de operacin y
aumentar las rentas, por no mencionar que es ms fcil la toma de decisiones
estratgicas.
2. El crecimiento de la computacin cliente/servidor, ha creado servidores de
hardware y software ms poderosos y sofisticados que nunca. Los servidores de
hoy compiten con las mainframes de ayer y ofrecen arquitecturas de memoria
tecnolgicamente superiores, procesadores de alta velocidad y capacidades de
almacenamiento masivas.
Al mismo tiempo, los Sistemas de Gestin de Base de Datos (Data Base
Management Systems - DBMS(s)) modernos, proporcionan mayor soporte para
las estructuras de datos complejas.
De esta renovacin de hardware y software surgen los data warehouses
multiterabyte que ahora se ve en ambientes de cliente/servidor.
2.2 Consideraciones Previas al Desarrollo de un Data

Warehouse
Hay muchas maneras para desarrollar data warehouses como tantas organizaciones
existen. Sin embargo, hay un nmero de dimensiones diferentes que necesitan ser
consideradas:
z Alcance de un data warehouse

z Redundancia de datos
z Tipo de usuario final
La Figura N 15 muestra un esquema bidimensional para analizar las opciones

bsicas. La dimensin horizontal indica el alcance del depsito y la vertical muestra
la cantidad de datos redundantes que deben almacenarse y mantenerse.
2.2.1 Alcance des Data Warehouse
El alcance de un data warehouse puede ser tan amplio como toda la informacin
estratgica de la empresa desde su inicio, o puede ser tan limitado como un data
warehouse personal para un solo gerente durante un ao.
En la prctica, en la amplitud del alcance, el mayor valor del data warehouse es para
la empresa y lo ms caro y consumidor de tiempo es crear y mantenerlo. Como
consecuencia de ello, la mayora de las organizaciones comienzan con data
warehouses funcionales, departamentales o divisionales y luego los expanden como
usuarios que proveen retroalimentacin.
2.2.2 Redundancia de Datos
Hay tres niveles esenciales de redundancia de datos que las empresas deberan
considerar en sus opciones de data warehouse:
z Data warehouses "virtual" o "Point to Point"

z Data warehouses "centrales"
z Data warehouses "distribuidos"
No se puede pensar en un nico enfoque. Cada opcin adapta un conjunto especfico

de requerimientos y una buena estrategia de almacenamiento de datos, lo constituye
la inclusin de las tres opciones.
Data Warehouses "Virtual" o "Point to Point"
Una estrategia de data warehouses virtual, significa que los usuarios finales pueden
acceder a bases de datos operacionales directamente, usando cualquier herramienta
que posibilite "la red de acceso de datos".
Este enfoque provee flexibilidad as como tambin la cantidad mnima de datos

redundantes que deben cargarse y mantenerse. Adems, se pueden colocar las
cargas de consulta no planificadas ms grandes, sobre sistemas operacionales.
Como se ver, el almacenamiento virtual es, frecuentemente, una estrategia inicial,

en organizaciones donde hay una amplia (pero en su mayor parte indefinida)
necesidad de conseguir la data operacional, desde una clase relativamente grande de
usuarios finales y donde la frecuencia probable de pedidos es baja.
Los depsitos virtuales de datos proveen un punto de partida para que las
organizaciones determinen qu usuarios finales estn buscando realmente.
Data Warehouses "Centrales"
El concepto de data warehouses centrales es el concepto inicial que se tiene del data
warehouse. Es una nica base de datos fsica, que contiene todos los datos para un
rea funcional especfica, departamento, divisin o empresa.
Los data warehouses centrales se seleccionan por lo general donde hay una
necesidad comn de los datos informticos y un nmero grande de usuarios finales
ya conectados a una red o computadora central. Pueden contener datos para
cualquier perodo especfico de tiempo. Comnmente, contienen datos de sistemas
operacionales mltiples.
Los data warehouses centrales son reales. Los datos almacenados en el data
warehouse son accesibles desde un lugar y deben cargarse y mantenerse sobre una
base regular. Normalmente se construyen alrededor de RDBMS avanzados o, en
alguna forma, de servidor de base de datos informtico multidimensional.
Data Warehouses Distribuidos
Los data warehouses distribuidos son aquellos en los cuales ciertos componentes del
depsito se distribuyen a travs de un nmero de bases de datos fsicas diferentes.
Cada vez ms, las organizaciones grandes estn tomando decisiones a niveles ms
inferiores de la organizacin y a la vez, llevando los datos que se necesitan para la
toma de decisiones a la red de rea local (Local Area Network - LAN) o computadora
local que sirve al que toma decisiones.
Los data warehouses distribuidos comnmente involucran la mayora de los datos

redundantes y como consecuencia de ello, se tienen procesos de actualizacin y
carga ms complejos.
2.2.3 Tipo de Usuario Final
De la misma forma que hay una gran cantidad de maneras para organizar un data
warehouse, es importante notar que tambin hay una gama cada vez ms amplia de
usuarios finales.
En general, se puede considerar tres grandes categoras:
z Ejecutivos y gerentes
z "Power users" o "Buzo de Informacin" (analistas financieros y de negocios,
ingenieros, etc.)
z Usuarios de soporte (de oficina, administrativos, etc.).
Cada una de estas categoras diferentes de usuario tienen su propio conjunto de

requerimientos para los datos, acceso, flexibilidad y facilidad de uso.
2.3 Elementos Claves para el Desarrollo de un Data

Warehouse
Los data warehouses exitosos comienzan cuando se escogen e integran
satisfactoriamente tres elementos claves.
Un data warehouse est integrado por un servidor de hardware y los DBMS que
conforman el depsito. Del lado del hardware, se debe combinar la configuracin de
plataformas de los servidores, mientras se decide cmo aprovechar los saltos casi
constantes de la potencia del procesador. Del lado del software, la complejidad y el
alto costo de los DBMSes fuerzan a tomar decisiones drsticas y balances
comparativos inevitables, con respecto a la integracin, requerimientos de soporte,
desempeo, eficiencia y confiabilidad.
Si se escoge incorrectamente, el data warehouse se convierte en una gran empresa

con problemas difciles de trabajar en su entorno, costoso para arreglar y difcil de
justificar.
Para conseguir que la implementacin del depsito tenga un inicio exitoso, se

necesita enfocar hacia tres bloques claves de construccin:
z Arquitectura total del depsito

z Arquitecturas del servidor
z Sistemas de Gestin de Base de Datos
A continuacin se presentan algunas recomendaciones para tomar las correctas

elecciones para su empresa.
2.3.1 Diseo de la Arquitectura
Arquitectura del Depsito
El desarrollo del data warehouse comienza con la estructura lgica y fsica de la base
de datos del depsito ms los servicios requeridos para operar y mantenerlo. Esta
eleccin conduce a la seleccin de otros dos tems fundamentales: el servidor de
hardware y el DBMS.
La plataforma fsica puede centralizarse en una sola ubicacin o distribuirse regional,

nacional o internacionalmente. A continuacin se dan las siguientes alternativas de
arquitectura:
1. Un plan para almacenar los datos de su compaa, que podra obtenerse desde
fuentes mltiples internas y externas, es consolidar la base de datos en un data
warehouse integrado. El enfoque consolidado proporciona eficiencia tanto en la
potencia de procesamiento como en los costos de soporte. (Ver Figura N 16).
2. La arquitectura global distribuye informacin por funcin, con datos financieros
sobre un servidor en un sitio, los datos de comercializacin en otro y los datos
de fabricacin en un tercer lugar. (Ver Figura N 17)
3. Una arquitectura por niveles almacena datos altamente resumidos sobre una
estacin de trabajo del usuario, con resmenes ms detallados en un segundo
servidor y la informacin ms detallada en un tercero.
La estacin de trabajo del primer nivel maneja la mayora de los pedidos para
los datos, con pocos pedidos que pasan sucesivamente a los niveles 2 y 3 para
la resolucin.
Las computadoras en el primer nivel pueden optimizarse para usuarios de carga
pesada y volumen bajo de datos, mientras que los servidores de los otros
niveles son ms adecuados para procesar los volmenes pesados de datos,
pero cargas ms livianas de usuario. (Ver figura N 18).
Arquitectura del servidor
Al decidir sobre una estructura de depsito distribuida o centralizada, tambin se

necesita considerar los servidores que retendrn y entregarn los datos. El tamao
de su implementacin (y las necesidades de su empresa para escalabilidad,
disponibilidad y gestin de sistemas) influir en la eleccin de la arquitectura del
servidor.
1 Servidores de un solo procesador
Los servidores de un slo procesador son los ms fciles de administrar, pero ofrecen
limitada potencia de procesamiento y escalabilidad. Adems, un servidor slo
presenta un nico punto de falla, limitando la disponibilidad garantizada del depsito.
Se puede ampliar un solo servidor de redes mediante arquitecturas distribuidas que

hacen uso de subproductos, tales como Ambientes de Computacin Distribuida
(Distributed Computing Environment - DCE) o Arquitectura Broker de Objeto Comn
(Common Objects Request Broker Architecture - CORBA), para distribuir el trfico a
travs de servidores mltiples.
Estas arquitecturas aumentan tambin la disponibilidad, debido a que las
operaciones pueden cambiarse al servidor de copia de seguridad si un servidor falla,
pero la gestin de sistemas es ms compleja.
2 Multiprocesamiento simtrico
Las mquinas de multiprocesamiento simtrico (Symmetric MultiProcessing - SMP)

aumentan mediante la adicin de procesadores que comparten la memoria interna
de los servidores y los dispositivos de almacenamiento de disco.
Se puede adquirir la mayora de SMP en configuraciones mnimas (es decir, con dos
procesadores) y levantar cuando es necesario, justificando el crecimiento con las
necesidades de procesamiento. La escalabilidad de una mquina SMP alcanza su
lmite en el nmero mximo de procesadores soportados por los mecanismos de
conexin (es decir, el backplane y bus compartido).
3 Procesamiento en paralelo masivo
Una mquina de procesamiento en paralelo masivo (Massively Parallel Processing -

MPP), conecta un conjunto de procesadores por medio de un enlace de banda ancha
y de alta velocidad. Cada nodo es un servidor, completo con su propio procesador
(posiblemente SMP) y memoria interna. Para optimizar una arquitectura MPP, las
aplicaciones deben ser "paralelizadas" es decir, diseadas para operar por separado,
en partes paralelas.
Esta arquitectura es ideal para la bsqueda de grandes bases de datos. Sin embargo,
el DBMS que se selecciona debe ser uno que ofrezca una versin paralela. Y an
entonces, se requiere un diseo y afinamiento esenciales para obtener una ptima
distribucin de los datos y prevenir "hot spots" o "data skew" (donde una cantidad
desproporcionada del procesamiento es cambiada a un nodo de procesamiento,
debido a la particin de los datos bajo su control).
4 Acceso de memoria no uniforme
La dificultad de mover aplicaciones y los DBMS a agrupaciones o ambientes

realmente paralelos ha conducido a nuevas y recientes arquitecturas, tales como el
acceso de memoria no uniforme (Non Uniform Memory Access - NUMA).
NUMA crea una sola gran mquina SMP al conectar mltiples nodos SMP en un solo
(aunque fsicamente distribuida) banco de memoria y un ejemplo nico de OS. NUMA
facilita el enfoque SMP para obtener los beneficios de performance de las grandes
mquinas MPP (con 32 o ms procesadores), mientras se mantiene las ventajas de
gestin y simplicidad de un ambiente SMP estndar.
Lo ms importante de todo, es que existen DBMS y aplicaciones que pueden

moverse desde un solo procesador o plataforma SMP a NUMA, sin modificaciones.
2.3.2 Sistemas de Gestin de Bases de Datos
Los data warehouses (conjuntamente con los sistemas de soporte de decisin
[Decision Support Systems - DSS] y las aplicaciones cliente/servidor), fueron los
primeros xitos para el DBMS relacional (Relational Data Base Management Systems
- RDBMS).
Mientras la gran parte de los sistemas operacionales fueron resultados de

aplicaciones basadas en antiguas estructuras de datos, los depsitos y sistemas de
soporte de decisiones aprovecharon el RDBMS por su flexibilidad y capacidad para
efectuar consultas con un nico objetivo concreto.
Los RDBMS son muy flexibles cuando se usan con una estructura de datos
normalizada. En una base de datos normalizada, las estructuras de datos son no
redundantes y representan las entidades bsicas y las relaciones descritas por los
datos (por ejemplo productos, comercio y transaccin de ventas). Pero un
procesamiento analtico en lnea (OLAP) tpico de consultas que involucra varias
estructuras, requiere varias operaciones de unin para colocar los datos juntos.
La performance de los RDBMS tradicionales es mejor para consultas basadas en

claves ("Encuentre cuenta de cliente #2014") que para consultas basadas en el
contenido ("Encuentre a todos los clientes con un ingreso sobre $ 10,000 que hayan
comprado un automvil en los ltimos seis meses").
Para el soporte de depsitos a gran escala y para mejorar el inters hacia las
aplicaciones OLAP, los proveedores han aadido nuevas caractersticas al RDBMS
tradicional. Estas, tambin llamadas caractersticas super relacionales, incluyen el
soporte para hardware de base de datos especializada, tales como la mquina de
base de datos Teradata.
Los modelos super relacionales tambin soportan extensiones para almacenar

formatos y operaciones relacionales (ofrecidas por proveedores como REDBRICK) y
diagramas de indexacin especializados, tales como aquellos usados por SYBASE IQ.
Estas tcnicas pueden mejorar el rendimiento para las recuperaciones basadas en el
contenido, al pre juntar tablas usando ndices o mediante el uso de listas de ndice
totalmente invertidos.
Muchas de las herramientas de acceso a los data warehouses explotan la naturaleza

multidimensional del data warehouse. Por ejemplo, los analistas de marketing
necesitan buscar en los volmenes de ventas por producto, por mercado, por perodo
de tiempo, por promociones y niveles anunciados y por combinaciones de estos
diferentes aspectos.
La estructura de los datos en una base de datos relacional tradicional, facilita

consultas y anlisis a lo largo de dimensiones diferentes que han llegado a ser
comunes. Estos esquemas podran usar tablas mltiples e indicadores para simular
una estructura multidimensional. Algunos productos DBMS, tales como ESSBASE y
GENTIUM, implementan tcnicas de almacenamiento y operadores que soportan
estructuras de datos multidimensionales.
Mientras las bases de datos multidimensionales (MultiDimensional Databases -
MDDBs) ayudan directamente a manipular los objetos de datos multidimensionales
(por ejemplo, la rotacin fcil de los datos para verlos entre dimensiones diferentes,
o las operaciones de drill down que sucesivamente exponen los niveles de datos ms
detallados), se debe identificar estas dimensiones cuando se construya la estructura
de la base de datos. As, agregar una nueva dimensin o cambiar las vistas
deseadas, puede ser engorroso y costoso. Algunos MDDBS requieren un recargue
completo de la base de datos cuando ocurre una reestructuracin.
2.3.3 Nuevas Dimensiones
Una limitacin de un RDBMS y un MDDB, es la carencia de soporte para tipos de

datos no tradicionales como imgenes, documentos y clips de vdeo / audio. Si usted
necesita estos tipos de objetos en su data warehouse, busque un DBMS relacional -
objeto (Ejemplo: ILLUSTRA de INFORMIX).
Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de
base de datos pueden acomodar estos tipos de datos, slo con extensiones basadas
en cierta referencias, tales como indicadores de archivos que contienen los objetos.
Muchos RDBMS almacenan los datos complejos como objetos grandes binarios
(Binary Large Objects - BLOBs). En este formato, los objetos no pueden ser
indexados, clasificados, o buscados por el servidor.
Los DBMS relacional - objeto, de otro lado, almacenan los datos complejos como
objetos nativos y pueden soportar las grandes estructuras de datos encontradas en
un ambiente orientado a objetos. Estos sistemas de base de datos naturalmente
acomodan no slo tipos de datos especiales sino tambin los mtodos de
procesamiento que son nicos para cada uno de ellos.
Pero una desventaja del enfoque relacional - objeto, es que la encapsulacin de los
datos dentro de los tipos especiales de datos (una serie de precios de stock a travs
del tiempo en cada registro de una tabla de stock, por ejemplo), requiere de
operadores especializados para que hagan bsquedas simples previamente (por
ejemplo, "Encontrar todas las existencias que han mostrado una disminucin en el
precio de Abril a Mayo 1996").
La seleccin del DBMS est tambin sujeta al servidor de hardware que se usa.
Algunos RDBMS, como el DB2 Paralelo, INFORMIX XPS y el ORACLE Paralelo, ofrecen
versiones que soportan operaciones paralelas. El software paralelo divide consultas,
uniones a travs de procesadores mltiples y corre estas operaciones
simultneamente para mejorar la performance.
Se requiere el paralelismo para el mejor desempeo en los servidores MPP grandes y

SMP agrupados. No es an una opcin con MDDBS o DBMS relacional - objeto.
En la tabla "Cmo comparar DBMS" se resume los pro y los contra de los diferentes
tipos de DBMS para operaciones de data warehouse.
La tabla "Matriz de Decisin del Data Warehouse" contiene algunos ejemplos de

cmo afectan estos criterios de decisin en la eleccin de una arquitectura de
Data Warehousing: Proyecto Pgina 16 de 19
ms disperso fuerte SMP soporte

informtica Web
Alcance: RDBMS
departamental Pequea - pocas Central con
Centralizado MPP
Usos: ubicaciones fuerte soporte
investigacin paralelo
2.3.4 Combinacion de la Arquitectura con el Sistema de Gestion de Bases de

Datos
Para seleccionar la combinacin correcta de la arquitectura del servidor y el DBMS,

primero es necesario comprender los requerimientos comerciales de su compaa, su
poblacin de usuarios y las habilidades del personal de soporte.
Las implementaciones de los data warehouses varan apreciablemente de acuerdo al

rea. Algunos son diseados para soportar las necesidades de anlisis especfico
para un solo departamento o rea funcional de una organizacin, tales como
finanzas, ventas o marketing. Las otras implementaciones renen datos a travs de
toda la empresa para soportar una variedad de grupos de usuarios y funciones. Por
regla general, a mayor rea del depsito, se requiere mayor potencia y funcionalidad
del servidor y el DBMS.
Los modelos de uso de los data warehouses son tambin un factor. Las consultas y
vistas de reportes preestructuradas frecuentemente satisfacen a los usuarios
informticos, mientras que hay menos demandas sobre el DBMS y la potencia de
procesamiento del servidor. El anlisis complejo, que es tpico de los ambientes de
decisin - soporte, requiere ms poder y flexibilidad de todos los componentes del
servidor. Las bsquedas masivas de grandes data warehouses favorecen el
paralelismo en el DBMS y el servidor.
Los ambientes dinmicos, con sus requerimientos siempre cambiantes, se adaptan

mejor a una arquitectura de datos simple, fcilmente cambiable (por ejemplo, una
estructura relacional altamente normalizada), antes que una estructura intrincada
que requiere una reconstruccin despus de cada cambio (por ejemplo, una
estructura multidimensional).
El valor de la data fresca requerida indica cun importante es para el data warehouse
renovar y cambiar los datos. Los grandes volmenes de datos que se refrescan a
intervalos frecuentes, favorecen una arquitectura fsicamente centralizada para
soportar una captura de datos eficiente y minimizar el tiempo de transporte de los
datos.
Un perfil de usuario debera identificar quines son los usuarios de su data

warehouse, dnde se ubican y cuntos necesita soportar. La informacin sobre cmo
cada grupo espera usar los data warehouses, ayudar a analizar los diversos estilos
servidor/ data warehouse.
Cmo comparar DBMSES?

Super Multidimensional Multidimensiona
Caractersticas/Funcin Relacional
Relacional (Lgico) (Fsico)
Estructuras
Normalizadas
Tipos de datos
abstractos
Paralelismo
Estructuras
Multidimensionales
Drill-Down
Rotacin
Operaciones
dependientes de datos
Matriz de Decisin para el Data Warehouse

Para estos ambientes Elija
Soporte
Requerimientos
Usuarios de Arquitectura Servidor DBMS
comerciales
Sistemas
Alcance: Local
departamental Procesador
Pequea - mnimo - Consolidado
nico o MDDB
Usos: anlisis ubicacin nica central - paquete
SMP
de datos promedio
Alcance: Grande
Seccionado Grupos de RDBMS
departamental Analistas en una Local
- detalle en SMP para para
sola ubicacin; mnimo -
Usos: anlisis central - central; central -
usuarios central
ms resumen en SP o SMP MDDB
informticos promedio
informtica local para local para local
dispersos
Alcance:
empresa Centralizado
Grande; Objeto-
Usos: anlisis geogrficamente Central Grupos de relacional-
de uso.
Conocer la ubicacin fsica de sus usuarios ayudar a determinar cmo y a qu rea

necesita distribuir el data warehouse. Una arquitectura por niveles podra usar
servidores en el lugar de las redes de rea local. O puede necesitar un enfoque
centralizado para soportar a los trabajadores que se movilizan y que trabajan en el
depsito desde sus laptops.
El nmero total de usuarios y sus modelos de conexin determinan el tamao de sus

servidores de depsito. Los tamaos de memoria y los canales de I/O deben soportar
el nmero previsto de usuarios concurrentes bajo condiciones normales, as como
tambin en las horas punta de su organizacin.
Finalmente, se debe factorizar la sofisticacin del personal de soporte. Los recursos

de los sistemas de informacin (Information System - IS) que estn disponibles
dentro de su organizacin, pueden limitar la complejidad o sofisticacin de la
arquitectura del servidor. Sin el personal especializado interno o consultores
externos, es difcil de crear y mantener satisfactoriamente una arquitectura que
requiere paralelismo en la plataforma del servidor (MPP o SMP agrupado, por
ejemplo).
2.3.5 Planes de Expansion
Como su depsito evoluciona y los datos que contiene llegan a ser ms accesible, los
empleados externos al depsito podran descubrir tambin el valor de sus datos. Al
enlazar su data warehouse a otros sistemas (tanto internos como externos a la
organizacin), se puede compartir informacin con otras entidades comerciales con
poco o sin desarrollo. Los mensajes de correo electrnico, servidores WEB y
conexiones Intranet/Internet, pueden entregar listas por niveles a sus proveedores o
segn su condicin, a sus socios de negocio.
Como los data warehouses continan creciendo en sofisticacin y uso, los datos
acumulados dentro de una empresa llegarn a ser ms organizados, ms
interconectados, ms accesibles y, en general, ms disponibles a ms empleados.
El resultado ser la obtencin de mejores decisiones en el negocio, ms

oportunidades y ms claridad de trabajo.
2.4 Confiabilidad de los Datos

La data "sucia" es peligrosa. Las herramientas de limpieza especializadas y las
formas de programar de los clientes proporcionan redes de seguridad.
No importa cmo est diseado un programa o cun hbilmente se use. Si se

alimenta mala informacin, se obtendr resultados incorrectos o falsos.
Desafortunadamente, los datos que se usan satisfactoriamente en las aplicaciones de
lnea comercial operacionales pueden ser basura en lo que concierne a la aplicacin
data warehousing.
Los datos "sucios" pueden presentarse al ingresar informacin en una entrada de

datos (por ejemplo, "Sistemas S. A." en lugar de "Sistemas S. A.") o de otras
causas. Cualquiera que sea, la data sucia daa la credibilidad de la implementacin
del depsito completo. A continuacin, en la Figura N 23 se muestra un ejemplo de
formato de ventas en el que se pueden presentar errores.
Afortunadamente, las herramientas de limpieza de datos pueden ser de gran ayuda.

En algunos casos, puede crearse un programa de limpieza efectivo. En el caso de
bases de datos grandes, imprecisas e inconsistentes, el uso de las herramientas
comerciales puede ser casi obligatorio.
Decidir qu herramienta usar es importante y no solamente para la integridad de los
datos. Si se equivoca, se podra malgastar semanas en recursos de programacin o

cientos de miles de dlares en costos de herramientas.
La limpieza de una data "sucia" es un proceso multifactico y complejo. Los pasos a

seguir son los siguientes:
1. Analizar sus datos corporativos para descubrir inexactitudes, anomalas y otros

problemas.
2. Transformar los datos para asegurar que sean precisos y coherentes.
3. Asegurar la integridad referencial, que es la capacidad del data warehouse,
para identificar correctamente al instante cada objeto del negocio, tales como
un producto, un cliente o un empleado.
4. Validar los datos que usa la aplicacin del data warehouse
Generalidades: Arquitecturas Pgina 1 de 2
Arquitecturas
Bases de Datos-Arquitecturas
1. Cliente / Servidor
2. Motor Distribuido
3. Componentes Distribuidos
En muchas ocasiones, despus de haber realizado un gran estudio detallado del

SGBD y haber revisado su diseo, nos podemos encontrar que ha implementado
sobre un equipo con insuficientes recursos o no se ha seleccionado la arquitectura
adecuada para su explotacin. Entre otras arquitecturas, caben destacar las
siguientes:
Cliente / Servidor
Esta arquitectura consta de un cliente inteligente que puede solicitar servicios de un
servidor en red. En el lado del cliente de esta arquitectura encontramos una
aplicacin frontal bastante sencilla ejecutndose en un ordenador personal. A una
aplicacin cliente / servidor se le puede pedir que realice validaciones o que muestre
listas de opciones vlidas, pero la mayor parte de las reglas de integridad de los
datos y de negocio se imponen en la propia base de datos: relaciones, ndices,
valores predeterminados, rangos, disparadores, procedimientos almacenados, etc.
En el lado del servidor encontramos un motor de servidor de bases de datos
inteligente. El servidor est diseado para aceptar consultas SQL desde la aplicacin
frontal, generalmente en forma de llamadas a procedimientos almacenados que
devuelven conjunto de resultados claramente definidos y de mbito limitado.
Generalmente, la aplicacin cliente es responsable, al menos, de la administracin de

la conexin, la captura de los datos, la presentacin de datos y la administracin de
los errores.
El servidor es el responsable de la administracin inteligente de los recursos, la

administracin de la seguridad, la administracin de los datos, de las consultas y
sobre todo de la integridad de los datos.
Motor Distribuido
En este caso, cada uno de los clientes posee el motor necesario para acceder a la
base de datos y acceden de forma independiente del resto de los usuarios. Esta
arquitectura tiene la ventaja del aprovechamiento de los recursos del cliente pero la
desventaja del control de versiones.
Generalidades: Arquitecturas Pgina 2 de 2
Componentes Distribuidos
Esta arquitectura aade un tercer elemento al sistema de acceso a la base de datos,
se trata de los objetos de lgica de negocio, encargados de procesar las peticiones
de los clientes y hacrselas llegar al servidor. Estos objetos pueden estar instalados
en mquinas diferentes a la del cliente y del servidor. La principal ventaja radica en
el aprovechamiento de los servicios cliente / servidor y en asegurar el control de las
versiones del motor de acceso a datos. La aplicacin frontal realiza peticiones a los
objetos de lgica de negocio que son trasmitidas al servidor, la respuestas del mismo
llegan a los objetos y stos las devuelven al cliente.
Generalidades: Cursores y Buffers Pgina 1 de 4
Cursores y Buffers
Generalidades-Cursores y Buffers
Bsicamente, un cursor es un conjunto de punteros a las filas devueltas por una

consulta, la mayora, son como un conjunto de resultados, excepto por que los datos
reales generalmente permanecen en el servidor.
Un buffer es un depsito RAM en el lado del cliente donde se guardan los datos del
conjunto de resultados de manera temporal hasta que pueden llevarse a otro lugar
para su almacenamiento.
Las columnas de datos de una o varias filas se dice que son miembros del cursor si la
clusula WHERE de la consulta las incluye. Esta columnas, combinadas en filas
lgicas se convierten en filas miembro del conjunto de resultados.
Por ejemplo:
SELECT
Nombre, Genero
FROM
Animales
WHERE
Edad < 10
Cuando se ejecuta esta consulta, el motor cliente empieza inmediatamente a

seleccionar miembros para el conjunto de resultados. En este caso son todos los
animales menores de diez aos.
Si no es necesaria una ordenador, el SGDB pasa las primeras filas de este conjunto
de resultados de vuelta a la estacin de trabajo nada ms capturarlas y despus
detiene el procesamiento hasta que la estacin recupera las filas capturadas, una vez
recuperadas el gestor de datos pasa ms filas y as sucesivamente. Debido a este
proceso, si otros usuarios estn actualizando la base de datos, hay posibilidades que
se aada otra fila que cumpla las condiciones del conjunto de resultados; en este
caso la fila aadida pasa a ser miembro del conjunto y es recuperada por la estacin
de trabajo. Tambin existe la posibilidad de la eliminacin o modificacin de una fila,
en estos casos, si la fila no ha sido enviada a la estacin de trabajo o no se enva o
se enva modificada; pero siempre cabe la posibilidad de que la estacin de trabajo
haya ledo una fila que ya no existe o que haya sido modificada por otro usuario.
Estas actualizaciones no se incluirn en el conjunto de resultados si la estacin de
trabajo ha comenzado a procesar los resultados.
El proceso de relleno del cursor finaliza cuando el gestor de datos ha determinado
cual es la ltima fila del conjunto de resultados y se considera completamente

relleno cuando la estacin de trabajo ha capturado la ltima fila, en este momento
cuando se conoce el nmero de filas que componen el cursor. Por este motivo los
mtodos o propiedades que informan del nmero de filas devueltas o afectadas no
son reales hasta que el cursos no se rellenado completamente.
Ubicacin de los cursores

Como ya se ha comentado un cursor es un conjunto de punteros a un conjunto de
resultados. Estos punteros pueden estar ubicados en el servidor o en la estacin de
trabajo, originando dos tipos de cursores, los cursores del lado del cliente y los
cursores del lado del servidor. Pero no todos los gestores de datos permiten crear
cursores en el lado del servidor, slo se pueden crear con aquellos gestores que
tengan comportamiento cliente / servidor.
Las ventajas e inconvenientes de cada tipo de cursor es muy variable y depende

siempre de la explotacin que se desee hacer de los datos, de la topologa de la red
y de los equipos empleados. En general los cursores en el lado del servidor reducen
los tiempos de acceso a los datos y mejoran el desplazamiento por el conjunto de
resultados, si embargo consumen ms cantidad de recursos de servidor y de red.
Tipos de cursores
Conjuntos de resultados sin cursor
Con un conjunto de resultados sin cursor las filas de datos pasan al frontal para su
procesamiento. Este el sistema ms rpido para llevar los datos desde el servidor al
cliente, pero no ofrece los beneficios del cursor, por que, si bien algunos son
actualizables, a menudo no lo son y hay que controlar el proceso desde el frontal
para controlar las modificaciones.
Cursores desplazables
Uno de los aspectos ms costosos de la administracin de los cursores es dar soporte
a la capacidad de desplazamiento. Esta capacidad significa que, una vez ejecutada
una consulta, un cursor desplazable permite la colocacin en cualquier fila del
conjunto de resultados. Estos mtodos de reubicacin son costosos en el sentido que
consumen recursos del sistema. Para aumentar el rendimiento se aconseja limitar los
cursores y seleccionar los no desplazables.
Cursores de slo avance

Este tipo de cursor slo permite utilizar los mtodos para desplazarse avanzando por
las filas del conjunto de resultados, no permiten el retroceso por las mismas. En este
caso el gestor de datos enviar las filas del conjunto de resultados tan rpido como
le sea posible.
Cursores estticos
Un cursor esttico proporciona la capacidad de direccionamiento por todo el conjunto
de resultados generando una copia en la estacin de trabajo de las filas devueltas,
todos los trabajos realizados sobre este conjunto de resultados afectar nicamente
a la copia local. Por su naturaleza este cursor necesita de un espacio de
almacenamiento en el cliente. Este cursor no es la mejor opcin para datos que
cambian constantemente, pero para tablas de bsqueda cuyos valores no es
probable que cambien, este cursor tiene mucho sentido.
Cursores de conjunto de claves

Un cursor de conjunto de claves, u hoja de respuesta dinmica, almacena un
conjunto de claves, bsicamente un conjunto de punteros, y permite volver a
capturar una fila seleccionada de acuerdo con la informacin especfica de la fila
almacenada en dichas claves. Estos cursores necesitan espacio de almacenamiento
independiente para los datos de cada una de las claves que lo componen. Cualquier
cambio o modificacin sobre una fila del conjunto de resultados por parte de
cualquier usuario es reflejado en cualquier estacin de trabajo al leer la informacin
de dicha fila.
Cursores dinmicos
Al igual que en los dos casos anteriores, un cursor dinmico almacena un bloque de
claves. Sin embargo, con este tipo de cursor, la consulta que se ha utilizado para
generar el conjunto de resultados se vuelve a ejecutar constantemente siempre que
se hace referencia al cursor. Debido a esta actividad repetida, los cursores dinmicos
consumen gran cantidad de recursos, pero poseen la gran ventaja que jams cierran
la pertenencia o no pertenencia de las filas al conjunto de resultados. En los dos
casos anteriores una vez rellenado el cursor no se admite la inclusin o exclusin de
filas.
Cursores de slo lectura

Todos los tipos de cursores citados admiten la posibilidad de slo lectura, en este
caso ninguna de las filas del conjunto de resultados pueden ser modificadas por la
estacin de trabajo. Este cursor es muy til para la generacin de consultas o
informes en donde se sabe que ningn dato ser modificado. Poseen la ventaja y el
inconveniente de no generar bloqueos sobre las filas consultadas, de tal forma que
cualquier usuario puede editar las filas contenidas en este cursor.
Tipos de buffers
Buffers de una nica fila
Un buffer de una nica fila no es en realidad un cursor, aunque aqu se apliquen las
mismas reglas de pertenencia que se aplican a un cursor de conjunto de claves de
slo avance. Con un buffer de una nica fila slo es posible examinar los datos de la
fila del conjunto de resultados. Las filas anteriores no estn disponibles y la fila
actual no estar accesible despus de pasar a la siguiente fila del conjunto de
resultados.
Buffers de n filas
Un buffer de n filas ampla el mbito y la capacidad de desplazamiento del buffer de
una nica fila. En este caso, a la estacin de trabajo se le expone un nmero
determinado de filas del conjunto de resultados y a la aplicacin se le permite que se
desplace libremente por esas filas.

Basese de Datos y SQL

Cargado por

Información del documento

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

Basese de Datos y SQL

Cargado por

Copyright:

Formatos disponibles

Generalidades: Definiciones Pgina 1 de 2

Generalidades Modelo de datos Modelo relacional El modelo E/R SQL

Generalidades: Definiciones Informticas

Bases de datos-Modelo de datos-Leyes de Murphi

1. Si algo puede salir mal, saldr mal.

Bases de datos-SQL-Funciones-Data Warehousing-Introduccin

La gestin administrativa reconoce que una manera de elevar su eficiencia est en

La razn principal es la manera en que han evolucionado las computadoras, basadas

El data warehouse, es actualmente, el centro de atencin de las grandes

Un data warehouse es una coleccin de datos en la cual se encuentra integrada la

Reunir los elementos de datos apropiados desde diversas fuentes de aplicacin en un

Las aplicaciones para soporte de decisiones basadas en un data warehousing,

Un data warehouse se crea al extraer datos desde una o ms bases de datos de

La innovacin de la Tecnologa de Informacin dentro de un ambiente data

Funciones-Data Warehousing-Aspectos Tericos

1. Introduccin al Concepto Data

Un Data Warehouse o Depsito de Datos es una coleccin de datos orientado a

Se puede caracterizar un data warehouse haciendo un contraste de cmo los datos

Base de Datos Operacional Data Warehouse

El ingreso de datos en el data warehouse viene desde el ambiente operacional en

Destacan entre estos sistemas: los Sistemas de Informacin Gerencial (MIS),

Sistemas Tcticos, diseados para soportar las actividades de coordinacin de

Destacan entre ellos: los Sistemas Ofimticos (OA), Sistemas de Transmisin de

Sistemas Tcnico - Operativos, que cubren el ncleo de operaciones tradicionales

Sistemas Interinstitucionales, este ltimo nivel de sistemas de informacin recin

2.1 Sistemas Tcnico - Operacionales

Debido a su volumen e importancia en la organizacin, los sistemas operacionales

Desde luego, la mayora de las organizaciones grandes de todo el mundo,

2.2 Sistemas de Soporte de Decisiones

Las funciones como "planificacin de marketing", "planeamiento de ingeniera" y

Estos sistemas estn relacionados con el anlisis de los datos y la toma de

Mientras las necesidades de los datos operacionales se enfocan normalmente hacia

3 Caractersticas de un Data Warehouse

3.1 Orientado a Temas

El ambiente operacional se disea alrededor de las aplicaciones y funciones tales

En el ambiente data warehousing se organiza alrededor de sujetos tales como

La alineacin alrededor de las reas de los temas afecta el diseo y la

Las diferencias entre la orientacin de procesos y funciones de las aplicaciones y la

Otra diferencia importante est en la interrelacin de la informacin. Los datos

La integracin de datos se muestra de muchas maneras: en convenciones de

El contraste de la integracin encontrada en el data warehouse con la carencia de

Se diferencian en la codificacin, en las estructuras claves, en sus caractersticas

Codificacin. Los diseadores de aplicaciones codifican el campo GENERO en varias

No importa mucho cmo el GENERO llega al data warehouse. Probablemente "M" y

Medida de atributos. Los diseadores de aplicaciones miden las unidades de

Al dar medidas a los atributos, la transformacin traduce las diversas unidades de

Cualquiera que sea la fuente, cuando la informacin de la tubera llegue al data

Convenciones de Nombramiento. El mismo elemento es frecuentemente referido

Fuentes Mltiples. El mismo elemento puede derivarse desde fuentes mltiples. En

Cualquiera que sea la forma del diseo, el resultado es el mismo - la informacin

Cuando el analista de sistema de soporte de decisiones observe el data warehouse,

Como la informacin en el data warehouse es solicitada en cualquier momento (es

Los datos histricos son de poco uso en el procesamiento operacional. La informacin

El tiempo variante se muestra de varias maneras:

1. La ms simple es que la informacin representa los datos sobre un horizonte

En la Figura N 4 se muestra que la actualizacin (insertar, borrar y modificar), se

Hay algunas consecuencias muy importantes de esta diferencia bsica, entre el

Data Warehousing-Realizacin de un proyecto

1.1 Factores en la Planificacion de un Data Warehouse

A continuacin, se indican algunos puntos claves que deben considerarse en la

Establecer una asociacin de usuarios, gestin y grupos

La gestin puede ayudar a priorizar la fase de la implementacin del data

Seleccionar una aplicacin piloto con una alta probabilidad de xito

Construir prototipos rpida y frecuentemente