W H Inmon-Building The Data Warehouse-EN (001-100)

Machine Translated by Google
Construyendo el
Almacén de datos
Tercera edicion
WH Inmón
Publicación informática de Wiley
John Wiley & Sons, Inc.
NUEVA YORK • CHICHESTER • WEINHEIM • BRISBANE • SINGAPUR • TORONTO
Construyendo el
Almacén de datos
Tercera edicion
Construyendo el
Almacén de datos
Tercera edicion
WH Inmón
Publicación informática de Wiley
John Wiley & Sons, Inc.
NUEVA YORK • CHICHESTER • WEINHEIM • BRISBANE • SINGAPUR • TORONTO
Editorial: Robert Ipsen
Editor: Robert Elliott
Editor de desarrollo: Emilie Herman
Director de redacción: John Atkins
Diseño y composición de texto: MacAllister Publishing Services, LLC
Las designaciones utilizadas por las empresas para distinguir sus productos a menudo se reclaman como marcas comerciales. En todos
los casos en los que John Wiley & Sons, Inc. tenga conocimiento de una reclamación, los nombres de los productos aparecen en
mayúscula inicial o TODAS LAS LETRAS MAYÚSCULAS. Sin embargo, los lectores deben comunicarse con las empresas correspondientes
para obtener información más completa sobre las marcas comerciales y el registro.
Este libro está impreso en papel sin ácido.
Copyright © 2002 por WH Inmon. Reservados todos los derechos.
Publicado por John Wiley & Sons, Inc.
Publicado simultáneamente en Canadá.
Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación o transmitida de ninguna
forma o por ningún medio, ya sea electrónico, mecánico, fotocopiado, grabado, escaneado o de otro modo, excepto según lo
permitido por las Secciones 107 o 108 de la Ley de derechos de autor de los Estados Unidos de 1976. Act, sin el permiso previo por
escrito del editor o la autorización mediante el pago de la tarifa correspondiente por copia al Copyright Clearance Center, 222
Rosewood Drive, Danvers, MA 01923, (978) 7508400, fax (978)
7504744. Las solicitudes de permiso al Editor deben dirigirse al Departamento de Permisos, John Wiley & Sons, Inc., 605 Third
Avenue, New York, NY 101580012, (212) 8506011, fax (212)
8506008, correo electrónico: PERMREQ @ WILEY.COM.
Esta publicación está diseñada para proporcionar información precisa y fidedigna con respecto al tema tratado. Se vende con el
entendimiento de que el editor no se dedica a servicios profesionales. Si se requiere asesoramiento profesional u otra asistencia de
expertos, se deben buscar los servicios de un profesional competente.
Datos de catalogación en publicación de la Biblioteca del Congreso:
ISBN: 0471081302
Impreso en los Estados Unidos de América.
10 9 8 7 6 5 4 3 2 1
Machine Translated by Google A Jeanne Friedman, una amiga para siempre
Prefacio para la segunda edición XIII
Prefacio para la Tercera Edición xiv
Expresiones de gratitud xix
Sobre el Autor XX
Capítulo 1 Evolución de los sistemas de apoyo a las decisiones 1
La evolución 2
El advenimiento de DASD 4
Tecnología PC/4GL 4
Ingrese al programa de extracción 5
La telaraña 6
Problemas con la arquitectura en evolución natural 6
Falta de credibilidad de los datos 6
Problemas con la productividad 9
De los datos a la información 12
Un cambio de enfoque 15
El Entorno Arquitectónico 16
Integración de datos en el entorno diseñado 19
¿Quién es el usuario? 19
El ciclo de vida del desarrollo 21
Patrones de utilización de hardware 22
Preparando el escenario para la reingeniería 23
Supervisión del entorno del almacén de datos 25
Resumen 28
Capítulo 2 El entorno del almacén de datos 31
La estructura del almacén de datos 35
Orientación del tema 36
Día 1Día n Fenómeno 41
granularidad 43
Los beneficios de la granularidad 45
Un ejemplo de granularidad 46
Niveles duales de granularidad 49
viii
Machine Translated by Google Exploración y Minería de Datos 53
Base de datos de muestra viva 53
Particionamiento como un enfoque de diseño 55
Particionamiento de datos 56
Estructuración de datos en el almacén de datos 59
Almacén de datos: el manual de estándares 64
Auditoría y Data Warehouse 64
Justificación de costos 65
Justificación de su almacén de datos 66
Homogeneidad/heterogeneidad de datos 69
Depuración de datos de almacén 72
Informes y el entorno diseñado 73
La ventana de oportunidad operativa 74
Datos incorrectos en el almacén de datos 76
Resumen 77
Capítulo 3 El almacén de datos y el diseño 81
Comenzando con datos operativos 82
Modelos de datos/procesos y el entorno diseñado 87
El almacén de datos y los modelos de datos 89
El modelo de datos del almacén de datos 92
El modelo de datos de nivel medio 94
El modelo de datos físicos 98
El modelo de datos y el desarrollo iterativo 102
Normalización/Desnormalización 102
Instantáneas en el almacén de datos 110
metadatos 113
Gestión de tablas de referencia en un almacén de datos 113
La ciclicidad de los datos: la arruga del tiempo 115
Complejidad de Transformación e Integración 118
Activación del registro del almacén de datos 122
Eventos 122
Componentes de la instantánea 123
Algunos ejemplos 123
Registros de perfil 124
Volumen de gestión 126
Creación de múltiples registros de perfil 127
Machine Translated by Google Pasando del Data Warehouse a lo Operacional
Ambiente 128
Acceso directo a los datos del almacén de datos 129
Acceso indirecto a los datos del almacén de datos 130
Un sistema de cálculo de comisiones de aerolíneas 130
Un sistema de personalización minorista 132
Puntuacion de credito 133
Uso indirecto de los datos del almacén de datos 136
Uniones estrella 137
Apoyando a la ODS 143
Resumen 145
Capítulo 4 Granularidad en el almacén de datos 147
Estimaciones sin procesar 148
Entrada al proceso de planificación 149
¿Datos en desbordamiento? 149
Almacenamiento de desbordamiento 151
Cuáles serán los niveles de granularidad 155
Algunas técnicas de bucle de retroalimentación 156
Niveles de GranularidadEntorno Bancario 158
Resumen 165
Capítulo 5 El almacén de datos y la tecnología 167
Gestión de grandes cantidades de datos 167
Gestión de múltiples medios 169
Datos de índice/supervisión 169
Interfaces para muchas tecnologías 170
Control del programador/diseñador de la ubicación de datos 171
Almacenamiento paralelo/Gestión de datos 171
Gestión de metadatos 171
Interfaz de idioma 173
Carga eficiente de datos 173
Utilización eficiente del índice 175
Compactación de datos 175
Claves compuestas 176
Datos de longitud variable 176
Gestión de bloqueo 176
Machine Translated by Google Procesamiento de solo índice 178
Restauración rápida 178
Otras características tecnológicas 178
Tipos de DBMS y el almacén de datos 179
Cambiar la tecnología DBMS 181
DBMS multidimensional y el almacén de datos 182
Almacenamiento de datos en múltiples medios de almacenamiento 188
Metadatos en el entorno del almacén de datos 189
Contexto y Contenido 192
Tres tipos de información contextual 193
Captura y gestión de información contextual 194
Mirando el pasado 195
Actualización del almacén de datos 195
Pruebas 198
Resumen 198
Capítulo 6 El almacén de datos distribuido 201
Tipos de almacenes de datos distribuidos 202
Almacenes de datos locales y globales 202
El almacén de datos distribuido tecnológicamente 220
El almacén de datos distribuidos en evolución independiente 221
La naturaleza de los esfuerzos de desarrollo 222
Almacenes completamente no relacionados 224
Desarrollo de almacenes de datos distribuidos 226
Coordinación del desarrollo en ubicaciones distribuidas 227
El modelo de datos corporativos distribuidos 228
Metadatos en el almacén distribuido 232
Construyendo el Almacén en Múltiples Niveles 232
Grupos Múltiples Construyendo el Nivel de Detalle Actual 235
Diferentes requisitos en diferentes niveles 238
Otros tipos de datos detallados 239
metadatos 244
Múltiples plataformas para datos de detalles comunes 244
Resumen 245
Capítulo 7 Sistemas de información ejecutiva y almacén de datos 247
EISLa Promesa 248
Un ejemplo sencillo 248
Análisis detallado 251
Machine Translated by Google Apoyo al proceso de profundización 253
El almacén de datos como base para EIS 254
Dónde girar 256
Mapeo de eventos 258
Datos detallados y EIS 261
Mantener solo datos resumidos en el EIS 262
Resumen 263
Capítulo 8 Datos externos/no estructurados y el almacén de datos 265
Datos externos/no estructurados en el almacén de datos 268
Metadatos y datos externos 269
Almacenamiento de datos externos/no estructurados 271
Diferentes componentes de datos externos/no estructurados 272
Modelado y datos externos/no estructurados 273
Informes secundarios 274
Archivar datos externos 275
Comparación de datos internos con datos externos 275
Resumen 276
Capítulo 9 Migración al entorno diseñado 277
Un plan de migración 278
El circuito de retroalimentación 286
Consideraciones estratégicas 287
Metodología y Migración 289
Una metodología de desarrollo basada en datos 291
Metodología basada en datos 293
Ciclos de vida del desarrollo del sistema 294
Una observación filosófica 294
Desarrollo Operativo/Desarrollo DSS 294
Resumen 295
Capítulo 10 El almacén de datos y la web 297
Apoyo al entorno de comercio electrónico 307
Mover datos de la web al almacén de datos 307
Mover datos del almacén de datos a la web 308
Soporte web 309
Resumen 310
Machine Translated by Google Capítulo 11 ERP y el almacén de datos 311
Aplicaciones ERP fuera del almacén de datos 312
Construcción del almacén de datos dentro del entorno ERP 314
Alimentando el almacén de datos a través de ERP y no ERP
Sistemas 314
El almacén de datos corporativo orientado a ERP 318
Resumen 320
Capítulo 12 Lista de verificación de revisión del diseño del almacén de datos 321
Cuándo hacer la revisión del diseño 322
¿Quién debe participar en la revisión del diseño? 323
¿Cuál debería ser la agenda? 323
Los resultados 323
Administración de la revisión Un 324
resumen típico de la revisión del diseño de un 324
almacén de datos 342
Apéndice 343
Glosario 385
Referencia 397
Índice 407
Las bases de datos y la teoría de bases de datos existen desde hace mucho tiempo. Las primeras
versiones de las bases de datos se centraban en una sola base de datos que cumplía todos los
propósitos conocidos por la comunidad de procesamiento de información, desde transacciones
hasta procesamiento por lotes y procesamiento analítico. En la mayoría de los casos, el enfoque
principal de los primeros sistemas de bases de datos era el procesamiento operativo, generalmente
transaccional. En los últimos años, ha surgido una noción más sofisticada de la base de datos:
una que atiende las necesidades operativas y otra que atiende las necesidades informativas o
analíticas. Hasta cierto punto, esta noción más ilustrada de la base de datos se debe a la llegada
de las PC, la tecnología 4GL y el empoderamiento del usuario final.
La división de las bases de datos operativas e informativas se produce por muchas razones:
■■ Los datos que atienden las necesidades operativas son datos físicamente diferentes de los
al servicio de las necesidades informativas o analíticas.
■■ La tecnología de soporte para el procesamiento operativo es fundamentalmente diferente de
la tecnología utilizada para soportar las necesidades analíticas o de información.
■■ La comunidad de usuarios de datos operativos es diferente de la que se sirve de datos
informativos o analíticos.
■■ Las características de procesamiento para el entorno operativo y el
entorno informativo son fundamentalmente diferentes.
Por estas razones (y muchas más), la forma moderna de construir sistemas es separar el
procesamiento y los datos operativos de los informativos o analíticos.
Este libro trata sobre el entorno analítico [o los sistemas de soporte de decisiones (DSS)] y la
estructuración de datos en ese entorno. El enfoque del libro está en lo que se denomina "almacén
de datos" (o "almacén de información"), que es el núcleo del procesamiento de información DSS.
Las discusiones en este libro están dirigidas al gerente y al desarrollador.
Cuando sea apropiado, algún nivel de discusión será a nivel técnico. Pero, en su mayor parte, el
libro trata sobre temas y técnicas. Este libro está destinado a servir como una guía para el
diseñador y el desarrollador.
XIII
Cuando se imprimió la primera edición de Building the Data Warehouse , los teóricos de las
bases de datos se burlaron de la noción de data warehouse. Un teórico afirmó que el
almacenamiento de datos hizo retroceder a la industria de la tecnología de la información 20
años. Otro afirmó que al fundador del almacenamiento de datos no se le debería permitir
hablar en público. Y otro académico proclamó que el almacenamiento de datos no era nada
nuevo y que el mundo académico había sabido sobre el almacenamiento de datos todo el
tiempo, aunque no había libros, artículos, clases, seminarios, conferencias, presentaciones,
referencias, artículos. , y ningún uso de los términos o conceptos existentes en la academia
en ese momento.
Cuando apareció la segunda edición del libro, el mundo estaba loco por cualquier cosa de
Internet. Para tener éxito, tenía que ser "e" algo: ebusiness, ecommerce, etailing, etc. Se
sabe que un capitalista de riesgo dijo: "¿Por qué necesitamos un almacén de datos cuando
tenemos Internet?"
Pero el almacenamiento de datos ha superado a los teóricos de las bases de datos que
querían poner todos los datos en una única base de datos. El almacenamiento de datos
sobrevivió al desastre de las puntocom provocado por los capitalistas de riesgo miopes. En
una era en la que la tecnología en general es rechazada por Wall Street y Main Street, el
almacenamiento de datos nunca ha estado más vivo ni más fuerte. Hay conferencias,
seminarios, libros, artículos, consultorías y similares. Pero sobre todo hay empresas que
realizan almacenamiento de datos y descubren que, a diferencia de la sobrevalorada Nueva
Economía, el almacenamiento de datos realmente cumple, aunque Silicon Valley todavía se
encuentra en un estado de negación.
La tercera edición de este libro anuncia un día más nuevo e incluso más fuerte para el
almacenamiento de datos. Hoy en día, el almacenamiento de datos no es una teoría, sino un
hecho de la vida. La nueva tecnología está a la vuelta de la esquina para satisfacer algunas
de las necesidades más exóticas de un almacén de datos. Las corporaciones ejecutan la
mayor parte de su negocio en almacenes de datos. El costo de la información se ha reducido
drásticamente debido a los almacenes de datos. Los gerentes por fin tienen una solución
viable a la fealdad del entorno de sistemas heredados. Por primera vez se dispone de una
“memoria” corporativa de información histórica. La integración de datos en toda la corporación
es una posibilidad real, en la mayoría de los casos por primera vez. Las corporaciones están aprend
xiv
Machine Translated by Google para pasar de los datos a la información a la ventaja competitiva. En resumen, la carcasa de
almacenamiento de datos ha abierto un mundo de posibilidades.
Un aspecto confuso del almacenamiento de datos es que es una arquitectura, no una tecnología. Esto
frustra tanto al técnico como al capitalista de riesgo porque estas personas quieren comprar algo en
una caja bonita y limpia. Pero la carcasa del software de datos simplemente no se presta a ser
"encajonada". La diferencia entre una arquitectura y una tecnología es como la diferencia entre Santa
Fe, Nuevo México y los ladrillos de adobe. Si conduces por las calles de Santa Fe sabes que estás
allí y en ningún otro lugar. Cada hogar, cada edificio de oficinas, cada restaurante tiene un aspecto
distintivo que dice "Esto es Santa Fe". La apariencia y el estilo que distinguen a Santa Fe son la
arquitectura. Ahora, esa arquitectura se compone de cosas como ladrillos de adobe y vigas a la vista.
Hay todo un arte en la fabricación de adobes y vigas vistas. Y ciertamente es cierto que no se podría
tener arquitectura santafesina sin tener adobes y vigas vistas.
Pero los ladrillos de adobe y las vigas vistas por sí solos no forman una arquitectura. Son tecnologías
independientes. Por ejemplo, tienes ladrillos de adobe en todo el suroeste y el resto del mundo que
no son arquitectura de Santa Fe.
Así sucede con la arquitectura y la tecnología, y con el almacenamiento de datos y las bases de datos
y otras tecnologías. Está la arquitectura, luego está la tecnología subyacente, y son dos cosas muy
diferentes. Sin duda, existe una relación entre el almacenamiento de datos y la tecnología de bases
de datos, pero ciertamente no son lo mismo. El almacenamiento de datos requiere el apoyo de
muchos tipos diferentes de tecnología.
Con la tercera edición de este libro, ahora sabemos qué funciona y qué no. Cuando se escribió la
primera edición, había algo de experiencia en el desarrollo y uso de almacenes, pero la verdad es
que no se contaba con la amplia base de experiencia que existe hoy. Por ejemplo, hoy sabemos con
certeza lo siguiente:
■■ Los almacenes de datos se construyen bajo una metodología de desarrollo diferente a las
aplicaciones. No tener esto en cuenta es una receta para el desastre.
■■ Los almacenes de datos son fundamentalmente diferentes de los data marts. Los dos no se
mezclan, son como el aceite y el agua.
■■ Los almacenes de datos cumplen su promesa, a diferencia de muchas tecnologías
sobrevaloradas que simplemente se desvanecieron.
■■ Los almacenes de datos atraen grandes cantidades de datos, hasta el punto de que
Se requieren nuevos enfoques para la gestión de grandes cantidades de datos.
Pero quizás lo más intrigante que se ha aprendido sobre el almacenamiento de almacenamiento de
datos es que los almacenes de datos forman la base para muchas otras formas de almacenamiento.
Machine Translated by Google Procesando. Los datos granulares que se encuentran en el almacén de datos se pueden remodelar y reutilizar.
Si hay una verdad inmutable y profunda sobre los almacenes de datos, es que los almacenes de datos
proporcionan una base ideal para muchas otras formas de procesamiento de información. Hay una gran
cantidad de razones por las que esta base es tan importante:
■■ Hay una única versión de la verdad.
■■ Los datos se pueden reconciliar si es necesario.
■■ Los datos están disponibles de inmediato para usos nuevos y desconocidos.
Y, por último, el almacenamiento de datos ha abaratado el coste de la información en la organización. Con el
almacenamiento de datos, los datos son económicos de obtener y rápidos
acceso.
Las bases de datos y la teoría de bases de datos existen desde hace mucho tiempo. Las primeras versiones
de las bases de datos se centraban en una sola base de datos que cumplía todos los propósitos conocidos
por la comunidad de procesamiento de información, desde transacciones hasta procesamiento por lotes y
procesamiento analítico. En la mayoría de los casos, el enfoque principal de los primeros sistemas de bases
de datos era el procesamiento operativo, generalmente transaccional. En los últimos años, ha surgido una
noción más sofisticada de la base de datos: una que atiende las necesidades operativas y otra que atiende
las necesidades informativas o analíticas. Hasta cierto punto, esta noción más ilustrada de la base de datos
se debe a la llegada de las PC, la tecnología 4GL y el empoderamiento del usuario final.
La división de las bases de datos operativas e informativas ocurre por muchas razones: ■■ Los datos que
atienden las necesidades operativas son datos físicamente diferentes de los
al servicio de las necesidades informativas o analíticas.
■■ La tecnología de soporte para el procesamiento operativo es fundamentalmente diferente de la tecnología
utilizada para soportar las necesidades analíticas o de información.
■■ La comunidad de usuarios de datos operativos es diferente de la que se sirve de datos informativos o
analíticos.
■■ Las características de procesamiento para el entorno operativo y el
entorno informativo son fundamentalmente diferentes.
Por estas razones (y muchas más), la forma moderna de construir sistemas es separar el procesamiento y
los datos operativos de los informativos o analíticos.
Este libro trata sobre el entorno analítico o DSS y la estructuración de datos en ese entorno. El enfoque del
libro está en lo que se denomina almacén de datos (o almacén de información), que está en el corazón del
procesamiento de información DSS.
¿Qué es el procesamiento analítico e informativo? Es el procesamiento el que sirve a las necesidades de la
gerencia en el proceso de toma de decisiones. A menudo conocido como DSS pro
Machine Translated by Google El procesamiento analítico examina amplias vistas de los datos para detectar tendencias. En lugar de
mirar uno o dos registros de datos (como es el caso del procesamiento operativo), cuando el analista
de DSS realiza un procesamiento analítico, se accede a muchos registros.
Es raro que el analista de DSS actualice los datos. En los sistemas operativos, los datos se actualizan
constantemente a nivel de registro individual. En el procesamiento analítico, se accede constantemente
a los registros y se recopilan sus contenidos para su análisis, pero se produce poca o ninguna
alteración de los registros individuales.
En el procesamiento analítico, los requisitos de tiempo de respuesta se relajan mucho en comparación
con los del procesamiento operativo tradicional. El tiempo de respuesta analítica se mide de 30 minutos
a 24 horas. Los tiempos de respuesta medidos en este rango para el procesamiento operativo serían
un desastre absoluto.
La red que sirve a la comunidad analítica es mucho más pequeña que la que sirve a la comunidad
operativa. Por lo general, hay muchos menos usuarios de la red analítica que de la red operativa.
A diferencia de la tecnología que sirve al entorno analítico, la tecnología del entorno operativo debe
preocuparse por el bloqueo de datos y transacciones, la contención de datos, el interbloqueo, etc.
Existen, entonces, muchas diferencias importantes entre el entorno operativo y el entorno analítico.
Este libro trata sobre el entorno analítico DSS y aborda los siguientes temas: ■■ Granularidad de los
datos ■■ Partición de los datos
■■ Metadatos
■■ Falta de credibilidad de los datos
■■ Integración de los datos del DSS
■■ La base temporal de los datos DSS
■■ Identificación de la fuente de datos del DSS: el sistema de registro ■■
Migración y metodología
Este libro es para desarrolladores, gerentes, diseñadores, administradores de datos, administradores
de bases de datos y otros que están creando sistemas en un entorno de procesamiento de datos
moderno. Además, los estudiantes de procesamiento de información encontrarán útil este libro. Cuando
corresponda, algunas discusiones serán más técnicas. Pero, en su mayor parte, el libro trata sobre
problemas y técnicas, y está destinado a servir como guía para el diseñador y el desarrollador.
Machine Translated by Google Este libro es el primero de una serie de libros relacionados con el almacenamiento de
datos. El siguiente libro de la serie es Uso del almacén de datos (Wiley, 1994). El uso
del almacén de datos soluciona los problemas que surgen una vez que haya creado el
almacén de datos. Además, Uso del almacén de datos introduce el concepto de una
arquitectura más grande y la noción de un almacén de datos operativos (ODS). Un
almacén de datos operativos es una construcción arquitectónica similar al almacén de
datos, excepto que el ODS se aplica solo a los sistemas operativos, no a los sistemas de infor
El tercer libro de la serie es Building the Operational Data Store (Wiley, 1999), que
aborda las cuestiones de qué es un ODS y cómo se construye un ODS.
El próximo libro de la serie es Corporate Information Factory, Third Edition (Wiley, 2002).
Este libro aborda el marco más amplio del cual el almacén de datos es el centro. En
muchos aspectos, el libro CIF y el libro DW son compañeros. El libro CIF proporciona
una imagen más amplia y el libro DW proporciona una discusión más enfocada. Otro
libro relacionado es Exploration Warehousing (Wiley, 2000). Este libro aborda un tipo
especializado de análisis de patrones de procesamiento utilizando técnicas estadísticas
sobre los datos que se encuentran en el almacén de datos.
Sin embargo, construir el almacén de datos es la piedra angular de todos los libros
relacionados. El almacén de datos forma la base de todas las demás formas de DSS
Procesando.
Quizás no haya un testimonio más elocuente de los avances logrados por el
almacenamiento de datos y la fábrica de información corporativa que las Referencias al
final de este libro. Cuando se publicó la primera edición, no había otros libros, ni libros
blancos, y solo un puñado de artículos a los que se podía hacer referencia.
En esta tercera edición, se mencionan muchos libros, artículos y libros blancos. De
hecho, las referencias solo comienzan a explorar algunas de las obras más importantes.
Las siguientes personas han influido, directa o indirectamente, en el material que se
encuentra en este libro. El autor está agradecido por las relaciones a largo plazo que
se han formado y por las experiencias que han proporcionado una base para el
aprendizaje.
Claudia Imhoff, Soluciones Inteligentes
Jon Geiger, Soluciones Inteligentes
Joyce Norris Montanari, Soluciones Inteligentes
John Zachman, Zachman Internacional
John Ladley, Grupo Meta
Bob Terdeman, Corporación EMC
Dan Meers, BillInmon.com
Cheryl Estep, consultora independiente
Lowell Fryman, consultor independiente
David Fender, SAS Japón
Jim Davis, SAS
Peter Grendel, SAP
Allen Houpt, California
xix
Bill Inmon, el padre del concepto de almacenamiento de datos, ha escrito 40
libros sobre gestión de datos, almacenamiento de datos, revisión de diseño y
gestión del procesamiento de datos. Bill ha traducido sus libros al ruso, alemán,
francés, japonés, portugués, chino, coreano y holandés. Bill ha publicado más de
250 artículos en muchas revistas especializadas. Bill fundó y sacó a bolsa Prism
Solutions. Su empresa más reciente, Pine Cone Systems, desarrolla software
para la gestión del entorno de data warehouse/data mart. Bill posee dos patentes
de software. Se pueden encontrar artículos, libros blancos, presentaciones y
mucho más material en su sitio web, www.billinmon.com.
XX
Evolución de la Decisión
Soporte de sistemas
tant declarando cuánto grano se le debe al Faraón. Algunas de las calles de Roma
Se nos dice
que ltos
fueron jeroglíficos
razadas en Egipto
por ingenieros csiviles
on principalmente
hace más de 2e000
l trabajo
dE
años. e
uena
l cuenta
xamen de los
huesos encontrados en excavaciones arqueológicas muestra que la medicina, al
menos en forma rudimentaria, se practicaba desde hace 10.000 años. Otras
profesiones tienen raíces que se remontan a la antigüedad. Desde esta perspectiva,
la profesión y la práctica de los sistemas y procesamiento de la información es
ciertamente inmadura, porque existe solo desde principios de la década de 1960.
El procesamiento de la información muestra esta inmadurez de muchas maneras, como
su tendencia a detenerse en los detalles. Existe la noción de que si tenemos los detalles
correctos, el resultado final de alguna manera se cuidará solo y lograremos el éxito. Es
como decir que si sabemos cómo colocar concreto, cómo perforar y cómo
instalar tuercas y pernos, no tenemos que preocuparnos por la forma o el uso
del puente que estamos construyendo. Tal actitud volvería loco a un ingeniero
civil más maduro profesionalmente. Tener todos los detalles correctos no
necesariamente trae más éxito.
El almacén de datos requiere una arquitectura que comience por mirar el todo y
luego trabaje hacia los detalles. Ciertamente, los detalles son importantes en
todo el almacén de datos. Pero los detalles son importantes solo cuando se ven
en un contexto más amplio.
1
Machine Translated by Google La historia del almacén de datos comienza con la evolución de la información y los sistemas de soporte de
decisiones. Esta visión amplia debería ayudar a poner el almacenamiento de datos en una perspectiva más
clara.
La evolución
Los orígenes del procesamiento DSS se remontan a los primeros días de las computadoras y los sistemas de
información. Es interesante que el procesamiento del sistema de soporte de decisiones (DSS) se desarrolló a
partir de una evolución larga y compleja de la tecnología de la información. Su evolución continúa en la
actualidad.
La Figura 1.1 muestra la evolución del procesamiento de la información desde principios de la década de 1960
hasta 1980. A principios de la década de 1960, el mundo de la computación consistía en crear aplicaciones
individuales que se ejecutaban utilizando archivos maestros. Las aplicaciones presentaban informes y
programas, generalmente construidos en COBOL. Las tarjetas perforadas eran comunes. Los archivos
maestros estaban alojados en cinta magnética, que eran buenos para almacenar un gran volumen de datos
de forma económica, pero el inconveniente era que había que acceder a ellos secuencialmente. En un paso
dado de un archivo de cinta magnética, donde se debe acceder al 100 por ciento de los registros, normalmente
solo se necesita el 5 por ciento o menos de los registros. Además, el acceso a un archivo de cinta completo
puede demorar entre 20 y 30 minutos, según los datos del archivo y el procesamiento que se realice.
A mediados de la década de 1960, se disparó el crecimiento de los archivos maestros y las cintas magnéticas.
Y con ese crecimiento llegaron enormes cantidades de datos redundantes. La proliferación de archivos
maestros y datos redundantes presentó algunos problemas muy insidiosos:
■■ La necesidad de sincronizar datos al momento de la
actualización ■■ La complejidad de mantener programas ■■ La
complejidad de desarrollar nuevos programas ■■ La necesidad de
grandes cantidades de hardware para soportar todos los archivos maestros
En poco tiempo, los problemas de los archivos maestros, problemas inherentes al propio medio, se volvieron
asfixiantes.
Es interesante especular cómo sería el mundo del procesamiento de la información si el único medio para
almacenar datos hubiera sido la cinta magnética. Si nunca hubiera habido nada para almacenar datos masivos
que no fuera cinta magnética
1960 archivos maestros, informes
• complejidad de— •
1965 mantenimiento
• desarrollo •
sincronización de datos • hardware
¡muchos archivos maestros!
DASD base de datos— “una sola fuente de
1970
SGBD datos para todo el procesamiento”
procesamiento de transacciones
1975
en línea de alto rendimiento
1980 PC, tecnología 4GL
procesamiento de tx MIS/DSS
el paradigma de base de datos única que sirve para todos los propósitos
Figura 1.1 Las primeras etapas evolutivas del entorno arquitectónico.
Machine Translated by Google archivos, el mundo nunca habría tenido grandes y rápidos sistemas de reservas, sistemas de cajeros
automáticos y similares. De hecho, la capacidad de almacenar y administrar datos en nuevos tipos de medios
abrió el camino para un tipo de procesamiento más poderoso que reunió al técnico y al empresario como nunca
antes.
El advenimiento de DASD
Para 1970, había amanecido el día de una nueva tecnología para el almacenamiento y acceso de datos. La
década de 1970 vio el advenimiento del almacenamiento en disco o dispositivo de almacenamiento de acceso
directo (DASD). El almacenamiento en disco era fundamentalmente diferente del almacenamiento en cinta
magnética en que se podía acceder a los datos directamente en DASD. No hubo necesidad de revisar los
registros 1, 2, 3, . . . n para llegar al registro n 1. Una vez que se conocía la dirección del registro n 1, era sencillo
ir al registro n 1 directamente.
Además, el tiempo requerido para ir al registro n 1 fue significativamente menor que el tiempo requerido para
escanear una cinta. De hecho, el tiempo para localizar un registro en DASD podría medirse en milisegundos.
Con DASD llegó un nuevo tipo de software de sistema conocido como sistema de gestión de base de datos
(DBMS). El propósito del DBMS era facilitar al programador el almacenamiento y el acceso a datos en DASD.
Además, el DBMS se encargó de tareas como almacenar datos en DASD, indexar datos, etc. Con DASD y
DBMS llegó una solución tecnológica a los problemas de los archivos maestros.
Y con el DBMS vino la noción de una "base de datos". Al observar el desorden que crearon los archivos
maestros y las masas de datos redundantes agregados en ellos, no es de extrañar que en la década de 1970
se definiera una base de datos como una única fuente de datos para todo el procesamiento.
A mediados de la década de 1970, el procesamiento de transacciones en línea (OLTP) hizo posible un acceso
aún más rápido a los datos, abriendo perspectivas completamente nuevas para los negocios y el procesamiento.
La computadora ahora podría usarse para tareas que antes no eran posibles, incluidos los sistemas de reservas
de conducción, los sistemas de cajeros bancarios, los sistemas de control de fabricación y similares. Si el
mundo hubiera permanecido en un estado de archivo de cinta magnética, la mayoría de los sistemas que damos
por sentado hoy en día no habrían sido posibles.
Tecnología PC/4GL
En la década de 1980, comenzaron a surgir más tecnologías nuevas, como PC y lenguajes de cuarta
generación (4GL). El usuario final comenzó a asumir un rol antes insondable: controlar directamente los datos
y los sistemas, un rol que antes estaba reservado para el procesador de datos. Con las PC y la tecnología 4GL
surgió la idea de que se podía hacer más con los datos que simplemente procesar transacciones en línea.
También se podría implementar MIS (sistemas de información gerencial), como se le llamó en los primeros
días. Conocido hoy como DSS, MIS se utilizaba para el procesamiento de decisiones de gestión. Anteriormente,
los datos y la tecnología se usaban exclu
Machine Translated by Google para impulsar decisiones operativas detalladas. Ninguna base de datos única podría servir tanto
para el procesamiento de transacciones operativas como para el procesamiento analítico al mismo
tiempo. La figura 1.1 muestra el paradigma de base de datos única.
Ingrese al programa de extracción
Poco después de la llegada de los sistemas OLTP masivos, comenzó a aparecer un programa
inocuo para el procesamiento de "extracciones" (consulte la Figura 1.2).
El programa extract es el más simple de todos los programas. Rebusca en un archivo o base de
datos, utiliza algunos criterios para seleccionar datos y, al encontrar datos calificados, los transporta
a otro archivo o base de datos.
1985
extraer programa
Comience con algunos parámetros, busque un
archivo en función de la satisfacción de los
parámetros y luego extraiga los datos en otro lugar.
procesamiento de extractos
¿Por qué extraer el
procesamiento? • rendimiento
• control
Figura 1.2 La naturaleza del procesamiento de extractos.
Machine Translated by Google El programa extract se hizo muy popular, al menos por dos razones:
■■ Debido a que el procesamiento de extractos puede mover datos fuera del camino de alta
procesamiento en línea de rendimiento, no hay conflicto en términos de rendimiento cuando
los datos deben analizarse en masa.
■■ Cuando los datos se mueven fuera del dominio operativo de procesamiento de transacciones con un
programa de extracción, se produce un cambio en el control de los datos. El usuario final es
propietario de los datos una vez que toma el control de ellos. Por estas (y probablemente muchas
otras) razones, el procesamiento de extractos pronto se encontró en todas partes.
La telaraña
Como se ilustra en la Figura 1.3, comenzó a formarse una “telaraña” de procesamiento de extractos.
Primero, hubo extractos; luego hubo extractos de extractos; luego extractos de extractos de extractos;
Etcétera. No era raro que una gran empresa realizara hasta 45.000 extractos por día.
Este patrón de procesamiento de extracción fuera de control en toda la organización se volvió tan común
que se le dio su propio nombre, la "arquitectura en evolución natural", que ocurre cuando una organización
maneja todo el proceso de arquitectura de hardware y software con un laissez actitud justa. Cuanto más
grande y más madura es la organización, peores se vuelven los problemas de la arquitectura en evolución
natural.
Problemas con la Naturalidad
Arquitectura en evolución
La arquitectura en evolución natural presenta muchos desafíos, tales como:
■■ Credibilidad de los
datos ■■ Productividad
■■ Incapacidad para transformar los datos en información
Falta de credibilidad de los datos
La falta de credibilidad de los datos se ilustra en la Figura 1.3. Digamos que dos departamentos están
entregando un informe a la gerencia: un departamento afirma que la actividad ha bajado un 15 por ciento,
el otro dice que la actividad ha subido un 10 por ciento. Los dos departamentos no solo no están
sincronizados entre sí, sino que están separados por márgenes muy amplios.
Además, tratar de conciliar los departamentos es difícil. A menos que se haya realizado una documentación
muy cuidadosa, la reconciliación es, a todos los efectos prácticos, imposible.
Machine Translated by Google Dpto. A
+10%
Dpto. B
–15%
• sin base de tiempo de los
datos • diferencial algorítmico
• niveles de extracción
• datos externos
• ninguna fuente común de datos para empezar
Figura 1.3 Falta de credibilidad de los datos en la arquitectura en evolución natural.
Cuando la gerencia recibe informes contradictorios, se ve obligada a tomar decisiones
basadas en políticas y personalidades porque ninguna de las fuentes es más o menos
creíble. Este es un ejemplo de la crisis de credibilidad de los datos en la arquitectura que
evoluciona naturalmente.
Esta crisis es generalizada y predecible. ¿Por qué? Como se muestra en la Figura 1.3,
hay cinco razones:
■■ Sin base de tiempo de los datos
■■ El diferencial algorítmico de datos
■■ Los niveles de extracción
■■ El problema de los datos externos
■■ No hay una fuente común de datos desde el principio
Machine Translated by Google La primera razón de la previsibilidad de la crisis es que no existe una base temporal
para los datos. La Figura 1.4 muestra tal discrepancia de tiempo. Un departamento
extrajo sus datos para su análisis un domingo por la tarde y el otro departamento los
extrajo un miércoles por la tarde. ¿Hay alguna razón para creer que el análisis realizado
en una muestra de datos tomada en un día será el mismo que el análisis de una
muestra de datos tomada en otro día? ¡Por supuesto que no! Los datos siempre están
cambiando dentro de la corporación. Cualquier correlación entre conjuntos de datos
analizados que se toman en diferentes puntos en el tiempo es solo una coincidencia.
La segunda razón es el diferencial algorítmico. Por ejemplo, un departamento ha optado
por analizar todas las cuentas antiguas. Otro departamento ha elegido a ana
Muro
Calle
múltiples
niveles de Diario
extracción
Dpto. A
+10%
• domingo por la noche •
cuentas antiguas
múltiples
niveles de
extracción
Dpto. B –
sin fuente común
15%
de datos para empezar
• Miércoles p. m. •
Grandes cuentas
Negocio
Semana
• pérdida de identidad
• falta de coordinación con otros
personas ingresando datos externos
Figura 1.4 Las razones de la previsibilidad de la crisis de credibilidad de los datos en la natu
arquitectura de rally en evolución.
Machine Translated by Google lyze todas las cuentas grandes. ¿Existe alguna correlación necesaria entre las características de
los clientes que tienen cuentas antiguas y las de los clientes que tienen cuentas grandes?
Probablemente no. Entonces, ¿por qué un resultado muy diferente debería sorprender a alguien?
La tercera razón es una que simplemente magnifica las dos primeras razones. Cada vez que se
realiza una nueva extracción, surgen las probabilidades de una discrepancia debido al tiempo o al
diferencial algorítmico. Y no es inusual que una corporación tenga ocho o nueve niveles de
extracción desde el momento en que los datos ingresan al sistema de la corporación hasta el
momento en que se prepara el análisis para la administración.
Hay extractos, extractos de extractos, extractos de extractos de extractos, y así sucesivamente.
Cada nuevo nivel de extracción exagera los otros problemas que ocurren.
La cuarta razón de la falta de credibilidad es el problema que plantean los datos externos. Con las
tecnologías actuales a nivel de PC, es muy fácil traer datos de fuentes externas. Por ejemplo, la
figura 1.5 muestra a un analista que trae datos a la corriente principal de análisis del Wall Street
Journal y a otro analista que trae datos de Business Week. Sin embargo, cuando el analista trae
datos, él o ella elimina la identidad de los datos externos. Debido a que no se captura el origen de
los datos, se convierten en datos genéricos que podrían haber venido de cualquier
fuente.
Además, el analista que trae datos del Wall Street Journal no sabe nada acerca de los datos que
se ingresan de Business Week, y viceversa. No es de extrañar, entonces, que los datos externos
contribuyan a la falta de credibilidad de los datos en la arquitectura en evolución natural.
El último factor que contribuye a la falta de credibilidad es que, para empezar, a menudo no existe
una fuente común de datos. El análisis para el departamento A se origina en el archivo XYZ. El
análisis para el departamento B se origina en la base de datos ABC. No hay sincronización ni
intercambio de datos de ningún tipo entre el archivo XYZ y la base de datos ABC.
Dadas estas razones, no es de extrañar que se esté gestando una crisis de credibilidad en cada
organización que permite que su legado de hardware, software y datos evolucione naturalmente
hacia la telaraña.
Problemas con la productividad
La credibilidad de los datos no es el único problema importante con la arquitectura que evoluciona
naturalmente. La productividad también es abismal, especialmente cuando es necesario analizar
datos en toda la organización.
Considere una organización que ha estado en el negocio por un tiempo y ha acumulado una gran
colección de datos, como se muestra en la parte superior de la Figura 1.5.
Machine Translated by Google productividad
Producir un informe corporativo, a través de todos los datos.
X
X X
X X
X X X X
X
X X
X X
X X X X
X
X X
X X
X X X X
Localizar los datos requiere mirar lotes de archivos
Muchos programas de extracción, cada uno personalizado, tienen que cruzar muchas barreras tecnológicas.
Figura 1.5 La arquitectura que evoluciona naturalmente no conduce a la productividad.
La gerencia quiere producir un informe corporativo, utilizando los muchos archivos y
colecciones de datos que se han acumulado a lo largo de los años. El diseñador
asignado a la tarea decide que se deben hacer tres cosas para producir el informe corporativo
Machine Translated by Google ■■ Localice y analice los datos para el informe.
■■ Compilar los datos para el informe.
■■ Obtenga recursos de programadores/analistas para realizar estas dos tareas.
Para localizar los datos, se deben analizar muchos archivos y diseños de datos.
Algunos archivos utilizan el Método de acceso al almacenamiento virtual (VSAM), algunos utilizan
el Sistema de gestión de información (IMS), algunos utilizan Adabas, algunos utilizan el Sistema
integrado de gestión de bases de datos (IDMS). Se requieren diferentes conjuntos de habilidades
para acceder a los datos en toda la empresa. Además, hay factores que complican la situación:
por ejemplo, dos archivos pueden tener un elemento llamado BALANCE, pero los dos elementos
son muy diferentes. En otro caso, una base de datos podría tener un archivo conocido como
CURRBAL, y otra colección de datos podría tener un archivo llamado INVLEVEL que representa
la misma información que CURRBAL. Tener que revisar todos los datos, no solo por su nombre,
sino también por definición y cálculo, es un proceso muy tedioso. Pero si se va a producir el
informe corporativo, este ejercicio debe hacerse correctamente. A menos que los datos se
analicen y “racionalicen”, el informe terminará mezclando manzanas y naranjas, creando otro
nivel de confusión.
La siguiente tarea para producir el informe es compilar los datos una vez que se encuentran.
El programa que debe escribirse para obtener datos de sus muchas fuentes debe ser simple. Sin
embargo, es complicado por los siguientes hechos:
■■ Hay que escribir muchos programas.
■■ Cada programa debe ser personalizado.
■■ Los programas cruzan todas las tecnologías que utiliza la empresa.
En resumen, aunque el programa de generación de informes debería ser fácil de escribir,
recuperar los datos para el informe es tedioso.
En una corporación que enfrenta exactamente los problemas descritos, un analista estimó
recientemente un tiempo muy largo para realizar las tareas, como se muestra en la figura 1.6.
Si el diseñador hubiera pedido solo dos o tres meseshombre de recursos, entonces generar el
informe podría no haber requerido mucha atención de la gerencia. Pero cuando un analista
solicita muchos recursos, la gerencia debe considerar la solicitud con todas las demás solicitudes
de recursos y debe priorizar las solicitudes.
Crear los informes utilizando una gran cantidad de recursos no estaría mal si hubiera que pagar
una penalización única. En otras palabras, si el primer informe corporativo generado requirió una
gran cantidad de recursos, y si todos los informes subsiguientes pudieran basarse en el primero,
entonces podría valer la pena pagar el precio por generar el primer informe. Pero ese no es el
caso.
Machine Translated by Google productividad
X
X X
X X
X X X X
X
X X
X X
X X X X
X
X X
X X
X X X X
LOCALIZAR DATOS 9–12 meses
OBTENER DATOS 15–24
PGMMER/
meses
ANALISTA ???
3–5 años
1er informe
2do informe
3er informe 3–5 años
…………
el informe
norte
A menos que las circunstancias sean muy inusuales, el trabajo realizado para el primer
informe no allana el camino para el segundo informe o el tercero. . . .
Figura 1.6 Cuando se escribe el primer informe, no se conocen los requisitos para
informes futuros.
A menos que los futuros requisitos de informes corporativos se conozcan de antemano y se
tengan en cuenta al crear el primer informe corporativo, ¡cada nuevo informe corporativo
probablemente requerirá los mismos gastos generales! En otras palabras, es poco probable
que el primer informe corporativo sea adecuado para los futuros requisitos de informes
corporativos.
La productividad, entonces, en el entorno corporativo es un problema importante frente a la
arquitectura en evolución natural y sus sistemas heredados. En pocas palabras, cuando se
utiliza la telaraña de los sistemas heredados, el acceso a la información es costoso y lleva
mucho tiempo crearla.
De los datos a la información
Como si la productividad y la credibilidad no fueran suficientes problemas, hay otra gran falla
de la arquitectura que evoluciona naturalmente: la incapacidad de pasar de los datos a los datos.
Machine Translated by Google información. A primera vista, la noción de pasar de datos a información parece ser un
concepto etéreo con poca sustancia. Pero ese no es el caso en absoluto.
Considere la siguiente solicitud de información, típica en un entorno bancario: "¿En
qué se ha diferenciado la actividad de la cuenta este año de cada uno de los últimos
cinco años?"
La figura 1.7 muestra la solicitud de información.
pasar de los datos a la información
DDA
prestamos CD
libreta de depósitos
Primero, te encuentras con muchas aplicaciones.
DDA
prestamos CD
mismo elemento, elemento existe
diferente nombre sólo aquí
elemento diferente,
mismo nombre
A continuación, se encuentra con la falta de integración entre aplicaciones.
Figura 1.7 "¿En qué se ha diferenciado la actividad de la cuenta este año de cada uno de los últimos cinco años para
la institución financiera?"
Machine Translated by Google Lo primero que descubre el analista de DSS al tratar de satisfacer la solicitud de información es que
acudir a los sistemas existentes para obtener los datos necesarios es lo peor que puede hacer. El
analista de DSS tendrá que lidiar con muchas aplicaciones heredadas no integradas. Por ejemplo,
un banco puede tener aplicaciones separadas de ahorro, préstamo, depósito directo y fideicomiso.
Sin embargo, tratar de obtener información de ellos de manera regular es casi imposible porque las
aplicaciones nunca se construyeron teniendo en cuenta la integración, y no son más fáciles de
descifrar para el analista de DSS que para cualquier otra persona.
Pero la integración no es la única dificultad que encuentra el analista al tratar de satisfacer una
solicitud de información. Un segundo obstáculo importante es que no hay suficientes datos históricos
almacenados en las aplicaciones para satisfacer las necesidades de la solicitud DSS.
La figura 1.8 muestra que el departamento de préstamos tiene datos de hasta dos años.
El procesamiento de libretas tiene hasta un año de datos. Las aplicaciones DDA tienen hasta 60
días de datos. Y el procesamiento de CD tiene hasta 18 meses de datos. Las aplicaciones se
crearon para satisfacer las necesidades del procesamiento de saldos actuales. Nunca se diseñaron
para contener los datos históricos necesarios para el análisis DSS. No es de extrañar, entonces,
que acudir a los sistemas existentes para el análisis DSS sea una mala elección. Pero, ¿dónde más
hay que ir?
Los sistemas que se encuentran en la arquitectura que evoluciona naturalmente son simplemente
inadecuados para satisfacer las necesidades de información. Les falta integración y hay discrepancia
Ejemplo de paso de datos a información:
“¿En qué ha sido diferente la actividad de la cuenta este año de cada uno de los últimos
cinco para la institución financiera?
DDA
prestamos actual CD
valor
actual 30 dias actual
valor valor
2 años 18 meses
valor
actual:
1 año
Figura 1.8 Las aplicaciones existentes simplemente no tienen los datos históricos necesarios para
convertir los datos en información.
Machine Translated by Google diferencia entre el horizonte temporal (o parámetro de tiempo) necesario para el procesamiento
analítico y el horizonte temporal disponible que existe en las aplicaciones.
Un cambio de enfoque
El statu quo de la arquitectura en evolución natural, donde comenzaron la mayoría de las tiendas,
simplemente no es lo suficientemente sólido para satisfacer las necesidades futuras. Lo que se
necesita es algo mucho más grande: un cambio en las arquitecturas. Ahí es donde entra en juego
el almacén de datos arquitectónico.
Básicamente, existen dos tipos de datos en el corazón de un entorno “arquitectónico”: datos
primitivos y datos derivados. La figura 1.9 muestra algunas de las principales diferencias entre los
datos primitivos y los derivados.
Las siguientes son algunas otras diferencias entre los dos.
■■ Los datos primitivos son datos detallados que se utilizan para ejecutar las operaciones diarias
de la empresa. Los datos derivados se han resumido o calculado de otro modo para satisfacer
las necesidades de la dirección de la empresa.
DATOS PRIMITIVOS/DATOS OPERACIONALES DATOS DERIVADOS/DATOS DSS
• orientado a la aplicación • • orientado al tema •
detallado resumido, refinado de otro modo • representa
• preciso, en el momento del acceso • sirve a la valores a lo largo del tiempo, instantáneas • sirve a la
comunidad administrativa • se puede actualizar • se comunidad gerencial • no está actualizado • se ejecuta de
ejecuta de forma repetitiva • los requisitos para el manera heurística • no se comprenden los requisitos para
procesamiento se entienden a priori • compatible con el el procesamiento • ciclo de vida completamente diferente •
SDLC • sensible al rendimiento • se accede a una unidad a rendimiento relajado • se accede a un conjunto a la vez
la vez a a priori
• impulsada por transacciones • impulsado por análisis
• control de actualización, una preocupación importante • control de actualización sin problemas
en términos de propiedad • alta disponibilidad •
administrado en su totalidad • sin redundancia • • disponibilidad relajada •
estructura estática; contenidos variables • pequeña administrado por subconjuntos •
cantidad de datos usados en un proceso • apoya las la redundancia es un hecho de la vida •
operaciones diarias • alta probabilidad de acceso estructura flexible • gran cantidad de
datos utilizados en un proceso • respalda las necesidades
administrativas • probabilidad de acceso baja y modesta
Figura 1.9 Toda la noción de datos cambia en el entorno diseñado.
Machine Translated by Google ■■ Los datos primitivos se pueden actualizar. Los datos derivados se pueden volver a calcular, pero no
actualizarse directamente.
■■ Los datos primitivos son principalmente datos de valor actual. Los datos derivados son a menudo histori
datos de cal.
■■ Los datos primitivos son operados por procedimientos repetitivos. Los datos derivados son
operados por programas y procedimientos heurísticos, no repetitivos.
■■ Los datos operativos son primitivos; Se derivan los datos DSS.
■■ Los datos primitivos respaldan la función administrativa. Los datos derivados apoyan la función
gerencial.
Es sorprendente que la comunidad de procesamiento de información pensara alguna vez que tanto los datos primitivos
como los derivados encajarían y coexistirían pacíficamente en una sola base de datos. De hecho, los datos primitivos y
los datos derivados son tan diferentes que no residen en la misma base de datos ni en el mismo entorno.
El Entorno Arquitectónico
La extensión natural de la división de datos causada por la diferencia entre datos primitivos y derivados se muestra en la
Figura 1.10.
niveles de la arquitectura
Operacional almacén departamental individual

atómico/de datos
• detallado • más granular • • parroquial • • temporal • ad

• día a día • variable en el algunos derivados; hoc • heurístico
valor actual • alta tiempo • integrado algo primitivo
probabilidad de • orientado al tema • departamentos • no
acceso • orientado • algún resumen típicos • repetitivo •
a la aplicación contabilidad • basado en PC,
marketing • estación de
ingeniería • trabajo
actuarial • fabricación
Figura 1.10 Aunque no es evidente a primera vista, hay muy poca redundancia de datos en todo el entorno
diseñado.
Machine Translated by Google Hay cuatro niveles de datos en el entorno diseñado: el nivel operativo, el nivel atómico o
de almacenamiento de datos, el nivel departamental (o el nivel de data mart) y el nivel
individual. Estos diferentes niveles de datos son la base de una arquitectura más grande
llamada fábrica de información corporativa. El nivel operativo de datos solo contiene
datos primitivos orientados a la aplicación y sirve principalmente a la comunidad de
procesamiento de transacciones de alto rendimiento. El nivel de almacenamiento de
datos contiene datos primitivos históricos integrados que no se pueden actualizar.
Además, allí se encuentran algunos datos derivados. El nivel de datos departamentales/
de mercado de datos contiene datos derivados casi exclusivamente. El nivel de datos
del departa mento/marco de datos está conformado por los requisitos del usuario final
en una forma que se adapta específicamente a las necesidades del departamento. Y el
nivel individual de datos es donde se realiza gran parte del análisis heurístico.
Los diferentes niveles de datos forman un conjunto superior de entidades arquitectónicas.
Estas entidades constituyen la fábrica de información corporativa y se describen con
más detalle en mi libro The Corporate Information Factory, Third Edition (Wiley, 2002).
Algunas personas creen que el entorno diseñado genera demasiados datos redundantes.
Aunque no es obvio a primera vista, este no es el caso en absoluto.
En cambio, es el entorno de la telaraña el que genera las cantidades brutas de
redundancia de datos.
Considere el ejemplo simple de datos en toda la arquitectura, que se muestra en la
figura 1.11. A nivel operativo hay un registro de un cliente, J Jones. El registro de nivel
operativo contiene datos de valor actual que se pueden actualizar en cualquier momento
y muestra el estado actual del cliente. Por supuesto, si la información de J Jones cambia,
el registro de nivel operativo se cambiará para reflejar los datos correctos.
El entorno del almacén de datos contiene varios registros para J Jones, que muestran el
historial de información sobre J Jones. Por ejemplo, se buscaría en el almacén de datos
para descubrir dónde vivió J Jones el año pasado. No hay superposición entre los
registros del entorno operativo, donde se encuentra la información actual, y el entorno
del almacén de datos, donde se encuentra la información histórica. Si hay un cambio de
dirección para J Jones, entonces se creará un nuevo registro en el almacén de datos,
reflejando las fechas desde y hasta que J Jones vivía en la dirección anterior. Tenga en
cuenta que los registros en el almacén de datos no se superponen. También tenga en
cuenta que hay algún elemento de tiempo asociado con cada registro en el almacén de
datos.
El entorno departamental, a veces denominado nivel de data mart, nivel OLAP o nivel
DBMS multidimensional, contiene información útil para los diferentes departamentos
parroquiales de una empresa. Hay una base de datos del departamento de marketing,
una base de datos del departamento de contabilidad, una base de datos actuarial
Machine Translated by Google un ejemplo simple: un cliente
Operacional almacén clientes de individual

atómico/de datos departamento/data mart por mes
j jones
j jones
j jones
J Jones Ene
4 4101
Ene 101 clientes
desde 1c982
lientes
123
pprincipal
123 rincipal 1986–1987
1986–1987 Febrero

Febrero 4 4209
209 desde
cuenta con con
1 982
Calle 456 calle marzo 4 4175 saldos
e>n
5c.000
uenta
Calle alta alta 456
calle marzo 175 saldos y
Crédito
A
AAA Crédito B Abril >
5.000 yc on
con
Crédito Crédito B Abril 4215

4 215 crédito
............
............ calificaciones
crediticias de B
.....
..... calificaciones de
j jones
J Jones ............
1987–1989 ............ B o superior o
1987–1989 .....
..... superior
456 calle
alta alta 456
calle
Crédito
A
Crédito A
¡temporario!
j jones
J Jones
1989–pres
1989–pres
Calle
pprincipal
Calle 1123
rincipal 23
Crédito
A
Crédito AAA
¿Qué es J Jones? ¿Cuál ha sido el ¿Estamos que tendencias son

calificación crediticia en este historial crediticio de atrayendo más o menos allí para el
momento? J Jones? clientes terminados clientes somos
¿tiempo? analizando?
Figura 1.11 Los tipos de consultas para las que se pueden utilizar los diferentes niveles de datos.
base de datos departamental, y así sucesivamente. El almacén de datos es la fuente de todos los
datos departamentales. Si bien los datos en el data mart ciertamente se relacionan con los datos
que se encuentran en el nivel operativo o en el almacén de datos, los datos que se encuentran en
el entorno departamental/data mart son fundamentalmente diferentes de los datos que se
encuentran en el entorno del data mart, porque los datos del data mart están desnormalizados. ,
resumido y moldeado por los requisitos operativos de un solo departamento.
Típico de los datos a nivel departamental/de mercado de datos es un archivo mensual de clientes.
En el archivo hay una lista de todos los clientes por categoría. J Jones se cuenta en este resumen
cada mes, junto con muchos otros clientes. Es una exageración considerar que el conteo de
información es redundante.
El último nivel de datos es el nivel individual. Los datos individuales suelen ser temporales y
pequeños. Gran parte del análisis heurístico se realiza a nivel individual. Como una regla,
Machine Translated by Google los niveles individuales de datos son compatibles con la PC. El procesamiento de los sistemas de
información ejecutiva (EIS) generalmente se ejecuta en los niveles individuales.
Integración de datos en el
Entorno Arquitectónico
Un aspecto importante del entorno diseñado que no se muestra en la figura 1.11 es la integración
de datos que se produce en toda la arquitectura. A medida que los datos pasan del entorno
operativo al entorno del almacén de datos, se integran, como se muestra en la Figura 1.12.
No tiene sentido traer datos del entorno operativo al entorno del almacén de datos sin integrarlos.
Si los datos llegan al almacén de datos en un estado no integrado, no se pueden utilizar para
respaldar una vista corporativa de los datos. Y una visión corporativa de los datos es una de las
esencias del entorno diseñado.
En todos los entornos, los datos operativos no integrados son complejos y difíciles de manejar.
Esto es simplemente un hecho de la vida. Y la tarea de ensuciarse las manos con el proceso de
integración nunca es agradable. Sin embargo, para lograr los beneficios reales de un almacén de
datos, es necesario someterse a este ejercicio doloroso, complejo y lento. El software de extracción/
transformación/carga (ETL) puede automatizar gran parte de este tedioso proceso. Además, este
proceso de integración tiene que hacerse una sola vez. Pero, en cualquier caso, es obligatorio
que los datos que fluyen hacia el almacén de datos se integren, y no simplemente se arrojen,
como si nada, al almacén de datos desde el entorno operativo.
¿Quién es el usuario?
Gran parte del almacén de datos es fundamentalmente diferente del entorno operativo. Cuando
los desarrolladores y diseñadores que han pasado toda su carrera en el entorno operativo se
encuentran por primera vez con el almacén de datos, a menudo se sienten incómodos. Para
ayudarlos a apreciar por qué existe una diferencia tan grande con el mundo que han conocido,
deben comprender un poco acerca de los diferentes usuarios del almacén de datos.
El usuario del almacén de datos, también llamado analista de DSS, es ante todo una persona de
negocios y, en segundo lugar, un técnico. El trabajo principal del analista de DSS es definir y
descubrir información utilizada en la toma de decisiones corporativas.
Es importante mirar dentro de la cabeza del analista de DSS y ver cómo percibe el uso del
almacén de datos. El analista de DSS tiene una mentalidad de "Dame lo que digo que quiero,
luego puedo decirte lo que realmente quiero". En otras palabras, el analista de DSS opera en un
modo de descubrimiento. Solo al ver un informe
Machine Translated by Google un ejemplo simple: un cliente
Operacional almacén
atómico/de datos
póliza de vida
j jones
femenino
20 de julio de 1945
...................
cliente
j jones
póliza de automóvil
femenino
20 de julio de 1945: dob
j jones
dos boletos el año pasado un
dos entradas el año pasado un
accidente grave
accidente grave
Calle principal 123
.....................
casado
dos niños
hipertensión
póliza de propietario .....................
j jones
Calle principal 123
casado
...................
politica de salud
j jones
dos niños
hipertensión
.....................
Figura 1.12 A medida que los datos se transforman del entorno operativo al entorno de
almacenamiento de datos, también se integran.
o al ver una pantalla, el analista de DSS puede comenzar a explorar las posibilidades
de DSS. El analista de DSS suele decir: “¡Ah! Ahora que veo cuáles son las
posibilidades, puedo decirles lo que realmente quiero ver. Pero hasta que sepa cuáles
son las posibilidades, no puedo describirte lo que quiero.
Machine Translated by Google La actitud del analista DSS es importante por las siguientes razones:
■■ Es legítimo. Así es simplemente como piensan los analistas de DSS y cómo confunden
canalizar su negocio.
■■ Es omnipresente. Los analistas de DSS de todo el mundo piensan así. ■■ Tiene
un efecto profundo en la forma en que se desarrolla y
sobre cómo se desarrollan los sistemas que utilizan el almacén de datos.
El ciclo de vida de desarrollo de sistemas clásico (SDLC) no funciona en el mundo del analista DSS. El
SDLC asume que los requisitos se conocen al comienzo del diseño (o al menos se pueden descubrir).
Sin embargo, en el mundo del analista de DSS, los nuevos requisitos suelen ser lo último que se
descubre en el ciclo de vida de desarrollo de DSS. El analista de DSS comienza con los requisitos
existentes, pero tener en cuenta nuevos requisitos es casi imposible. Un ciclo de vida de desarrollo muy
diferente está asociado con el almacén de datos.
El ciclo de vida del desarrollo
Hemos visto cómo los datos operativos suelen estar orientados a la aplicación y, en consecuencia, no
están integrados, mientras que los datos del almacén de datos deben estar integrados.
También existen otras diferencias importantes entre el nivel operativo de datos y procesamiento y el
nivel de datos y procesamiento del almacén de datos. Los ciclos de vida de desarrollo subyacentes de
estos sistemas pueden ser una gran preocupación, como se muestra en la Figura 1.13.
La figura 1.13 muestra que el entorno operativo está respaldado por el ciclo de vida de desarrollo de
sistemas clásicos (el SDLC). El SDLC a menudo se llama el enfoque de desarrollo de “cascada” porque
se especifican las diferentes actividades y una actividad, una vez completada, se derrama en la
siguiente actividad y desencadena su inicio.
El desarrollo del almacén de datos opera bajo un ciclo de vida muy diferente, a veces llamado CLDS
(el reverso del SDLC). El SDLC clásico se basa en los requisitos. Para construir sistemas, primero debe
comprender los requisitos. Luego pasas a las etapas de diseño y desarrollo.
El CLDS es casi exactamente lo contrario: el CLDS comienza con datos. Una vez que los datos están
disponibles, se integran y luego se prueban para ver qué sesgo hay en los datos, si los hay. Luego, los
programas se escriben contra los datos. Se analizan los resultados de los programas y finalmente se
comprenden los requisitos del sistema.
El CLDS se suele llamar una metodología de desarrollo "espiral". En el sitio Web, www.billinmon.com,
se incluye una metodología de desarrollo en espiral .
requisitos
almacén de datos
programa
programa
requisitos
SDLC clásico almacén de datos SDLC
• recopilación de requisitos • • implementar almacén •
análisis • diseño • integrar datos • probar el
programación • pruebas • sesgo • programar contra
integración • implementación datos • diseñar un sistema
DSS • analizar resultados •
comprender los requisitos
Figura 1.13 El ciclo de vida de desarrollo del sistema para el entorno del almacén de datos es
casi exactamente lo contrario del clásico SDLC.
CLDS es un ciclo de vida de desarrollo basado en datos clásico, mientras que SDLC
es un ciclo de vida de desarrollo basado en requisitos clásico. Tratar de aplicar
herramientas y técnicas de desarrollo inapropiadas sólo resulta en desperdicio y confusión.
Por ejemplo, el mundo CASE está dominado por el análisis basado en requisitos.
No es recomendable intentar aplicar las herramientas y técnicas CASE al mundo del
data warehouse, y viceversa.
Patrones de utilización de hardware
Otra diferencia importante entre los entornos operativos y de almacenamiento de
datos es el patrón de utilización del hardware que se produce en cada entorno. La
figura 1.14 ilustra esto.
El lado izquierdo de la figura 1.14 muestra el patrón clásico de utilización de hardware
para el procesamiento operativo. Hay picos y valles en el procesamiento operativo,
pero finalmente hay un patrón relativamente estático y predecible de utilización de
hardware.
Machine Translated by Google Operacional almacén de datos
100%
0%
Figura 1.14 Los diferentes patrones de utilización del hardware en los diferentes entornos.
Hay un patrón esencialmente diferente de utilización de hardware en el entorno del almacén de datos
(que se muestra en el lado derecho de la figura): un patrón binario de utilización. El hardware se está
utilizando por completo o no se está utilizando en absoluto. No es útil calcular un porcentaje medio de
utilización para el entorno de almacenamiento de datos. Incluso calcular los momentos en que el
almacén de datos se usa mucho no es particularmente útil o esclarecedor.
Esta diferencia fundamental es una razón más por la que intentar mezclar los dos entornos en la
misma máquina al mismo tiempo no funciona. Puede optimizar su máquina para el procesamiento
operativo o para el procesamiento de almacenamiento de datos, pero no puede hacer ambas cosas al
mismo tiempo en el mismo equipo.
Preparando el escenario para la reingeniería
Aunque indirecto, hay un efecto secundario muy beneficioso al pasar del entorno de producción al
entorno de almacenamiento de datos con arquitectura. La figura 1.15 muestra la progresión.
En la Figura 1.15, se realiza una transformación en el entorno de producción. El primer efecto es la
eliminación de la mayor parte de los datos, en su mayoría archivos, del entorno de producción. La
eliminación de volúmenes masivos de datos tiene un efecto beneficioso de varias maneras. El entorno
de producción es más fácil de:
■■ Correcto
■■ Reestructurar
■■ Supervisar
■■ Índice
En definitiva, la mera eliminación de un volumen importante de datos hace que el entorno de producción
sea mucho más maleable.
Otro efecto importante de la separación de los entornos operativo y de almacenamiento de datos es la
eliminación del procesamiento de información del
entorno
de producción
entorno almacén de datos
operativo ambiente
Figura 1.15 La transformación del entorno de sistemas heredados al entorno
arquitectónico centrado en el almacén de datos.
entorno de producción. El procesamiento de la información se produce en forma de informes, pantallas,
extractos, etc. La naturaleza misma del procesamiento de la información es un cambio constante. Las
condiciones comerciales cambian, la organización cambia, la administración cambia, las prácticas
contables cambian, etc. Cada uno de estos cambios tiene un efecto en el procesamiento de resumen e
información. Cuando el procesamiento de la información se incluye en el entorno heredado de producción,
el mantenimiento parece ser eterno. Pero mucho de lo que se llama mantenimiento en
el entorno de producción es en realidad un procesamiento de información que pasa por el ciclo normal de
cambios. Al trasladar la mayor parte del procesamiento de información al almacén de datos, la carga de
mantenimiento en el entorno de producción se alivia en gran medida. La figura 1.16 muestra el efecto de
eliminar volúmenes de datos y procesamiento de información del entorno de producción.
Una vez que el entorno de producción experimenta los cambios asociados con la transformación al
entorno diseñado y centrado en el almacén de datos, el entorno de producción está preparado para la
reingeniería porque:
■■ Es más pequeño.
■■ Es más simple.
■■ Está enfocado.
En resumen, el paso más importante que una empresa puede dar para que sus esfuerzos de reingeniería
sean exitosos es ir primero al entorno del almacén de datos.
Machine Translated by Google la mayor parte de los
datos históricos que
tienen una probabilidad
de acceso muy baja y
rara vez se modifican
entorno de
producción
requisitos informativos y
analíticos que se muestran
como mantenimiento eterno
Figura 1.16 Eliminación de requisitos de información y datos innecesarios del producto
entorno de almacenamiento: los efectos de ir al entorno de almacenamiento de datos.
Supervisión del entorno del almacén de datos
Una vez que se construye el almacén de datos, se debe mantener. Un componente
importante del mantenimiento del almacén de datos es la gestión del rendimiento, que
comienza con la supervisión del entorno del almacén de datos.
Dos componentes operativos se monitorean regularmente: los datos que residen en el
almacén de datos y el uso de los datos. El monitoreo de los datos en el entorno del
almacén de datos es esencial para administrar el almacén de datos de manera efectiva.
Algunos de los resultados importantes que se logran al monitorear estos datos incluyen
los siguientes:
■■ Identificar qué crecimiento está ocurriendo, dónde está ocurriendo el crecimiento y a
qué tasa de crecimiento está ocurriendo ■■ Identificar qué datos se están utilizando
■■ Calcular el tiempo de respuesta que obtiene el usuario final ■■ Determinar quién está
utilizando realmente los datos ■■ Especificar qué parte del almacén de datos utilizan los
usuarios finales ■■ Determinar con precisión cuándo se está utilizando el almacén de
datos ■■ Reconocer cuánto se está utilizando del almacén de datos ■■ Examinar el nivel
de uso del almacén de datos
Machine Translated by Google Si el arquitecto de datos no sabe la respuesta a estas preguntas, no puede administrar de manera
efectiva el entorno del almacén de datos de manera continua.
Como ejemplo de la utilidad de monitorear el almacén de datos, considere la importancia de saber qué
datos se utilizan dentro del almacén de datos.
La naturaleza de un almacén de datos es un crecimiento constante. La historia se agrega constantemente
al almacén. Constantemente se agregan resúmenes. Se están creando nuevos flujos de extracción. Y la
tecnología de almacenamiento y procesamiento en la que reside el almacén de datos puede ser costosa.
En algún momento surge la pregunta: “¿Por qué se acumulan todos estos datos? ¿Hay realmente alguien
usando todo esto? Ya sea que haya un usuario legítimo del almacén de datos, ciertamente hay un costo
creciente para el almacén de datos a medida que los datos se colocan en él durante su funcionamiento
normal.
Mientras el arquitecto de datos no tenga forma de monitorear el uso de los datos dentro del almacén, no
hay más remedio que comprar continuamente nuevos recursos informáticos, más almacenamiento, más
procesadores, etc. Cuando el arquitecto de datos puede monitorear la actividad y el uso en el almacén
de datos, puede determinar qué datos no se están utilizando. Entonces es posible, y sensato, mover los
datos no utilizados a medios menos costosos. Esta es una recompensa muy real e inmediata para
monitorear los datos y la actividad.
Los perfiles de datos que se pueden crear durante el proceso de monitoreo de datos incluyen lo siguiente:
■■ Un catálogo de todas las tablas en el almacén ■■ Un perfil del contenido de esas tablas ■■ Un perfil
del crecimiento de las tablas en los datos almacén ■■ Un catálogo de los índices disponibles para la
entrada a las tablas ■■ Un catálogo de las tablas de resumen y las fuentes para el resumen
Las siguientes preguntas ilustran la necesidad de monitorear la actividad en el almacén de datos:
■■ ¿ A qué datos se accede?
■■ ¿Cuándo?
■■ ¿ Por quién?
■■ ¿ Con qué frecuencia?
■■ ¿ A qué nivel de detalle?
■■ ¿Cuál es el tiempo de respuesta de la solicitud?
■■ ¿ En qué momento del día se presenta la solicitud?
■■ ¿ Qué tan grande fue la solicitud?
■■ ¿ Se canceló la solicitud o terminó de forma natural?
Machine Translated by Google El tiempo de respuesta en el entorno DSS es bastante diferente del tiempo de respuesta
en el entorno de procesamiento de transacciones en línea (OLTP). En el entorno OLTP,
el tiempo de respuesta casi siempre es fundamental para la misión. El negocio comienza
a sufrir inmediatamente cuando el tiempo de respuesta se vuelve malo en OLTP. En el
entorno DSS no existe tal relación. El tiempo de respuesta en el entorno del almacén de
datos DSS siempre es relajado. No existe una naturaleza de misión crítica para el tiempo
de respuesta en DSS. En consecuencia, el tiempo de respuesta en el entorno del
almacén de datos DSS se mide en minutos y horas y, en algunos casos, en términos de días
El hecho de que el tiempo de respuesta sea relajado en el entorno del almacén de datos
DSS no significa que el tiempo de respuesta no sea importante. En el entorno del
almacén de datos DSS, el usuario final realiza el desarrollo de forma iterativa. Esto
significa que el siguiente nivel de investigación de cualquier desarrollo iterativo depende
de los resultados obtenidos por el análisis actual. Si el usuario final realiza un análisis
iterativo y el tiempo de respuesta es de solo 10 minutos, será mucho más productivo que
si el tiempo de respuesta es de 24 horas. Existe, entonces, una relación muy importante
entre el tiempo de respuesta y la productividad en el entorno DSS. El hecho de que el
tiempo de respuesta en el entorno DSS no sea de misión crítica no significa que no sea
importante.
La capacidad de medir el tiempo de respuesta en el entorno DSS es el primer paso para
poder administrarlo. Solo por esta razón, monitorear la actividad de DSS es un
procedimiento importante.
Uno de los problemas de la medición del tiempo de respuesta en el entorno DSS es la
pregunta: "¿Qué se está midiendo?" En un entorno OLTP, está claro lo que se mide. Una
solicitud se envía, se atiende y se devuelve al usuario final. En el entorno OLTP, la
medición del tiempo de respuesta es desde el momento de la presentación hasta el
momento de la devolución. Pero el entorno del almacén de datos DSS difiere del entorno
OLTP en que no hay un tiempo claro para medir el retorno de los datos. En el entorno del
almacén de datos DSS, a menudo se devuelve una gran cantidad de datos como
resultado de una consulta. Algunos de los datos se devuelven en un momento y otros
datos se devuelven más tarde. Definir el momento de devolución de los datos para el
entorno del almacén de datos no es tarea fácil. Una interpretación es el momento del
primer retorno de datos; otra interpretación es la última devolución de datos. Y existen
muchas otras posibilidades para la medición del tiempo de respuesta; el monitor de
actividad del almacén de datos DSS debe poder proporcionar muchas interpretaciones
diferentes.
Uno de los problemas fundamentales de usar un monitor en el entorno del almacén de
datos es dónde hacer el monitoreo. Un lugar donde se puede realizar el monitoreo es en
la terminal del usuario final, lo cual es conveniente, aquí muchos ciclos de máquina son
gratuitos y el impacto en el rendimiento de todo el sistema es mínimo. Monitorear el
sistema a nivel de terminal de usuario final implica que cada terminal que será
monitoreado requerirá su propia administración. En un mundo donde hay como
Machine Translated by Google Con hasta 10.000 terminales en una sola red DSS, tratar de administrar el monitoreo de cada
terminal es casi imposible.
La alternativa es hacer el monitoreo del sistema DSS a nivel de servidor.
Una vez formulada la consulta y pasada al servidor que gestiona el almacén de datos, se puede
realizar el seguimiento de la actividad. Sin duda, aquí la administración del monitor es mucho
más sencilla. Pero existe una muy buena posibilidad de que se incurra en una penalización de
rendimiento en todo el sistema. Debido a que el monitor usa recursos en el servidor, el impacto
en el rendimiento se siente en todo el entorno del almacén de datos DSS. La ubicación del
monitor es un tema importante que debe pensarse cuidadosamente. La compensación es entre
la facilidad de administración y la minimización de los requisitos de rendimiento.
Uno de los usos más poderosos de un monitor es poder comparar los resultados de hoy con un
día "promedio". Cuando ocurren condiciones inusuales del sistema, a menudo es útil preguntar:
"¿Qué tan diferente es hoy del día promedio?" En muchos casos, se verá que las variaciones
en el rendimiento no son tan malas como se imagina. Pero para hacer tal comparación, debe
haber un perfil de día promedio, que contenga las medidas estándar importantes que describen
un día en el entorno DSS. Una vez que se mide el día actual, se puede comparar con el perfil
del día promedio.
Por supuesto, el día promedio cambia con el tiempo, y tiene sentido hacer un seguimiento de
estos cambios periódicamente para poder medir las tendencias del sistema a largo plazo.
Resumen
Este capítulo ha discutido los orígenes del almacén de datos y la arquitectura más amplia en la
que encaja el almacén de datos. La arquitectura ha evolucionado
a lo largo de la historia de las diferentes etapas del procesamiento de la información. Hay cuatro
niveles de datos y procesamiento en la arquitectura: el nivel operativo, el nivel de almacenamiento
de datos, el nivel departamental/de data mart y el nivel individual.
El almacén de datos se crea a partir de los datos de la aplicación que se encuentran en el
entorno operativo. Los datos de la aplicación se integran a medida que pasan al almacén de
datos. El acto de integrar datos es siempre una tarea compleja y tediosa. Los datos fluyen desde
el almacén de datos hacia el entorno departamental/data mart.
Los datos en el entorno departamental/data mart están determinados por los requisitos de
procesamiento únicos del departamento.
El almacén de datos se desarrolla bajo un enfoque de desarrollo completamente diferente al
utilizado para los sistemas de aplicación clásicos. Clásicamente, las aplicaciones se han
desarrollado mediante un ciclo de vida conocido como SDLC. el material de datos
Machine Translated by Google house se desarrolla bajo un enfoque llamado metodología de desarrollo en espiral.
El enfoque de desarrollo en espiral exige que pequeñas partes del almacén de datos
se desarrollen hasta su finalización y luego otras pequeñas partes del almacén se
desarrollen en un enfoque iterativo.
Los usuarios del entorno del almacén de datos tienen un enfoque completamente
diferente para usar el sistema. A diferencia de los usuarios operativos que tienen un
enfoque directo para definir sus requisitos, el usuario del almacén de datos opera con
una mentalidad de descubrimiento. El usuario final del almacén de datos dice: "Dame
lo que digo que quiero, luego puedo decirte lo que realmente quiero".
El almacén de datos
Ambiente
dación de todo el procesamiento de DSS. El trabajo del analista DSS en el almacén de datos
El almacén de datos
El entorno es einfinitamente
s el corazón m
del
efntorno
ás diseñado
ácil que y es la
en el entorno hberedado
ase clásico porque
hay una única fuente integrada de datos (el almacén de datos) y porque los datos
granulares en el almacén de datos son fácilmente accesibles.
Este capítulo describirá algunos de los aspectos más importantes del almacén de
datos. Un almacén de datos es una colección de datos orientada a temas, integrada,
no volátil y variable en el tiempo en apoyo de las decisiones de gestión. El almacén
de datos contiene datos corporativos granulares.
La orientación temática del almacén de datos se muestra en la Figura 2.1. Los sistemas
de operaciones clásicos se organizan en torno a las aplicaciones de la empresa. Para
una compañía de seguros, las aplicaciones pueden ser automóviles, salud, vida y accidentes
Las principales áreas temáticas de la corporación de seguros pueden ser el cliente, la póliza,
la prima y la reclamación. Para un fabricante, las principales áreas temáticas pueden ser el
producto, el pedido, el proveedor, la lista de materiales y las materias primas. Para un
minorista, las principales áreas temáticas pueden ser producto, SKU, venta, proveedor, etc.
Cada tipo de empresa tiene su propio conjunto único de temas.
La segunda característica sobresaliente del almacén de datos es que está integrado.
De todos los aspectos de un almacén de datos, la integración es el más importante. Los
datos se alimentan desde múltiples fuentes dispares al almacén de datos. Como los datos son
31
Machine Translated by Google orientación temática
Operacional almacén de datos
auto cliente
política
vida
de primera calidad
salud
afirmar
víctima
aplicaciones asignaturas
Figura 2.1 Un ejemplo de orientación de datos por tema.
se convierte, se reformatea, se vuelve a secuenciar, se resume, etc. El resultado es que los
datos, una vez que residen en el almacén de datos, tienen una única imagen corporativa
física. La figura 2.2 ilustra la integración que se produce cuando los datos pasan del entorno
operativo orientado a la aplicación al almacén de datos.
Las decisiones de diseño tomadas por los diseñadores de aplicaciones a lo largo de los
años se manifiestan de diferentes maneras. En el pasado, cuando los diseñadores de
aplicaciones creaban una aplicación, nunca consideraban que los datos con los que
operaban tendrían que integrarse con otros datos. Tal consideración era solo una teoría
descabellada. En consecuencia, a través de múltiples aplicaciones no hay consistencia de
aplicación en codificación, convenciones de nomenclatura, atributos físicos, medición de
atributos, etc. Cada diseñador de aplicaciones ha tenido rienda suelta para tomar sus propias
decisiones de diseño. El resultado es que cualquier aplicación es muy diferente de cualquier
otra aplicación.
Los datos se ingresan en el almacén de datos de tal manera que se deshacen las muchas
inconsistencias en el nivel de la aplicación. Por ejemplo, en la figura 2.2, en la medida en que
Machine Translated by Google integración
codificación
appl A m,f appl mf
B 1,0 appl C
x,y appl D
macho, hembra
medición de atributos
aplicación A tubería—cm
tubería—cm
aplicación B tubería—pulgadas
aplicación C tubería—mcf
aplicación D tubería—yds
múltiples fuentes
appl A descripción appl
B descripción appl C
? descripción
descripción appl D
descripción
claves en conflicto
appl A key char(10) appl B
key dec fixed(9,2) appl C key pic
carácter clave(12)
'9999999' appl D key char(12)
Figura 2.2 El tema de la integración.
En lo que respecta a la codificación de género, importa poco si los datos en el almacén están
codificados como m/f o 1/0. Lo que importa es que, independientemente del método o la
aplicación de origen, la codificación del almacén se realiza de forma coherente. Si los datos de
la aplicación están codificados como X/Y, se convierten a medida que se mueven al almacén.
La misma consideración de coherencia se aplica a todos los problemas de diseño de
aplicaciones, como las convenciones de nomenclatura, la estructura clave, la medición de
atributos y las características físicas de los datos.
La tercera característica importante de un almacén de datos es que no es volátil.
La figura 2.3 ilustra la no volatilidad de los datos y muestra que los datos operativos se acceden
y manipulan regularmente un registro a la vez. Los datos se actualizan en el entorno operativo
de forma habitual, pero los datos del almacén de datos
Machine Translated by Google no volatilidad
datos
Operacional depósito
cambiar
es
acceso
dleta dleta carga
es acceso
cambiar
manipulación de datos carga/acceso
registro por registro masivo de datos
Figura 2.3 El problema de la no volatilidad.
exhibe un conjunto muy diferente de características. Los datos del almacén de datos se cargan
(generalmente en masa) y se accede a ellos, pero no se actualizan (en el sentido general).
En cambio, cuando se cargan los datos en el almacén de datos, se cargan en una instantánea, en
formato estático. Cuando se producen cambios posteriores, se escribe un nuevo registro de
instantánea. Al hacerlo, se mantiene un historial de datos en el almacén de datos.
La última característica destacada del almacén de datos es que es variable en el tiempo.
La variación de tiempo implica que cada unidad de datos en el almacén de datos es precisa en algún
momento en el tiempo. En algunos casos, un registro tiene una marca de tiempo. En otros casos, un
registro tiene una fecha de transacción. Pero en todos los casos, hay algún tipo de marca de tiempo
para mostrar el momento en el tiempo durante el cual el registro es exacto. La figura 2.4 ilustra cómo
la variación temporal de los datos del almacén de datos puede mostrarse de varias maneras.
Diferentes entornos tienen diferentes horizontes de tiempo. Un horizonte de tiempo son los parámetros
de tiempo representados en un entorno. El horizonte de tiempo colectivo para los datos que se
encuentran dentro de un almacén de datos es significativamente más largo que el de los sistemas
operativos. Un horizonte temporal de 60 a 90 días es normal para los sistemas operativos; un horizonte
temporal de 5 a 10 años es normal para el almacén de datos. Como resultado de esta diferencia en
los horizontes temporales, el almacén de datos contiene mucho más historial que cualquier otro entorno.
Las bases de datos operativas contienen datos de valor actual cuya precisión es válida en el momento
del acceso. Por ejemplo, un banco sabe cuánto dinero tiene depositado un cliente en cualquier
momento. O una compañía de seguros sabe qué pólizas están vigentes en cada momento. Como tal,
los datos de valor actual se pueden actualizar a medida que cambian las condiciones comerciales. El
saldo bancario se cambia cuando el cliente hace un depósito. La cobertura del seguro es
Machine Translated by Google variación de tiempo
• horizonte temporal: actual de 60 a 90 días • • horizonte temporal: 5 a 10 años •
actualización de registros • la estructura clave puede instantáneas sofisticadas de datos • la
o no contener un elemento de tiempo estructura clave contiene un elemento de tiempo
Figura 2.4 El problema de la variación del tiempo.
cambia cuando un cliente deja que una póliza caduque. Sin embargo, los datos del almacén de
datos son muy diferentes a los datos de valor actual. Los datos del almacén de datos no son más
que una serie sofisticada de instantáneas, cada una tomada en un momento determinado. El
efecto creado por la serie de instantáneas es que el almacén de datos tiene una secuencia
histórica de actividades y eventos, algo que no es del todo aparente en un entorno de valor actual
donde solo se puede encontrar el valor más actual.
La estructura clave de los datos operativos puede o no contener algún elemento de tiempo, como
año, mes, día, etc. La estructura clave del almacén de datos siempre contiene algún elemento de
tiempo. La incrustación del elemento de tiempo puede adoptar muchas formas, como una marca
de tiempo en cada registro, una marca de tiempo para toda una base de datos, etc.
La estructura del almacén de datos
La figura 2.5 muestra que hay diferentes niveles de detalle en el almacén de datos.
Hay un nivel de detalle más antiguo (generalmente en almacenamiento masivo alternativo), un
nivel de detalle actual, un nivel de datos ligeramente resumidos (el nivel de data mart) y un nivel
de datos altamente resumidos. Los datos fluyen hacia el almacén de datos desde el entorno
operativo. Por lo general, se produce una transformación significativa de los datos al pasar del
nivel operativo al nivel del almacén de datos.
Una vez que los datos envejecen, pasan del detalle actual al detalle más antiguo. A medida que
los datos se resumen, pasan de los detalles actuales a los datos ligeramente resumidos, luego de
los datos ligeramente resumidos a los datos altamente resumidos.
Machine Translated by Google ventas mensuales
por línea de productos
1981–1992
altamente
resumido
ventas semanales por
metro
línea de subproductos
et ligeramente resumido
1984–1992
(mart de datos)
a
d
a
t
detalle detalle de ventas
a
actual 19901991
transformación
operativa
detalle de ventas
viejo detalle 19841989
Figura 2.5 La estructura del almacén de datos.
Orientación del tema
El almacén de datos está orientado a las principales áreas temáticas de la corporación
que se han definido en el modelo de datos corporativos de alto nivel. Las áreas temáticas
típicas incluyen lo siguiente:
■■ Cliente
■■ Producto
■■ Transacción o actividad
■■ Política
■■ Reclamo
■■ cuenta
Cada área temática principal se implementa físicamente como una serie de tablas
relacionadas en el almacén de datos. Un área temática puede constar de 10, 100 o incluso más
Machine Translated by Google cliente
datos básicos de datos básicos de actividad del cliente

clientes 1985–1987 clientes 1988–1990 19861989
Identificación del cliente Identificación del cliente Identificación del cliente

partir de la fecha de datos mes
hasta la fecha hasta la fecha número de transacciones
nombre nombre cantidad promedio de tx tx alto
DIRECCIÓN DIRECCIÓN tx bajo
fecha de nacimiento calificación crediticia
del teléfono empleador dob txs cancelado
sexo .......................
........ sexo
.........
detalle de la actividad detalle de la actividad
del cliente 19871989 del cliente 19901991
Identificación del cliente Identificación del cliente
cantidad de fecha de cantidad de fecha de
actividad actividad
ubicación ubicación
por artículo n º de pedido
factura no artículo de línea no
identificación del empleado cantidad de ventas
n º de pedido factura no
............ entregar a
.............
Figura 2.6 Los datos del almacén de datos están organizados por área temática principal, en este
caso, por cliente.
Machine Translated by Google tablas físicas que están todas relacionadas. Por ejemplo, la implementación del área
temática para un cliente podría parecerse a la que se muestra en la figura 2.6.
Hay cinco tablas físicas relacionadas en la figura 2.6, cada una de las cuales ha sido
diseñada para implementar una parte de un área temática importante: el cliente. Existe una
tabla base para la información de clientes definida desde 1985 hasta 1987. Existe otra para
la definición de datos de clientes entre 1988 y 1990. Existe una tabla de actividad acumulada
de clientes para actividades entre 1986 y 1989. Cada mes se realiza un registro resumen
para cada registro de cliente basado en la actividad del cliente para el mes.
Existen fichas detalladas de actividad por cliente de 1987 a 1989 y otra de 1990 a 1991. La
definición de los datos en las fichas es diferente según el año.
Todas las tablas físicas para el área de asunto del cliente están relacionadas por una clave
común. La figura 2.7 muestra que la clave (ID del cliente) conecta todos los datos
Identificación del cliente
de datos
Identificación del cliente hasta la fecha Identificación del cliente
partir de la fecha nombre mes
hasta la fecha DIRECCIÓN número de transacciones
nombre cantidad promedio de tx tx alto
calificación crediticia
DIRECCIÓN tx bajo
empleador dob
fecha de nacimiento
del teléfono
sexo txs cancelado
sexo ......... .......................
........
fecha de actividad
cantidad
ubicación
fecha de actividad
cantidad pedido sin
ubicación del artículo de línea no
artículo cantidad de ventas
factura no factura no
identificación del empleado
entregar a
n º de pedido
.............
............
Figura 2.7 Las colecciones de datos que pertenecen a la misma área temática están
unidas por una clave común.
Machine Translated by Google que se encuentra en el área de asunto del cliente. Otro aspecto interesante del área temática del
cliente es que puede residir en diferentes medios, como se muestra en la Figura 2.8.
No hay nada que diga que una tabla física debe residir en el disco, incluso si se relaciona con otros
datos que residen en un disco.
La figura 2.8 muestra que algunos de los datos del área temática relacionada residen en un dispositivo
de almacenamiento de acceso directo (DASD) y algunos residen en una cinta magnética. Una
implicación de los datos que residen en diferentes medios es que puede haber más de un DBMS
administrando los datos en un almacén o que algunos datos pueden no ser administrados por un
DBMS en absoluto. El hecho de que los datos residan en una cinta magnética o en algún otro medio
de almacenamiento que no sea el almacenamiento en disco no significa que los datos no formen
parte del almacén de datos.
Los datos que tienen una alta probabilidad de acceso y un bajo volumen de almacenamiento residen
en un medio que es rápido y relativamente costoso. Los datos que tienen una baja probabilidad de
acceso y son voluminosos residen en un medio que es más barato y más lento de acceder. Por lo
general (pero no siempre), los datos que son más antiguos tienen una menor probabilidad de acceso.
Por regla general, los datos más antiguos residen en un medio que no es el almacenamiento en disco.
DASD y la cinta magnética son los dos medios más populares para almacenar datos en un almacén
de datos. Pero no son los únicos medios; otros dos que no deben pasarse por alto son la ficha y el
disco óptico. La ficha es buena para almacenar
cliente
datos básicos de
clientes 1988–1990
datos básicos de
actividad del cliente
clientes 1985–1987
19861989
detalle de la actividad detalle de la actividad
del cliente 19871989 del cliente 1990–1991
Figura 2.8 El área temática puede contener datos en diferentes medios en el software de datos
casa.
Machine Translated by Google registros detallados que nunca más tendrán que ser reproducidos en un medio electrónico. Los registros
legales a menudo se almacenan en fichas por un período de tiempo indefinido.
El almacenamiento en disco óptico es especialmente bueno para el almacenamiento de datos porque es
económico, relativamente rápido y capaz de almacenar una gran cantidad de datos. Otra razón por la que el
disco óptico es útil es que los datos del almacén de datos, una vez escritos, rara vez se actualizan, si es que
se actualizan alguna vez. Esta última característica hace que el almacenamiento en disco óptico sea una
opción muy deseable para los almacenes de datos.
Otro aspecto interesante de los archivos (que se muestra en la Figura 2.8) es que hay un nivel de resumen y
un nivel de detalle para los mismos datos. Se resume la actividad por mes. El detalle que respalda la actividad
por mes se almacena en el nivel de datos de la cinta magnética. Esta es una forma de "cambio en la
granularidad", que se discutirá más adelante.
Cuando los datos se organizan en torno al sujeto, en este caso, el cliente, cada clave tiene un elemento de
tiempo, como se muestra en la Figura 2.9.
de datos
Identificación del cliente Identificación del cliente
hasta la fecha
partir de la fecha mes
nombre
hasta la fecha número de transacciones
DIRECCIÓN
nombre cantidad promedio de tx tx alto
calificación crediticia
DIRECCIÓN tx bajo
empleador dob
fecha de nacimiento
del teléfono txs cancelado
sexo
sexo .......................
.........
........
fecha de actividad
cantidad
ubicación
fecha de actividad
n º de pedido
cantidad
ubicación del artículo de línea no
artículo cantidad de ventas
factura no factura no
identificación del empleado
entregar a
n º de pedido
.............
............
Figura 2.9 Cada tabla en el almacén de datos tiene un elemento de tiempo como parte de la
estructura clave, generalmente la parte inferior.
Machine Translated by Google Algunas tablas están organizadas de fecha a fecha. Esto se llama una organización continua
de datos. Otras tablas se organizan sobre una base mensual acumulativa y otras sobre una
base de fecha de registro o actividad individual. Pero todos los registros tienen algún tipo de
fecha adjunta a la clave, generalmente en la parte inferior de la clave.
Día 1Día n Fenómeno
Los almacenes de datos no se construyen todos a la vez. En cambio, están diseñados y
poblados paso a paso y, como tales, son evolutivos, no revolucionarios. Los costos de construir
un almacén de datos de una sola vez, los recursos necesarios y la alteración del medio
ambiente dictan que el almacén de datos se construya de manera ordenada, iterativa y paso a
paso. El enfoque de “gran explosión” para el desarrollo de almacenes de datos es simplemente
una invitación al desastre y nunca es una alternativa adecuada.
La figura 2.10 muestra el proceso típico de construcción de un almacén de datos. El día 1 hay
una políglota de sistemas heredados que esencialmente realizan procesamiento transaccional
operativo. El día 2, se completan las primeras tablas de la primera área temática del almacén
de datos. En este punto, surge cierta curiosidad y los usuarios comienzan a descubrir los
almacenes de datos y el procesamiento analítico.
En el día 3, se llena una mayor parte del almacén de datos, y con la población de más datos
llegan más usuarios. Una vez que los usuarios encuentran que existe una fuente integrada de
datos a la que es fácil acceder y que tiene una base histórica diseñada para observar los datos
a lo largo del tiempo, hay más que curiosidad. Aproximadamente en este momento, el analista
serio de DSS se siente atraído por el almacén de datos.
El día 4, a medida que se llena más el almacén, algunos de los datos que residían en el
entorno operativo se colocan correctamente en el almacén de datos. Y el almacén de datos
ahora se descubre como una fuente para
haciendo el procesamiento analítico. Surgen todo tipo de aplicaciones DSS. De hecho, tantos
usuarios y tantas solicitudes de procesamiento, junto con un volumen bastante grande de
datos que ahora residen en el almacén, parecen desanimar a algunos usuarios por el esfuerzo
requerido para llegar al almacén de datos. La competencia por llegar al almacén se convierte
en un obstáculo para su uso.
El día 5, las bases de datos departamentales (data mart u OLAP) comienzan a florecer.
Los departamentos descubren que es más barato y más fácil realizar su procesamiento al
llevar los datos del almacén de datos a su propio entorno de procesamiento departamental. A
medida que los datos pasan al nivel departamental, se atraen algunos analistas de DSS.
día 1
sistemas existentes
almacén de datos
dia 2
1ra área temática
sistemas existentes
más temas
día 3
sistemas existentes
El almacén comienza
a llenarse por
completo y el acceso
día 4
a él
sistemas existentes
surge como un problema.
El almacén crece y
el nivel departamental
dia 5 de procesamiento
sistemas existentes comienza a florecer.
Más datos son
vertido en el
almacén de datos y
día 6 mucha atención
Operacional
ahora se centra en
los datos
departamentales, ya
que es más fácil de
llegar a.
día norte
Operacional
Figura 2.10 Fenómeno de día 1día n .
Machine Translated by Google El día 6 se produce la carrera de tierras hacia los sistemas departamentales. Es más barato,
más rápido y más fácil obtener datos departamentales que obtener datos del almacén de
datos. Pronto, los usuarios finales se separan del detalle del almacén de datos para
procesamiento departamental.
El día n, la arquitectura está completamente desarrollada. Todo lo que queda del conjunto
original de sistemas de producción es el procesamiento operativo. El almacén está lleno de datos.
Hay algunos usuarios directos del almacén de datos. Hay muchas bases de datos mentales
departamentales. La mayor parte del procesamiento analítico del DSS ocurre a nivel
departamental porque es más fácil y económico obtener allí los datos necesarios para el
procesamiento.
Por supuesto, la evolución del día 1 al día n lleva mucho tiempo. La evolución no ocurre en
cuestión de días. Varios años es la norma. Durante el proceso de pasar del día 1 al día n, el
entorno DSS está activo y funcional.
Tenga en cuenta que la telaraña parece haber reaparecido en una forma más grande y
grandiosa. No es así en absoluto, aunque la explicación es bastante compleja.
Consulte "El efecto gabinete", en la edición de mayo de 1991 de Diseño de programación de
bases de datos, para obtener una explicación detallada de por qué el entorno diseñado no es
simplemente una recreación del entorno de la telaraña.
El fenómeno del día 1día n que se describe aquí es la forma ideal de llegar al almacén de
datos. Hay muchos otros caminos. Uno de esos caminos es a través de la construcción de
data marts primero. Este camino es miope y conduce a una gran cantidad de desperdicio.
granularidad
El aspecto más importante del diseño de un almacén de datos es el tema de la granularidad.
De hecho, el problema de la granularidad impregna toda la arquitectura que rodea el entorno
del almacén de datos. La granularidad se refiere al nivel de detalle o resumen de las unidades
de datos en el almacén de datos. Cuanto más
detalle hay, menor es el nivel de granularidad. Cuanto menos detalle haya, mayor será el nivel
de granularidad.
Por ejemplo, una transacción simple tendría un bajo nivel de granularidad. Un resumen de
todas las transacciones del mes tendría un alto nivel de granularidad.
La granularidad de los datos siempre ha sido un problema de diseño importante. En los
primeros sistemas operativos, la granularidad se daba por sentada. Cuando se actualizan
datos detallados, es casi un hecho que los datos se almacenen en el nivel más bajo de
granularidad. Sin embargo, en el entorno del almacén de datos, no se asume la granularidad.
La figura 2.11 ilustra los problemas de granularidad.
granularidad—
el nivel de detalle
alto nivel de detalle—bajo bajo nivel de detalle—
nivel de granularidad alto nivel de granularidad
EJEMPLO: EJEMPLO: el
los detalles de cada resumen de las llamadas
llamada telefónica realizada telefónicas realizadas por un
por un cliente durante un mes cliente durante un mes
( )a
partición de datos
• la división de datos en pequeñas unidades •
hecho a nivel de aplicación o el
nivel DBMS
( )b
difícil de manejar
fácil de administrar
Figura 2.11 Principales problemas de diseño del almacén de datos: granularidad, partición y diseño adecuado.
La granularidad es el principal problema de diseño en el entorno del almacén de datos porque
afecta profundamente el volumen de datos que residen en el almacén de datos y el tipo de
consulta que se puede responder. El volumen de datos en un almacén se compensa con el
nivel de detalle de una consulta.
En casi todos los casos, los datos ingresan al almacén de datos con un nivel de granularidad
demasiado alto. Esto significa que el desarrollador debe gastar muchos recursos separando los
datos. Sin embargo, en ocasiones, los datos ingresan al almacén con un nivel de granularidad
demasiado bajo. Un ejemplo de datos con un nivel de granularidad demasiado bajo son los
datos de registro web generados por el entorno de comercio electrónico basado en la web. Los
datos de flujo de clics del registro web deben editarse, filtrarse y resumirse antes de que su
granularidad sea adecuada para el entorno del almacén de datos.
Machine Translated by Google Los beneficios de la granularidad
Muchas organizaciones se sorprenden al descubrir que el almacenamiento de datos
proporciona una base invaluable para muchos tipos diferentes de procesamiento de DSS. Las
organizaciones pueden construir un almacén de datos para un propósito, pero descubren que
se puede usar para muchos otros tipos de procesamiento de DSS. Aunque la infraestructura
para el almacén de datos es costosa y difícil de construir, debe construirse solo una vez. Una
vez que el almacén de datos se ha construido correctamente, proporciona a la organización
una base que es extremadamente flexible y reutilizable.
Los datos granulares que se encuentran en el almacén de datos son la clave para la
reutilización, porque muchas personas pueden usarlos de diferentes maneras. Por ejemplo,
dentro de una corporación, los mismos datos pueden usarse para satisfacer las necesidades
de marketing, ventas y contabilidad. Los tres departamentos analizan los mismos datos
básicos. Marketing puede querer ver ventas mensuales por distrito geográfico, ventas puede
querer ver ventas por vendedor por distrito de ventas semanalmente y finanzas puede querer
ver ingresos reconocibles trimestralmente por línea de producto. Todos estos tipos de
información están estrechamente relacionados, pero son ligeramente diferentes. Con un
almacén de datos, las diferentes organizaciones pueden ver los datos como desean verlos.
Mirar los datos de diferentes maneras es solo una de las ventajas de tener una base sólida.
Un beneficio relacionado es la capacidad de reconciliar datos, si es necesario. Una vez que
existe una base única en la que todos confían, si es necesario explicar una discrepancia en
los análisis entre dos o más departamentos, entonces la conciliación es relativamente simple.
Otro beneficio relacionado es la flexibilidad. Supongamos que marketing desea alterar la
forma en que ve los datos. Tener una base en su lugar permite que esto se logre fácilmente.
Otro beneficio de los datos granulares es que contienen un historial de actividades y eventos
en toda la corporación. Y el nivel de granularidad es lo suficientemente detallado como para
que los datos se puedan remodelar en toda la corporación para muchas necesidades diferentes.
Pero quizás el mayor beneficio de una base de almacenamiento de datos es que se pueden
acomodar futuros requisitos desconocidos. Supongamos que hay un nuevo requisito para
mirar los datos, o la legislatura estatal aprueba una nueva ley, o la OPEP cambia sus reglas
para la asignación de petróleo, o el mercado de valores se desploma. Hay un flujo constante
de nuevos requisitos de información porque el cambio es inevitable. Con el almacén de datos
implementado, la corporación puede responder fácilmente a los cambios.
Cuando surge un nuevo requisito y existe la necesidad de información, el almacén de datos
ya está disponible para el análisis y la organización está preparada para manejar los nuevos
requisitos.
Un ejemplo de granularidad
La figura 2.12 muestra un ejemplo de los problemas de granularidad. El lado izquierdo
muestra un bajo nivel de granularidad. Cada actividad, en este caso, una llamada telefónica,
se registra en detalle. Al final del mes, cada cliente tiene, en promedio, 200 registros (uno por
cada llamada telefónica registrada a lo largo del mes) que requieren alrededor de 40 000
bytes en conjunto.
El lado derecho de la figura muestra un mayor nivel de granularidad. Un alto nivel de detalle
se refiere a un bajo nivel de granularidad. Un bajo nivel de detalle se refiere a un alto nivel de
granularidad. Los datos que se muestran en la figura 2.12 tienen un alto nivel de granularidad.
Representa la información de resumen stet. Cada registro resume la actividad de un mes
para un cliente, lo que requiere alrededor de 200 bytes.
granularidad
alto nivel de detalle bajo nivel de detalle
EJEMPLO: EJEMPLO:
los detalles de cada llamada el resumen de las llamadas
telefónica realizada por un cliente telefónicas realizadas por un
durante un mes cliente durante un mes
40.000 bytes al mes 200 200 bytes
registros al mes 1 registro por mes
01 actividadrec. 02 01 actividadrec.
fecha 02 meses
02 tiempo 02 corridas
02 a quien 02 longitud media
02 op asistida 02 02 cumlongdistance 02
llamada completada 02 cuminterrupted
tiempo completado 02 ..................
larga distancia 02 celular
02 tarifa especial
...................
...................
Figura 2.12 Determinar el nivel de granularidad es el problema de diseño más importante
en el entorno del almacén de datos.
Machine Translated by Google Es obvio que si el espacio es un problema en un almacén de datos (y el volumen de datos es
siempre el primer y mayor problema en el almacén de datos), un alto nivel de granularidad es
una forma mucho más eficiente de representar datos que una representación usando un bajo
nivel de granularidad.
No solo se requieren muchos menos bytes de datos con un mayor nivel de granularidad, sino
que también se necesitan menos entradas de índice. Pero el volumen de datos y el tema del
espacio bruto no son los únicos temas relevantes. La cantidad de potencia de procesamiento
que se necesita usar frente a un gran volumen de datos para acceder a los datos también es
un factor.
Hay, entonces, un muy buen caso para la compactación de datos en un almacén de datos.
Cuando se compactan los datos, se pueden lograr ahorros significativos en la cantidad de
DASD utilizada, la cantidad de entradas de índice requeridas y los recursos de procesador
necesarios para manipular los datos.
Otro aspecto de la compactación de datos ocurre cuando se eleva el nivel de granularidad.
La figura 2.13 demuestra la compensación. A medida que aumenta el nivel de granularidad
de los datos, existe una pérdida correspondiente en la capacidad de responder consultas
utilizando los datos. Dicho de otro modo, con un nivel de granularidad muy bajo, puedes
responder prácticamente a cualquier consulta. Pero un alto nivel de granularidad limita el
número de preguntas que pueden manejar los datos.
Otra consideración al diseñar la granularidad es determinar qué entidades arquitectónicas se
alimentarán del almacén de datos. Cada entidad tiene sus propias consideraciones únicas. El
almacén de datos debe estar diseñado para alimentar el nivel más bajo de granularidad que
necesita cualquier entidad arquitectónica.
Para ilustrar el efecto de la granularidad en la capacidad de realizar consultas, en la Figura
2.13 se realiza la siguiente consulta: “¿Cass Squire llamó a su novia en Boston la semana
pasada?”
Con un bajo nivel de granularidad, la consulta puede ser respondida. Puede que se necesiten
muchos recursos para hojear muchos registros, pero al final del día, se puede determinar si
Cass llamó a su novia en Boston la semana pasada.
Pero con un alto nivel de detalle, no hay forma de responder definitivamente a la pregunta.
Si todo lo que se mantiene sobre Cass Squire en el almacén de datos es el número total de
llamadas que realizó durante una semana o un mes determinado, no se puede determinar si
una de esas llamadas fue a Boston.
Al realizar el procesamiento de DSS en el entorno del almacén de datos, es raro examinar un
solo evento. Una vista colectiva de los datos es mucho más común. Para lograr una vista
colectiva se requiere mirar una gran cantidad de registros.
Por ejemplo, supongamos que se realiza la siguiente consulta colectiva: "En promedio,
¿cuántas llamadas telefónicas de larga distancia hizo la gente de Washington el mes pasado?"
Machine Translated by Google granularidad
EJEMPLO: EJEMPLO:
los detalles de cada llamada el resumen de las llamadas
telefónica realizada por un cliente telefónicas realizadas por un
durante un mes cliente durante un mes
"¿Cass Squire llamó a su novia en Boston la
semana pasada?"
• Se puede responder, aunque se requiere • No se puede contestar en ningún caso El
cierta cantidad de excavación. detalle se ha ido.
Pero buscar un solo registro es un evento
muy poco común.
“En promedio, ¿cuántas llamadas telefónicas
de larga distancia hizo la gente de
Washington el mes pasado?”
busque a través de 175,000,000 busque a través de 1,750,000
registros, haciendo 45,000,000 I/Os registros, haciendo 450,000 E/S
Figura 2.13 El nivel de granularidad tiene un profundo efecto tanto sobre qué preguntas pueden
ser respondida y sobre qué recursos se requieren para responder una pregunta.
Este tipo de consulta es normal en un entorno DSS. Por supuesto, puede ser respondida
tanto por el alto como por el bajo nivel de granularidad. Sin embargo, al responderla, hay
una tremenda diferencia en los recursos utilizados. Un bajo nivel de granularidad requiere
clasificar cada registro, porque se requieren muchos recursos cuando se utilizan datos muy
detallados.
Pero usando el alto nivel de granularidad, los datos son mucho más compactos y pueden
proporcionar una respuesta con relativa rapidez. Si contiene suficientes detalles, los datos
con un alto nivel de granularidad son mucho más eficientes de usar.
Machine Translated by Google La Figura 2.14 muestra el compromiso de determinar el nivel de granularidad de los datos a
utilizar. Esta compensación se debe considerar con mucho cuidado al comienzo del diseño y la
construcción del almacén de datos.
Niveles duales de granularidad
La mayoría de las veces, existe una gran necesidad de eficiencia en el almacenamiento y acceso
a los datos, y de la capacidad de analizar los datos con gran detalle. (En otras palabras, ¡la
organización quiere tener su pastel y comérselo también!) Cuando una organización tiene muchos
datos en el almacén, tiene mucho sentido considerar dos (o más) niveles de granularidad en la
porción detallada de el almacén de datos. De hecho, existe tal necesidad de más de un nivel de
granularidad que un diseño de doble nivel de granularidad debería ser el predeterminado para
casi todas las tiendas. La figura 2.15 muestra dos niveles de granularidad en el nivel detallado del
almacén de datos.
Llamado nivel dual de granularidad, el diseño que se muestra en la figura 2.15 (una compañía
telefónica) se ajusta a las necesidades de la mayoría de las tiendas. Hay una enorme cantidad
de detalles a nivel operativo. La mayor parte de este detalle es necesario para los sistemas de
facturación. Hasta 30 días de detalle se almacenan en el nivel operativo.
El almacén de datos de este ejemplo contiene dos tipos de datos: datos ligeramente resumidos
y datos detallados de "archivo verdadero". Los datos en el almacén de datos pueden remontarse
a 10 años. Los datos que emanan del almacén de datos son datos de "distrito" que fluyen a los
diferentes distritos de la compañía telefónica. cada distrito
nivel de detalle: responda cualquier flexibilidad: volúmenes lo
pregunta suficientemente pequeños como
para poder manipularlos
grandes volúmenes de datos pequeños volúmenes
Figura 2.14 El compromiso con la granularidad es tan marcado que para la mayoría de las organizaciones
la mejor solución es alguna forma de múltiples niveles de granularidad.
Machine Translated by Google una compañía telefónica de dos
niveles de granularidad
• 30 días de historial de 10 años de actividad procesamiento

llamadas detallado • otra historial de llamadas distrito por distrito analítico
actividad del cliente
ligeramente resumido
la gestión de los volúmenes de
datos en los datos
nivel de almacén
verdadero archivo
Figura 2.15 El volumen de datos es tal que la mayoría de las organizaciones necesitan tener dos niveles de granularidad en el
almacén de datos.
luego analiza sus datos independientemente de otros distritos. Gran parte del
procesamiento analítico heurístico ocurre a nivel individual.
Los datos de un resumen ligero son datos detallados que se han resumido solo en una
medida muy pequeña. Por ejemplo, la información de la llamada telefónica se puede
resumir por hora. O la información de cheques bancarios puede resumirse por día.
La Figura 2.16 muestra tal resumen.
A medida que los datos pasan del almacén de datos operativo de 30 días, se resumen,
por cliente, en campos que es probable que se utilicen para el análisis DSS. El registro
de J Jones muestra la cantidad de llamadas realizadas por mes, la duración promedio de
cada llamada, la cantidad de llamadas de larga distancia realizadas, la cantidad de
llamadas asistidas por un operador, etc.
Hay un volumen de datos significativamente menor en la base de datos ligeramente
resumida que en la base de datos detallada. Por supuesto, hay un límite en el nivel de
detalle al que se puede acceder en la base de datos ligeramente resumida.
datos ligeramente resumidos
Detalle de 30 días ligeramente resumido
j jones Abril
12 de abril 6:01 pm a 6:12 pm 4155669982 j jones
asistido por operador número de llamadas 45
12 de abril 6:15 pm a 6:16 pm 4153348847 duración promedio de la llamada 14 minutos
larga distancia número de llamadas de larga distancia 18
12 de abril 18:23 a 18:38 número de llamadas asistidas por operador 2
4082237745 número de llamadas incompletas 1
13 de abril 9:12 am a 9:23 am
4082237745
13 de abril 10:15 am a 10:21 am 4082237745
asistido por operador número de bytes necesarios para albergar un
15 de abril 11:01 am a 11:21 am 4159644738 registro: 225
15 de abril 11:39 am a 12:01 pm
7035705770 incompleto
15 de abril 12:10 a 12:46
7038415770 número equivocado
16 de abril 12:34 a 12:56
4159643130
...............................
...............................
Para un solo cliente durante un mes, se requiere
un promedio de 45.000 bytes para albergar 200
registros.
Figura 2.16 Con datos de resumen ligero, se pueden representar grandes cantidades de datos de
forma compacta.
El segundo nivel de datos en el almacén de datos, el nivel más bajo de granularidad, se
almacena en el verdadero nivel de archivo de datos, como se muestra en la Figura 2.17.
En el verdadero nivel de archivo de datos, se almacenan todos los detalles provenientes del
entorno operativo. Realmente hay una multitud de datos a este nivel. Por esa razón, tiene
sentido almacenar los datos en un medio como una cinta magnética u otro medio de
almacenamiento masivo porque el volumen de datos es muy grande.
Al crear dos niveles de granularidad en el almacén de datos, el arquitecto de DSS ha matado
dos pájaros de un tiro: la mayor parte del procesamiento de DSS se realiza contra
Machine Translated by Google Abril
j jones
número de llamadas 45
duración promedio de la llamada 14 minutos
número de llamadas de larga distancia 18 número
de llamadas asistidas por operador 2 número de
llamadas incompletas 1
ligeramente resumido
El 95 % o más del
procesamiento de DSS se realiza aquí
j jones
12 de abril 6:01 pm a 6:12 pm 4155669982
asistido por operador
5% o menos del
12 de abril 6:15 pm a 6:16 pm 4153348847 verdadero archivo
larga distancia procesamiento de DSS realizado aquí
12 de abril 6:23 pm a 6:38 pm 4082237745
• lento • complejo • $$$$
13 de abril 9:12 am a 9:23 am
4082237745
13 de abril 10:15 am a 10:21 am 4082237745
asistido por operador
15 de abril 11:01 am a 11:21 am 4159644738
15 de abril 11:39 am a 12:01 pm 7035705770
incompleto
15 de abril 12:10 pm a 12:46 pm 7038415770
número equivocado
16 de abril 12:34 a 12:56
4159643130
...............................
...............................
Figura 2.17 Los niveles duales de granularidad le permiten procesar la mayoría de las solicitudes de manera eficiente
cientemente y responda cualquier pregunta que pueda ser respondida.
los datos ligeramente resumidos, donde los datos son compactos y se accede de manera
eficiente. Cuando se requiere un mayor nivel de detalle (5 por ciento del tiempo o menos), existe
el verdadero nivel de archivo de datos. Es costoso, engorroso y complejo acceder a los datos en
el verdadero nivel de granularidad del archivo, pero si existe, estará allí cuando sea necesario.
Si con el tiempo se desarrolla un patrón de búsqueda del verdadero nivel de archivo de los datos,
el diseñador puede querer crear algunos nuevos campos de datos en el nivel ligeramente
resumido, para que la mayor parte del procesamiento pueda ocurrir allí.
Debido a los costos, la eficiencia, la facilidad de acceso y la capacidad de responder a cualquier
consulta que se pueda responder, el nivel dual de datos es la mejor opción de arquitectura para
el nivel detallado del almacén de datos para la mayoría de las tiendas. un solo
Machine Translated by Google nivel de datos solo debe intentarse cuando una tienda tiene una cantidad relativamente pequeña
de datos en el entorno del almacén de datos.
Exploración y Minería de Datos
Los datos granulares que se encuentran en el almacén de datos admiten más que data marts.
También soporta los procesos de exploración y minería de datos. La exploración y la extracción
de datos toman una gran cantidad de datos históricos detallados y los examinan en busca de
patrones de actividad comercial previamente desconocidos.
El almacén de datos contiene una fuente de datos muy útil para el explorador y el minero de
datos. Los datos que se encuentran en el almacén de datos se limpian, integran y organizan. Y
los datos son históricos. Esta base es precisamente lo que necesitan el minero de datos y el
explorador para iniciar la actividad de exploración y minería de datos. Cabe señalar que, si bien
el almacén de datos proporciona una excelente fuente de datos para el minero y el explorador, el
almacén de datos a menudo no es la única fuente. Los datos externos y otros datos se pueden
mezclar libremente con los datos del almacén de datos en el curso de la exploración y la minería.
Consulte el libro Exploration Warehousing (Wiley, 2000) para obtener más información sobre este
tema.
Base de datos de muestra viva
Ocasionalmente, es necesario crear un tipo diferente de almacén de datos. Algunas veces
simplemente hay demasiados datos para el acceso y análisis normales. Cuando esto sucede, se
pueden utilizar enfoques de diseño especiales.
Una forma híbrida interesante de un almacén de datos es la base de datos de muestra viva, que
es útil cuando el volumen de datos en el almacén ha crecido mucho.
La base de datos de muestra viva se refiere a un subconjunto de datos de archivo verdaderos o
datos ligeramente resumidos tomados de un almacén de datos. El término "vivo" proviene del
hecho de que es un subconjunto, una muestra, de una base de datos más grande, y el término
"muestra" proviene del hecho de que la base de datos debe actualizarse periódicamente. La
figura 2.18 muestra una base de datos de muestra viva.
En algunas circunstancias (por ejemplo, el análisis estadístico de una población o la presentación
de perfiles), una base de datos de muestra viva puede ser muy útil y puede ahorrar una gran
cantidad de recursos. Pero existen algunas restricciones severas, y el diseñador no debe construir
una base de datos de este tipo como parte del almacén de datos a menos que sea consciente de
las limitaciones.
almacén de datos
“De todos nuestros asegurados, ¿cuántos son
hombres mayores de 35 años que están casados y
tienen títulos universitarios?”
datos de muestra vivos
• una fracción de datos en el almacén
• utilizado para la formulación muy eficiente de una consulta
• no se puede usar para
análisis de propósito general; solo se
poder puede usar para análisis estadístico
Figura 2.18 Living simple data: otra forma de cambiar la granularidad de los datos.
Una base de datos de muestra viva no es una base de datos de propósito general. Si
quisiera averiguar si J Jones es un cliente, no buscaría esa información en una base de
datos de muestra viva. Es absolutamente posible que J Jones sea un cliente pero no
esté registrado en la muestra viva. Estas bases de datos son buenas para el análisis
estadístico y la observación de tendencias, y pueden ofrecer algunos resultados muy
prometedores cuando los datos deben analizarse colectivamente. No son del todo útiles
para tratar con registros individuales de datos.
Uno de los aspectos importantes de la construcción de una base de datos de muestra
viva es cómo se cargan los datos, lo que determina la cantidad de datos en la base de
datos y qué tan aleatorios serán los datos. Considere cómo se carga normalmente una
base de datos de muestra activa. Un programa de extracción/selección hurga en una
gran base de datos, eligiendo cada centésima o cada milésima de registro. Luego, el
registro se envía a la base de datos de muestras vivas. La base de datos de muestra
viva resultante, entonces, es una centésima o una milésima parte del tamaño de la base
de datos original. La consulta que opera en esta base de datos usa una centésima o
una milésima parte de los recursos como una consulta que operaría directamente en el
almacén de datos completo.
La selección de registros para su inclusión en la muestra viva suele ser aleatoria.
En ocasiones, se toma una muestra de juicio, en la que un registro debe cumplir con
ciertos criterios para ser seleccionado. El problema con las muestras de juicio es que
casi siempre introducen sesgos en los datos de la muestra viva. El problema con una
selección aleatoria de datos es que puede no producir significación estadística. Pero
como sea que se haga, se selecciona un subconjunto del almacén de datos para la
muestra viva. El hecho de que un registro dado no se encuentre en la base de datos de muest
Machine Translated by Google no significa nada porque el procesamiento que opera contra la muestra viva no requiere que
todos los registros en el almacén de datos estén en la muestra viva.
El mayor activo de una base de datos de muestra viva es que es muy eficiente para acceder.
Debido a que su tamaño es una fracción de la base de datos más grande de la que se deriva, en
consecuencia, es mucho más eficiente para acceder y analizar.
Dicho de otra manera, supongamos que un analista tarda 24 horas en escanear y analizar una
gran base de datos. Puede tomar tan solo 10 minutos escanear y analizar una base de datos de
muestra viva. Al realizar un análisis heurístico, el tiempo de respuesta es crucial para el análisis
que se puede realizar. En el análisis heurístico, el analista ejecuta un programa, estudia los
resultados, reformula el programa y lo vuelve a ejecutar. Si se tarda 24 horas en ejecutar el
programa, el proceso de análisis y reformulación se ve muy perjudicado (sin mencionar los
recursos necesarios para hacer la reformulación).
Con una base de datos de muestra viva lo suficientemente pequeña como para escanearla en 10
minutos, el analista puede pasar por el proceso iterativo muy rápidamente. En resumen, la
productividad del analista DSS depende de la velocidad con la que se dé la vuelta al análisis que
se está realizando.
Un argumento afirma que hacer un análisis estadístico arroja respuestas incorrectas.
Por ejemplo, un analista puede compararse con un gran archivo de 25 millones de registros para
determinar que el 56,7 % de los conductores en la carretera son hombres. Utilizando una base
de datos de muestra viva, el analista utiliza 25.000 registros para determinar que el 55,9 por
ciento de los conductores en la carretera son hombres. Un análisis ha requerido muchos más
recursos que el otro, pero la diferencia entre los cálculos es muy pequeña. Sin duda, el análisis
contra la gran base de datos fue más preciso, pero el costo de esa precisión es exorbitante,
especialmente frente al procesamiento heurístico, donde las iteraciones de procesamiento son la
norma.
Si se desean grados muy altos de precisión, una técnica útil es formular la solicitud y pasar por
el procesamiento iterativo en la base de datos de muestras vivas. Al hacerlo, el analista de DSS
formula rápidamente la solicitud. Luego, después de realizar varias iteraciones de análisis, cuando
se comprende la solicitud, se ejecuta una última vez en la base de datos grande.
Los datos de muestra vivos son solo una forma más de cambiar el nivel de granularidad en el
almacén de datos para acomodar el procesamiento de DSS.
Particionamiento como un enfoque de diseño
Un segundo problema importante de diseño de datos en el almacén (después de la granularidad)
es el de la partición (consulte la Figura 2.11b). La partición de datos se refiere a la
Machine Translated by Google desglose de datos en unidades físicas separadas que se pueden manejar de forma independiente.
En el almacén de datos, los problemas relacionados con el particionamiento no se centran en si se
debe realizar el particionamiento, sino en cómo se debe realizar.
A menudo se dice que si tanto la granularidad como la partición se realizan correctamente, casi todos
los demás aspectos del diseño y la implementación del almacén de datos resultan sencillos. Si la
granularidad no se maneja adecuadamente y si la partición no se diseña e implementa con cuidado,
entonces ningún otro aspecto del diseño realmente importa.
La partición adecuada puede beneficiar al almacén de datos de varias maneras:
■■ Carga de datos
■■ Acceso a datos ■■
Archivo de datos ■■
Eliminación de datos ■■
Monitoreo de datos ■■
Almacenamiento de datos
Particionar los datos correctamente permite que los datos crezcan y se administren. No particionar los
datos correctamente no permite que los datos se administren o crezcan correctamente.
Por supuesto, hay otros aspectos importantes del diseño del almacén de datos que se analizarán en
capítulos posteriores.
Particionamiento de datos
En el entorno del almacén de datos, la pregunta no es si se dividirán los datos detallados actuales, sino
cómo se dividirán los datos detallados actuales. La figura 2.19 ilustra la partición.
El propósito de particionar los datos detallados actuales es dividir los datos en unidades físicas
pequeñas y manejables. ¿Por qué es esto tan importante? El personal de operaciones y el diseñador
tienen más flexibilidad en la gestión de pequeñas unidades físicas de datos que en las grandes.
Las siguientes son algunas de las tareas que no se pueden realizar fácilmente cuando los datos residen
en grandes unidades físicas:
■■ Reestructuración
■■ Indexación
■■ Escaneo secuencial, si es necesario
■■ Reorganización
Machine Translated by Google ■■ Recuperación
■■ Monitoreo
En definitiva, una de las esencias del data warehouse es el acceso flexible a los datos.
Grandes masas de datos anulan gran parte del propósito del almacén de datos.
Por lo tanto, se dividirán todos los datos del almacén de datos de detalle actual.
Los datos se dividen cuando los datos de una estructura similar se dividen en más de una
unidad física de datos. Además, cualquier unidad de datos dada pertenece a una y solo
una partición.
partición de datos
Las pequeñas unidades de datos pueden ser:
• reestructurado •
indexado
• escaneado secuencialmente, si es necesario
• reorganizado • recuperado
• supervisado
1989
1988
Las unidades de datos gestionadas de forma
independiente pueden tener diferentes definiciones.
1990
1991
1987
complejo de
procesamiento A
complejo de
procesamiento B
Figura 2.19 Las particiones de datos administradas de forma independiente se pueden enviar a diferentes
complejos de procesamiento sin otras consideraciones del sistema.
Machine Translated by Google Los datos se pueden dividir por muchos criterios, tales como:
■■ Por fecha
■■ Por línea de negocio
■■ Por geografía
■■ Por unidad organizativa
■■ Por todo lo anterior
Las opciones para particionar los datos dependen estrictamente del desarrollador. Sin embargo, en el entorno del almacén de
datos, es casi obligatorio que uno de los criterios para la partición sea por fecha.
Como ejemplo de cómo una compañía de seguros de vida puede elegir dividir sus datos, considere las siguientes unidades
físicas de datos:
■■ 2000 declaraciones de propiedades saludables
■■ Declaraciones de propiedades saludables de 2001
■■ Declaraciones de propiedades saludables de 2002
■■ Reclamos de vida de 1999
■■ 2000 siniestros de vida
■■ 2000 reclamos por siniestros
■■ Reclamaciones por siniestros de 2001
■■ Reclamaciones por siniestros de 2002
La compañía de seguros ha utilizado los criterios de fecha, es decir, año, y tipo de siniestro para particionar los datos.
La partición se puede hacer de muchas maneras. Uno de los principales problemas que enfrenta el desarrollador del almacén
de datos es si la partición se realiza a nivel del sistema o de la aplicación. La partición a nivel del sistema es una función del
DBMS y del sistema operativo hasta cierto punto. El particionamiento a nivel de la aplicación se realiza mediante el código de
la aplicación y está controlado única y estrictamente por el desarrollador y el programador, por lo que el DBMS y el sistema
no conocen ninguna relación entre una partición y la otra.
Como regla general, tiene sentido particionar los datos del almacén de datos en el nivel de la aplicación. Hay algunas razones
importantes para esto. Lo más importante es que a nivel de aplicación puede haber una definición diferente de datos para
cada año.
Puede haber una definición de datos de 2000 y puede haber una definición de datos de 2001,
Machine Translated by Google que puede o no ser lo mismo. La naturaleza de los datos en un almacén es la recopilación de
datos durante un largo período de tiempo.
Cuando la partición se realiza a nivel del sistema, el DBMS inevitablemente requiere que haya
una sola definición de datos. Dado que el almacén de datos almacena datos durante un largo
período de tiempo (hasta 10 años) y dado que la definición cambia regularmente, no tiene
sentido permitir que el DBMS o el sistema operativo dicten que debe haber una única definición
de datos.
Al permitir que la partición de datos se administre a nivel de aplicación en lugar de a nivel de
DBMS, los datos se pueden mover de un complejo de procesamiento a otro con impunidad.
Cuando la carga de trabajo y el volumen de datos se convierten en una carga real en el entorno
del almacén de datos, esta característica puede ser una verdadera ventaja.
La prueba de fuego para la partición de datos es hacer la pregunta: "¿Se puede agregar un
índice a una partición sin interrupción perceptible de otras operaciones?" Si se puede agregar
un índice a voluntad, entonces la partición está lo suficientemente bien. Si un índice no se puede
agregar fácilmente, entonces la partición debe desglosarse más finamente.
Estructuración de datos en el almacén de datos
Hasta ahora, no hemos analizado cómo son realmente las estructuras de datos que se
encuentran en el almacén de datos. Muchos tipos de estructuras se encuentran en el almacén
de datos. Ahora veremos algunos de los más comunes.
Quizás la estructura de datos más simple y común que se encuentra en el almacén de datos
es la estructura acumulativa simple, que se muestra en la Figura 2.20.
La figura 2.20 muestra las transacciones diarias que se transportan desde el entorno operativo.
Después de eso, se resumen en registros del almacén de datos, que pueden ser por cliente,
por cuenta o por cualquier área temática en el almacén de datos. Las transacciones de la figura
2.20 se resumen por día. En otras palabras, toda la actividad diaria de un cliente para una
cuenta se totaliza y pasa al almacén de datos día a día.
La figura 2.21 muestra una variación de la acumulación diaria simple denominada
almacenamiento de datos resumidos continuos.
Los datos pasan del entorno operativo al entorno del almacén de datos como lo hacía
anteriormente. Sin embargo, en los datos de resumen continuo, los datos se ingresan en una
estructura muy diferente. Durante los primeros siete días de la semana, la actividad se resume
en siete franjas horarias diarias. En el octavo día, los siete espacios diarios se suman y se
colocan en el primer espacio semanal. Luego, los totales diarios se agregan a la primera ranura
diaria.
Machine Translated by Google datos acumulativos simples
transacciones diarias
Datos operacionales
resumen diario
1 de enero 2 de enero 3 de enero . . .
1 de febrero 2 de febrero 3 de febrero . . .
1 de marzo 2 de marzo 3 de marzo . . .
. . . . . . . . . . . . . .
Figura 2.20 La forma más simple de datos en el almacén de datos son los datos que se han
acumulados registro por registro, denominados datos acumulativos simples.
transacciones diarias
Datos operacionales a diario
resumen
día 1 día 2 día 3 . . . día 7
semana 1 semana 2 semana 3 . . . semana 5
lun 1 lun 2 lun 3 . . . lunes 12
año 1 año 2 año 3 . . . año norte
Figura 2.21 Una variación del archivo acumulativo es el archivo de resumen continuo.
Machine Translated by Google Al final del mes, los espacios semanales se suman y se colocan en el primer espacio mensual.
Luego, los espacios semanales se restablecen a cero. Al final del año, se suman los espacios
mensuales y se carga el primer espacio anual.
Luego, las franjas horarias mensuales se restablecen a cero.
Una estructura de datos de resumen continuo maneja muchas menos unidades de datos que
una simple estructuración acumulativa de datos. En la Figura 2.22 se muestra una comparación
de las ventajas y desventajas del resumen continuo frente a la estructuración acumulativa simple
de datos.
Otra posibilidad para la estructuración de los datos del almacén de datos es el archivo directo
simple, que se muestra en la Figura 2.23.
La figura 2.23 muestra que los datos simplemente se extraen del entorno operativo al entorno
del almacén de datos; no hay acumulación. Además, el archivo directo simple no se realiza a
diario. En cambio, se realiza durante un período de tiempo más largo, como una semana o un
mes. Como tal, el archivo directo simple representa una instantánea de los datos operativos
tomados en un instante en el tiempo.
Se puede crear un archivo continuo a partir de dos o más archivos directos simples, como se
muestra en la Figura 2.24. Dos instantáneas, una de enero y otra de febrero, son
datos resumidos continuos
día 1 día 2 día 3 . . . día 7
• muy compacto •
semana 1 semana 2 semana 3 . . . semana 5 cierta pérdida de detalles •
cuanto más antiguos se vuelven los datos, menos
detalles se conservan
lun 1 lun 2 lun 3 . . . lunes 12
año 1 año 2 año 3 . . . año norte
datos acumulativos simples
1 de enero 2 de enero 3 de enero . . . • se requiere mucho almacenamiento
• sin pérdida de detalles
• mucho procesamiento para hacer cualquier cosa
1 de febrero 2 de febrero 3 de febrero . . .
con los datos
1 de marzo 2 de marzo 3 de marzo . . .
Figura 2.22 Comparación de datos acumulativos simples con datos de resumen continuo.
Machine Translated by Google Clientes de enero
j adams Calle principal 123
P. Anderson 456 Calle principal
Calle K Appleby 10 A
L Azimoff 64 N Ranch Rd
..........................
Datos operacionales
Figura 2.23 Creación de un archivo continuo a partir de archivos directos.
Clientes de enero clientes de febrero
W Abraham 12 Carretera 9
P. Anderson 456 Calle principal
P Anderson 1455 Tincup Ct
L Azimoff 64 N Ranch Rd Calle K Appleby 10 A
..........................
..........................
j adams Ene–pres 123 Main Street
W Abraham Feb–pres 12 Hwy 9
P Anderson Ene–Ene 456 High Street
P Anderson Febpres 1455 Tincup Ct
K Appleby Ene–pres 10 A Street
L Azimoff Ene–pres 64 N Ranch Rd
.............................................
Figura 2.24 Creación de un archivo continuo a partir de archivos directos.
combinados para crear un archivo continuo de datos. Los datos en el archivo continuo
representan los datos continuamente desde el primer mes hasta el último.
Por supuesto, se puede crear un archivo continuo agregando una instantánea de los datos
a una versión anterior del archivo continuo, como se muestra en la Figura 2.25.
Machine Translated by Google archivo continuo clientes de marzo
j adams Ene–pres 123 Main Street
W Abraham 12 Carretera 9
W Abraham Feb–pres 12 Hwy 9
P Anderson Ene–Ene 456 High Street
P Anderson Febpres 1455 Tincup Ct
..........................
K Appleby Ene–pres 10 A Street
L Azimoff Ene–pres 64 N Ranch Rd
j adams ene–pres Calle principal 123

Abraham febpres 12 Carretera 9
P Anderson Ene–Ene Calle principal 456
P Anderson febrerofebrero 1455 Tincup Ct
K Appleby ene–pres Calle 10A
L Azimoff ene–pres 64 N Ranch Rd
.............................................
Figura 2.25 Los archivos continuos se pueden crear a partir de archivos directos simples, o pueden tener
archivos directos simples adjuntos a ellos.
Hay muchas más formas de estructurar los datos dentro del almacén de datos. Los
más comunes son estos:
■■ acumulativo simple
■■ Resumen continuo
■■ Simple directo
■■ Continuo
A nivel de clave, las claves del almacén de datos son inevitablemente claves
compuestas. Hay dos razones convincentes para esto: ■■ La fecha (año, año/mes,
año/mes/día, etc.) casi siempre es parte de la clave.
■■ Debido a que los datos del almacén de datos están particionados, los diferentes componentes de
la partición aparece como parte de la clave.
Almacén de datos: el manual de estándares
El almacén de datos es relevante para muchos gerentes de personas, analistas de DSS, desarrolladores,
planificadores, etc. En la mayoría de las organizaciones, el almacén de datos es nuevo.
En consecuencia, debe haber una explicación organizacional oficial y una descripción de lo que hay en
el almacén de datos y cómo se puede utilizar el almacén de datos.
Llamar a la explicación de lo que hay dentro del almacén de datos un "manual de estándares" es
probablemente mortal. Los manuales de normas tienen una connotación lúgubre y son famosos por ser
ignorados y acumular polvo. Sin embargo, alguna forma de publicación interna es un esfuerzo necesario
y valioso.
El tipo de cosas que debe contener la publicación (¡como se llame!) son las siguientes:
■■ Una descripción de lo que es un almacén de datos
■■ Una descripción de los sistemas fuente que alimentan el almacén
■■ Cómo utilizar el almacén de datos
■■ Cómo obtener ayuda si hay un problema
■■ ¿ Quién es responsable de qué?
■■ El plan de migración para el almacén
■■ Cómo se relacionan los datos del almacén con los datos operativos
■■ Cómo usar los datos del almacén para DSS
■■ Cuándo no agregar datos al almacén
■■ Qué tipo de datos no están en el almacén
■■ Una guía de los metadatos que están disponibles
■■ ¿ Qué es el sistema de registro?
Auditoría y Data Warehouse
Una cuestión interesante que surge con los almacenes de datos es si se puede o se debe realizar una
auditoría desde ellos. La auditoría se puede realizar desde el almacén de datos. En el pasado ha habido
algunos ejemplos de auditorías detalladas realizadas allí. Pero hay muchas razones por las que la
auditoría, incluso si se puede realizar desde el almacén de datos, no se debe realizar desde allí. Las
principales razones para no hacerlo son las siguientes:
■■ Los datos que, de otro modo, no llegarían al almacén, de repente tienen que estar allí.
Machine Translated by Google ■■ El momento de la entrada de datos en el almacén cambia drásticamente cuando se requiere capacidad
de auditoría.
■■ Las restricciones de copia de seguridad y recuperación para el almacén de datos cambian drásticamente
ticamente cuando se requiere la capacidad de auditar.
■■ La auditoría de datos en el almacén obliga a que la granularidad de los datos en el almacén se
encuentre en el nivel más bajo.
En resumen, es posible auditar desde el entorno del almacén de datos, pero debido a las complicaciones
involucradas, tiene mucho más sentido auditar en otro lugar.
Justificación de costos
La justificación de costos para el almacén de datos normalmente no se realiza sobre la base del retorno
de la inversión (ROI) a priori. Para realizar dicho análisis, se deben conocer los beneficios antes de
construir el almacén de datos.
En la mayoría de los casos, los beneficios reales del almacén de datos no se conocen ni se anticipan
antes de que comience la construcción porque el almacén se usa de manera diferente a otros datos y
sistemas creados por los sistemas de información. A diferencia de la mayoría de los procesamientos de
información, el almacén de datos existe en un ámbito de "Dame lo que digo que quiero, luego puedo
decirte lo que realmente quiero". El analista de DSS realmente no puede determinar las posibilidades y
los potenciales del almacén de datos, ni cómo y por qué se utilizará, hasta que esté disponible la primera
iteración del almacén de datos. El analista opera en un modo de descubrimiento, que no puede comenzar
hasta que el almacén de datos esté funcionando en su primera iteración. Solo entonces el analista de
DSS puede comenzar a desbloquear el potencial del procesamiento de DSS.
Por esta razón, las técnicas clásicas de ROI simplemente no se aplican al entorno de almacenamiento
de datos. Afortunadamente, los almacenes de datos se construyen de forma incremental. La primera
iteración se puede hacer rápidamente y por una cantidad de dinero relativamente pequeña.
Una vez que se crea y completa la primera parte del almacén de datos, el analista puede comenzar a
explorar las posibilidades. Es en este punto que el analista puede comenzar a justificar los costos de
desarrollo del almacén.
Como regla general, la primera iteración del almacén de datos debe ser lo suficientemente pequeña para
ser construida y lo suficientemente grande para ser significativa. Por lo tanto, la casa de almacenamiento
de datos se construye mejor una pequeña iteración a la vez. Debe haber una retroalimentación directa.
bucle entre el desarrollador del depósito y el analista de DSS, en el que modifican constantemente los
datos existentes del depósito y agregan otros datos al depósito. Y la primera iteración debe hacerse
rápidamente. Se dice que el diseño inicial del almacén de datos es un éxito si tiene una precisión del 50
por ciento.
Machine Translated by Google Por lo general, el almacén de datos inicial se centra en una de estas áreas funcionales:
■■ Finanzas
■■ Comercialización
■■ Ventas
Ocasionalmente, la primera área funcional del almacén de datos se centrará en una de estas
áreas:
■■ Ingeniería/fabricación
■■ Intereses actuariales
Justificación de su almacén de datos
No se puede evitar el hecho de que los almacenes de datos cuestan dinero. Los datos, los
procesadores, las comunicaciones, el software, las herramientas, etc., cuestan dinero. De
hecho, los volúmenes de datos que se agregan y recopilan en el almacén de datos van mucho
más allá de cualquier cosa que la corporación haya visto jamás. El nivel de detalle y la historia
de ese detalle suman una gran cantidad de dinero.
En casi todos los demás aspectos de la tecnología de la información, la mayor inversión para
un sistema radica en crear, instalar y establecer el sistema. Los costos continuos de
mantenimiento de un sistema son minúsculos en comparación con los costos iniciales.
Sin embargo, establecer la infraestructura inicial del almacén de datos no es el costo más
significativo: los costos continuos de mantenimiento superan con creces los costos de
infraestructura inicial. Hay varias buenas razones por las que los costos de un almacén de
datos son significativamente diferentes del costo de un sistema estándar:
■■ El volumen verdaderamente enorme de datos que ingresa al almacén de datos.
■■ El costo de mantener la interfaz entre el almacén de datos y las fuentes operativas. Si la
organización ha elegido una herramienta de extracción/transferencia/carga (ETL), estos
costos se mitigan con el tiempo; si una organización ha optado por construir la interfaz
manualmente, entonces los costos de mantenimiento se disparan.
■■ El hecho de que un almacén de datos nunca se termina. Incluso después de los pocos primeros
las iteraciones del almacén de datos se completan con éxito, agregar más áreas
temáticas al almacén de datos es una necesidad constante.
Informes de costos de ejecución
¿Cómo justifica una organización los costos de un almacén de datos antes de construir el
almacén de datos? Hay muchos enfoques. Discutiremos uno en profundidad aquí, pero tenga
en cuenta que hay muchas otras formas de justificar un almacén de datos.
Machine Translated by Google Elegimos este enfoque porque es simple y porque se aplica a todas las organizaciones. Cuando la
justificación se presenta correctamente, es muy difícil negar las poderosas justificaciones de costos de un
almacén de datos. Es un argumento que tanto los técnicos como los no técnicos pueden apreciar y
comprender.
El almacenamiento de datos reduce el costo de la información en aproximadamente dos órdenes de
magnitud. Esto significa que con un almacén de datos una organización puede acceder a una pieza de
información por $100; una organización que no tiene un almacén de datos puede acceder a la misma
unidad de información por $10,000.
¿Cómo demuestra que el almacenamiento de datos reduce considerablemente el costo de la información?
En primer lugar, utilice un informe. No es necesario que sea un informe real. Puede ser una pantalla, un
informe, una hoja de cálculo o algún tipo de análisis que demuestre la necesidad de información en la
corporación. En segundo lugar, debe observar su entorno heredado, que incluye aplicaciones únicas o
múltiples, aplicaciones antiguas y nuevas. Las aplicaciones pueden ser aplicaciones de planificación de
recursos empresariales (ERP), aplicaciones que no son de ERP, aplicaciones en línea o aplicaciones
fuera de línea.
Ahora considere dos empresas, la empresa A y la empresa B. Las empresas son idénticas con respecto a
sus aplicaciones heredadas y su necesidad de información.
La única diferencia entre los dos es que la empresa B tiene un almacén de datos desde el que generar
informes y la empresa A no.
La empresa A recurre a sus aplicaciones heredadas para recopilar información. Esta tarea incluye lo
siguiente:
■■ Encontrar los datos necesarios para el informe ■■
Acceder a los datos ■■ Integrar los datos ■■ Fusionar
los datos ■■ Crear el informe
Encontrar los datos no puede ser una tarea fácil. En muchos casos, los sistemas heredados no están
documentados. Hay un dicho consagrado: los verdaderos programadores no documentan. Esto volverá a
atormentar a las organizaciones, ya que simplemente no hay una manera fácil de volver y averiguar qué
datos hay en los antiguos sistemas heredados y qué procesamiento se ha producido allí.
Acceder a los datos es aún más difícil. Algunos de los datos heredados están en el Sistema de gestión
de la información (IMS), algunos en el Modelo 204, algunos en Adabas. Y ya no existe la experiencia en
tecnología IMS, Model 204 y Adabas.
La tecnología que alberga el entorno heredado es un misterio. E incluso si se puede acceder al entorno
heredado, el departamento de operaciones informáticas se interpone porque no quiere que nada se
interponga en el camino de la ventana de procesamiento en línea.
Machine Translated by Google Si se puede encontrar y acceder a los datos, es necesario integrarlos. Los informes normalmente necesitan
información de múltiples fuentes. El problema es que esas fuentes nunca fueron diseñadas para funcionar
juntas. Un cliente en un sistema no es un cliente en otro sistema, una transacción en un sistema es diferente
de una transacción en otro sistema, y así sucesivamente. Debe llevarse a cabo una enorme cantidad de
conversión, reformateo, interpretación y similares para integrar datos de múltiples sistemas.
Fusionar los datos es fácil en algunos casos. Pero en el caso de grandes cantidades de datos o en el caso de
datos provenientes de múltiples fuentes, la fusión de datos puede ser una operación bastante complicada.
Finalmente, se construye el informe.
¿Cuánto tiempo lleva este proceso para la empresa A? ¿Cuánto cuesta?
Dependiendo de la información que se necesite y del tamaño y estado del entorno de los sistemas heredados,
puede tomar una cantidad de tiempo considerable y un alto costo para obtener la información. El costo típico
oscila entre $ 25,000 y $ 1 millón. El tiempo típico para acceder a los datos es de 1 a 12 meses.
Supongamos ahora que una empresa B ha construido un almacén de datos. El costo típico aquí oscila entre $
500 y $ 10,000. El tiempo típico para acceder a los datos es de una hora a medio día. Vemos que los costos y
la inversión de tiempo de la empresa B para recuperar información son mucho menores. El diferencial de
costes entre la empresa A y la empresa B constituye la base de la justificación de costes de un almacén de
datos.
El almacenamiento de datos reduce considerablemente el costo de la información y acelera el tiempo necesario
para obtener la información.
Costo de construir el almacén de datos
El observador astuto preguntará, ¿qué pasa con el costo de construir la casa de almacenamiento de datos?
La Figura 2.26 muestra que para generar un informe único para la empresa B, todavía es necesario encontrar,
acceder, integrar y fusionar los datos. Estos son los mismos pasos iniciales que se tomaron para crear un solo
informe para la empresa A, por lo que no se encuentran ahorros reales en la creación de un almacén de datos.
En realidad, crear un almacén de datos para ejecutar un informe es una costosa pérdida de tiempo y dinero.
Pero ninguna corporación en el mundo opera a partir de un solo informe. Las diferentes divisiones, incluso de
la corporación más simple y pequeña, analizan los datos de manera diferente.
La contabilidad mira los datos de una manera; el marketing mira los datos de otra manera; ventas mira los
datos de otra manera; y la gerencia analiza los datos incluso de otra manera. En este escenario, el costo de
construir el almacén de datos vale la pena. Es un costo único que libera la información que se encuentra en el
almacén de datos.
Mientras que cada informe que necesita la empresa A es costoso y lleva mucho tiempo, com
Machine Translated by Google aplicaciones de legado
informe
almacén de datos
datos
encontrar
1 2 el
los
acceso
a los
dla
atos
3 ilos
ntegrar
combinación datos
de 4 5 construir el informe
datos
Figura 2.26 Dónde están los costos y las actividades cuando se construye un almacén de datos.
La empresa B utiliza el costo único de construir el almacén de datos para generar múltiples
informes (consulte la Figura 2.27).
Pero ese gasto es un gasto de una sola vez, en su mayor parte. (Al menos el establecimiento
inicial del almacén de datos es un gasto único). La figura 2.27 muestra que, de hecho, el
almacenamiento de datos reduce considerablemente el costo de la información y acelera en
gran medida la velocidad a la que se puede recuperar la información.
¿La empresa A incluso pagaría para generar informes individuales? Probablemente no.
Quizás pagaría el precio de la información las primeras veces. Cuando se da cuenta de que
no puede pagar el precio de cada informe, simplemente deja de crear informes. El usuario
final tiene la actitud: "Sé que la información está en mi corporación, pero no puedo acceder a
ella". El resultado de los altos costos de obtener información y el tiempo requerido es tal que
los usuarios finales se sienten frustrados y descontentos con su organización de TI por no
poder entregar información.
Homogeneidad/heterogeneidad de datos
A primera vista, puede parecer que los datos que se encuentran en el almacén de datos son
homogéneos en el sentido de que todos los tipos de registros son iguales. En verdad, los
datos en el almacén de datos son muy heterogéneos. Los datos que se encuentran en el
almacén de datos se dividen en subdivisiones principales denominadas áreas temáticas. La
figura 2.28 muestra que un almacén de datos tiene áreas temáticas de producto, cliente,
proveedor y transacción.
La primera división de datos dentro de un almacén de datos está en la línea de los temas
principales de la corporación. Pero con cada área temática hay más subdivisiones. Los datos
dentro de un área temática se dividen en tablas. La figura 2.29 muestra esta división de datos
en tablas para el producto del área temática.
Machine Translated by Google empresa A
$1,000,000
$500,000
$2,000,000
$2,500,000
$1,000,000
empresa b
$250
$10,000
$1,000
$2,000
$2,000,000
$3,000
Figura 2.27 Los informes múltiples hacen que el costo del almacén de datos valga la pena.
producto cliente
proveedor
transacción
Figura 2.28 Los datos en las diferentes partes del almacén de datos están agrupados por
área temática.
Machine Translated by Google proveedor
producto producto
producto descripción
ubicación de la fecha orden
producto
fecha
...... ...... ...... ...... ......
............ ............ ............ ............
..... ..... ..... .....
producto
producto fecha de
número de bom
envío cantidad de envío
descripción de bom
........ ........
.................... .................... .......... ..........
Figura 2.29 Dentro del área temática del producto existen diferentes tipos de tablas, pero cada una
la tabla tiene un identificador de producto común como parte de la clave.
La figura 2.29 muestra que hay cinco tablas que componen el área temática dentro del almacén
de datos. Cada una de las tablas tiene sus propios datos y hay un hilo común para cada una de
las tablas en el área temática. Ese hilo común es el producto clave/elemento de datos de clave
externa.
Dentro de las tablas físicas que componen un área temática hay más subdivisiones. Estas
subdivisiones son creadas por diferentes ocurrencias de valores de datos.
Por ejemplo, dentro de la tabla de envío de productos, hay envíos de enero, envíos de febrero,
envíos de marzo, etc.
Los datos en el almacén de datos se subdividen según los siguientes criterios:
■■ Área temática
■■ Mesa
■■ Ocurrencias de datos dentro de la tabla
Esta organización de datos dentro de un almacén de datos hace que los datos sean fácilmente
accesibles y comprensibles para todos los diferentes componentes de la arquitectura que deben
construir sobre los datos que se encuentran allí. El resultado es que el almacén de datos, con
sus datos granulares, sirve como base para muchos componentes diferentes, como se ve en la
figura 2.30.
La organización simple pero elegante de los datos dentro del entorno del almacén de datos que
se ve en la Figura 2.30 hace que los datos sean accesibles de muchas maneras diferentes para
muchos propósitos diferentes.
Fig. 2.30 El almacén de datos se encuentra en el centro de un gran marco.
Depuración de datos de almacén
Los datos no se vierten eternamente en un almacén de datos. También tiene su propio
ciclo de vida dentro del almacén. En algún momento, los datos se eliminan del almacén.
El problema de la depuración de datos es uno de los problemas de diseño fundamentales
que no debe escapar al diseñador del almacén de datos.
En algunos sentidos, los datos no se eliminan del almacén en absoluto. Simplemente se
acumula en niveles más altos de resumen. Hay varias formas en que se depuran los
datos o se transforma el detalle de los datos, incluidas las siguientes:
Machine Translated by Google ■■ Los datos se agregan a un archivo de resumen continuo donde se pierden los detalles.
■■ Los datos se transfieren a un medio de almacenamiento masivo desde un dispositivo de alto rendimiento
medio como DASD.
■■ Los datos se eliminan realmente del sistema.
■■ Los datos se transfieren de un nivel de la arquitectura a otro, como del nivel operativo al nivel del almacén
de datos.
Hay, entonces, una variedad de formas en las que los datos se depuran o se transforman
dentro del entorno del almacén de datos. El ciclo de vida de los datos, incluida su
depuración o diseminación de archivo final, debe ser una parte activa del proceso de
diseño del almacén de datos.
Informes y el entorno diseñado
Es una tentación decir que una vez que se haya construido el almacén de datos, todos
los informes y el procesamiento de la información se realizarán desde allí. Ese
simplemente no es el caso. Existe una clase legítima de procesamiento de informes que
pertenece legítimamente al dominio de los sistemas operativos. La figura 2.31 muestra
dónde deben ubicarse los diferentes estilos de procesamiento.
informes operativos informes de almacenamiento de datos
• la línea de pedido es esencial; el • la línea de pedido es de poca o ninguna utilidad
resumen es de poca o ninguna una vez usado; el resumen u otro
importancia una vez utilizado • de cálculo es de importancia primordial •
interés para la comunidad clerical de interés para la comunidad gerencial
Figura 2.31 Las diferencias entre los dos tipos de informes.
Machine Translated by Google La Figura 2.31 muestra que los informes operativos son para el nivel administrativo y se enfocan
principalmente en el artículo de línea. El almacenamiento de datos o procesamiento de información se
centra en la gestión y contiene información resumida o calculada de otro modo. En el estilo de
generación de informes del almacén de datos, se hace poco uso de la información detallada de
elementos de línea, una vez que se realiza el cálculo básico de los datos.
Como ejemplo de las diferencias entre los informes operativos y los informes DSS, considere un banco.
Todos los días, antes de irse a casa, un cajero debe equilibrar el efectivo en su ventanilla. Esto significa
que el cajero toma la cantidad inicial de efectivo, cuenta todas las transacciones del día y determina
cuál debe ser el saldo de efectivo final del día. Para hacer esto, el cajero necesita un informe de todas
las transacciones del día. Esta es una forma de informe operativo.
Ahora considere al vicepresidente del banco que está tratando de determinar cuántos cajeros
automáticos nuevos colocar en un centro comercial recientemente desarrollado. El vicepresidente
bancario analiza una gran cantidad de información, parte de la cual proviene del interior del banco y
parte de la cual proviene de fuera del banco. el vicio del banco
El presidente está tomando una decisión estratégica a largo plazo y utiliza información clásica del DSS
para tomar su decisión.
Entonces existe una diferencia real entre los informes operativos y los informes DSS. Los informes
operativos siempre deben realizarse dentro de los límites del entorno operativo.
La ventana de oportunidad operativa
En su sentido más amplio, el archivo representa cualquier cosa más antigua que ahora. Por lo tanto, la
barra de pan que compré hace 30 segundos es información de archivo. Lo único que no es un archivo
es la información que está actualizada.
La base del procesamiento de DSS, el almacén de datos, no contiene nada más que información de
archivo, la mayor parte con una antigüedad mínima de 24 horas. Pero los datos de archivo se encuentran
en otras partes del entorno diseñado. En particular, algunas cantidades limitadas de datos de archivo
también se encuentran en el entorno operativo.
En el almacén de datos es normal tener una gran cantidad de datos de archivo, desde
5 a 10 años de datos es común. Debido al amplio horizonte temporal de los datos de archivo, el almacén
de datos contiene una gran cantidad de datos. El horizonte temporal de los datos de archivo que se
encuentran en el entorno operativo, la “ventana operativa” de datos, no es tan largo. Puede ser desde 1
semana hasta 2 años.
El horizonte temporal de los datos de archivo en el entorno operativo no es la única diferencia entre los
datos de archivo en el almacén de datos y en el entorno operativo.
Machine Translated by Google ambiente. A diferencia del almacén de datos, los datos de archivo del entorno operativo no son
voluminosos y tienen una alta probabilidad de acceso.
Para comprender el papel de los datos de archivo nuevos, no voluminosos y de alta probabilidad
de acceso en el entorno operativo, considere la forma en que funciona un banco. En un entorno
bancario, el cliente puede esperar razonablemente encontrar información sobre las transacciones
de este mes. ¿Pagó el cheque de alquiler de este mes?
¿Cuándo se depositó un cheque de pago? ¿Cuál fue el saldo bajo del mes? ¿El banco sacó
dinero de la factura de la luz la semana pasada?
El entorno operativo de un banco, entonces, contiene transacciones muy detalladas y muy
actuales (que todavía son de archivo). ¿Es razonable esperar que el banco le diga al cliente si un
cheque se hizo a nombre de la tienda de comestibles hace 5 años o si se cobró un cheque para
una campaña política hace 10 años? Estas transacciones difícilmente estarían en el dominio de
los sistemas operativos del banco. Estas transacciones son muy antiguas, por lo que tiene una
probabilidad muy baja de
acceso.
La ventana de tiempo operativa varía de una industria a otra e incluso en el tipo de datos y
actividad dentro de una industria.
Por ejemplo, una compañía de seguros tendría una ventana operativa muy larga, de 2 a 3 años.
La tasa de transacciones en una compañía de seguros es muy baja, al menos en comparación
con otro tipo de industrias. Hay relativamente pocas interacciones directas entre el cliente y la
compañía de seguros. La ventana operativa para las actividades de un banco, por otro lado, es
muy corta, de 0 a 60 días. Un banco tiene muchas interacciones directas con sus clientes.
La ventana operativa de una empresa depende de la industria en la que se encuentre. En el caso
de una empresa grande, puede haber más de una ventana operativa, dependiendo de los detalles
del negocio que se realice. Por ejemplo, en una compañía telefónica, los datos de uso de los
clientes pueden tener una ventana operativa de 30 a 60 días, mientras que la actividad del
vendedor/proveedor puede tener una ventana de 2 a 3 años.
Las siguientes son algunas sugerencias sobre cómo puede verse la ventana operativa de los
datos de archivo en diferentes industrias:
■■ Seguro: de 2 a 3 años ■■
Procesamiento de fideicomisos bancarios: de 2
a 5 años ■■ Uso de clientes telefónicos: de 30 a 60 días
■■ Actividad de proveedores/vendedores: de 2 a 3 años
■■ Actividad de cuentas de clientes de banca minorista: 30 días ■
■ Actividad del proveedor—1 año ■■ Préstamos—2 a 5 años
Machine Translated by Google ■■ Actividad de SKU de venta minorista: de 1 a 14 días
■■ Actividad del proveedor: 1 semana a 1 mes
■■ Actividad de asientos de vuelo de aerolíneas: 30 a 90 días
■■ Actividad del vendedor/proveedor: 1 a 2 años
■■ Utilización del cliente de servicios públicos—60 a 90 días
■■ Actividad del proveedor—1 a 5 años
La duración de la ventana operativa es muy importante para el analista de DSS porque determina
dónde va el analista para realizar diferentes tipos de análisis y qué tipos de análisis se pueden realizar.
Por ejemplo, el analista de DSS puede realizar un análisis de elementos individuales en los datos que
se encuentran dentro de la ventana operativa, pero no puede realizar un análisis de tendencias masivo
durante un período de tiempo prolongado. Los datos dentro de la ventana operativa están orientados al
acceso individual eficiente. Solo cuando los datos pasan fuera de la ventana operativa, se orientan al
almacenamiento masivo de datos y
acceso.
Por otro lado, el analista de DSS puede realizar un análisis de tendencia de barrido en los datos que se
encuentran fuera de la ventana operativa. Se puede acceder a los datos y procesarlos en masa,
mientras que el acceso a cualquier unidad individual de datos no es óptimo.
Datos incorrectos en el almacén de datos
El arquitecto necesita saber qué hacer con los datos incorrectos en el software de datos.
casa. La primera suposición es que los datos incorrectos llegan al almacén de datos de forma
excepcional. Si los datos se ingresan incorrectamente en el almacén de datos de forma mayorista,
entonces corresponde al arquitecto encontrar el programa ETL ofensivo y hacer los ajustes.
Ocasionalmente, incluso con el mejor procesamiento ETL, algunos datos incorrectos ingresan al entorno
del almacén de datos. ¿Cómo debe manejar el arquitecto los datos incorrectos en el almacén de datos?
Hay al menos tres opciones. Cada enfoque tiene sus propias fortalezas y debilidades, y ninguno es
absolutamente correcto o incorrecto. En cambio, bajo algunas circunstancias, una opción es mejor que
otra.
Por ejemplo, suponga que el 1 de julio se realiza un asiento por $5 000 en un sistema operativo para
la cuenta ABC. El 2 de julio se crea una instantánea por $5000 en el almacén de datos para la cuenta
ABC. Luego, el 15 de agosto, se descubre un error.
En lugar de una entrada de $5,000, la entrada debería haber sido de $750. ¿Cómo se pueden corregir
los datos en el almacén de datos?
Machine Translated by Google ■■ Opción 1: Vuelva al almacén de datos para el 2 de julio y encuentre al delincuente
entrada entrante. Luego, usando las capacidades de actualización, reemplace el valor de $5,000
con el valor de $750. Esta es una solución limpia y ordenada cuando funciona, pero presenta
nuevos problemas:
■■ La integridad de los datos ha sido destruida. No se podrá conciliar ningún informe que se
ejecute entre el 2 de julio y el 16 de agosto.
■■ La actualización debe realizarse en el entorno del almacén de datos.
■■ En muchos casos, no hay una sola entrada que deba corregirse, sino muchas, muchas
entradas que deben corregirse.
■■ Opción 2: Introducir entradas de contrapartida. Se hacen dos entradas el 16 de agosto, una por
$5,000 y otra por $750. Este es el mejor reflejo de la información más actualizada en el almacén
de datos entre el 2 de julio y el 16 de agosto. Hay algunos inconvenientes en este enfoque:
■■ Puede que haya que corregir muchas entradas, no sólo una. Hacer un ajuste simple puede no
ser nada fácil de hacer.
■■ A veces, la fórmula para la corrección es tan compleja que no se puede hacer un ajuste.
■■ Opción 3: restablecer la cuenta al valor correcto el 16 de agosto. Una entrada el 16 de agosto
refleja el saldo de la cuenta en ese momento, independientemente de cualquier actividad pasada.
Se haría una entrada por $750 el 16 de agosto. Pero este enfoque tiene sus propios inconvenientes:
■■ La capacidad de simplemente restablecer una cuenta a partir de un momento en el tiempo
requiere convenciones de aplicación y de procedimiento.
■■ Tal restablecimiento de valores no explica con precisión el error que se ha cometido.
La opción 3 es lo que probablemente sucede cuando no puede equilibrar su cuenta corriente al final
del mes. En lugar de tratar de averiguar qué ha hecho el banco, simplemente crea la palabra del
banco y restablece el saldo de la cuenta.
Entonces, hay al menos tres formas de manejar datos incorrectos a medida que ingresan al almacén
de datos. Dependiendo de las circunstancias, uno de los enfoques dará mejores resultados que otro
enfoque.
Resumen
Las dos decisiones de diseño más importantes que se pueden tomar se refieren a la granularidad
de los datos y la partición de los datos. Para la mayoría de las organizaciones, un nivel dual

W H Inmon-Building The Data Warehouse-EN (001-100)

Cargado por

Información del documento

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

W H Inmon-Building The Data Warehouse-EN (001-100)

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Localizar los datos requiere mirar lotes de archivos

Operacional almacén departamental individual

• detallado • más granular • • parroquial • • temporal • ad

Operacional almacén clientes de individual

¿Qué es J Jones? ¿Cuál ha sido el ¿Estamos que tendencias son

dleta dleta carga

datos básicos de datos básicos de actividad del cliente

Identificación del cliente Identificación del cliente Identificación del cliente

• 30 días de historial de 10 años de actividad procesamiento

j adams ene–pres Calle principal 123

También podría gustarte