Libroespañol

El Almacn de Datos Toolkit
La Segunda Edicin El Gua Cabal para

El Modelado Dimensional
Editor publicista: Robert Ipsen

Editor: Robert Elliott Editor Asistente: Emilie Herman Manejando Al Editor: John Atkins Asocie Al Editor de los Medios de Comunicacin Nuevo: Brian Snapp Avise Por Escrito Composicin: Los Servicios de Composicin Juan Wiley
Las designaciones usadas por compaas para distinguir sus productos son a menudo reclamadas como marcas de fbrica. En todo ofrece como ejemplo donde John Wiley y los Hijos, el S.A., se da cuenta de un reclamo, los nombres del producto aparecen en capital inicial o TODAS LAS LETRAS MAYSCULAS. Los lectores, sin embargo, deberan contactar a las compaas apropiadas para informacin ms completa estimando marcas registradas e inscripcin. Este libro es impreso en escrito libre de cido. _ Derecho De Autor 2002 por Ralph Kimball y Margy Ross. Reservados todos los derechos. Publicado por John Wiley e Hijos, S.A. Publicado simultneamente en Canad. Ninguna parte de esta publicacin puede ser reproducida, almacenada en un sistema de recuperacin o puede ser transmitido en cualquier forma o por cualquier medio, electrnico, mecnico, fotocopiando, registrando, escudriando o de otra manera, excepto como permitido debajo de Secciones 107 o 108 de lo 1976 United States Copyright Act, sin ya sea el anterior permiso escrito del Editor Publicista, o pago directo authoriza tion de lo apropiado por copia dele propina para la Liquidacion de Mercaderas de Derecho de Autor Centro, 222 Rosewood Conducen, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Pide para el Editor Publicista pues el permiso debera ser dirigido al Departamento de Permisos, John Wiley e Hijos, S.A., 605 la Tercera Avenida, Nueva York, NY 10158-0012, (212) 850-6011, fax (212) 850-6008, Correo Electrnico: PERMREQ@WILE Esta publicacin es diseada para proveer informacin precisa y magisterial con relacin a la materia sujeta cubierta. Es vendida con la comprensin que el editor publicista no est comprometido en servicios profesionales. Si el consejo profesional u otra asistencia docta es requerido, los servicios de una persona profesional competente deberan ser buscados.
Aceptaciones Introduccin Captulo 1 La Cartilla Dimensional de Modelado Los Mundos Diferentes de Informacin Las metas de un Almacn de Datos La Metfora Editorial Los componentes de un Almacn de Datos Los Sistemas Operacionales de la Fuente El rea de Escenificacin de Datos La Presentacin de Datos Las Herramientas de Acceso de Datos Las Consideraciones Adicionales El Vocabulario Dimensional de Modelado La Mesa de Hecho Las Tablas de Dimensin Juntando Hechos y Dimensiones Los Mitos Dimensionales de Modelado Las Hoyas Cubiertas Comunes para Avoid Resumen Captulo 2 Comercio Al Por Menor El Proceso Dimensional del Diseo de Cuatro Pasos Venda Al Por Menor Estudio de Casos Paso 1. Seleccione el Proceso Comercial Paso 2. Declare el Grano Paso 3. Escoja las Dimensiones Paso 4. Identifique los Hechos
Xv Xvi 1 2 2 4 6 7 8 10 13 14
Los Atributos de la Mesa de Dimensin La Dimensin de Fecha La Dimensin del Producto Almacene Dimensin La Dimensin de Promocin Degenere Dimensin de Nmero de Transaccin Venda Al Por Menor Dibujo Tcnico en Actividad Venda Al Por Menor Extensibilidad del Dibujo Tcnico Resistiendo Deseos de la Zona de Comodidad La Normalizacin de Dimensin (Snowflaking) Demasiadas Dimensiones Subrogue Llaves El Anlisis de la Canasta de Mercado Resumen Captulo 3 Inventario La introduccin para la Cadena de Valor Modelos Inventariales Inventare Foto Peridica Las Transacciones de Inventario El Inventario Acumulando Foto La Integracin de la Cadena de Valor Los Datos Almacenan Arquitectura del Autobs Los Datos Almacenan Matriz del Autobs Las dimensiones conformadas Los hechos conformados Resumen
38 38 42 45 46 50 51 52 54 55 57 58 62 65 67 68 69 69 74 75 76 78 79 82 87 88 89 89 90 91 93
Captulo 4
Adquisicin El Estudio De Casos de Adquisicin Las Transacciones de Adquisicin El Mltiplo Versus Tablas de Hecho de Single-Transaction La Foto Complementaria de Adquisicin Lentamente Cambiando Dimensiones Tipo 1: Sobrescriba el Valor Tipo 2: Sume Una Fila de Dimensin Tipo 3: Sume Una Columna de Dimensin
Hbrido Lentamente Cambiando Tcnicas de Dimensin Los Cambios Previsibles con Capas Superpuestas Mltiples de Versin Los Cambios Imprevisibles con Sola Capa Superpuesta de Versin Ms Rpidamente Cambiando Dimensiones Resumen Captulo 5 La Gerencia de Orden La Introduccin para Mandarle A Gerencia Ordene Transacciones La Normalizacin de Hecho La Caracterizacin De Papeles de Dimensin La Dimensin del Producto Vuelta a Visitar El Barco del Cliente para la Dimensin La Dimensin de Trato Degenere Dimensin para Nmero de Orden Las Dimensiones de Trastos Viejos Las Monedas Circulantes Mltiples El Encabezado y los Hechos de Rubro Contable con Granularidad Diferente Facture Transacciones Los Hechos de Ganancias Y Prdidas Rentabilidad el Centro de Compras de Datos Ms Poderoso La Rentabilidad Expresa de Dar Aviso Los Hechos de Satisfaccin del Cliente Acumulando Foto para la Tubera de Cumplimiento de Orden Los Clculos de Atraso Las Mltiples Unidades de Medida Ms All Del Espejo Retrovisor La Comparacin de la Mesa de Hecho Las Tablas de Hecho de Transaccin Las Tablas Peridicas de Hecho de la Foto Acumulando Tablas de Hecho de la Foto
Captulo 6 Gestor De Relaciones Con El Cliente La visin general de gestor de relaciones con el cliente La operacional y Analtica gestor de relaciones con el cliente Las Particiones de Tiempo Real de Diseo Los requisitos para la Particin De Tiempo Real El Grano de Transaccin la Particin de Tiempo Autntico La Foto Peridica la Particin de Tiempo Autntico Acumulando Foto Realmente Particin de Tiempo Resumen La empacada gestor de relaciones con el cliente La Dimensin del Cliente El Nombre y el Anlisis Gramatical de la Direccin Otros Atributos Comunes del Cliente Los arbotantes de dimensin para un Low Cardinality Atribuyen Set Las Dimensiones Cambiantes Grandes del Cliente Las Implicaciones de Tipo 2 el Cliente Dimensionan Cambios El Estudio de Comportamiento del Cliente Se Agrupa Las Jerarquas Comerciales del Cliente Combinando Fuentes Mltiples de Datos del Cliente Analizando Datos del Cliente de Procesos Comerciales Mltiples Resumen Captulo 7 Contabilidad Llevando Las Cuentas Estudio de Casos Los Datos Generales del Libro Mayor El Libro Mayor General la Foto Peridica Las Transacciones Generales de la Publicacin del Libro Mayor Estados Financieros Presupuestando Proceso Las Tablas Consolidadas de Hecho El papel de Soluciones OLAP y Analytic Empacado Resumen
Captulo 8 Administracin De Recursos Humanos El rastreo de sello de tiempo de Transaccin en una Dimensin La Dimensin de Sello De Tiempo con Hechos Peridicos de la Foto La Dimensin de Auditora La Dimensin del Arbotante de Palabra Clave / la investigacin de operaciones de operador booleano AND Dilemma Yendo En Busca De Subcadenas Los Datos del Cuestionario de Encuesta Resumen Captulo 9 Servicios Financieros Poniendo En El Banco Estudio de Casos El Triage de Dimensin La Dimensin de Toda la Casa Multivalued Dimensions Minidimensions Revisited El Arbitrario Value Agrupndose de Hechos El Punto en el Tiempo Se Balancea Los Dibujos Tcnicos Heterogneos del Producto Los Productos Heterogneos con Hechos de Transaccin Resumen Divida En Captulos 10 Telecomunicaciones y Servicios Pblicos El Estudio De Casos de Telecomunicaciones Las Consideraciones Generales de Revisin del Diseo Granularidad La Dimensin de Fecha Degenere Dimensiones La Dimensin Descifra y Descripciones Subrogue Llaves Demasiadas (o Demasiado Pocas) Dimensiones Redacte Debate de Ejercicio del Diseo La Dimensin Geogrfica de la Posicin El Arbotante de la Posicin Apalancando Geogrficos Sistemas de Informacin Resumen
Captulo 11 el Transporte La Aerolnea el Estudio de Casos Frecuente del Aviador Las Granularidades Mltiples de la Mesa de Hecho El Eslabonamiento Se Segmenta en los Viajes Las Extensiones para Otras Industrias El Expedidor del Cargamento Los Servicios de Viaje Combinando En Trozos Pequeos Dimensiones en un Superdimension La Clase de Servicio El Origen y el Destino Ms Consideraciones de Fecha y de Tiempo Los Calendarios Especficos En Pas El tiempo de Da como una Dimensin o el Hecho Salga En Citas y Tiempo en los Husos Horarios Mltiples Resumen Captulo 12 Educacin El Universitario Estudio de Casos Acumulando Foto para Admisiones Rastreando Las Tablas de Hecho de Factless Los Acontecimientos Estudiantiles de Inscripcin La Cobertura de Utilizacin de Facilidades Los Acontecimientos Estudiantiles de Asistencia Otras reas de Inters Analtico Resumen 234 235 236 236 237 239 239 240 240 241 243 244 244 246 247 249 250 253 254
Captulo 13
Asistencia Mdica Para La Salud 255 El Crculo de Valor de Asistencia Mdica para la Salud 256 La Cuenta de Asistencia Mdica para la Salud 258 Los Papeles Tocaron por la Dimensin de Fecha 261 La Dimensin Multipreciada de Diagnstico 262 Extendiendo Una Mesa Facturadora de Hecho para la Rentabilidad de265 Funcin Las Dimensiones Pues las Estadas Facturadas del Hospital 266
Complique Acontecimientos de Asistencia Mdica para la Salud
267
Fichas Mdicas La Dimensin de Hecho para los Hechos Escasos La Vuelta Atrs con el Tiempo El Hecho Que Llega Tarde Rema La Dimensin Que Llega Tarde Rema Resumen
269 269 271 271 273 274
Captulo Comercio Electrnico 277 14 El Manual De Instruccin de Interacciones del Servidor de Cliente de Web278 Por Qu el Clickstream No Es Simplemente Otra Fuente de Datos 281 Los Retos de Rastrear con Clickstream Data 282 Las dimensiones especficas para el Clickstream 287 Clickstream Fact Table para Sesiones Completas 292 Clickstream Fact Table para Individual Page Events 295 Las Tablas de Hecho del Clickstream del Agregado 298 Integrando al Clickstream Data Mart en lo El Almacn de Datos de la Empresa 299 El Centro De Compras de Datos de Rentabilidad de Comercio Electrnico 300 Resumen 303 Captulo Seguro 15 El Estudio De Casos de Seguro La Cadena de Valor de Seguro Redacte Matriz del Autobs de Seguro Las Transacciones de Poltica La Dimensin Detalla y Tcnicas La Poltica Alternativa (o Complementary)
Acumulando Foto
305 306 307 309 309 310

315
La Poltica la Foto Peridica Las dimensiones conformadas Los hechos conformados Los Productos Heterogneos Otra Vez Las Dimensiones Multipreciadas Otra Vez
316 316 316 318 318
Ms Historial de Estudio de Casos de Seguro La Matriz Actualizada del Autobs de Seguro Reclama Transacciones Reclama Acumular Foto La Poltica /reclamos Consolid Foto Los Acontecimientos de Accidente de Factless El Comn Dimensional Modelando 6 Resumen
Errores
para
Avoid 32
33 0 Captulo 1 El 2 El 33 La 16 Construyendo el Almacn de Datos 33 Lifecycle 33 Inters 3 Gerencia 33 Presteza 3
Mapa
De
Rutas
Dimensional
Comercial
del
Mapa
De
Rutas
Major
Points
de
Planificacin
De
Proyecto
la
4 Evaluando 34 Scoping
3 36 Justificacin 3 36 Dotacin 37 de personal 3
Desarrollndose 39 La 0 El
Manteniendo
el
Plan
de
Proyecto 3 Requisitos 34 Requisitos 3 Comerciales 3 Seguimiento 3
Definicin
Comercial
de
Planeamiento
Previo
de
41 Coleccionando 43 Postcollection 45 La 7 El 8 El 48 La 1 La 3 El 3 El 5 La
los
Requisitos
Documentation
Pista
de
Tecnologa
del
Lifecycle 34 Arquitectura 34
Diseo
Tcnico
de
Proceso
de
Ocho
Pasos
para
Crear
la
Arquitectura
Tcnica 3
Seleccin
del
Producto
la
Instalacin 35 Lifecycle 35 Dimensional 35 Fsico 35
Pista
de
Datos
del
Modelado
Diseo
Estrategia
de
Agregacin
3 56 La 57 El 8 La 58 La 61 Estrategia Inicial de Indexacin 3 y el Desarrollo 35 Dimensin 3 de Hecho 3
Diseo
de
Escenificacin
de
Datos
Escenificacin
de
la
Mesa
de
Escenificacin
de
la
Mesa
El Lifecycle la Pista Analtica de Aplicaciones La Especificacin Aplicativa Analtica El Desarrollo Aplicativo Analtico Implementacin El Mantenimiento y el Crecimiento Errores Que Almacenan Datos Comunes para Avoid Resumen Captulo 17 Presente Imperativos y Futuro Punto de Vista La Tecnologa en Curso Avanza Privacidad Prendaria y Conmovedora Que Exige Fuerzas Polticas El Conflicto entre Beneficial Acostumbra e Insidious Abusa Quin Posee Sus Datos Personales? Qu Es Probable para Happen? Observando A los Observadores. . . Cmo Observando los Datos de Afectos de Observadores
La Arquitectura del Almacn
Diseando para Evitar Fracaso Catastrfico Los Fracasos Catastrficos Antagonizando Fracasos Catastrficos La Propiedad Intelectual y la Feria Acostumbran Las Tendencias Culturales en Datos Almacenando
Ingenindose de acuerdo con las reglas A travs de la Empresa La Confianza Aumentada en Llave Sofisticada Los Indicadores de Funcin
El Comportamiento Es la Aplicacin Nueva del Entoldado Las Aplicaciones Empacadas Han Golpeado Su Punto Alto La Integracin Aplicativa para Ser Ha Hecho por Alguien Los Datos Almacenan Subcontratar Necesidades Una Sobria Determinac de Riesgo En Cerrar Glosario El ndice
F
El irst de todo, quiere agradecer lo miles de ti que ha ledo nuestros libros Toolkit,
asisti a nuestros cursos, y nos contrat en consultarle proyectos. Hemos aprendido como mucho de usted como hayamos enseado. Como un grupo, usted ha tenido un impacto profundamente positivo en la industria de almacenamiento de datos. Felicitaciones! Este libro no habra sido escrito sin la asistencia de nuestros socios comerciales. Queremos darle a Julie Kimball de Ralph Kimball Associates las gracias por su vista y su determinacin en tener el proyecto lanzado. Mientras Julie fue el catalizador que puso la pelota a rodar, Bob Becker de manutencin ayudada DecisionWorks Consulting que ella en marcha como l redact, revis, y le sirvi de una general tabla de armona. Les agradecemos ambos porque ayudaron una cantidad de enor-mous. Escribimos este libro con un poco de ayuda de nuestros amigos, quien provey aporte o informacin retroactiva en captulos especficos. Queremos agradecer a Bill Schmarzo de Decision-Works, Charles Hagensen de Corporacin Attachmate, y el thwaite Warren Thorn de InfoDynamics para su consejo en Captulos 6, 7, y 16, respectivamente. Bob Elliott, nuestro editor en John Wiley y los Hijos, y el equipo entero Wiley han soportado este proyecto con habilidad, nimo, y entusiasmo. Ha sido un placer surtir efecto con ellos. Tambin queremos darle a Justin Kestelyn, editor en jefe en Empresa Inteligente las gracias por dejarnos adaptar materiales de sev-eral de los artculos de Ralph para inclusin en este libro. Para nuestras familias, gracias por estar all para nosotros cuando necesitamos a usted y para giv-ing para nosotros el tiempo tom. Esposo Julie Kimball y Scott Ross y nias Sara Hayden Smith, Brian Kimball, y Katie Ross completamente contribuida bastante para este libro, a menudo sin caer en cuenta de ello. Gracias por su apoyo incondicional.
l que la industria de almacenamiento de datos ciertamente tiene, madur desde pub-lished Ralph Kimball la primera edicin de La Data Warehouse Toolkit (Wiley) en 1996. Aunque el bono corporativo grande temprano los adoptadores pavimentaron la ruta, desde entonces, el almacenar datos ha sido aceptado por organizaciones de todos los tamaos. La industria ha construido miles de almacenes de datos. El volumen de datos contina aumentando como poblamos nuestros almacenes con datos progresivamente atmicos y los actualizamos con mayor frecuencia. Los vendedores continan cubriendo el mercado de un que se expande alguna vez juego de herramientas para ayudarnos con diseo del almacn de datos, desarrollo, y uso. Ms importantes, armados con acceso para nuestros almacenes de datos, los profesionales de busi-ness hacen mejores decisiones y generando devolucin de lo adeudado sobre sus inversiones del almacn de datos. Desde que la primera edicin de La Data Warehouse Toolkit fue publicada, el modelar dimen-sionales ha sido ampliamente aceptado como la tcnica dominante para la presentacin del almacn de datos. Los datos que los practicantes del almacn y los expertos del mismo modo han reconocido que los datos almacenan presentacin debe estar encallada en sim-plicity si aguanta ms probabilidad de xito. La simplicidad es la llave fundamental que deja a los usuarios comprender bases de datos fcilmente y software para navegar bases de datos eficazmente. De muchas formas, el modelado dimensional equivale a sujetar el fuerte en contra de los asaltos sobre la simplicidad. Por consistentemente regresar a una perspectiva conducida en negocio y rehusndose a transigir las metas de funcin del usuario de comprensibilidad y de averiguacin, establecemos un diseo coherente que sirve para las necesidades analticas de la organizacin. Basado sobre nuestra experiencia y la informacin retroactiva abrumadora de numerosos practicantes de compaas gusta lo tuyo, creemos que el modelado dimensional es absolutamente crtico para una iniciativa de almacenamiento de datos de suc-cessful. El modelado dimensional tambin ha emergido como la nica arquitectura coherente para construir distribuy los datos almacenan sistemas. Cuando usamos las dimensiones conformadas y hechos conformados de un set de modelos dimensionales, tenemos un armazn prctico y previsible para incrementalmente construyendo sistemas complicados del almacn de datos que no tienen centro. Para todo lo que ha cambiado en nuestra industria, el tech-niques modelador
dimensional de fondo que Ralph Kimball public seis aos atrs ha resistido la prueba de tiempo. Los conceptos como lentamente cambiando dimensiones, productos heterogneos,
El libro es organizado alrededor de una serie de vietas comerciales o estudios de casos. Creemos e las tcnicas del diseo por el ejemplo es un acercamiento sumamente efectivo porque nos deja com muy tangible. Mientras no pretendido para ser aplicacin en gran escala o soluciones de la indu ejemplos sirven de un armazn para discutir los patrones que descuellan en mod-eling dimensional. experiencia, es a menudo ms fcil de asir los elementos principales de una tcnica del diseo de ale todas las complejidades demasiado familiares de las propias aplicaciones de uno para pensar ace negocio. Los lectores de la primera edicin han respondido muy favorablemente para este acercam
Los captulos de este libro se fundamentan en el uno al otro. Comenzaremos con con-cepts introduciremos contenido ms adelantado como el libro se despliegue. Los captulos deben ser led por cada lector. Por ejemplo, el Captulo 15 en seguro ser difcil de comprender a menos que usted los captulos precedentes sobre vender al por menor, adquisicin, le manda a gerencia, y gestor de con el cliente.
Aqullos de vosotros que han ledo la primera edicin pueden estar tentados de saltarse la primera captulos. Mientras algunos del encallamiento anticipado estimando hechos y dimen-sions pued enzacatada familiar, no queremos que usted corra a velocidad demasiado lejos delante. Por ejemplo estudio de casos enfoca la atencin en la industria de venta al menudeo, tal como hizo en la prime Sin embargo, en esta edicin apoyamos un acercamiento nuevo, mak-ing un caso fuerte para abord atmicos del lecho de roca, de su organizacin. Usted pasar por alto sobre esta racionalizac actualizaciones para con-cepts fundamental si a usted se le pasa delante demasiado rpidamente.
Ayudas De Navegacin
Hemos rociado el libro con consejos, teclee conceptos, y divida en captulos punteros para h utilizable y con holgura para el que se estableci referencias en el futuro. Adems, nosotros hem un glosario extensivo de trminos.ChEl contenido en este libro es suavemente tcnico. Discutimos modelado dimensional
En el contexto de una base de datos relacional primordialmente. Suponemos que los lectores tienen
El conocimiento bsico de conceptos de la base de datos de relaciones como Tablas, filas, llaves, Y las junturas. Dado que discutiremos modelos dimensionales en un non La manera religiosa, no bucearemos en diseo fsico especfico y
Afinando gua para cualquier dados sistemas de gestin de base de datos.Las Tablas de hecho de factless, y los centros de compras de datos ar discutidos en datos Los talleres del diseo del almacn alrededor del globo. Los conceptos originales tienen Estado embellecido y realzado por las tcnicas nuevas y complementarias. Nosotros Bien definido para publicar una segunda edicin del trabajo seminal de Kimball porque sentimos Que sera til ponerse juntos encima nuestros pensamientos colectivos dimensionales El modelado debajo de una sola cubierta. Tenemos a cada uno enfocado exclusivamente sobre la decisin El soporte y los datos almacenando por ms de dos decenios. Esperamos compartir lo Los patrones dimensionales de modelado que tienen, emergieron repetidamente durante lo Camino de nuestro almacenamiento de datos corre a velocidad. Este libro tiene mucho dinero con especfico Las recomendaciones del diseo prcticas basadas en panoramas del mundo real.
La meta de este libro debe proveer una tienda donde se encuentra de todo para las tcnicas dimen modelado. Cierta para su ttulo, es un toolkit de principios dimensionales del diseo y tc ocuparemos de las necesidades de esos simplemente comenzando en datos de dimen-sional alma describiremos conceptos adelantados para aqullos de vosotros que han estado en esto un rato. Cr este libro es nico en su profundidad de cobertura sobre el tema de modelado dimensional.
uno
Usted puede encontrar los consejos rociados a todo lo largo de este libro hojeando los captulos y el icono de la bombilla.
Empezamos cada captulo con un recuadro complementario de conceptos cruciales, denota icono crucial. Pur La actitud de Cada Captulo
Antes de que comenzamos, queremos darle un captulo por la exhibicin preliminar de capt conceptos cubiertos como el libro se despliega.
Captulo 1: La Cartilla Dimensional de Modelado
El libro comienza con una cartilla sobre el modelado dimensional. Exploramos el com-pon arquitectura global del almacn de datos y establecemos vocabu-lary de fondo que ser usado resto del libro. Ahuyentamos una cierta cantidad de los mitos y los conceptos equivocados modelado dimensional, y discutimos el papel de modelos normalizados.
Captulo 2: Comercio Al Por Menor
La venta al menudeo es el ejemplo clsico usado para ilustrar modelado dimensional. Comenzam clsico porque es uno que todos nosotros comprendemos. Si Dios quiere, usted no necesitar p arduo acerca de la industria porque queremos que usted enfoque la atencin en conceptos dimens modelado de fondo en lugar de eso. Empezamos por discutir el proceso de cuatro pasos para disea dimensionales. Exploramos Tablas de dimen-sion a fondo, incluir la dimensin de fecha que ser repeat-edly a todo lo largo del libro. Tambin discutimos dimensiones degeneradas, snowfla substituto teclea. Aun si usted no es un detallista, este captulo es requerido rezando porque est c fundamentos.
Captulo 3: Inventario
Quedamos dentro de la industria por menor para nuestro segundo estudio de casos pero fijam atencin en otro proceso comercial. Este estudio de casos proveer un ejemplo muy vvido de la ar del autobs del almacn de datos y el uso de hechos y dimensiones conformadas. Estos conc crticos para alguien mirando hacia con-struct una arquitectura del almacn de datos que es in extensible.
Captulo 4: Adquisicin Este captulo refuerza la importancia de mirar la cadena de valor de su organizacin como usted representa grficamente su almacn de datos. Tambin exploramos una serie de tcnicas bsicas y adelantadas para manipulador lentamente cambiando atributos de dimensin.
Captulo 5: La Gerencia de Orden En este estudio de casos echamos un vistazo en los procesos de negocio que es a menudo la primera parte ser implementado en almacenes de datos como ellos suministran la mtrica comercial de per-formance de fondo qu nosotros vendemos para cules clientes en qu le pone precio a? Discutimos la situacin en la cual una dimensin juega papeles mltiples dentro de un dibujo tcnico. Tambin exploramos una cierta cantidad de los retos comunes que los modeladores afrontan al ocuparse de informacin de la gerencia de orden, como encabezado /lnea tem aprenden de memoria sideraciones, monedas circulantes mltiples o unidades de medida, y dimensiones de trastos viejos con indicadores miscelneos de transaccin. Comparamos los tres tipos fundamentales de Tablas de hecho: Transaccin, foto peridica, y acumularse con un chasquido le dispararon a. Finalmente, proveemos recomendaciones para requisitos manipuladores y ms que alojan loza de tiempo real.
Captulo 6: Gestor De Relaciones Con El Cliente
Los numerosos almacenes de datos se han construido en la premisa que necesitamos para bet-ter comprenda y repare a nuestros clientes. Esta subsidiaria considera-tions de la llave de cubiertas rodeando la dimensin del cliente, incluyendo se ocupa de estandarizacin, manejando dimensiones grandes de volumen, y modelando jerarquas imprevisibles del cliente. Tambin discute la consolidacin de datos del cliente de fuentes mltiples.
Captulo 7: Contabilidad En este captulo completamente nuevo discutimos el modelado de informa-tion general del libro mayor para el almacn de datos. Describimos el manejo apropiado de ao para fechar hechos y calendarios fiscales mltiples, as como tambin la nocin de modelos dimensionales consolidados que combinan datos de negocio mltiple va en procesin.
Captulo 8: Administracin De Recursos Humanos Este nuevo captulo explora varios aspectos nicos de modelos humanos de dimen-sional de recursos, incluir la situacin en la cual una mesa de dimensin comienza a comportarse como una mesa de hecho. Tambin introducimos dimensiones de auditora y de palabra clave, as como tambin el manejo de datos del cuestionario de encuesta.
Captulo 9: Servicios Financieros El estudio bancario de caso explora el concepto de productos heterogneos en los cuales cada clase de negocio tiene atributos descriptivos nicos y mtrica de funcin. Obviamente, la necesidad para maniobrar productos heterogneos no es nica para los servicios financieros. Tambin discutimos las relaciones complicadas entre cuentas, clientes, y grupos familiares.
Captulo 10: Las Telecomunicaciones y los Servicios Pblicos Este nuevo captulo est estructurado algo diferentemente para resaltar considera-tions al realizar una revisin del diseo de modelo de datos. Adems, exploramos las idiosincrasias de dimensiones geogrficas de la posicin, as como tambin las oportunidades para apalancar geogrficos sistemas de informacin.
Captulo 11: Transporte En este estudio de casos le echamos un vistazo a las Tablas relacionadas de hecho en niveles diferentes de gran-ularity. Discutimos otro acercamiento para dimensiones pequeas manipuladoras, y tomamos una mirada ms cercana a la fecha y las dimensiones de tiempo, cubriendo tales conceptos como sincronizacin y calendarios especficos en pas a travs de los husos horarios mltiples.
Captulo 12: Educacin Miramos varias Tablas de hecho de factless en este captulo y discutimos su impor-tance en analizar lo que no ocurri. Adems, exploramos la tubera aplicativa estudiantil, lo cual es un ejemplo de primera de una mesa de hecho de la foto de atesoramiento.
Captulo 13: Asistencia Mdica Para La Salud
Algunos de los modelos ms complicados que alguna vez hemos trabajado es de la industria de asistencia mdica para la salud. Este nuevo captulo ilustra el manejo de tal com-plexities, incluyendo el uso de una mesa del puente a modelar mltiplo diagnostica y los proveedores se asociaron con un tratamiento paciente.
Captulo 14: Comercio Electrnico Este captulo le provee una introduccin a modelar informacin del clickstream. Lo con-cepts est derivativo de La Data Webhouse Toolkit (Wiley 2000), cul el coauthored Ralph Kimball con Richard Merz. Captulo 15: Seguro
El final estudio de casos viene a ilustrar muchas de las tcnicas que discutimos ms temprano en el soltero se sedimentan de dibujos tcnicos relacionados. Puede ser mirado como una traccin eso to divide en captulos porque las tcnicas modeladoras sern a capas encima de uno otro, simi revestimiento en lo alto las diapositivas de proyector.
Captulo 16: Construyendo el Almacn de Datos
Ahora que usted es diseo confortable modelos dimensionales, proveemos una visin general de a las actividades que se encontr durante el lifecycle de una iteracin tpica de proyecto del almac Este captulo podra ser considerado una excursin del relmpago de La Data Warehouse Lifecy (Wiley 1998) que nosotros el coauthored con Laura Reeves y Warren Thornthwaite.
Captulo 17: Presente Imperativos y Futuro Punto de Vista
En este captulo final miramos con atencin en nuestra bola de cristal para proveer una exhibicin de a lo que anticipamos que almacenamiento de datos se parecer en el futuro.
Glosario
Hemos suministrado un glosario detallado para servir de un recurso remisivo. Eso ayudar a salva entre su negocio general entendiendo y los estudios de casos se derivaron de negocios aparte del tu
Co
El sitio Web del panion
Usted puede lograr acceso al sitio Web del compaero del libro en las ofertas del sitio Web del siguientes recursos:
registro para Diseo Se Vuelca para recibir gua en curso, prctica acerca de modelado dimension del almacn de datos por correo electrnico sobre una base peridica. conecte para todos los artculos de Ralph Kimball de Empresa Inteligente y su predecesor, la sistema de gestin de base de datos. entrese de clases Kimball University para la calidad, educacin independiente en vendedor cons las experiencias de los autores y escrituras.
Resumen
La meta de este libro debe comunicar un set de tcnicas estndar para diseo dimensional del almacn de datos. Escabrosamente hablando, si usted como el lector no obtiene nada ms de este libro aparte de la conviccin que sus datos tienen cuidado con casa debe ser conducido de las necesidades de usuarios comerciales y por consiguiente debe forjarse y debe replantearse de una perspectiva dimensional simple, entonces este libro habr servido para su propsito. Nos fiamos de que usted ser un paso gigante ms cercano para xito que almacena datos si usted acoge estas premisas. Ahora que usted sabe dnde somos liderados, es hora de bucear en los detalles. Comenzaremos con una cartilla sobre el modelado dimensional en Captulo 1 a asegurar que todo el mundo est en la misma pgina estimando terminologa crucial y conceptos arquitectnicos. Desde all empezaremos nuestro debate del tech-niques fundamental de modelado dimensional, comenzando con la industria probada y verdadera y por menor.
EL CARBONO HAPTE R
El Modelado Dimensional
Cartilla
yo
La n este primer captulo que colocamos el trabajo de base para los estudios de casos que entienda. Empezaremos por dar un paso de regreso a considerar datos almacenando de un per-spective de macro. Algunos lectores pueden estar desilusionados para enterarse de que no se trata de herramientas y tcnicas ante todo, el almacn de datos debe considerar las necesidades del negocio. Conduciremos estacas en el suelo referente a las metas del almacn de datos al observar las similitudes extraas entre las responsabilidades de unos datos almacena gerente y ese de un editor publicista. Con esta perspectiva del cuadro grande, exploraremos los componentes principales del ambiente de la casa de loza, incluyendo el papel de modelos normalizados. Finalmente, cerraremos estableciendo vocabulario fundamental para el modelado dimensional. Por el fin de este captulo esperamos que usted tendr un aprecio para la necesidad para ser medio administrador de base de datos (el administrador de la base de datos) y medio Mster en Administracin de Empresas (el analista de empresas) como usted aborda su almacn de datos.
Subsidiaria 1 discute los siguientes conceptos:
las metas conducidas en negocio de un almacn de datos los datos almacenan publicacin los componentes principales del almacn global de datos la importancia de modelado dimensional para el rea de presentacin del almacn de datos el hecho y la dimensin posponen terminologa los mitos rodeando modelado dimensional las hoyas cubiertas comunes de almacenamiento de datos a evitar
Los Mundos Diferentes de Informacin Uno de los activos ms importantes de cualquier organizacin es su informacin. Este activo es casi siempre conservado por una organizacin en dos formas: Los sistemas operacionales registrados y el almacn de datos. Escabrosamente hablando, los sistemas operacionales est donde la informacin es metida en, y el almacn de datos est donde publicamos los datos. Los usuarios de una vuelta operacional del sistema las ruedas de la organizacin. Reciben rdenes, contratan a clientes nuevos, y ponen en bitcora quejas. Los usuarios de un sistema de opera-tional casi siempre tratan de un registro a la vez. Repetidamente realizan las mismas tareas operacionales repetidas veces. Los usuarios de un almacn de datos, por otra parte, observan las ruedas del orga-nization dar vuelta. Cuentan las nuevas rdenes y las comparan con las rdenes de la semana pasada y preguntan por qu se alistaron los clientes nuevos y lo que los clientes se quejaron acerca de. Los usuarios de una informacin almacenan casi nunca trato con una fila a la vez. Ms bien, sus preguntas a menudo piden que los centenares o miles de filas sean buscados y comprimidos en un set de respuesta. Para fomentarlos materias complejas, usuarios de un almacn de datos continuamente cambio las clases de preguntas preguntan. En la primera edicin de La Data Warehouse Toolkit (Wiley 1996), Ralph Kimball dedic un captulo entero a describir la dicotoma entre los mundos de datos y procesamiento operacional almacenando. A esta hora, es ampliamente nized de rediente de engranaje que el almacn de datos tiene profundamente necesidades diferentes, clientes, struc-tures, y ritmos que los sistemas operacionales registrados. Desafortunadamente, continuamos encontrando supuestos datos almacena esa son meras copias del sistema operacional y registrado almacenado en una plataforma separada del hardware. Mientras esto puede ocuparse de la necesidad para aislar el environ-ments operacional del almacn y para las razones de funcin, no hace nada para ocuparse de las otras diferencias inherentes entre estos dos tipos de sistemas. Los usuarios comerciales son poco anonadada por la usabilidad y la funcin provisto por estos almacenes seudos de datos. Estos impostores perjudican datos almacenando porque no admiten que los usuarios del almacn tengan necesidades drsticamente diferentes que usuarios operacionales del sistema.
Las metas de un Almacn de Datos Antes de que ahondemos en los detalles de modelar y la implementacin, es de ayuda enfocar la atencin en las metas fundamentales del almacn de datos. Las metas pueden ser desarrolladas pasando en medio de los vestbulos de cualquier organizacin y escuchando administracin de empresas. Inevitablemente, estos temas recurrentes emergen:
Tenemos montaas de datos en esta compaa, pero no podemos acceder a eso. Necesitamos cortar en rodajas y jugar a los dados los datos desordenadamente. Usted ha conseguido facilitarlo a personas comerciales para alcanzar los datos en seguida. Slo mustreme lo que es importante. Vuelve loco a m para tener presente de dos personas la misma mtrica comercial en una reunin, pero con nmeros diferentes. Queremos que personas usen informacin para soportar ms basada en hechos toma de decisiones. Basadas sobre nuestra experiencia, estas preocupaciones son tan universales que conducen los requisitos del lecho de roca para el almacn de datos. Convirtamos estas citas comerciales de man-agement en requisitos del almacn de datos. El almacn de datos debe hacer a la informacin de una organizacin fcilmente acces sible. Los contenidos del almacn de datos deben tener sentido. Los datos deben ser intuitivos y obvios para el usuario comercial, no meramente el desarrollador. La comprensibilidad le da a entender legibilidad; Los contenidos del almacn de datos necesitan estar etiquetados significativamente. Los usuarios comerciales quieren para sepa-rate y combinan los datos en el almacn en combinaciones interminables, un proceso comnmente llamada caladura y jugando a los dados. Las herramientas que acceden a los datos almacenan debe ser simple y fcil para usar. Tambin le deben devolver los resultados de averiguacin al usuario con veces mnimas de espera. El almacn de datos debe presentar consis-tently de informacin de la organizacin. Los datos en el almacn deben ser crebles. Los datos deben ser cuidadosamente ensamblados de una coleccin variada de fuentes alrededor de la organizacin, limpiado, la calidad asegurada, y soltado slo cuando es competente para consumo del usuario. La informacin de un proceso comercial debera igualar a la informacin de otro. Si dos medidas de funcin tienen el mismo nombre, en ese entonces deben querer decir lo mismo. Inversamente, si dos medidas no quieren decir lo mismo, en ese entonces deberan estar etiquetadas diferentemente. La informacin coherente quiere decir informacin de alta calidad. Quiere decir tan todos los datos son tomados en consideracin y completos. La consistencia tambin le da a entender eso definiciones comunes para el contenido del almacn de datos est disponible para usuarios. El almacn de datos debe ser adaptable y elstico para cambiar. Simplemente
no podemos evitar cambio. El usuario necesita, condiciones de negocios, datos, y tecnologa es todo tema para las arenas alternantes de tiempo. El almacn de datos debe ser diseado para manejar este cambio inevitable. Se cambia al almacn de datos debera ser gracioso, querer decir que no invalidan aplicaciones o datos existentes. Las datos existentes y aplicaciones no deberan estar cambiados o desordenados cuando el mundo de los negocios pregunta preguntas nuevas o datos nuevos se suman al almacn. Si los datos descriptivos en el almacn es modus-fied, debemos dar razn de los cambios apropiadamente.
El almacn de datos debe ser un bastin seguro que protege nuestros activos de informacin. Las informativas joyas de la corona de una organizacin se guardan en el almacn de datos. En un mnimo, el almacn probablemente contiene informacin acerca de lo que vendemos a quin a qu precio los detalles potencialmente dainos en las manos de las personas equivocadas. El almacn de datos effec-tively debe controlar acceso para la informacin confidencial de la organizacin. Los datos para los que el almacn le debe servir de la fundacin mejoraron toma de decisiones. El almacn de datos debe tener los datos correctos en l para soportar deci-sion haciendo. Hay slo una salida cierta de un almacn de datos: El deci-sions que se hace despus de que los datos que el almacn tiene presentaron su prueba. Estas decisiones dan el impacto comercial y el valor atribuible al almacn. La etiqueta original que le pone una fecha anterior a los datos el almacn es todava la mejor descripcin de lo que diseamos: Un sistema de apoyo para la toma de decisiones. El mundo de los negocios debe acoger el almacn de datos si es ser estimado atinado. No importa que hemos construido una solucin elegante usando plataformas y productos mejores en su campo. Si el mundo de los negocios no ha abrazado el almacn de datos y ha continuado usndolo activamente seis meses despus de entrenarse, en ese entonces hemos errado la prueba de aceptacin. A diferencia de una versin reescrita operacional del sistema, donde los usuarios comerciales no les quedan nada ms que usar al sistema nuevo, uso del almacn de datos es algunas veces optativo. Negocio
La aceptacin del usuario tiene ms para hacer con simplicidad que cualquier otra cosa.
Como esta lista ilustra, demandas atinadas de almacenamiento de datos bastante ms que ser un estelar administrador de base de datos o la tcnica. Con una iniciativa que almacena datos, tenemos un pie en nuestra zona de comodidad de tecnologa de la informacin (L), mientras nuestro otro pie est en la tierra enzacatada poco familiar de usuarios comerciales. Debemos sobrepasar lo dos, modify-ing algunos de nuestras habilidades probadas y ciertas para adaptarnos a las demandas nicas de datos almacenando. Claramente, necesitamos traer a un grupo de habilidades a la fiesta para comportarnos como somos una / Asociacin de Banqueros Hipotecarios de Amrica hbrida del administrador de base de datos.
La Metfora Editorial Con las metas de los datos el almacn como un teln de fondo, nos dej comparar nuestro respon-sibilities como los datos almacenan a los gerentes con ese de un editorial redactor en jefe. Como el editor de una revista de alta calidad, usted recibira latitud amplia para manejar el contenido de la revista, estilo, y entrega. Alguien con este ttulo de trabajo probablemente abordara las siguientes actividades: identifique a sus lectores demogrficamente. averige lo que los lectores quieren en esta clase de revista. identifique a los mejores lectores que renovarn sus suscripciones y productos de compra de los anunciantes de la revista.
encuentre a los lectores nuevos potenciales y dgales la revista. escoja el contenido de la revista la mayora de advocacin para los lectores del blanco. haga decisiones del trazado y de interpretacin que maximizan el placer de los lectores. sostenga alta calidad escribiendo y editando estndares, mientras adoptando un estilo coherente de presentacin. continuamente monitoree la exactitud de los artculos y los reclamos del anunciante. desarrolle una buena red de escritores y los contribuyentes como usted recogen aporte nuevo para el contenido de la revista de una coleccin variada de fuentes. atraiga publicidad y corra la revista aprovechadamente. publique la revista de forma regular. mantenga la confianza de los lectores. mantenga a los dueos de negocio felices.
Tambin podemos identificar artculos que deberan ser poco metas para el redactor en jefe de la revista. Estos incluiran cosas as como basar la revista en la tecnologa de una mquina impresora particular, meter a energa de la gerencia en eficiencias operacionales exclusivamente, imponiendo un estilo tcnico de la escritura que los lectores fcilmente no comprenden, o creando un trazado intrincado y abarrotado que es difcil de estudiar atentamente y ley. Construyendo el negocio editorial en una fundacin de servirle a los lectores eficazmente, su revista tiene probabilidad de tener xito. Inversamente, pase a travs de la lista y supngase qu pasa si usted omite cualquier solo artculo; Finalmente, su revista tendra problemas serios. El punto de esta metfora, por supuesto, debe extraer lo paralelamente entre ser un editor publicista convencional y sea un gerente del almacn de datos. Somos con-vinced que la correcta descripcin de trabajo pues una informacin gerente del almacn es pub-lisher de los datos correctos. Conducido por las necesidades del negocio, los datos almacenan a los gerentes son responsables de datos editoriales que han sido recogidos en una coleccin variada de fuentes y revisado para la calidad y la consistencia. Su responsi-bility principal como un gerente del almacn
de datos debe servirle a sus lectores, conocido como usuarios comerciales. La metfora editorial acenta la necesidad para enfocar de guerra apagada para sus clientes en vez de meramente enfocando hacia dentro en productos y los procesos. Mientras usted usar tecnologa para entregar su almacn de datos, la tecnologa es en el mejor de los casos unos medios para conseguir un fin. Como tal, la tecnologa y tech-niques que usted suele construir sus almacenes de datos no deberan directamente aparecer en sus responsabilidades sobresalientes de trabajo. Remodelemos las responsabilidades del editor publicista de la revista como los datos las responsabilidades del envejecente de hombre del almacn:
comprndalos a sus usuarios por las responsabilidades del rea comercial, de trabajo, y la tolerancia de com-put. determine las decisiones que los usuarios comerciales quieren hacer de la ayuda del almacn de datos. identifique a los mejores usuarios que hacen decisiones efectivas, de alto impacto usando el almacn de datos. encuentre a los usuarios nuevos potenciales y dgales el almacn de datos. escoja el subconjunto ms efectivo, demandable de los datos para presentar en el almacn de datos, extrado del vasto universo de datos posibles en su organizacin. haga las interfaces de usuario y aplicaciones simples y conducidas en plantilla, explcitamente que hace juego para las reseas cognitivas de procesamiento de los usuarios. haga seguro los datos son precisos y pueda ser en lo que se confi, etiquetndolo consistentemente a travs de la empresa. continuamente monitoree la exactitud de los datos y el contenido de los informes entregados.
vaya en busca de fuentes nuevas de datos, y continuamente adapte el almacn de datos a cambiar reseas de datos, reportando requisitos, y las prioridades comerciales. tome una porcin del crdito por las decisiones comerciales hechas usando el almacn de datos, y use estos xitos para justificar su dotacin de personal, software, y gastos del hardware. publique los datos de forma regular. mantenga la confianza de usuarios comerciales. mantenga a sus usuarios comerciales, sus patrocinadores ejecutivos, y su jefe feliz. Si usted hace un buen trabajo con todas estas responsabilidades, usted ser un gran gerente del almacn de datos! Inversamente, descienda a travs de la lista y supngase qu pasa si usted omite cualquier solo artculo. Finalmente, su almacn de datos tendra problemas serios. Le instamos a contrastar esta vista de trabajo de un gerente del almacn de datos con su descripcin de trabajo. Es probable que la lista precedente est mucho ms orientada hacia usuario y asuntos comerciales y aun no puede sonar como a un trabajo en ELLA. En nuestra opinin, ste es qu
almacenamiento de datos de marcas interesndole.
Los componentes de un Almacn de Datos Ahora que comprendemos las metas de un almacn de datos, investiguemos los componentes que hacen un ambiente completo de almacenamiento. Es de ayuda comprender las pedazos cuidadosamente antes de que comencemos a combinarlas crear uno
El almacn de datos. Cada componente del almacn sirve para una funcin especfica. Necesitamos aprender el significado estratgico de cada componente y cmo ejercerlo de manera impresionante para ganar el juego de almacenamiento de datos. Una de las amenazas ms grandes para xito que almacena datos confunde los papeles de los componentes y funciona. Como ilustrados en Figura 1.1, hay cuatro componentes separados y discretos ser considerados exploramos el ambiente del almacn de datos la fuente operacional que los sistemas, el rea de escenificacin de datos, el rea de presentacin de datos, y los datos acceden a labra.
Los Sistemas Operacionales de la Fuente stos son los sistemas operacionales de registro que captan las transacciones del negocio. La fuente como la que los sistemas deberan ser considerados fuera de la casa de loza de datos porque probablemente tenemos poco para ningn control sobre el contenido y para alfombrilla de los datos en estos sistemas legados operacionales. Las prioridades principales de los sistemas de la fuente tramitan funcin y disponibilidad. Las averiguaciones en contra de sistemas de la fuente son el registro estrecho, un en un tiempo pone en duda eso es de lo ni curso de transaccin de mal y gravemente restringida en sus demandas en el sistema de opera-tional. Hacemos la suposicin fuerte que los sistemas de la fuente no son puestos en duda en las formas amplias e inesperadas que los almacenes de datos tpicamente son puestos en duda. Los sistemas de la fuente mantienen datos histricos pequeos, y si usted tiene un buen almacn de datos, a los sistemas de la fuente puede quitrseles mucho de la responsabilidad para representar el pasado. Cada sistema de la fuente es a menudo una aplicacin natural de la tobera, donde la inversin pequea ha sido hecha para compartir datos de com-mon como producto, el cliente, la geografa, o el calendario con otros sistemas de opera-tional en la organizacin. Sera genial si sus sistemas de la fuente estuviesen siendo rediseados con una vista coherente. Tal esfuerzo de integracin de la aplicacin de la empresa (la Empresa para la Iniciativa de las Amricas) har los datos almacenar tarea del diseo mucho ms ms fcil.
Los Sistemas Operacionales de la Fuente El rea de Escenificacin de Datos El rea de Presentacin de Datos Las Herramientas de Acceso de Datos
Extraiga
Extraiga
Extraiga Servicios: Por completo, combine, y compare con un estndar Conforme dimensiones NINGN USUARIO QUE LA AVERIGUACIN REPARA La Tienda de Datos: Las limas planas y las Tablas de relaciones Procesamiento: La clasificacin y El procesamiento secuencial La carga
La carga El #1 del Centro de Compras de Datos El DIMENSIONAL Atomic y Los datos sumarios Basado sobre un solo proceso comercial DW Vaya en Autobs: Las dimensiones y hechos conformados Datos Mart #2 ... (De Modo Semejante diseado) El acceso El acceso
Las Herramientas Ad Hoc de Averiguacin Denuncian A los Escritores Analticos Aplicaciones El modelado: Pronosticando a Anotar Minera de datos
Figura 1.1 Los elementos bsicos del almacn de datos.
El rea de Escenificacin de Datos El rea de escenificacin de datos del almacn de datos es ambos un rea de almacenamiento y un set de procesos comnmente llamada carga de transformacin de extracto (ETL). El rea que escenifica datos es todo entre los sistemas operacionales de la fuente y el rea de presentacin de datos. Est algo anlogo para la cocina de un restaurante, donde los artculos alimenticios crudos son transformados en una comida fina. En la casa de loza de datos, los datos operacionales crudos son transformado en un producto a entregarse del almacn adecuado para la averiguacin del usuario y el consumo. Similar para la cocina del restaurante, la zona de estacionamiento de datos de la trastienda es accesible slo para los profesionales expertos. Los datos tienen cuidado con personal de la cocina de la casa est ocupado preparando comidas y simultneamente no pueden responder para las averiguaciones del cliente. Los clientes no son invitados a comer en la cocina. Ciertamente no es seguro que clientes entren tranquilamente en la cocina. No querramos que nuestros clientes del almacn de datos sean heridos por el equipo peligroso, superficies calientes, y nota en sostenido acuchillan que pueden encontrar en la cocina, as es que los prohibimos ir a acceder a la zona de estacionamiento. Adems, las cosas ocurren en la cocina a la que los clientes slo no deberan ser privados.
El requisito arquitectnico crucial para el rea que escenifica datos es que est fuera de lmites para los usuarios comerciales y no provee servicios de averiguacin y de presentacin.
La extraccin es el primer paso en curso de meterle datos en el ambiente de la casa de loza de datos. Extractando manera rezando y comprendiendo los datos de la fuente y copiando los datos necesitados para el almacn de datos en la zona de estacionamiento para la ms manipulacin. Una vez los datos son extrados para la zona de estacionamiento, hay numerosas transformaciones potenciales, como limpiar los datos (corrigiendo faltas de ortografa, resolver dominio est en conflicto, ocuparse de perder elementos, o
anlisis gramatical en estndar para alfombrillas), combinar datos de fuentes mltiples, los datos deduplicating, y las llaves del almacn de assign-ing. Estas transformaciones son todos los precursores para cargar los datos en el rea de presentacin del almacn de datos. Desafortunadamente, hay todava consternacin considerable de la industria aproximadamente ya sea los datos que mantiene o resulta de este proceso debera ser instantiated en estructuras normalizadas fsicas antes de cargar en el rea de presentacin para poner en duda y reportar. A estas estructuras normalizadas algunas veces se les refiere en la industria como el almacn de datos de la empresa; Sin embargo, creemos que esta terminologa es un nombre inapropiado porque el almacn en verdad mucho ms abarca que este set de Tablas normalizadas. Los datos de la empresa que la casa de loza ms exactamente refiere a la conglomeracin de los datos de una organizacin almacenan reas de escenificacin y de presentacin. As, a todo lo largo de este libro, cuando nos referimos al almacn de datos de la empresa, queremos decir la unin de todos los componentes diversos del almacn de datos, no simplemente el rea de escenificacin de la trastienda.
La rama que escenifica datos es dominado por las actividades simples de ordenar y el procesamiento secuencial. En muchos casos, el rea que escenifica datos no se basa en tecnologa de relaciones sino en lugar de eso puede consistir en un sistema de limas planas. Despus de que usted valide sus datos para la conformidad con lo definido uno a uno y muchos para una reglas de negocio, puede estar sin sentido tomar el paso final de construir una base de datos fsica de la forma normal tercera en toda la extensin de la palabra. Sin embargo, hay casos donde los datos arriban al umbral del rea de escenificacin de datos en una tercera forma normal formato de relaciones. En estas situaciones, los gerentes del rea de escenificacin de datos simplemente pueden ser ms perform-ing confortable la purificacin y las tareas de transformacin usando un set de struc-tures normalizado. Una normalizada base de datos para almacenamiento que escenifica datos es aceptable. Sin embargo, continuamos teniendo algunas reservaciones acerca de este acercamiento. La creacin de ambos normaliz estructuras para escenificar y las estructuras dimensionales para presen-tation la manera que los datos son extractados, transformados, y cargados dos veces una vez en la normalizada base de datos y no obstante cuando carga el modelo dimensional. Obviamente, este proceso de dos pasos requiere ms tiempo y recursos para el esfuerzo de desarrollo, ms tiempo para la carga peridica o actualizando de datos, y ms capacidad para almacenar el mltiplo copia de los datos. En la parte inferior aplquele delineador, esto tpicamente se traduce en la necesidad para el mayor desarrollo, soporte en curso, y presupuestos de la plataforma del hardware. Desafortunadamente, algunos datos tienen cuidado con proyecto de la casa que los equipos han errado miserablemente porque canalizaron toda su energa y recursos a construir las estructuras normalizadas en vez de ubicar hora del desarrollo de un rea de presentacin que mantiene mejor comercial toma de decisiones. Mientras creemos que consis-tency ancho en la empresa de datos es una meta fundamental del ambiente del almacn de datos, hay lo igualmente acercamientos efectivos y menos costosos que fsicamente creando una normal-ized colocada de Tablas en su zona de estacionamiento, si estas estructuras ya no existen. Es aceptable crear una normalizada base de datos para soportar los procesos de escenificacin; Sin embargo, ste no es el objetivo final. Las estructuras normalizadas deben estar prohibido para las averiguaciones del usuario porque derrotan comprensibilidad y funcin. Tan pronto como uno
La base de datos soporta servicios de averiguacin y de presentacin, debe ser considerada parte del rea de presentacin del almacn de datos. Por defecto, las bases de datos normalizadas quedan excluidas del rea de presentacin, lo cual debera ser estrictamente dimensionalmente estructurado. Sin tener en cuenta si est en marcha con una serie de limas planas o una estructura normalizada de datos en la zona de estacionamiento, el paso final del proceso ETL es lo load-ing de datos. Cargar en el ambiente del almacn de datos usualmente se plasma en presentarle las Tablas dimensionales aseguradas en calidad a la masa cargando instalaciones de cada centro de compras de datos. Los datos del blanco para los que el centro de compras entonces debe indexar los datos recin llegados ponen en duda funcin. Cuando cada centro de compras de datos ha tenido frescamente mucho dinero, ha indexado, ha dado abasto con agregados correctos, y la ms calidad
Confiada, la comunidad del usuario est notificada que los datos nuevos han sido publicados. La publicacin incluye a comunicar la naturaleza de cualquier cambios que han ocurrido en las dimensiones subyacentes y cualesquiera suposiciones nuevas que han sido introducidas en los hechos medidos o calculados.
La Presentacin de Datos El rea de presentacin de datos est donde informacin es organizada, almacenada, y se hace capacitada en la ganancia para directo interrogando por usuarios, denuncian escritores, y otro applica-tions analtico. Desde que el rea de escenificacin de la trastienda est fuera de lmites, el rea de presentacin es el almacn de datos hasta donde el mundo de los negocios est preocupado. Es todo el mundo de los negocios ve y los toques por datos acceden a las herramientas. El ttulo de funcionamiento de preliberacin para la primera edicin de La Data Warehouse Toolkit originalmente publicaba los Datos. ste es qu el rea de presentacin con sus modelos dimensionales es a todo alrededor. Tpicamente nos referimos al rea de presentacin como una serie de centros de compras integrados de datos. Un centro de compras de datos es una cua del pastel global del rea de presentacin. En su la mayora de forma de sim-plistic, un centro de compras de datos presenta los datos de un solo proceso comercial. Estos procesos comerciales cruzan los linderos de funciones organizativas. Tenemos varias opiniones fuertes acerca del rea de presentacin. Ante todo, insistimos en que los datos sean presentados, almacenados, y accedidos a en dibujos tcnicos dimensionales. Afortunadamente, la industria ha madurado para el punto donde ya no debatimos este mandato. La industria ha concluido que model-ing dimensional es la tcnica ms viable para darle datos a los usuarios del almacn de datos. El modelado dimensional es un nombre nuevo para una vieja tcnica para hacer bases de datos simplistas y comprensibles. En el caso despus del caso, empezando en los 1970s, eso organismos, asesores, destruyan a los usuarios, y los vendedores han gravitado para una estructura dimensional simple para corresponder a la necesidad humana fundamental para la simplicidad. Imagine a un director de la empresa (el director general) que describe su negocio tan, vendemos productos en
los mercados diversos y medimos nuestra funcin con el paso del tiempo. Como diseadores dimensionales, escuchamos cuidadosamente el nfasis del director general en producto, mercado, y tiempo. La mayora de la gente lo encuentra intuitiva para pensar acerca de este busi-ness como un cubo de datos, con los bordes etiquet producto, mercado, y tiempo. Podemos imaginar cortar en rodajas y jugando a los dados a lo largo de cada uno de estas dimensiones. Los puntos dentro del cubo estn donde las medidas para esa combinacin de producto, mercado, y el tiempo son almacenados. La habilidad para visualizar algo como extracto como un set de datos en una forma concreta y tangible es el secreto de comprensibilidad. Si esta perspectiva parece demasiado simple, entonces bien! Un modelo de datos que comienza por ser simple tiene una probabilidad de permanecer simplista al final del diseo. Un modelo que comienza por estar complicado seguramente estar excesivamente complicado al final. Los modelos excesivamente complicados corrern despacio y sern desechados por usuarios comerciales.
El modelado dimensional es realmente diferente a tercera mod-eling de la forma normal (3NF). El modelar 3NF es una tcnica del diseo que trata de quitar redun-dancies de datos. Los datos estn divididos en muchas entidades discretas, cada uno del cual se convierte en una mesa en la base de datos relacional. Una base de datos de rdenes de ventas podra ponerse en marcha con un registro para cada lnea de orden pero las vueltas en un diagrama del spiderweb asombrosamente complicado como un modelo del 3NF, quiz consistente en los centenares o podra emparejar miles de Tablas normalizadas. La industria algunas veces se refiere a los modelos del 3NF como los modelos ER. ER es un acrnimo para la relacin de entidad. Los diagramas de relacin de entidad (ER diagrama o ERDs) son dibujos de cajas y lneas para comunicar las relaciones entre Tablas. Ambos modelos de 3NF y dimensionales pueden ser representados en ERDs porque ambos consisten en Tablas de relaciones unidas; La diferencia crucial entre los modelos de 3NF y de dimen-sional es el grado de normalizacin. Desde que ambos tipos modelo pueden replantearse como ERDs, nos guardaremos de en lo referente a los modelos del 3NF como modelos ER; En lugar de eso, les llamaremos modelos normalizados a minimizar confusin. El modelado normalizado es inmensamente de ayuda a perfor-mance procesador operacional porque una actualizacin o la transaccin del inserto slo necesita tocar la base de datos en un lugar. Los modelos normalizados, sin embargo, son demasiados complicados para averiguaciones del almacn de datos. Los usuarios no pueden comprender, pueden navegar, o pueden recordar modelos de normal-ized que se parecen al sistema de la autopista sin peaje de Los Angeles. Asimismo, los sistemas de gestin de base de datos de rela-tional (RDBMSs) no pueden poner en duda un modelo normalizado eficazmente; La complejidad abruma los optimizadores de la base de datos, result-ing en la funcin desastrosa. El uso de modelado normalizado en el rea de presentacin del almacn de datos derrota todo el propsito de datos almacenando, a saber, recuperacin intuitiva y de alto rendimiento de datos. Hay un sndrome comn en muchas tiendas grandes de tecnologa de la informacin. Es un tipo de enfermedad que viene excesivamente dibujos tcnicos complicados de almacenamiento de datos. Los sntomas podran incluir:
una inversin de $10 millones del hardware y del software que realiza slo un puado de averiguaciones al da un DEPARTAMENTO DE INFORMTICA que es metido a la fuerza en un tipo de sacerdocio, escribir todos los datos almacena averiguaciones las averiguaciones aparentemente simples que requieren varias pginas de espacio solo
El cdigo estructurado de Lenguaje de Consulta (el lenguaje normalizado de consulta)
un departamento de ventas que est descontento porque no puede acceder al sys-tem directamente (y todava no sabe si la compaa sea lucrativa en Schenectady) un inquieto Jefe de Informacin (el informtico en jefe) que est decidido a hacer algunos cambios si cosas no mejoran dramticamente
Afortunadamente, el modelado dimensional se ocupa del problema de dibujos tcnicos excesivamente complicados en el rea de presentacin. Un modelo dimensional contiene el mismo infor-mation como un modelo normalizado pero empaqueta que los datos en un formato cuyo diseo las metas son comprensibilidad del usuario, ponen en duda funcin, y elasticidad para cambiar. Nuestra segunda estaca en el suelo acerca de centros de compras de datos del rea de presentacin es que deben contener datos detallados, atmicos. Los datos atmicos son requeridos para resistir asaltos de imprevisible respecto a las averiguaciones del usuario del hoc. Mientras los centros de compras de datos tambin pueden contener datos sumarios que realzan funcin, o agregados, no es lo suficiente como para entregar estos resmenes sin los datos granulares subyacentes en una forma dimensional. En otras palabras, es completamente inaceptable almacenar slo datos sumarios en los modelos dimensionales mientras los datos atmicos le ech llave adentro modelos normalizados. Es imprctico esperar que un usuario se entrene abajo datos dimensionales directos casi para el nivel ms granular y entonces pierda los beneficios de una presentacin dimensional en el paso final. En Captulo 16 que veremos que cualquier aplicacin del usuario puede bajar sin esfuerzo alguno hasta el lecho de roca datos granulares por la navegacin utilizadora del agregado, pero slo si todos los datos estn disponibles en lo mismo, la forma dimensional consistente. Mientras los usuarios del almacn de datos pueden considerar infrecuentemente un solo rubro contable sobre una orden, pueden seguir con mucho inters las rdenes de la semana pasada para productos de un tamao dado (o el sabor, el tipo del paquete, o man-ufacturer) para clientes que primero compraron en un plazo de los ltimos seis meses (o reside en un estado dado o tiene ciertas condiciones del crdito). Necesitamos la mayor parte de con precisin datos granulados en nuestro rea de presentacin a fin de que los usuarios puedan preguntar las preguntas ms precisas posibles. Porque los requisitos de los usuarios son imprevisibles y con-stantly cambiando, le debemos proveer el acceso a los detalles exquisitos a fin de que pueden estar enrollados para ocuparse de las preguntas del momento. Todos los centros de compras de datos deben construirse usando dimensiones comunes y hechos, cul referimos a como conformado. sta es la base del architec-ture del autobs del almacn de datos, cul explicaremos en detalle en Captulo 3. La adherencia para la arquitectura del autobs es nuestra tercera estaca
en el suelo referente al rea de presentacin. Sin dimensiones compartidas, conformadas y hechos, un centro de compras de datos es una aplicacin auto sostenible de la tobera. Los centros de compras aislados de datos de la tobera que no pueden ser atados son el flagelo del movimiento del almacn de datos. Meramente perpetan incompatibles puntos de vista de la empresa. Si usted tiene cualquier esperanza de construir un almacn de datos que es robusto e integrado, usted debe comprometerse a lo archi-I-tecture del autobs. En este libro ilustraremos que cuando los centros de compras de datos han sido diseados con hechos y dimensiones conformadas, pueden estar combinados y usados juntos. Los datos almacenan rea de presentacin en un almacn grande de datos de la empresa finalmente consistir en 20 o ms centros de compras de datos muy que miran similar. Los modelos dimensionales en estos centros de compras de datos tambin se parecern realmente. Cada centro de compras de datos puede contener varias Tablas de hecho, cada uno con 5 para 15 Tablas de dimensin. Si el diseo ha terminado correctamente, muchas de estas Tablas de dimensin sern compartidas de mesa de hecho para mesa de hecho.
Usar la arquitectura del autobs es el secreto para construir sistemas distribuidos del almacn de datos. Seamos reales la mayor parte de nosotros no tenemos el presupuesto, cronometramos, o poder poltico para construir un almacn de datos con creces centralizado. Cuando el autobs que la arquitectura es usada como un armazn, podemos dar rienda suelta a que los datos de la empresa almacenan para desarrollarse en una forma descentralizada (y positivista ms lejano).
Los datos en el rea capaz de poner en duda de presentacin del almacn de datos deben ser dimen-sional, deben ser atmicos, y deben pegrsele a la arquitectura del autobs del almacn de datos.
Si el rea de presentacin se basa en una base de datos relacional, en ese entonces estas Tablas modeladas dimen sionally son llamados dibujos tcnicos de la estrella. Si el rea de presentacin se basa en multidimensional base de datos o tecnologa analtica de procesamiento en lnea (OLAP), en ese entonces los datos se guardan en cubos. Mientras la tecnologa originalmente no fue llamado OLAP, muchos del ven-dors tempranero de sistema de apoyo para la toma de decisiones basaron a sus sistemas en el concepto del cubo, tan los vendedores OLAP del hoy naturalmente son alineados con el acercamiento dimensional para datos almacenando. El modelado dimensional es aplicable para ambas bases de datos de relaciones y multidimensionales. Ambos tienen un diseo lgico comn con dimensiones reconocibles; Sin embargo, la implementacin fsica difiere. Afortunadamente, la mayor parte del recom-mendations en este libro pertenece, sin tener en cuenta la plataforma de la base de datos. Mientras las capacidades de tecnologa OLAP mejoran continuamente, al momento de esta escritura, la mayora de centros de compras grandes de datos son todava implementados en bases de datos de relaciones. Adems, la mayora de cubos OLAP son sourced de o se entrenan en dibujos tcnicos dimensionales de la estrella de relaciones usando una variacin de navegacin del agregado. Para estas razones, la mayor parte de los debates especficos rodeando el rea de presentacin son arrellanados en trminos de una plataforma de relaciones.
En contra de la religin original del almacn de datos, a los centros de compras modernos de datos bien puede ponrseles al corriente, algunas veces frecuentemente. Los datos incorrectos obviamente deberan corregirse. Cambia en etiquetas, las jerarquas, el estatus, y la propiedad corporativa a menudo provocan cambios necesarios en los datos originales almacenados en los centros de compras de datos que comprenden el almacn de datos, pero en general, stas son actualizaciones de carga administrada, no actualizaciones transaccionales.
Las Herramientas de Acceso de Datos El componente principal de cierre del ambiente del almacn de datos es la herramienta de acceso de datos (s). Usamos la herramienta de trmino holgadamente referirnos a la variedad de capacidades que pueden ser provistas a las usuarias comerciales para apalancar el rea de presentacin para la analtica toma de decisiones. Por definicin, todo lo que los datos acceden a labra averiguacin que los datos en los datos almacenan rea de presentacin. Poniendo en duda, obviamente, es todo el punto de usar el almacn de datos.
Una herramienta de acceso de datos puede ser tan simple como una herramienta ad hoc de averiguacin o tan complicado como una minera sofisticada de datos o aplicacin modeladora. Con fines especficos ponga en duda herramientas, tan energtico como lo son, pueden ser comprendidas y usadas eficazmente slo por un porcentaje pequeo de los datos potenciales poblacin del usuario de negocio del almacn. La mayor parte del negocio el usuario basa probablemente acceder a los datos por aplicaciones analticas accionadas por parmetros preconstruidas. Aproximadamente 80 para 90 por ciento de los usuarios potenciales sern servidos por estas aplicaciones enlatadas que son esencialmente terminado las plantillas que no requieren a los usuarios construir averiguaciones de relaciones directamente. Algunos de los datos ms sofisticados acceden a herramientas, como modelar o pronosticar herramientas, en verdad pueden tele-enviar sus resultados de vuelta a sistemas operacionales de la fuente o las reas de escenificacin /presentacin del almacn de datos.
Las Consideraciones Adicionales Antes de que dejamos el debate de componentes del almacn de datos, all estn conceptos del otro de sev-eral que garantizan debate.
Metadata Metadata es toda la informacin en el ambiente del almacn de datos que no es la informacin real misma. Metadata es semejante para una enciclopedia para la casa de loza de datos. Los datos almacenan parejas a menudo gastan una enorme cantidad de talk-ing de tiempo aproximadamente, preocupndose acerca de, y acusndoles la conciencia acerca de metadatos. Desde que la mayora de desarrolladores tienen una aversin natural para el desarrollo y el ordenanza archivando de documentacin, los metadatos a menudo queda cortado del plan de proyecto a pesar de cada un la aceptacin que es importante. Metadata viene en una coleccin variada de formas y unas colecciones variadas de formas para soportar las necesidades dispares de los grupos tcnicos, administrativos del usuario, y comerciales del almacn de datos. Tenemos
metadatos operacionales del sistema de la fuente incluyendo dibujos tcnicos de la fuente y los copiacartas que facilitan la extraccin van en procesin. Una vez los datos estn en la zona de estacionamiento, encontramos escenificar metadatos para guiar la transformacin y cargar apfisis, incluyendo escenificando archivo y los trazados de la mesa del blanco, la transformacin y limpiar reglas, dimensin conformada y definiciones de hecho, definiciones de agregacin, y transmisin ETL horarios y resultados del leo corrido. Empareje la costumbre programando cdigo de escritura en el rea de escenificacin de datos son metadatos. Metadata rodeando el sistema de gestin de base de datos del almacn da razn de tales artculos como las Tablas del sistema, ajustes de la particin, ndices, definiciones de vista, y los privilegios prendarios nivelados en sistema de gestin de base de datos y las concesiones. Finalmente, los datos acceden a los metadatos de la herramienta identifican nombres de la empresa y definiciones para las Tablas del rea de presentacin y las columnas as como tambin la restriccin filtra, especificaciones aplicativas de la plantilla, acceso y estadsticas de uso, y otra documentacin del usuario. Y por supuesto, si no tenemos
Incluido eso ya, no olvida todos los ajustes prendarios, a partir de fuente datos transaccionales y extensible hasta la parte superior de un escritorio del usuario. El objetivo final es encerrar en el corral, catalogar, integrarse, y entonces apalancar estas variedades de dis-parate de metadatos, mucho gustarle los recursos de una biblioteca. Repentinamente, el esfuerzo para construir modelos dimensionales parece decrecer en importancia en contraste. Sin embargo, solamente porque la tarea surge amenazadoramente de gran estatura, que simplemente no podemos ignorar el desarrollo de un armazn de metadatos para el almacn de datos. Necesitamos desarrollar un plan global de metadatos al darle prioridad a los productos a entregarse de corto plazo, incluir el pur-chase o la construccin de un confidente para seguirle la pista a todos los metadatos.
La Tienda Operacional de Datos Alguno de ustedes probablemente se pregunta donde los datos operacionales almacenan (los desarrollos organizativos) ataques en nuestro diagrama de componentes del almacn. Desde all no la sola definicin universal para los desarrollos organizativos, si y donde pertenece dependa de su situacin. Los ODSs son copias frecuentemente actualizadas, algo integradas de datos operacionales. La frecuencia de actualizacin y el grado de integracin de un ODS varan basados sobre los requisitos especficos. En todo caso, la O es la carta operativa en el acrnimo de desarrollos organizativos. Ms comnmente, unos desarrollos organizativos es implementado para entregar informacin operacional, especialmente cuando ni el legado ni ms sistemas que procesan transaccin (OLTP) moderna y en lnea proveen informes operacionales adecuados. Estos informes son caracterizados por un set limitado de averiguaciones fijas que pueden ser de hilos de metal duro en una aplicacin ponente. Los informes se ocupan de los requisitos ms para toma de decisiones tcticos de la organizacin. Agregaciones que realzan funcin, el canturreo signifi la serie temporal histrica, y la extensiva atribucin descriptiva quedan especficamente excluidos de los desarrollos organizativos. Los desarrollos organizativos como una instancia ponente pueden ser un punto de apoyo para alimentar datos operacionales en el almacn.
En otros casos, ODSs son fortalecidos para soportar interacciones de tiempo real, especialmente en aplicaciones de la gerencia de relacin de Cu-tomer (la gestor de relaciones con el cliente) como acceder a su itinerario de viaje en un sitio Web o su historia de servicio cuando usted llama en soporte del cliente. Los datos tradicionales almacenan tpicamente no es en condiciones de soportar la demanda para cerca de datos de tiempo real o los inmediatos tiempos de respuesta. Similares para la panorama operacional de informacin, las averiguaciones de datos para soportar estos interAc-tions de tiempo real tienen una estructura fija. Interesantemente, este tipo de desarrollos organizativos algunas veces apalanca informacin del almacn de datos, como una aplicacin del centro de llamada de servicio al cliente que utiliza al cliente que la informacin conductista de los datos almacena para precalcular puntuaciones de propensin y una tienda ellas en los desarrollos organizativos. En cualquier panorama, los desarrollos organizativos pueden ser ya sea un sistema fsico de tercera parte sedentes entre los sistemas operacionales y los datos almacena o una particin especialmente caliente administrada del almacn de datos mismo. Cada organizacin obviamente necesita
Los sistemas operacionales. Asimismo, cada organismo sacara provecho de un almacn de datos. Lo mismo no puede ser dicho acerca de un ODS fsicamente discreto a menos que los otros dos sistemas no puedan contestar sus preguntas operacionales inmediatas. Claramente, usted no debera ubicar recursos para construir un tercer sistema fsico a menos que sus necesidades comerciales no pueden contar con el respaldo tampoco el sistema recaudatorio en datos operacional o el almacn de datos. Para estas razones, creemos que la tendencia en diseo del almacn de datos es dar los desarrollos organizativos como uno especialmente porcin adminis tered del almacn convencional de datos. Fomentaremos discos ODSs de estilo de particin caliente en Captulo 5. Finalmente, antes de que dejamos este tema, algunos han definido los desarrollos organizativos para querer decir el lugar en el almacn de datos donde almacenamos datos atmicos granulares. Creemos que esta informacin detallada debera ser considerada una parte natural del rea de presentacin de la casa de loza de datos y no de una entidad separada. Empezando en Captulo 2, mostraremos cmo son las transacciones niveladas mnimas en un negocio la fundacin para el rea de presentacin de los datos almacena.
El Vocabulario Dimensional de Modelado
A todo lo largo de este libro que referiremos repetidamente al hecho y que las Tablas de dimensin. En contra del folklore popular, Ralph Kimball no invent esta terminologa. Como mejor como podemos determinar, las dimensiones de trminos y hechos se originaron de un proyecto de investigacin unido bajo la direccin de General Mills y Dartmouth University en lo 1960s. En los 1970s, la corriente alterna Nielsen e IRI usaron estos trminos consistentemente describir sus ofertas sindicadas de datos, lo cual pudo estar descrito exactamente hoy como centros de compras dimensionales de datos para datos de ventas por menor. Mucho antes de que la simplicidad fuese una tendencia de estilo de vida, las sindicadoras antiguas de la base de datos gravitaron para estos con-cepts para simplificar la presentacin de informacin analtica. Tuvieron por entendido que una base de datos no sera usada a menos que estaba empacada
simplemente.
Es probablemente precisa decir que una sola persona no invent el ap-ACh dimensional. Es una fuerza irresistible en el diseo de bases de datos que siempre resultarn cuando el diseador coloque comprensibilidad y funcin como las metas ms altas.
La Mesa de Hecho Una mesa de hecho es la mesa primaria en un modelo dimensional donde las medidas numricas de funcin del negocio son almacenado, como ilustradas en Figura 1.2. Nos esforzamos por almacenar los datos de medida resultando de un proceso comercial en un solo centro de compras de datos. Desde datos de medida es abrumadoramente la parte ms grande de cualquier centro de compras de datos, evitamos que duplicar en series mltiples coloca alrededor de la empresa.
La Mesa Diaria de Hecho de Ventas La cantidad de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) Vendi Las Ventas del Dlar Tienen Importancia Creo 1.2 la mesa de hecho De Muestra.
Usamos el hecho de trmino para representar una medida comercial. Podemos imaginar estar en el mercado observando ser productos vendi y depreciando el quan-tity vendido y cantidad de ventas del dlar cada da para cada producto en cada tienda. Una medida es tomada en la interseccin de todas las dimensiones (el da, el producto, y la tienda). Esta lista de dimensiones define la cantidad muy pequea de la mesa de hecho y nos dice lo que el alcance de la medida es.
Una fila en una mesa de hecho concuerda con una medida. Una medida es una fila en una mesa de hecho. Todas las medidas en una mesa de hecho deben estar en el mismo grano.
Los hechos ms tiles son numricos y aditivos, como ventas del dlar tienen importancia. A todo lo largo de este libro usaremos dlares como la moneda circulante estndar para hacer los ejemplos de estudio de casos ms tangibles por favor soprtelos a los autores y substi-tute su propia moneda local si no acierta a ser dlares. Additivity es crucial porque los datos almacenan aplicaciones casi nunca recupere una sola fila de la mesa de hecho. Ms bien, traen de vuelta centenares, miles, o aun millones de filas de hecho a la vez, y la cosa ms til a hacer con tantas filas debe sumarlos. En Figura 1.2, cueste lo que cueste corte en rodajas de la base de datos que el usuario escoge, podemos sumar las cantidades y dlares para un total vlido. Veremos ms tarde en este libro que hay hechos que son semiaditivos y todava
otros que son poco aditivos. Los hechos Semiadditive pueden agregarse slo a lo largo de una cierta cantidad de las dimensiones, y los hechos poco aditivos simplemente no pueden agregarse del todo. Con hechos poco aditivos nos vemos forzados a usar cuentas o promedios si deseamos para sum-marize las filas o se reducen a imprimir las filas de hecho uno de cada vez. ste sera un ejercicio aburrido en una mesa de hecho con un billn de filas.
Los hechos ms tiles en una mesa de hecho son numricos y aditivos.
A menudo describimos hechos tan continuamente apreciados principalmente como un gua para que el diseador ayude a ordenar fuera lo que es un hecho versus un atributo de dimensin. Las ventas de dol-Lar que la cantidad el hecho es continuamente apreci en este ejemplo porque puede cobrar virtualmente cualquier valor dentro de un alcance amplio. Como observadores, tenemos que estar parados
Fuera de adentro el mercado y espera para la medida antes de que tengamos cualquier idea qu el valor ser. Es tericamente posible que un hecho para medido sea textual; Sin embargo, lo con-dition asciende raras veces. En la mayora de los casos, una medida textual es una descripcin de algo y es sacada de una lista discreta de valores. El diseador debera hacer lo imposible por poner medidas textuales en dimensiones porque pueden estar correlacionados ms eficazmente con los otros atributos textuales de dimensin y consumirn demasiado menos espacio. No almacenamos informacin textual redundante en Tablas de hecho. A menos que el texto es nico para cada fila en la mesa de hecho, corresponde a la mesa de dimensin. Un texto verdadero el hecho es raro en un almacn de datos porque el contenido imprevisible de un hecho del texto, como un comentario gratis del texto, lo imposibilita casi para analizar. En nuestra mesa de hecho (vea Figura 1.2) de muestra, si no hay actividad de ventas en un da dado en una tienda dada para un producto dado, omitimos la fila de la mesa. Tiene mucha importancia que no intentamos llenar la mesa de hecho de ceros no representando nada ocurriendo porque estos ceros abrumaran la mayor parte de nuestras Tablas de hecho. Por slo incluir actividad cierta, las Tablas de hecho tienen tendencia a ser muy escasas. A pesar de su sparsity, las Tablas de hecho usualmente hacen 90 por ciento o ms del espacio total consumido por una dimensional base de datos. Las Tablas de hecho tienen tendencia a ser profundos en trminos del nmero de filas sino estrecho en trminos del nmero de columnas. Dado su tamao, nosotros somos juiciosos acerca de la utilizacin del espacio de la mesa de hecho. Como desarrollamos los ejemplos en este libro, veremos que todos los granos de la mesa de hecho caen en una de tres categoras: Transaccin, foto peridica, y foto de accumu-lating. Las Tablas de hecho del grano de transaccin estn entre lo ms comn. Introduciremos Tablas de hecho de transaccin en Captulo 2, fotos peridicas en Chap Ter 3, y fotos que acumulan en Captulo 5. Todas las Tablas de hecho tienen dos o ms llaves extranjeras, como llamado por la notacin FK en Figura 1.2, eso conctese a las llaves primarias de las Tablas de dimensin. Por ejemplo, la llave del producto en el hecho que la mesa siempre corresponder a una llave especfica del producto en la mesa de dimensin del
producto. Cuando todas las llaves en el hecho ponen sobre una mesa fsforo su respec-tive llaves primarias correctamente en la dimensin correspondiente pospone, decimos que las Tablas satisfacen integridad de referencia. Accedemos al hecho que la mesa por las Tablas de dimensin se incorpor a l. El hecho que la mesa misma generalmente tiene su propia llave primaria hecha de un subconjunto de las llaves extranjeras. Esta llave es a menudo llamado una llave compleja o concatenada. Cada hecho que la mesa en un modelo dimensional tiene una mezcla la llave, e inversamente, cada mesa que tiene una llave compleja es una mesa de hecho. Otra manera para decir esto es ese adentro un modelo dimensional, cada mesa que expresa uno muchos para muchas relacin debe ser una mesa de hecho. Todo lo que otras Tablas son Tablas de dimensin.
Las Tablas de hecho expresan lo muchos para muchas relaciones entre dimensiones en los modelos de dimen-sional.
Slo un subconjunto de los componentes en el hecho que la llave de la mezcla de la mesa tpicamente se necesita para garantizar unicidad de la fila. Hay usualmente acerca de unas medias dimensiones de docena que tienen robusto muchos para muchas relaciones con cada otro y excepcionalmente identifica cada fila. Algunas veces hay como pocos como dos dimensiones, como el nmero de factura y el producto teclean. Una vez este subconjunto ha sido identificado, el resto de dimensiones cobran un solo valor en el contexto de la llave primaria de la fila de la mesa de hecho. En otras palabras, prosiguen para el paseo. En la mayora de los casos, no hay ventaja para introducir una llave nica ROWID a servir de la llave primaria en la mesa de hecho. El proceder hace su mesa de hecho ms grande, mientras cualquier ndice en este ROWID fingido llave primaria sera una porquera. Sin embargo, tal llave puede ser requerida para aplacar el sistema de gestin de base de datos, espe-cially si usted puede legtimamente, de una perspectiva comercial, mltiplo de carga iden tical rema en la mesa de hecho. Las Tablas de Dimensin Las Tablas de dimensin son compaeras integrales para una mesa de hecho. Las Tablas de dimensin contienen los descriptores textuales del negocio, tan ilustradas en Figura 1.3. En un modelo dimensional bien diseado, las Tablas de dimensin tienen un montn de columnas o atributos. Estos atributos describen las filas en la mesa de dimensin. Nos esforzamos por incluir tantas descripciones significativas del textlike tan posible. No es raro para una mesa de dimensin tener 50 para 100 atributos. Las Tablas de dimensin tienen tendencia a ser relativamente poco hondo en trminos del nmero de filas (a menudo mucho menos cantidad de que 1 millones de filas) pero son anchas con muchas columnas grandes. Cada dimensin est definida por su sola llave primaria, llamada por la notacin PK en Figura 1.3, lo cual sirve de la base para la integridad de referencia con cualquier mesa dada de hecho para la cual es simultnea.
El saque de atributos de dimensin como la fuente primaria de restricciones de averiguacin, group-ings, y las etiquetas de informe. En una averiguacin o una peticin de informe, los atributos son identificados como lo por palabras. Por ejemplo, cuando un usuario manifiesta que l o ella quiere ver ventas de dol-Lar por la semana por marca, la semana y la marca deben estar disponibles como atributos de dimensin. Los atributos de la mesa de dimensin juegan un papel extremadamente importante en el almacn de datos. Desde que son la fuente de virtualmente todas las restricciones interesantes y el informe etiqueta, son llave para hacer el almacn de datos utilizable y comprensible. De muchas formas, los datos como los que el almacn es slo bueno como los atributos de dimensin. El poder del almacn de datos es en seguida proporcional para la calidad y la profundidad de lo
Los atributos de dimensin. La ms tiempo suministracin gastada atribuye con terminologa comercial poco concisa, lo que mejor los datos almacenan es. El ms tiempo transcurrido poblando los valores en una columna de atributo, lo que mejor el almacn de datos es. El ms tiempo transcurrido asegurando la calidad de los valores en una columna de atributo, lo que mejor el almacn de datos es.
Las Tablas de dimensin son los puntos de entrada en la mesa de hecho. Attrib-utes robusto de dimensin da caladura analtica robusta y a jugar a los dados capacidades. El imple-ment de dimensiones la interfaz de usuario para el almacn de datos. Los mejores atributos son textuales y discretos. Los atributos deberan consistir en palabras autnticas en vez de abreviaturas secretas. Los atributos tpicos para una dimensin del producto incluiran una descripcin pequea (10 para 15 personajes), una larga descripcin (30 para 50 personajes), un nombre de marca, un nombre categorial, embalaje mecanografa, el tamao, y numerosas otras caractersticas del producto. Aunque el tamao es probablemente numrico, que es todava un atributo de dimensin porque se comporta ms gusta una descripcin textual antes que gustar una medida numrica. El tamao es un descriptor discreto y constante de un producto especfico. Algunas veces cuando diseamos una base de datos es poco clara si un campo de dato numrico extractado de una fuente de datos de produccin es un hecho o un atributo de dimensin. A menudo podemos tomar la decisin preguntando si el dominio es un mea-surement que cobra montones de valores y participa de clculos (hacindole un hecho) o es una con discrecin descripcin preciada que es ms o menos perseverante y participa de restricciones (hacindole un atributo dimensional). Por ejemplo, el coste estndar pues un producto parece como un constante atributo del producto pero puede variarse tantas veces que eventualmente decidimos que es ms como un hecho medido. Ocasionalmente, no podemos estar seguros de la clasificacin. En tales casos, puede caber modelar el campo de dato de una u otra manera, a causa de la prerrogativa de diseador.
La Mesa de Dimensin del Producto La descripcin del Producto de la Llave del producto (PK) El nmero de unidad de control de inventarios (la Llave Natural) Brand Description El Tamao Categorial del Paquete de Descripcin de Tipo del Paquete de Descripcin del Departamento de Descripcin El Peso Contento Grueso de Descripcin de Tipo de Dieta de Descripcin Las Unidades De Peso de Medida La Profundidad del Estante de Altura del Estante de Anchura del Estante de Tipo de Tiempo Antes de Caducar de Tipo de Almacenamiento ... y muchos ms Figura 1.3 Pruebe mesa de dimensin.
Nos esforzamos por minimizar el uso de cdigos en nuestra dimensin pospone reemplazndolos con atributos ms textuales poco concisos. Tenemos por entendido que usted ya le pudo haber enseado a los usuarios a hacer sentido de mandos de operacin, pero yendo para distrito, nos gustara minimizar su confianza en notas en miniatura adjunto a la presente para su monitor de la computadora para traducciones de cdigo. Queremos tener estndar descifra para los mandos de operacin disponibles como atributos de dimensin as es que el etiquetado en almacn de datos pone en duda y reporta es coherente. No queremos alentar descifra sepultado en nuestras aplicaciones ponentes, donde la inconsistencia es inevitable. Los cdigos algunas veces operacionales o los identificadores tienen significado legtimo de busi-ness para los usuarios o son requeridos para comunicarse de regreso al mundo de opera-tional. En estos casos, los cdigos deberan aparecer como atributos explcitos de dimensin, adems de los descriptores textuales de fcil manejo correspondientes. Hemos identificado operacionales, la nota natural teclea las cifras de dimensin, segn el caso, a todo lo largo de este libro. Los mandos de operacin a menudo tienen inteligencia incrustada en ellos. Por ejemplo, los primeros dos dgitos pueden identificar la clase de negocio, mientras que los siguientes dos dgitos pueden identificar la regin global. En vez de obligar a los usuarios a interrogar o fil-ter sobre el mando de operacin, tiramos fuera de los significados incrustados y les presentamos a los usuarios como la dimensin separada atribuye eso pueden ser filtrados, agrupados, o pueden ser reportado adelante fcilmente. Las Tablas de dimensin a menudo representan relaciones jerrquicas en el negocio. En nuestra mesa de dimensin del producto de muestra, los productos se remangan en marcas y entonces en las categoras. Para cada fila en la dimensin del producto, almacenamos la marca y la descripcin categorial se asoci con cada producto. Nos damos cuenta de que la informacin descriptiva hierar chical se guarda redundantemente, pero hacemos eso en el espritu de facilidad de uso y ponemos en duda funcin. Resistimos nuestro deseo natural a almacenar slo el cdigo de marca en la dimensin del producto y crear una mesa separada de bsqueda de marca. ste sera llamado un copo de nieve. Las Tablas de dimensin tpicamente son altamente denormalized. Son usualmente bastantes pequeas (menos de 10 por ciento de los requisitos totales de almacenamiento de datos). Desde que las Tablas de dimensin tpicamente son geomtricamente ms pequeas
que Tablas de hecho, mejorando eficiencia de almacenamiento por ah normalizando o snowflaking no tiene virtualmente impacto sobre el tamao global de la base de datos. Casi siempre entregamos a cambio espacio de la mesa de dimensin para la simplicidad y la accesibilidad. Juntando Hechos y Dimensiones Ahora que comprendemos Tablas de hecho y de dimensin, traigamos los dos bloques de build-ing juntos en un modelo dimensional. Como ilustrado en Figura 1.4, el hecho que la mesa consistente en las medidas numricas es adjuntada a un set de Tablas de dimensin se llen de atributos descriptivos. Esta estructura caracterstica del starlike es a menudo llamado un dibujo tcnico de la juntura de la estrella. Este trmino data de los das del earliest de bases de datos de rela-tional.
La Dimensin de Fecha Los atributos de Fecha de la Llave de fecha (FK) Los Hechos Diarios de Ventas Los hechos de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (PK) La Dimensin del Producto Los atributos del Producto de la Llave del producto (PK)
Almacene Dimensin Almacene Atributos De la Tienda Cruciales (PK) Figura 1.4 el Hecho y Tablas de dimensin en un modelo dimensional.
La primera cosa que notamos acerca del dibujo tcnico dimensional resultante es su sim-plicity y simetra. Obviamente, los usuarios comerciales sacan provecho de la simplicidad porque los datos son ms fciles de entender y navegar. El encanto del diseo en Figura 1.4 es que es altamente reconocible para los usuarios comerciales. Hemos observado literalmente centenares de instancias donde los usuarios estn inmediatamente de acuerdo que el modelo dimensional es su negocio. Adems, el nmero reducido de Tablas y el uso de descriptores comerciales significativos hacen eso menos probablemente que las mal-tomas ocurrirn. La simplicidad de un modelo dimensional tambin tiene beneficios de funcin. Los optimizadores de bases de datos procesarn estos dibujos tcnicos simples ms eficazmente con menos junturas. Un motor de la base de datos puede hacer suposiciones muy fuertes acerca de la primera contra poniendo tirantes las Tablas de dimensin pesadamente indexadas, y entonces atacando la mesa de hecho al mismo tiempo con el producto cartesiano del satis-fying de llaves de la mesa de dimensin las restricciones del usuario. Asombrosamente, usando este acercamiento cabe evaluar junturas arbitrarias de n-way para una mesa de hecho en un solo paso a travs del ndice de la mesa de hecho. Finalmente, los modelos dimensionales son graciosamente extensibles para acomodar cambio. El armazn previsible de un modelo dimensional resiste giros imprevistos en el comportamiento del usuario. Cada dimensin es equivalentes; Todas las dimensiones son simtricamente entrada igual ensea con el dedo en la mesa de hecho. El modelo lgico no tiene suponer prejuicios incorporados esper patrones de averiguacin. No hay preferencias para las preguntas comerciales que preguntaremos este mes versus las preguntas preguntaremos el mes prximo. Ciertamente no queremos ajustar nuestros dibujos tcnicos si los usuarios comerciales sacan de entre manos nuevos mtodos para analizar el negocio.
Veremos repetidamente en este libro que los datos ms granulares o atmicos tiene la mayor parte de dimensionalidad. Los datos atmicos que no han sido agregados es lo
La mayora de datos expresivos; Esta informacin atmica debera ser la fundacin para cada diseo de la mesa de hecho para resistir los ataques ad hoc de usuarios de negocio donde plantean averiguaciones inesperadas. Con modelos dimensionales, le podemos aadir las dimensiones nuevas com pletely al dibujo tcnico con tal de que un solo valor de esa dimensin est definido para cada fila existente de hecho. Asimismo, le podemos aadir los hechos nuevos, imprevistos a la mesa de hecho, suponiendo que el nivel de detalle es con-sistent con la mesa existente de hecho. Podemos suplementar Tablas preexistentes de dimensin con atributos nuevos, imprevistos. Tambin podemos quebrarnos existiendo filas de dimen-sion hasta un nivel ms bajo de granularidad de un cierto punto con el tiempo adelante. En cada caso, existir Tablas puede estar cambiado en el lugar ya sea simplemente sumando filas nuevas de datos en la mesa o ejecutando una orden de la MESA de lenguaje normalizado de consulta ALTER. Los datos no tendran que ser vueltos a cargar. Todas las aplicaciones existentes de acceso de datos continan corriendo sin resultados diferentes lucrativos. Examinaremos esta extensibilidad graciosa de nuestros modelos dimensionales ms completamente en Captulo 2. Otra manera para pensar acerca de la naturaleza complementaria de hecho y dimensionar Tablas deben verlos traducido en un informe. Como ilustrados en Figura 1.5, los atributos de dimensin suministran el informe etiquetando, mientras que las Tablas de hecho suministran los valores numricos del informe. Finalmente, como ya nos hemos estresado, insistimos en que los datos en el rea de presentacin sean dimensionalmente estructurado. Sin embargo, hay una relacin natural entre modelos dimensionales y normalizados. La llave para comprender la relacin es que un soltero normaliz diagrama ER a menudo suspensiones abajo en dibujos tcnicos dimensionales mltiples. Un modelo normalizado abrumador para una organizacin puede tener llamadas de ventas, rdenes, facturas de embarque, pagos del cliente, y el producto devuelve todo en el mismo diagrama. En cierto modo, el diagrama normalizado ER hace por s mismo un perjuicio representando, en un solo dibujo, los procesos mltiples de negocio eso nunca coexiste en un solo conjunto de datos en un solo punto con el tiempo. No es extrao que el modelo normalizado parece complicado. Si usted ya tiene un diagrama normalizado existente ER, el primer paso en con-verting que l en un set de modelos dimensionales es poner aparte el diagrama
ER en su negocio discreto procesa y en ese entonces modelo cada uno separadamente. El segundo paso debe seleccionar esos muchos para muchas relaciones en los diagramas ER que aprenden de memoria azogue numricos y los hechos poco cruciales aditivos y designado ellos como las Tablas de hecho. El paso final es para denormalize todas los dems Tablas en Tablas planas con llaves que se singularizan en parte que adjuntan directamente a las Tablas de hecho. Estas Tablas se convierten en las Tablas de dimen-sion.
La Dimensin del Producto La descripcin del Producto de la Llave del producto (PK) El nmero de unidad de control de inventarios (la Llave Natural) Brand Description Subcategory Description Category Description ... y ms Los Hechos Diarios de Ventas La cantidad de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (PK) Vendi Las Ventas del Dlar Tienen Importancia La Dimensin de Fecha La fecha de la Llave de fecha (PK) El Da de Semana Mes Ao ... y ms
Almacene Dimensin Almacene ZIP de la Tienda del Estado de la Tienda de la Ciudad de la Tienda de la Direccin de la Tienda de Nombre de la Tienda de Nmero De la Tienda Crucial (PK) Almacene Distrito Almacene Regin ... y ms
La suma
La suma
El Distrito Atherton Atherton Belmont Belmont Belmont Marque Ayuno Limpio Ms Zippy de Poder Limpie Rpido Ms Zippy de Poder Las Ventas del Dlar Tienen Importancia 1,233 2,239 848 2,097 2,428 633 La Cantidad Vendida 1,370 2,035 707 2,330 2,207 527
Figura 1.5 Avanzando lentamente y descartando hechos y atributos dimensionales en un informe simple.
Los Mitos Dimensionales de Modelado A pesar de la aceptacin general de modelado dimensional, algn mispercep-tions siga diseminado en la industria. Nos referimos a estos mal-con-ceptions como los mitos dimensionales de modelado. El mito 1. Los modelos dimensionales y los centros de compras de datos son para datos sumarios slo. Este primer mito es la causa de fondo de muchos modelos dimensionales mal diseados. Porque posiblemente no podemos predecir todas las preguntas preguntadas por usuarios comerciales, necesitamos proveerles de acceso capaz de poner en duda a los datos ms detallados a fin de que lo puedan comenzar a rodar arriba basado sobre la pregunta comercial a la mano. Los datos en lo El nivel mnimo de detalle es prcticamente a prueba de sorpresas o cambia. Nuestros centros de compras de datos tambin incluirn datos comnmente resumidos pedidos en dibujos tcnicos dimensionales. Esta informacin sumaria debera complementar el detalle de granu-Lar solamente para proveer funcin mejorada para las averiguaciones comunes, pero no el intento para hacer las funciones de un reemplazo para los detalles. Un corolario relacionado para este primer mito es una cantidad tan limitada nica de histor-ical informacin deberan guardarse en las estructuras dimensionales. No hay nada
Acerca de un modelo dimensional que prohbe el almacenamiento de historia sustancial. La cantidad de historia disponible en centros de compras de datos debe ser conducida por los requisitos del busi-ness. El mito 2. Los modelos dimensionales y los centros de compras de datos son departamentales, no empresa, solu-tions. En vez de dibujar linderos basados en depart-ments organizativo, mantenemos que los centros de compras de datos deberan ser organizados alrededor de los procesos de negocio, como las rdenes, las facturas, y las llamadas de servicio. Las funciones comerciales mltiples a menudo quieren analizar la misma mtrica resultando de un solo proceso comercial. Nos esforzamos por evitar multiplicar por dos las medidas de fondo en mltiples bases de datos alrededor de la organizacin. Los defensores de los datos normalizados almacenan va de entrada algunas veces diagramas levadizos del spiderweb con extractos mltiples de la misma fuente alimentndose en centros de compras mltiples de datos. La ilustracin supuestamente bosqueja los peligros de proceder sin un almacn normalizado de datos a alimentar los centros de compras de datos. Estos defensores le advierten acerca de costes aumentados e inconsisten-cies potencial como los cambios en el sistema de la fuente registrado necesitaran ser rizados para el proceso ETL de cada centro de compras. Esta discusin cae aparte porque nadie apoya extractos mltiples autlogos. Los diagramas del spiderweb se rehusan a valorizarse que los centros de compras de datos no son cntricos en proceso, cntricos en departamento, y que los datos sean extrados una vez de la fuente operacional y se replanteen en un solo lugar. Claramente, las personas operacionales de apoyo de sistema desaprobaran el acercamiento del extracto mltiple. As es que haga nosotros. El mito 3. Los modelos dimensionales y los centros de compras de datos no son dimensionables. Las Tablas modernas de hecho tienen un montn de billones de filas en ellos. Los modelos dimensionales dentro de nuestros centros de compras de datos son sumamente dimensionables. Los vendedores de sistema de gestin de base de datos de relaciones han abrazado datos almacenando y han incorporado numerosas capacidades en sus productos para optimizar la dimensionalidad y la funcin de modelos dimensionales. Un corolario para el mito 3 es que los modelos dimensionales son slo apropiados para datos de venta al por menor o de ventas. Esta nocin est arraigado en los orgenes histricos de dimen-sional modelador pero no en su realidad de da actual. El modelado dimensional ha sido aplicado a virtualmente cada industria,
incluyendo operando en bancos, el seguro, el corretaje, el telfono, el peridico, el petrleo y el gas, el gobierno, confeccionando, el viaje, jugando, la asistencia mdica para la salud, la educacin, y muchos ms. En este libro usamos la industria por menor para ilustrar varios conceptos anticipados principalmente porque es Una industria para la cual todos nosotros hemos quedado al descubierto; Sin embargo, estos conceptos son sumamente transferibles para otros negocios. El mito 4. Los modelos dimensionales y los centros de compras de datos son slo apropiados cuando hay un patrn previsible de uso. Un corolario relacionado es que los modelos dimensionales no son receptivos para cambiar necesidades comerciales. Al contrario, por
Su simetra, las estructuras dimensionales en nuestros centros de compras de datos es sumamente flexible y adaptable para cambiar. El secreto para poner en duda flexibilidad es construir las Tablas de hecho en el nivel ms granular. En nuestra opinin, la fuente de El mito 4 es el diseador en brega con el hecho pospone ese ha sido premA-turely agregado basado en la creencia aciaga del diseador en el mito 1 datos sumarios relacionados. Los modelos dimensionales que slo entregan datos sumarios deben ser problemticos. Los usuarios entran corriendo a las paredes analticas del ladrillo cuando intentan entrenarse abajo en los detalles no disponibles en las Tablas sumarias. Los desarrolladores tambin entran corriendo a las paredes del ladrillo porque no pueden fcilmente la fecha de accommo las dimensiones nuevas, los atributos, o los hechos con estos prematuramente Tablas summa rized. El correcto punto de partida para sus modelos dimensionales debe expresar datos en el detalle mnimo posible para la mxima flexibilidad y la extensibilidad.
El mito 5. Los modelos dimensionales y los centros de compras de datos no pueden ser integrados y por consiguiente pueden conducir a las soluciones de la tobera. Los modelos dimensionales y los centros de compras de datos con toda seguridad pueden ser integrados si se conforman a la arquitectura del autobs del almacn de datos. Las bases de datos del rea de presentacin que no se le pegan a los datos almacenan autobs que la arquitectura conducirn para las soluciones autos sostenibles. Usted no puede mantener que modelado dimensional responsable por el para fracasado de algunas para organizaciones abracen una de sus afirmaciones fundamentales.
Las Hoyas Cubiertas Comunes para Avoid Mientras podemos proveer recomendaciones positivas acerca de datos dimensionales almacenando, algunos lectores mejor se relacionan con un listado de trampas u hoyas cubiertas comunes en las cuales los otros ya han dado un paso. Tomar prestado de un popular nocturno programa de televisin, aqu es nuestra lista 10 sobresaliente favorita de errores comunes para evitar al construir su almacn de datos. stos son todos errores muy letales uno a solas puede ser lo suficiente como para traer abajo de sus datos iniciativa del almacn. Fomentaremos elaborados en
estos en Captulo 16; Sin embargo, quisimos plantar las semillas de temprano por mientras tenemos su atencin completa. La hoya cubierta 10. Vulvase excesivamente enamorado con tecnologa y datos en vez de enfocar la atencin en los requisitos del negocio y las metas. La hoya cubierta 9. Fracase en abrazar o reclutar un vidente influyente, accesible, y razonable y administrativo como el patrocinador comercial del almacn de datos. La hoya cubierta 8. El aparejo un proyecto galctico de multiao en vez de perseguir a ms hombre envejecible, al todava compeler, esfuerzos iterativos de desarrollo. La hoya cubierta 7. Ubique energa para construir una estructura normalizada de datos, pero quedarse sin presupuesto antes de construir un rea de presentacin viable basado en modelos de dimen-sional.
La hoya cubierta 6. Preste ms atencin a la trastienda la facilidad y funcin operacional de desarrollo que la funcin de facilidad y averiguacin de sala de estar de uso. La hoya cubierta 5. Haga los datos supuestamente capaz de poneres en duda en el rea de presentacin excesivamente complejo. Los diseadores de la base de datos que prefieren una presentacin ms complicada deberan gastar un ao manteniendo usuarios de negocio; Desarrollaran un aprecio mucho mejor para la necesidad para buscar soluciones ms simples. La hoya cubierta 4. Pueble modelos dimensionales sobre una base auto sostenible sin hacer caso de una arquitectura de datos que los vincula utilizadoras dimensiones compartidas, conformadas. La hoya cubierta 3. La carga slo resumi datos en las estructuras de dimen-sional del rea de presentacin. La hoya cubierta 2. Suponga ese el negocio, sus requisitos y analytics, y los datos subyacentes y la tecnologa de respaldo son estticos. La hoya cubierta 1. Descudese de admitir que los datos almacenan xito est empatado directamente para la aceptacin del usuario. Si los usuarios no han aceptado el almacn de datos como una fundacin para la mejorada toma de decisiones, en ese entonces sus esfuerzos han sido ejercicios en la futilidad.
Resumen En este captulo discutimos las metas primordiales para el almacn de datos y las diferencias entre almacenes de datos y sistemas operacionales de la fuente. Exploramos los componentes principales del almacn de datos y discutimos el papel de per-missible de modelos normalizados ER en la zona de estacionamiento, pero no como el objetivo final. Entonces canalizamos nuestra atencin a modelado dimensional para el rea de presen-tation y establecimos vocabulario preliminar estimando hechos y las dimensiones. Permanezca afinado como pongamos en prctica estos conceptos en nuestro primer estudio de casos en el siguiente captulo.
Comercio Al Por Menor EL CARBONO HAPTE R
l la mejor forma para comprender los principios de modelado dimensional debe penetrar a fuerza de trabajo una serie de ejemplos tangibles. Visualizando casos autnticos, podemos sujetar los retos particulares del diseo y las soluciones en nuestras mentes muy ms effec-tively que lo que si se replantean desligadamente. En este libro desarrollaremos exam-ples de un alcance de negocios para ayudar a superar propio detalle y sacar de entre manos el diseo correcto. Para aprender modelado dimensional, por favor lea todos los captulos en este libro, aun si usted no maneja una compra y venta o trabaja para una firma de telecomunicaciones. Los captulos no estn dirigidos a ser manuales de solucin en gran escala para un indus-try dado o la funcin comercial. Cada captulo es una metfora para un set caracterstico de problemas dimensionales de modelado que surge en casi toda clase de busi-ness. Universidades, compaas de seguros, bancos, y aerolneas del mismo modo seguramente necesitarn que las tcnicas sean desarrolladas en este captulo por menor. Adems, pensando acerca de alguien si no el negocio es refrescante a veces. Es muy fcil dejar a las complejidades histricas se descarrila nosotros cuando nos ocupamos de datos de nuestro compa-nies. Dando un paso fuera de nuestras organizaciones y entonces regresando con un principio del diseo (o dos) bien comprendido, es ms fcil de recordar el espritu los principios
del diseo como descendemos en los detalles intrincados de nuestros negocios.
29
Subsidiaria 2 discute los siguientes conceptos: El proceso de cuatro pasos para disear modelos dimensionales las Tablas niveladas en la transaccin de hecho los hechos aditivos y poco aditivos pruebe atributos de la mesa de dimensin las dimensiones causales, como la promocin las dimensiones degeneradas, como el nmero del boleto de transaccin prolongando un modelo existente de dimensin Snowflaking dimensione atributos evitar lo demasiados dimensiona trampa subrogue llaves el anlisis de la canasta de mercado
El Proceso Dimensional del Diseo de Cuatro Pasos A todo lo largo de este libro nos acercaremos al diseo de una dimensional base de datos por consistentemente considerando cuatro pasos en una orden particular. El significado de estos cuatro pasos se pondr ms obvio como sigamos con los propsitos diversos, pero proveeremos definiciones iniciales a esta hora. 1. Seleccione el proceso comercial para modelar. Un proceso es un natural activ-ity comercial realizado en su organizacin que tpicamente cuenta con el respaldo de una fuente el sistema recaudatorio en datos. Escuchar a sus usuarias es la manera ms eficiente para seleccionar el proceso comercial. Las medidas de funcin que claman para analizar en el almacn de datos resultan de procesos comerciales de mea-surement. Los procesos de negocio de ejemplo incluyen materias primas comprando, rdenes, embarques, facturando, hacen inventario, y el libro mayor general. Es importante recordar que no nos referimos a un departamento comercial organizativo o funcionamos cuando hablamos de procesos comerciales. Por ejemplo, construiramos un solo modelo dimensional para maniobrar informacin
de rdenes en vez de los modelos separados edificadores para las ventas y mercadeo Departamentos, cul ambos quieren acceder a los datos de rdenes. Enfocando la atencin en procesos de busi-ness, en vez de en departamentos comerciales, pueden entregar informacin de con-sistent ms econmicamente a todo lo largo de la organizacin. Si establecemos departamentalmente modelos dimensionales destinados, inevitablemente duplicaremos datos con terminologa y etiquetas diferentes. Los mltiples flujos de datos en los modelos dimensionales separados nos harn vulnerables para incon-sistencies de datos. La mejor forma para asegurar consistencia es publicar los datos una vez. Una sola carrera de publicacin tambin reduce el esfuerzo de desarrollo de carga de transformacin de extracto (ETL), as como tambin la carga de administracin de datos en curso y de almacenamiento en disco.
2. Declare el grano del proceso comercial. Declarar el grano quiere decir speci-fying exactamente qu fila individual de la mesa de tan hecho representa. Lo con-veys del grano que el nivel de detalle asoci con las medidas de la mesa de hecho. Eso le provee la respuesta a la pregunta, Cmo describe usted una sola fila En la mesa de hecho? Las declaraciones del grano de ejemplo incluyen: un rubro contable individual en el boleto de venta de venta al por menor de un cliente tan medido por un dispositivo del escner un rubro contable en una cuenta recibida de un doctor un individual tiquete de abordaje para colocar en un vuelo una foto diaria del inventario derriba para cada producto en un almacn una foto mensual para cada cuenta corriente Los datos que el almacn mancomuna a menudo intentan pasar por encima de este paso aparentemente innecesario del proceso. Por favor no lo haga! Es sumamente importante que todo el mundo en el equipo del diseo est de acuerdo referente a la granularidad de la mesa de hecho. Es virtualmente imposible alcanzar cierre a comps 3 sin declarar el grano. Tambin le deberamos advertir que una declaracin impropia del grano rondar una implementacin del almacn de datos. Declarar el grano es un paso de crit-ical que no puede ser tomado a risa. Habiendo dicho esto, usted puede descubrir en los pasos 3 o 4 que la declaracin del grano est equivocada. Esto est bien, pero entonces usted debe regresar al paso 2, redebe declarar el grano correctamente, y debe volver a visitar pasos 3 y
4 otra vez.
3. Escoja las dimensiones que se aplican a cada fila de la mesa de hecho. Las dimensiones se caen de la pregunta, Cmo describe el businesspeople los datos que los resultados del proceso comercial? Queremos decorar nuestras Tablas de hecho con un set robusto de dimensiones representando todo lo que descripciones posibles que toman Sobre los solos valores en el contexto de cada medida. Si estamos seguros acerca del grano, en ese entonces las dimensiones tpicamente pueden ser identificadas muy fcilmente. Con la eleccin de cada dimensin, listaremos todos los atributos discretos textlike, que se rellenarn de msculo fuera de cada mesa de dimensin. Los ejemplos de dimensiones comunes incluyen tipo de fecha, del producto, del cliente, de transaccin, y estatus.
4. Identifique los hechos numricos que poblarn cada fila de la mesa de hecho. Los hechos contestan determinados por la pregunta, Qu nosotros tomamos una medida? Los usuarios comerciales con entusiasmo interes en analizar esta funcin comercial de proceso medidas. Todos los hechos del candidato en un diseo deben ser ciertos para el grano definido a comps 2. Los hechos que claramente pertenecen a una cantidad muy pequea diferente debe estar en una mesa separada de hecho. Los hechos tpicos son figuras aditivas numricas como cantidad ordenada o el dlar cost cantidad.
A todo lo largo de este libro tendremos a la vista estos cuatro pasos como desarrollemos cada uno de los estudios de casos. Aplicaremos a comprensin de un usuario del negocio a decidir qu las dimensiones y los hechos se necesitan en el modelo dimensional. Claramente, necesitamos considerar ambos los requisitos de nuestros usuarios comerciales y las realidades de nuestros datos de la fuente a la vez para hacer decisiones referente a los cuatro pasos, tan ilustrados en Figura 2.1. Fuertemente le alentamos a resistir la tentacin a modelar los datos mirando ficheros de datos de la fuente a solas. Nos damos cuenta de que puede ser mucho menos intimidante bucear en los arreglos de archivo y cuadernos en vez de entrevistar a una persona de negocios; Sin embargo, no son substitutos para el aporte del usuario. Desafortunadamente, muchas organizaciones han intentado este camino de resistencia mnima acercamiento conducido en datos, pero sin mucho xito. Venda Al Por Menor Estudio de Casos Comencemos con una descripcin breve de la compra y venta que usaremos en este caso estudio para hacer dimensin y el hecho pospone ms comprensibles. Comenzamos con esta fabricacin porque es una para la cual todos nosotros podemos tener relacin. Imagnate trabajamos en el centro de operaciones de una cadena grande de la tienda de comestibles. Nuestro negocio tiene 100 tiendas de gro-cery se extienden por un rea de cinco estados. Cada uno de las tiendas tienen un comple-ment lleno de departamentos, incluyendo tienda de comestibles, los alimentos congelados, la carne lechera,, el producto, la panadera, floral, y las ayudas de salud /belleza. Cada tienda tiene apenas 60,000 productos de individ-ual en sus estantes. Los productos individuales son llamados unidades de control de inventarios (SKUs). Aproximadamente 55,000 de los SKUs viene de fabricantes exteriores y tiene cdigos del bar impresos en el paquete del producto. Estos cdigos de barras son llamados cdigos universales de productos (UPCs). Los UPCs estn en el mismo grano como SKUs individuales. Cada variacin diferente del paquete de un producto tiene un separado cdigo universal de productos y por lo tanto es una separada unidad de control de inventarios.
Negocio Requisitos
El Modelo Dimensional 1. El Proceso Comercial 2. Grano 3. Dimensiones 4. Hechos
Datos Realidades Figura 2.1 pasos.
Teclee aporte para el proceso dimensional del diseo de cuatro
Los dems 5,000 SKUs vienen de departamentos como carne, producto, panadera, o floral. Mientras estos productos nacionalmente no han reconocido a UPCs, la cadena de la tienda de comestibles les asigna los nmeros de unidad de control de inventarios. Desde que nuestra cadena de la tienda de comestibles es altamente automatizada, pegamos etiquetas del escner muchos de los artculos en estos otros departamentos. Aunque los cdigos de barras no son UPCs, son ciertamente nmeros de unidad de control de inventarios. Los datos son coleccionados en varios lugares interesantes en una tienda de comestibles. Algunos de los datos ms tiles son coleccionados en las cajas registradoras como los clientes compren prod-ucts. Nuestra moderna tienda de comestibles escudria los cdigos de barras directamente en el sistema de punto de venta (el punto de venta). El SISTEMA DE TERMINALES EN EL PUNTO DE VENTA est en la puerta principal de la tienda de comestibles donde la comida para llevar del consumidor est medida. La puerta trasera, dnde los vendedores hacen entregas, es otro punto recaudatorio en datos interesante. En la tienda de comestibles, la gerencia est preocupada con la logstica de hacer el pedido, surtiendo, y vender productos mientras maximizar ganancia. La ganancia finalmente proviene de ir a la carga lo ms posible para cada costos del producto, rebajamiento para la adquisicin del producto y en lo alto, y al mismo tiempo atraer a tantos clientes tan posibles en un ambiente de fijacin de precios altamente competitivo. Algunos de las decisiones ms administrativas significativas tienen que ver con fijacin de precios y promociones. Ambos almacenan al mercadeo de gerencia y del centro de operaciones gasta una gran cantidad de tiempo jugueteando mentalmente con ponindole precio y las promociones. Las promociones en una tienda de comestibles incluyen temporales reducciones de precio, anuncios en peridicos y los insertos del peridico, los despliegues en la tienda de comestibles (el fin inclusivo que el pasillo exhibe), y los cupones. La forma ms directa y efectiva para crear una oleada en el volumen de producto vendido es aminorar el precio dramticamente. Una reduccin de 50 centavos en el precio de escrito seca con toalla, especialmente cuando fue pareada con un anuncio y despliegue, puede causar que la venta de las toallas de papel salte por un factor de 10. Desafortunadamente, una tan grande reduccin de precio usualmente no es sostenible porque las toallas probablemente son vendidas con prdida. Como resultado de estos asuntos, la visibilidad de todas las formas de promocin es una
parte importante de analizar las operaciones de una tienda de comestibles. Ahora que hemos descrito nuestro comercial estudio de casos, comenzaremos a disear el modelo dimensional.
Paso 1. Seleccione el Proceso Comercial El primer paso en el diseo debe decidir qu proceso comercial (es) para modelar combinando una comprensin de los requisitos comerciales con una comprensin de los datos disponibles.
El primer modelo dimensional construido debera ser el de la mayor parte de impacto debera contestar las preguntas ms comerciales apremiantes y debera fcilmente ser accesible para la extraccin de datos.
En nuestro estudio de casos por menor, la gerencia quiere mejor comprender al cliente compra tan capturado por el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA. As la apfisis comercial que vamos a modelar es comercio al por menor del punto de venta. Esta informacin nos dejar analizar lo que almacena los productos se venden en cul en qu los das debajo de qu condiciones promocionales.
Paso 2. Declare el Grano Una vez que el proceso comercial ha sido identificado, los datos almacenan caras del equipo una decisin seria acerca de la granularidad. Qu derriba de detalle de datos debera ser hecho disponible en el modelo dimensional? Esto nos trae a un consejo importante del diseo.
Preferentemente usted debera desarrollar modelos dimensionales para la informacin ms atmica captada por un proceso comercial. Los datos atmicos es el col-lected de informacin ms detallado; Tales datos no pueden estar subdivididos ms all.
Abordando datos en su grano mnimo, ms atmico que las marcas detectan en partes delanteras mltiples. Los datos atmicos son altamente dimensionales. Lo ms detallado y atmico la medida de hecho, las ms cosas que sabemos con seguridad. Todas esas cosas para las que sabemos seguro se traducen en dimensiones. A este respecto, los datos atmicos es un partido perfecto para el acercamiento dimensional. Los datos atmicos provee mxima flexibilidad analtica porque puede ser puesta tirante en contra y podido rodar arriba en todos los aspectos posible. Los datos detallados en un modelo dimensional son equilibrados y listos para el ataque ad hoc por usuarios comerciales. Por supuesto, usted siempre puede declarar cantidades muy pequeas del nivel ms
alto para un proceso comercial que representan una agregacin de los datos ms atmicos. Sin embargo, tan pronto como seleccionamos un grano del nivel ms alto, somos limitantes nosotros para menos y / o poten-tially menos detall dimensiones. El modelo menos granular es inmediatamente vul nerable nerable para el usuario inesperado solicita profundizar en los detalles. Los usuarios inevitablemente entran corriendo a una pared analtica cuando no le son dados acceso a los datos atmicos. Como veremos en Captulo 16, obras teatrales sumarias agregadas de datos un papel importante como una herramienta que afina funcin, pero no es un substituto para darle va de entrada de usuarios a los detalles del nivel mnimo. Desafortunadamente, algunos expertos de la industria han estado confusos en este punto. Afirman que los modelos dimensionales son slo appro priate priate para datos resumidos y entonces critican el acercamiento dimensional de modelado para su supuesta necesidad para anticipar la pregunta comercial. Este malentendido se desvanece cuando es detallado, datos atmicos son hechos disponibles en un modelo dimensional. En nuestro estudio de casos, los datos ms granulares es un rubro contable individual en un punto de venta
Transaccin. Para asegurar mxima dimensionalidad y flexibilidad, procederemos
Con este grano. Es digno de reparar en que esta declaracin de granularidad representa un cambio de la primera edicin de este texto. Previamente, enfocamos la atencin en datos de punto de venta, pero en vez del detalle representador de rubro contable de transaccin en el modelo dimensional, elegimos proveer los datos de ventas se remangaron por producto y promocin en una tienda en un da. En el momento, estos totales diarios del producto representaron el estado actual de la tecnologa para bases de datos de ventas por menor sindicadas. Fue irrazonable esperar que software y hardware actualizado a la fecha se ocupe eficazmente de los volmenes de datos asociados con rubros contables de transaccin de punto de venta individuales. Con tal que el acceso para la informacin de transaccin de punto de venta nos d con una mirada muy detallada en las ventas de la tienda. Mientras los usuarios probablemente no estn interesados en los artculos solos analyz ing se asociaron con una transaccin de punto de venta especfica, no podemos predecir todas las formas que querrn entresacar hasta el final esa informacin. Por ejemplo, pueden querer comprender la diferencia en las ventas el lunes versus domingo. O pueden querer evaluar si vale la pena surtir tantos tamaos individuales de ciertas marcas, como cereal. O pueden querer comprender cuntos compradores se aprovecharon de los 50 centavos fuera de la promocin en champ. O pueden querer determinar el impacto en trminos de las ventas disminuidas cuando un producto de soda de dieta de com-petitive fue promovido pesadamente. Mientras ninguna de estas averiguaciones encargan datos de una transaccin especfica, son preguntas amplias que requieren detallado los datos cortados en rodajas en las formas muy precisas. Ninguno de ellos pudo haber sido contestado si elegimos slo proveerle el acceso a resumido los datos.
Un almacn de datos casi siempre exige que datos sean expresados en el grano posible mnimo de cada dimensin no porque las averiguaciones quiere ver filas de bajo nivel individuales, pero porque las averiguaciones necesitan desgarrar los detalles en las formas muy precisas.
Paso 3. Escoja las Dimensiones
Una vez que el grano de la mesa de hecho ha estado escogido, la fecha, producto, y dimensiones de la tienda se desprenden inmediatamente. Suponemos que la fecha del calendario es el valor de fecha dado a nosotros por el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA. Ms tarde, ya veremos qu hacer si tambin obtenemos una vez de da junto con la fecha. Dentro del armazn de las dimensiones de pri-mary, podemos preguntar si otras dimensiones pueden ser atribuidas a los datos, como la promocin debajo de la cual el producto es vendido. Expresamos esto como otro principio del diseo:
Una declaracin cuidadosa del grano determina la dimensionalidad primaria de la mesa de hecho. Cabe entonces a menudo aadirle ms dimensiones al grano anticido de la mesa de hecho, donde estas dimensiones adicionales naturalmente cobran slo un valor debajo de cada combinacin de las dimensiones primarias. Si la dimensin adicional invade el grano por filas adicionales causantes de hecho para ser generada, en ese entonces la declaracin del grano debe estar revisada para acomodar esta dimensin.
La Dimensin de Fecha La llave de fecha (PK) La fecha Atribuye a TBD
Almacene Dimensin Almacene Llave (PK) Almacene a Attributes TBD Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta Hecho TBD La Dimensin del Producto El producto de la Llave del producto (PK) Atribuye a TBD
La Dimensin de Promocin La promocin de la Llave de promocin (PK) Atribuye a TBD
Resuelvo dibujo tcnico de ventas de 2.2 Preliminares de por menor. TBD quiere decir para estar resuelto.
En nuestro estudio de casos nos hemos decidido por las siguientes dimensiones descriptivas: La fecha, el producto, la tienda, y la promocin. Adems, incluiremos el nmero del boleto de transaccin de punto de venta como una dimensin especial. Ms se dirn en esto ms tarde en el captulo.
Comenzamos a visualizar el dibujo tcnico preliminar tan ilustrado en Figura 2.2. Antes de que ahondemos en poblar las Tablas de dimensin con attrib-utes descriptivo, nos dejan completar el paso final del proceso. Queremos asegurar que usted se encuentra a gusto con el proceso de cuatro pasos completo no queremos que usted pierda de vista el bosque para los rboles en esta etapa del juego.
Paso 4. Identifique los Hechos El cuarto y paso final en el diseo debe hacer una determinacin cuidadosa de la cual los hechos aparecern en la mesa de hecho. Otra vez, las criadas asistentas de declaracin del grano anclan nuestra manera de pensar. En trminos sencillos, los hechos deben ser ciertos para el grano: El rubro contable de indi-vidual sobre la transaccin de punto de venta en este caso. Al considerar hechos de poten-tial, usted otra vez puede descubrir que los ajustes necesitan ser hechos para ya sea nuestras anteriores suposiciones del grano o nuestra eleccin de dimensiones. Los hechos recabados por el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA incluyen la cantidad de ventas (e.g., El num-be de latas de sopa de fideos de pollo), por el precio de venta de la unidad, y el dlar de ventas tiene importancia. La cantidad del dlar de ventas iguala la cantidad de ventas multiplicado por el precio unitario. Ms los sofisticados SISTEMAS DE TERMINALES EN EL PUNTO DE VENTA tambin proveen un costo estndar del dlar para el producto
tan entregado para la tienda por el vendedor. Suponiendo que este costo el hecho es perfectamente disponible y no requiere una iniciativa basada en actividades heroica de costeo, incluiremos eso en la mesa de hecho. Nuestro hecho al que la mesa comience para llevar forma en Figura 2.3. Tres de los hechos, cantidad de ventas, venta dlar tienen importancia, y cuestan cantidad del dlar, son bellamente aditivos a travs de todas las dimensiones. Podemos cortar en rodajas y podemos jugar a los dados la mesa de hecho con impunidad, y cada suma de estos tres hechos es vlida y correcta.
La Dimensin de Promocin La promocin de la Llave de promocin (PK) Atribuye a TBD La Dimensin de Fecha La llave de fecha (PK) La fecha Atribuye a TBD Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta La Cantidad de Ventas La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
La Dimensin d Producto El producto de la Lla del producto (PK Atribuye a TBD
Almacene Dimensin Almacene Llave (PK) Almacene a Attributes TBD Resuelvo 2.3 hechos Medidos en el dibujo tcnico de ventas por menor.
Podemos computar la ganancia bruta sustrayendo la cantidad costada del dlar de la
cantidad del dlar de ventas, o la renta. Aunque se computa, esta ganancia bruta es tambin perfectamente aditiva a travs de todas las dimensiones podemos calcular la ganancia bruta de cualquier combinacin de productos vendidos en cualquier set de tiendas en cualquier set de das. Los modeladores dimensionales algunas veces dudan si un hecho calculado debera ser almacenado fsicamente en la base de datos. Generalmente recomendamos que se guarde fsicamente. En nuestro estudio de casos, el clculo vulgar de la ganancia es liso y llano, pero almacenarlo elimina la posibilidad de error del usuario. El costo de un usuario la ganancia bruta incorrectamente representadora abruma el costo incremental menor de stor-age. Almacenarlo tambin asegura que todos los usuarios y sus aplicaciones ponentes se refieren a la ganancia bruta consistentemente. Desde que la ganancia bruta puede calcularse de datos de adja-cent dentro de una fila de la mesa de hecho, algunos sostendran la opinin que deberamos realizar el clculo en una vista que es indistinguible de la mesa. ste es un acercamiento de rea-sonable si todos los usuarios acceden a los datos por medio de esta vista y ningn usuario con averiguacin ad hoc que las herramientas pueden escamotear alrededor de la vista para alcanzar la mesa fsica. Los puntos de vista son una forma razonable para minimizar error del usuario al economizar en el uso de almacenamiento, pero el administrador de base de datos no debe permitir excepciones para el acceso de datos a travs de la vista. Asimismo, algunos organismos quieren realizar el clculo en la herramienta de averiguacin. Otra vez, esto trabaja si todos los usuarios acceden a los datos usando una herramienta comn (cul es rara vez el caso en nuestra experiencia). El margen bruto puede calcularse dividiendo la ganancia bruta por la renta del dlar. El margen bruto es un hecho poco aditivo porque no puede estar resumido a lo largo de cualquier dimensin. Podemos calcular el margen bruto de cualquier set de productos, tiendas, o das acordndose de que para sumar los ingresos y costos antes de dividir. Esto puede ser dicho como un principio del diseo:
Los porcentajes y las proporciones, como el margen bruto, son poco aditivos. El numerador y denominador deberan ser almacenados en la mesa de hecho. La proporcin puede calcularse en una herramienta de acceso de datos para que cualquier rebanada de la mesa de hecho acordndose de que calculen la proporcin de las sumas, no la suma de las proporciones.
El precio unitario es tambin un hecho poco aditivo. Tratando de resumir precio unitario a travs de cualquiera de las dimensiones da como resultado un nmero sin sentido, absurdo. En orden para ana-lyze el comn precio de venta para un producto en una serie de tiendas o a travs de un perodo de tiempo, debemos sumar los dlares de ventas y cantidades de ventas antes de dividir los dlares totales por la cantidad total vendida. Cada escritor de informe o herramienta de averiguacin en el mercado del almacn de datos automticamente debera realizar este cor-rectly de funcin, pero desafortunadamente, algunos todava no lo maniobran muy graciosamente. En esta etapa anticipada del diseo, es a menudo de ayuda estimar el nmero de filas en nuestra mesa ms grande, la mesa de hecho. En nuestro estudio de casos, simplemente puede ser cuestin de hablar con un gur del sistema de la fuente para comprender cuntos los rubros contables de transaccin de punto de venta son generados sobre una base peridica. El trfico por menor flucta significativamente de da en da, as es que querremos comprender el activ-ity de transaccin durante un razonable perodo de tiempo. Alternativamente, podramos estimar el num-be de filas agrand la mesa de hecho anualmente dividiendo el ingreso bruto anual de la cadena por el artculo comn vendiendo precio. Suponiendo que los ingresos brutos son $4 billn por el ao y que el precio medio de un artculo en un boleto del cliente es $2.00, suponemos que hay aproximadamente 2 billones de rubros contables de transaccin al ao. sta es la estimacin de una ingeniera tpica que nos trae sorprendentemente cerca de dimensionar un diseo directamente de nuestros sillones. Como diseadores, siempre deberamos triangular para determinar si nuestros clculos son razonables.
Los Atributos de la Mesa de Dimensin Ahora que hemos pasado en medio de la apfisis de cuatro pasos, regresemos a las Tablas de dimensin y enfoquemos la atencin en llenarlas de atributos robustos.
La Dimensin de Fecha
Comenzaremos con la dimensin de fecha. La fecha que la dimensin es el nico dimen sion casi asegur estar en cada centro de compras de datos porque virtualmente cada centro de compras de datos es una serie temporal. De hecho, la fecha es usualmente la primera dimensin en la orden de tipo de underly-ing de la base de datos tan ese la carga sucesiva de espacios de tiempo de datos es colocada dentro de territorio virgen en el disco. Pues los lectores de la primera edicin de La Data Warehouse Toolkit (Wiley 1996), esta dimensin fue llamada la dimensin de tiempo en ese texto. En vez de stick-ing con que nomenclatura ms ambigua, usamos la dimensin de fecha en este libro para referirnos Tablas de dimensin diariamente granuladas. Esto ayuda a hacer la distincin la fecha y cronometrar de dimensiones de da, cul intercambiaremos opiniones ms tarde en este captulo. A diferencia de la mayor parte de nuestras otras dimensiones, podemos construir la mesa de dimensin de fecha por adelantado. Podemos poner 5 o 10 aos de filas representando das en la mesa as
Que podemos cubrir la historia hemos almacenado, as como tambin varios aos en el futuro. Aun el valor de das de 10 aos es slo acerca de 3,650 filas, lo cual es una rela-tively en trozos pequeos mesa de dimensin. Para una dimensin diaria de fecha posponemos en un envi-ronment por menor, recomendamos la lista parcial de columnas mostradas en Figura 2.4. Cada columna en la mesa de dimensin de fecha est definida por el da particular que la fila representa. La columna da de semana contiene el nombre del da, como lunes. Esta columna se usara para crear informes comparando el busi-ness los lunes con negocio dominical. El nmero de da en columna de mes de calendario comienza con 1 al principio de cada mes y corre a 28, 29, 30, o 31, a merced del mes. Esta columna es muy apropiada para asemejarse el mismo da cada mes. De modo semejante, podramos tener un nmero de mes en el ao (1, ..., 12). El nmero de da en la poca es de manera impresionante un nmero juliano (es decir, un nmero consecutivo de da empezando desde el principio de alguna poca) de da. Tambin podramos incluir
La Dimensin de Fecha La fecha de la Llave de fecha (PK) Abatane Descripcin de Fecha El Da de Semana El Nmero de Da en Nmero de Semana de poca en Nmero de Mes de poca en la poca El Nmero de Da en Calendar Month Day Number en Calendar Year Day Number en el Mes Fiscal El Nmero de Da en el Da Fiscal de la Horma de Ao en el Da de la Horma del Indicador de Semana en Indicador de Mes Calendar Week Ending Date El Nmero de Semana Calendario en el Ao El Nombre de Mes de Calendario El nmero de mes de calendario en Cantn del Calendario de Year-Month del Calendario de Ao (YYYY-MM) El Calendario la Ao Civil Cuarto de En Ao de Semestre del Calendario La Semana Fiscal El Nmero Fiscal de Semana en el Ao El Mes Fiscal El Nmero Fiscal de Mes en el Ao El Mes Fiscal de Ao La Cuarta Parte Fiscal El Ao Fiscal Medio Fiscal Cuarto de En Ao Fiscal de Ao El Indicador de Da Laborable del Indicador de Da de Fiesta Vendiendo Acontecimiento Season Major El fechador de lenguaje normalizado de consulta y ms Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta La Cantidad de Ventas La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
La Dimensin de Promocin de Dimensin de la Tienda de Dimensin del
Producto
Figura 2.4 Feche dimensin en el dibujo tcnico de ventas por menor.
La semana absoluta y el mes numeran columnas. Todos estos enteros soportan aritmtica simple de fecha entre los das a travs de linderos de ao y de mes. Para reportar, querramos un mes nombre con valores como enero. Adems, una columna de mes de ao (YYYY-MM) es til como un encabezado de la columna de informe. Probablemente tambin querremos un nmero cuarto de (Q1, ..., Q4), as como tambin una cuarta parte de ao, como 2001-Q4. Tendramos columnas similares para los perodos fiscales si difieren de perodos del calendario. El indicador de da de fiesta cobra los valores de Da de Fiesta o Nonholiday. Remem-be que los atributos de la mesa de dimensin le sirven de etiquetas de informe. Simplemente populat ing el indicador de da de fiesta con una Y o una N sera mucho menos til. Imagine un informe donde comparamos ventas de da de fiesta para un producto dado versus las ventas de poco da de fiesta. Obviamente, sera de ayuda si las columnas tuviesen valores significativos como Holiday Nonholiday versus una Y secreta / N. Ms Bien que decod-ing banderas secretas en etiquetas comprensibles en una aplicacin ponente, escogemos que lo descifre gurdese en la base de datos a fin de que un valor coherente est disponible para todos los usuarios sin tener en cuenta su ambiente ponente. Una discusin similar conserva su validez para el indicador de da laborable, lo cual tendra un valor de Da Laborable o el Fin de Semana. Sbados y domingos obviamente seran asignados el valor De Fin de Semana. Por supuesto, los atributos mltiples de la mesa de fecha pueden estar conjuntamente constreidos, as es que fcilmente podemos asemejarnos que el da laborable vacaciona con de fines de semana das de fiesta, por ejemplo. La estacin vendedora que la columna est colocada para el nombre de la estacin de venta al menudeo, si cualquier. Los ejemplos en los Estados Unidos podran incluir la Navidad, el Da de Accin de Gracias, la Pascua, da de los enamorados, Cuarto de julio, o Ninguno. La columna principal de acontecimiento es similar a la columna de estacin y puede usarse para marcar especial fuera de los acontecimientos como Tazn Sper el Domingo o la Huelga Laboral. Los acontecimientos promocionales normales usualmente no son manejados en la mesa de fecha sino ms bien estn descritos que ms completamente por medio de la promocin dimensionan, cuanto ms que los acontecimientos promocionales no estn definidos solamente por la fecha sino usualmente estn definidos por una
combinacin de fecha, producto, y tienda. Algunos diseadores se detienen en este punto a preguntar por qu se necesita una mesa explcita de dimensin de fecha. Razonan que si la llave de fecha en la mesa de hecho es una compaera de cita escribe campo, entonces cualquier averiguacin de lenguaje normalizado de consulta directamente puede constreir sobre el hecho la llave de fecha de la mesa y la semntica de fecha de lenguaje normalizado de consulta de nota natural de uso a filtrar en el mes o el ao al evitar uno sup-posedly juntura cara. Este razonamiento cae aparte para varias razones. Ante todo, si nuestra base de datos relacional no puede maniobrar una juntura eficiente para la mesa de dimen-sion de fecha, estamos ya en el problema profundo. La mayora de optimizadores de la base de datos son realmente eficientes en resolver averiguaciones dimensionales; No hay que evitar junturas como la plaga. Tambin, sobre la funcin confronte, la mayora de bases de datos no indexan clculos de fecha de lenguaje normalizado de consulta, as averiguaciones constriendo en un campo calculado en lenguaje normalizado de consulta no se aprovecharan de un ndice.
En trminos de la usabilidad, el usuario comercial tpico no es avezado en seman-tic de fecha de lenguaje normalizado de consulta, as es que l o ella sera incapaz directamente apalancar capacidades inherentes asociadas con una fecha que los datos determinan el tipo sanguneo. Las funciones de fecha de lenguaje normalizado de consulta no le dan apoyo a filtrar por los atributos como los das laborables versus los fines de semana, los das de fiesta, los perodos fiscales, los hijos del mar, o los acontecimientos principales. Suponer que el negocio necesita cortar en rodajas datos por estos atributos no convencionales de fecha, entonces una mesa explcita de dimensin de fecha es esencial. En el meollo del asunto, la lgica del calendario corresponde a una mesa de dimensin, no en el cdigo aplicativo. Finalmente, vamos a sugerir que la llave de fecha es un entero en vez de una informacin de fecha mecanografa de cualquier manera. Una llave basada en lenguajes normalizados de consulta de fecha tpicamente es 8 bytes, as es que usted desperdicia 4 bytes en la mesa de hecho para cada llave de fecha en cada fila. Ms se dirn en esto ms tarde en este captulo. Figura 2.5 ilustra varias filas de una mesa parcial de dimensin de fecha.
Los almacenes de datos siempre necesitan una mesa explcita de dimensin de fecha. Hay muchos atributos de fecha sin apoyo por la fecha de lenguaje normalizado de consulta funcin, perodos fiscales inclusivos, estaciones, das de fiesta, y fines de semana. En vez de tratar de determinar estos clculos del calendario no estndar en una averiguacin, deberamos buscar ellos en una mesa de dimen-sion de fecha.
Si quisisemos acceder al tiempo de la transaccin para anlisis de la parte de da (por ejemplo, la actividad durante la tarde despus de la prisa de trabajo o la tercera parte cambia de posicin), tuvimos han-dle l a travs de un tiempo separado de dimensin de da adjunt a la mesa de hecho. La fecha y el tiempo son casi completamente independientes. Si combinsemos el dos dimen-sions, la dimensin de fecha crecera significativamente; Nuestra dimensin limpia de fecha con 3,650 filas para manejar 10 aos de datos expandira para 5,256,000 filas si intentsemos manejar tiempo por el minuto en la misma mesa (o por un arbotante). Obvi-ously, es
preferible crear una mesa de dimensin de fecha de 3,650 filas y una separata
El tiempo de 1,440 filas de da por dimensin menuda.
En Captulo 5 que discutiremos el manejo de mltiplo sale en citas en un solo dibujo tcnico. Exploraremos la fecha internacional y cronometraremos consideraciones en Captulos 11 y 14.
Salg a en Salga citas citas Tecl ee

1 2 3 4 5 6 01/01/2002 01/02/2002 01/03/2002 01/04/2002 01/05/2002 01/06/2002
La Fecha Calendari Calendari El Mes Da de fiest en Completa El Da de o o Fiscal de Indicador Descripcin Semana Mes Ao Ao
El 1 de Enero de 2002 Martes El 2 de Enero de 2002 Mircoles El 3 de Enero de 2002 Jueves El 4 de Enero de 2002 Viernes El 5 de Enero de 2002 Sbado El 6 de Enero de 2002 Domingo
Enero Enero Enero Enero Enero Enero
2002 2002 2002 2002 2002 2002
F2002-01 F2002-01 F2002-01 F2002-01 F2002-01 F2002-01
Da de fiesta
Poco Da De Fies
Poco Da De Fies
Poco Da De Fies
Poco Da De Fies
Poco Da De Fies
01/07/2002 El 7 de Enero Lunes Enero de 2002 8 01/08/2002 El 8 de Enero Martes Enero de 2002 Resuelvo 2.5 detalle de la mesa de dimensin de Fecha.
2002 2002
F2002-01 Poco Da D Fiesta F2002-01 Poco Da D Fiesta
La Dimensin del Producto La dimensin del producto describe cada unidad de control de inventarios en la tienda de comestibles. Mientras una tienda de typ-ical en nuestra cadena puede surtir a 60,000 SKUs, cundo damos razn de planes diferentes de comercializacin a travs de la cadena y los productos histricos que estn ya no disponibles, nuestra dimensin del producto tendra al menos 150,000 filas y quiz tantos como un milln reme. La dimensin del producto est casi siempre sourced del archivo maestro operacional del producto. La mayora de detallistas administran sus archivos principales del producto en centro de operaciones y hacen un download de un subconjunto del archivo para el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA de cada tienda a los intervalos frecuentes. Es la responsabilidad de centro de operaciones definir el registro bsico apropiado (y el nmero nico de unidad de control de inventarios) del producto para cada cdigo universal de productos nuevo creado por fabricantes empacados de bienes. El centro de operaciones tambin definen las reglas por las cuales los SKUs son asignados a tales artculos como bienes de la panadera, carne, y producto. Extraemos el archivo maestro del producto en nuestra mesa de dimensin del producto cada vez que el amo del producto cambia. Una funcin importante del amo del producto es mantener los muchos atributos descriptivos de cada unidad de control de inventarios. La jerarqua de la mercanca es un grupo importante de atributos. Tpicamente, los SKUs individuales se remangan para marcas. Las marcas se remangan para las categoras, y las categoras ruedan hasta departamentos. Cada uno de estos es uno muchos para una relacin. Esta jerarqua de la mercanca y estos atributos adicionales son detallados para un subconjunto de productos en Figura 2.6. Para cada unidad de control de inventarios, toda derriba de la jerarqua de la mercanca est bien definido. Algunos atributos, como la descripcin de unidad de control de inventarios, son nicos. En este caso, hay al menos 150,000 valores diferentes en la columna de descripcin de unidad de control de inventarios. En el otro extremo, hay slo quiz 50 valores bien definidos del atributo del departamento. As, por trmino medio, hay 3,000 repeticiones de cada valor nico en el atributo del departamento. Esto est bien! No necesitamos separar estos valores repetidos en una en segundo lugar mesa normalizada para ahorrar espacio.
Recuerde que los requisitos del espacio de la mesa de dimensin decrecen en importancia en contraste con consideraciones del espacio de la mesa de hecho.
Product o La Descripcin del Producto Teclee

1 Tierno 2 3 La Harina Integral Rodajeada Mullida La Luz Mullida Cort en Rodajas Harina Integral
Marque Categora Descripci Descripcin n

Al Horno Mullido Mullido Pan Pan
Departament o Co Descripcin go
Panadera La
El Sourdough Ligero Sano Asado Al Horno el Pan El Pozo Asado Pan
Red Panadera Panadera
La G La
Red
La Vainilla de Amantes de Dieta 2 el Coldpack Galn 6 La Pacana Ligera y Cremosa de Freshlike Mantequilla 1 la Pinta 7 El Galn del 1/2 de Amantes de Muy fro Chocolate 8 El Hielo de la Fresa la Pinta 1 Helado Cremosa 9 Los Emparedados Helados de Helado Helado Resuelvo 2.6 detalle de la mesa de dimensin del Producto.
4 5
La Minicanela Gratis Gruesa Rueda
Luz
Endulce Pan
Panadera
Gor
Los Postres Alimentos Congelados Congelados Los Postres Alimentos Congelados Congelados Los Postres Alimentos Congelados Congelados Los Postres Alimentos Congelados Congelados Los Postres Alimentos Congelados Congelados
Go No La Re La No La No La No
La Dimensin del Producto La descripcin del Producto de la Llave del producto (PK) El nmero de unidad de control de inventarios (la Llave Natural) Brand Description El Tamao Categorial del Paquete de Descripcin de Tipo del Paquete de Descripcin del Departamento de Descripcin El Peso Contento Grueso de Tipo de Dieta Las Unidades De Peso de Medida La Profundidad del Estante de Altura del Estante de Anchura del Estante de Tipo de Tiempo Antes de Caducar de Tipo de Almacenamiento y ms Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta La Cantidad de Ventas La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
La Dimensin de Promocin de Dimensin de la Tienda de Dimensin de Fecha
Figura 2.7 la dimensin del Producto en el dibujo tcnico de ventas por menor.
Muchos de los atributos en la mesa de dimensin del producto no son parte de la jerarqua de mer-chandise. El atributo de tipo de paquete, por ejemplo, podra tener valores como Botella, Bolsa, Caja, u Otro. Cualquier unidad de control de inventarios en cualquier departamento podra tener uno de estos valores. Hace sentido perfecto para combinar una restriccin sobre este atributo con una restriccin sobre un atributo de jerarqua de la mercanca. Por ejemplo, podramos vernos del todo los SKUs en el Cereal que la categora empaquet en Bolsas. Para poner esto de cualquier otro modo, podemos hacer una lectura ligera entre los atributos de dimensin de todos modos pertenecen a la jerarqua de la mercanca, y podemos entrenarnos arriba y podemos profundizar usando atributos de todos modos pertenecen a la jerarqua de la mercanca. Aun podemos tener ms que una jerarqua explcita en nuestra mesa de dimensin del producto. Una dimensin parcial recomendable del producto para un centro de compras de datos de la tienda de comestibles por menor se parecera mucho a la Figura 2.7. Una mesa razonable de dimensin del producto tendra 50 o ms atributos descriptivos. Cada atributo es una fuente sustanciosa para constreir y construir encabezados de la fila. Mirados de esta manera, vemos que profundizar no es nada ms que pedir un encabezado de la fila que provee ms informacin. Digamos que tenemos un informe simple donde hemos resumido la cantidad del dlar de ventas y la cantidad por departamento. Departamento
Descripcin
El Dlar de Ventas
Cantidad
Panadera
Alimentos Congelados
$12,331
$31,776
La Cantidad de Ventas 5,088

15,565
Si queremos profundizar, podemos arrastrar virtualmente algn otro atributo, como marca, de la dimensin del producto en el informe junto a departamento, y automticamente profundiza as de despus derribar de detalle. Un taladro tpico
cado dentro de la jerarqua de la mercanca se parecera a esto:
Departamento Descripcin
Marque Descripcin
El Dlar de Ventas Ventas Cantidad
Cantidad
Panadera
Panadera Panadera Alimentos Congelados Alimentos Congelados Alimentos Congelados Alimentos Congelados Alimentos Congelados
El Pozo Asado Al Horno$3,009

Mullido Luz Coldpack Freshlike Muy fro Helado QuickFreeze $3,024 $6,298 $5,321 $10,476 $7,328 $2,184 $6,467
1,138
1,476 2,474 2,640 5,234 3,092 1,437 3,162
O podramos profundizar por el atributo contento en la grasa, si bien no est en el movimiento hacia arriba de jerarqua de la mercanca. Departamento
Descripcin
El Dlar de Ventas Content gorda Gordo A Non

La Grasa Reducida La Grasa Normal Gordo A Non La Grasa Reducida La Grasa Normal Cantidad
Ventas
Cantidad
Panadera
Panadera Panadera Alimentos Congelados Alimentos Congelados Alimentos Congelados
$6,298
$5,027 $1,006 $5,321 $10,476 $15,979
2,474
2,086 528 2,640 5,234 7,691
Hemos pormenorizado en exceso los ejemplos de profundizar para hacer un punto, cul expresaremos como un principio del diseo.
Profundizar en un centro de compras de datos no es nada ms que sumar encabezados de la fila de las Tablas de dimensin. La perforacin de arriba quita encabezados de la fila. Podemos profundizar o arriba de adelante los atributos de ms que una jerarqua explcita y con atributos que son parte de no jerarqua.
La dimensin del producto es una de las dos o tres dimensiones primarias en casi cada centro de compras de datos. El esmero debera ser tomado para llenar esta dimensin con como muchos atributos descriptivos tan posibles. Un set robusto y completo de atributos de dimensin se traduce en capacidades del usuario para anlisis robusto y completo. Fomentaremos hace un reconocimiento de la dimensin del producto en Captulo 4, donde tambin discutiremos el manejo de cambios de atributo del producto.
Almacene Dimensin La dimensin de la tienda describe cada tienda en nuestra cadena de la tienda de comestibles. A diferencia del amo del producto el archivo que es casi garantizado para estar disponible en cada negocio abrumador de la tienda de comestibles, no puede estar un archivo maestro de la tienda asimilativo. El amo del producto necesita ser del que se hizo un download para cada tienda cada tiempo hay un producto nuevo o cambiado. Sin embargo, los individuales SISTEMAS DE TERMINALES EN EL PUNTO DE VENTA no requieren a un amo de la tienda. Los personales de tecnologa de la informacin (ESO) frecuentemente deben ensamblar los componentes necesarios de la dimensin de la tienda de fuentes operacionales mltiples en centro de operaciones. La dimensin de la tienda es la dimensin geogrfica primaria en nuestro estudio de casos. Cada tienda puede ser considerada como una posicin. Por esto, podemos enrollar tiendas a cualquier atributo geogrfico, como cdigo postal, condado, y estado en los Estados Unidos. Las tiendas usualmente tambin se remangan para almacenar distritos y regiones. Estas dos jerarquas de dif-ferent son ambos con holgura representadas en la dimensin de la tienda porque ambos las jerarquas geogrficas y de la tienda y regionales estn bien definidos para una sola fila de la tienda.
No es raro representar jerarquas mltiples en una mesa de dimensin. Idealmente, el atributo nombra y los valores deberan ser nicos a travs de las jerarquas mltiples.
Una mesa de dimensin de la tienda recomendable para el negocio de la tienda de comestibles es mostrada adentro Figura 2.8.
Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta La Cantidad de Ventas La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia La Dimensin de Fecha La Dimensin Producto La Dimensin Promocin del
de
Almacene Dimensin Almacene Nombre De la Tienda Crucial (PK) Almacene Direccin de la Calle de la Tienda de Nmero (la Llave Natural) Almacene Tipo del Plano de Piso de la Regin de la Tienda del Distrito de la Tienda del Gerente de la Tienda de Cdigo Postal de la Tienda del Estado de la Tienda del Condado de la Tienda de la Ciudad El Tipo de Procesamiento de la Foto la Fecha por Fijar Financiera de Primera Parte de Metraje del Cuadrado de Total de Metraje del Cuadrado de Venta de Tipo de Servicio Por ltimo Remodele la Fecha y ms Figura 2.8 Almacene dimensin en el dibujo tcnico de ventas por menor.
El tipo del plano de piso que, el tipo de procesamiento de la foto, y el tipo de servicios de finanzas son todos descriptores del texto breves que describen la tienda particular. stos no deberan ser cdigos de un carcter sino ms bien deberan ser 10 para los descriptores estndar y de 20 carcteres que tienen sentido cundo mirados en una lista fcilmente bajable o usado como un informe hace avanzar con el remo encabezado. La columna describiendo metraje cuadrado vendedor es numrica y tericamente aditiva a travs de tiendas. Uno podra estar tentado de colocarlo en la mesa de hecho. Cmo es alguna vez, claramente un constante atributo de una tienda y es utilizado como un encabezado de informe de restriccin o de la fila ms a menudo que lo que sea utilizada como un elemento aditivo en un summa-tion. Para estas razones, nos fiamos de que el metraje cuadrado vendedor corresponda a la mesa de dimensin de la tienda. La primera fecha por fijar y horma remodelan dtil tpicamente son llaves de la juntura para copias de la dimensin de fecha mesa. Estas copias de dimensin de fecha son declaradas en el lenguaje normalizado de consulta por la construccin de VISTA y son semnticamente bien definido del dimen-sion primario de fecha. La declaracin de VISTA mirara como CREE VISTA FIRST_OPEN_DATE (FIRST_OPEN_DAY_NUMBER, FIRST_OPEN_MONTH ...) COMO DAY_NUMBER SELECTO, EL MES, DESDE la FECHA
Ahora los actos del sistema como si haya otra copia fsica de la mesa de dimensin de fecha designado FIRST_OPEN_DATE. Las restricciones en esta fecha nueva la mesa no tienen nada que ver con restricciones en la mesa primaria de dimensin de fecha. La primera vista manifiesta de fecha es un arbotante permisible para la dimensin de la tienda. Echo de ver que nosotros cuidadosamente hemos reetiquetado todas las columnas en la vista a fin de que no pueden estar confusos con columnas de la dimensin primaria de fecha. Fomentaremos arbotantes de dis-cuss en Captulo 6.
La Dimensin de Promocin La dimensin de promocin es potencialmente la dimensin ms interesante en nuestro dibujo tcnico. La dimensin de promocin describe las condiciones de promocin debajo de las cuales un producto fue vendido. Las condiciones de promocin incluyen temporales reducciones de precio, terminan despliegues del pasillo, anuncios del peridico, y cupones. Esta dimensin es a menudo llamado una dimensin causal (a distincin de una dimensin casual) porque describe pensamiento de factores para causar un cambio en las ventas del producto. Los gerentes en ambos centro de operaciones y se interes en las tiendas determinar si una promocin es efectiva o no. Las promociones son juzgadas en uno o ms de los siguientes factores: si los productos debajo de la promocin experimentaron una ganancia en las ventas durante el perodo promocional. ste es llamado el alza. El alza slo puede ser medido
Si la provisin puede convenir en lo que las ventas de la lnea de fondo de los productos promovidos habran estado sin la promocin. Los valores de la lnea de fondo pueden ser estimados de anterior historia de ventas y, en algunos casos, con la ayuda de modelos matemticos sofisticados. si los productos debajo de la promocin mostraron una cada en las ventas poco antes de o despus de la promocin, cancelndole la ganancia en ventas durante la promocin (cronometre cambiar de posicin). En otras palabras, transferimos ventas de productos regularmente a los que se puso precio a por ahora productos de cotizaciones reducida? si los productos debajo de la promocin mostraron una ganancia en las ventas pero otros productos cerca en el estante mostrado una disminucin correspondiente (can-nibalization) de ventas. si todos los productos en la categora promovida de experi-enced de productos un mono de la red aumentan de ventas tomando en cuenta los lapsos de tiempo antes, durante, y despus de la promocin (comercialice crecimiento si la promocin fue lucrativa. Usualmente la ganancia de una promocin
Est ocupado para ser la ganancia incremental en ganancia de la categora promovida encima Las mercaderas en rebaja de la lnea de fondo teniendo en cuenta tiempo cambiando de posicin y la cannibalizacin, tan Bien como los costos de la promocin, incluyendo temporales reducciones de precio, Anuncios, despliegues, y cupones.
Las condiciones causales potencialmente afectando una venta no son necesariamente con orugas directamente por el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA. El sistema de transaccin le sigue la pista a reduc-tions de precio y rebajas. La presencia de cupones tambin tpicamente es captada con la transaccin porque el cliente tampoco presenta cupones al momento de la venta o no hace. Los anuncios y las condiciones de despliegue en reserva pueden necesitar ser vinculados de otras fuentes. Las condiciones causales posibles diversas estn altamente correlacionadas. Una temporal reduccin de precio usualmente es asociada con un anuncio y quiz un despliegue del pasillo de fin. Los cupones a menudo son asociados con anuncios. Por esta razn, tiene sentido para crear una fila en la dimensin de promocin para cada combinacin de condiciones de promocin que ocurre. Sobre el curso de un
ao, puede haber 1,000 anuncios, 5,000 temporales reducciones de precio, y 1,000 terminan despliegues del pasillo, pero slo pueden haber 10,000 combinaciones de esto affect-ing de tres condiciones cualquier producto particular. Por ejemplo, en una promocin dada, la mayor parte de las tiendas correran todos los tres mecanismos de promocin simultneamente, pero unos cuantos de las tiendas no podran destacar las exhibiciones del pasillo de fin. En este caso, dos filas separadas de condicin de promocin seran necesitadas, uno para la reduccin de precio de normalidad y respecto a ms el despliegue y uno para el reduc-tion de precio y respecto a slo. Una mesa recomendable de dimensin de a promocin le son mostrados en Figura 2.9.
Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) El nmero de Transaccin de punto de venta La Cantidad de Ventas La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia La Dimensin de Fecha La Dimensin Producto Almacene Dimensin del
La Dimensin de Promocin La llave de promocin (PK) el Tipo de Reduccin de Precio de Promocin Name Los Medios De Comunicacin de Promocin Mecanografan Respecto Al Tipo del Cupn de Tipo de Despliegue de Tipo La Promocin del Proveedor de Despliegue de Nombre de Medios de Comunicacin del Anuncio Cost Promocin Comienza la Fecha de Fin de Promocin de Fecha y ms Figura 2.9 la dimensin de Promocin en el dibujo tcnico de ventas por menor.
De un puramente lgico punto de vista, podramos registrar informacin muy similar acerca de las promociones separando los cuatro mecanismos causales principales (las reducciones de precio, los anuncios, los despliegues, y los cupones) en cuatro dimensiones separadas en vez de combinarlos en una dimensin. Finalmente, esta eleccin es la prerrogativa de la diseadora. Los trueques a favor de mantener las cuatro dimensiones juntos incluyen lo siguiente: desde los cuatro mecanismos causales es altamente correlacionado, la dimensin combinada de sin-gle no es muy mayor que cualesquier del dimen-sions separado lo sera. la dimensin sola combinada puede ser hecha una lectura ligera eficazmente para ver cmo son usados las reducciones de precio diversas, anuncios, despliegues, y cupones juntos. Sin embargo, esto haciendo una lectura ligera slo muestra las combinaciones posibles. Hacer una lectura ligera en la mesa de dimensin no revela cules tiendas o productos estaban afecto de la promocin. Esta informacin se encuentra en la mesa de hecho. Los trueques a favor de separar los cuatro mecanismos causales en que la dimensin bien definida pone sobre una mesa incluyen lo siguiente: las dimensiones separadas pueden tener ms sentido al mundo de los negocios si los usuarios piensan acerca de estos mecanismos separadamente. Esto se traslucira durante las entrevistas comerciales de requisito. la gerencia de las dimensiones separadas puede ser ms franca que administrar una dimensin combinada. Tenga a la vista que no hay diferencia en la informacin contenta en el almacn de datos entre estas dos elecciones.
Tpicamente, muchos rubros contables de transaccin de ventas requieren productos que no estn siendo promovidos. Necesitaremos incluir una fila en la dimensin de promocin, con el suyo llave nica, a no identificar Promocin en vigor y evitar una llave nula de promo-tion en la mesa de hecho. La integridad de referencia es violada si pusimos uno nulo en una columna de la mesa de hecho declarada como una llave extranjera a una mesa de dimensin. Adems de las alarmas de integridad de referencia, las llaves nulas son la fuente de gran confusin para nuestros usuarios porque no pueden unir claves nulas.
Usted debe evitar llaves nulas en la mesa de hecho. Un el diseo correcto incluye una fila en la mesa correspondiente de dimensin a identificar que la dimensin no es aplicable para la medida.
La Mesa de Hecho de Factless de Cobertura de Promocin Sin tener en cuenta el manejo de la dimensin de promocin, est una pregunta importante que se contest por nuestro dibujo tcnico de ventas por menor: Qu productos estaban sobre la promocin pero no vendieron? La mesa de hecho de ventas slo registra los SKUs en verdad vendidos. No hay filas de la mesa de hecho con hechos de cero para SKUs que no vendieron porque haciendo eso ampliara la mesa de hecho enormemente. En el mundo de relaciones, una segunda cobertura de promocin o mesa de hecho de acontecimiento se necesita para ayudar a contestar que la pregunta concirnindole lo que no ocurri. Las llaves de la mesa de hecho de cobertura de promocin seran la fecha, el producto, la tienda, y la promocin en nuestro estudio de casos. Esto obviamente se parece mucho a la mesa de hecho de ventas que acabamos de disear; Sin embargo, el grano sera significativamente diferente. En el caso de la mesa de hecho de edad de cubierta de promocin, cargaramos una fila en la mesa de hecho para cada producto en promo-tion en una tienda cada da (o la semana, desde que muchas promociones por menor sean una semana en la duracin) sin tener en cuenta ya sea el producto vendido o no. La mesa de hecho de cobertura nos deja ver la relacin entre las llaves tan definidas por una promocin, independiente de otros acontecimientos, como las ventas reales del producto. Nos referimos a eso como una mesa de hecho de factless porque no tiene
mtrica de medida; Eso meramente los tures de gorra la relacin entre las llaves requeridas. Para determinar qu productos dnde sobre la promocin pero no vendi requiere un proceso de dos pasos. Primero, ponamos en duda la mesa de cobertura de promocin para determinar el universo de productos que estaban sobre la promocin en un da dado. Entonces determinaramos qu vendieron los productos de la mesa de hecho de ventas de punto de venta. La respuesta para nuestra pregunta original es el dif-ference determinado entre estas dos listas de productos. Permanezca afinado para Captulo que 12 para la cobertura ms completa de hecho de factless posponen; Ilustraremos la mesa de edad de cubierta de promocin y proveeremos el lenguaje normalizado de consulta determinado de diferencia. Si usted est trabajando con datos en un ambiente analtico del cubo de procesamiento en lnea multidimensional (OLAP), es a menudo ms fcil de contestar la pregunta suponiendo qu no vendi porque el cubo tpicamente contiene celdas explcitas para el poco comportamiento.
Degenere Nmero de Transaccin Dimensin La mesa de hecho de ventas por menor contiene el nmero de transaccin de punto de venta en cada fila de rubro contable. En una base de datos de nio en padre tradicional, el nmero de transaccin de punto de venta sera la llave para el registro del encabezado de transaccin, conteniendo todo el informa-tion vlido para la transaccin como un todo, tan la fecha de transaccin e identificador de la tienda. Sin embargo, en nuestro modelo dimensional, ya hemos extrado esta informacin interesante del encabezado en otras dimensiones. El nmero de transaccin de punto de venta es todava til porque sirve de la llave del agrupamiento para juntar todos los productos compr en una sola transaccin. Aunque el nmero de transaccin de punto de venta se parece a una dimensin crucial en la mesa de hecho, nos hemos quitado todos los artculos descriptivos que de otra manera podran caerse en una dimensin de transaccin de punto de venta. Desde que la dimensin resultante es vaca, nos referimos al nmero de transaccin de punto de venta como una dimensin degenerada (identificados por la notacin DD en Figura 2.10). El nmero operacional natural del boleto, como el nmero de transaccin de punto de venta, se sienta por s mismo en la mesa de hecho sin asociarse para una mesa de dimensin. Las dimensiones degeneradas son muy comunes cuando la cantidad muy pequea de una mesa de hecho representa una lnea de transaccin sola o de transaccin tem porque la dimensin degenerada representa el identificador nico del padre. Nmeros de orden, nmeros de factura, y nmeros de conocimientos de embarque casi siempre aparecen como degeneran dimensiones en un modelo dimensional. Las dimensiones degeneradas a menudo juegan un papel integral en la llave primaria de la mesa de hecho. En nuestro estudio de casos, la llave primaria de la mesa de hecho de ventas por menor consiste en la llave de transaccin (suponiendo que el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA enrolla todas las mercaderas en rebaja para un producto dado dentro de un carrito de compras de punto de venta en un solo rubro contable) de degenerada de punto de venta nmero y del producto. A menudo, la llave primaria de una mesa de hecho es un subconjunto de las llaves extranjeras de la mesa. Tpicamente no necesitamos que cada clave extranjera en la mesa de hecho garantice la unicidad de una fila de la
mesa de hecho.
El control operacional numera como nmeros de orden, nmeros de factura, y los nmeros de conocimientos de embarque usualmente le dan lugar a las dimensiones vacas y son representados como dimensiones de degen-erate (es decir, la dimensin teclea sin Tablas correspondientes de dimensin) En Tablas de hecho donde el grano de la mesa es el documento mismo o un rubro contable en el documento.
Si, por alguna razn, uno o ms atributos se queda legtimamente sobre despus todas las otras dimensiones ha sido creado y parece pertenecerle a esta entidad del encabezado, simplemente crearamos un registro normal de dimensin con una juntura normal. Cmo tendramos alguna vez, ya no una dimensin degenerada.
Enero
2002 La Dimensin de Fecha La fecha de la Llave de fecha (PK) El Da de Semana La Fecha de Final de Semana Calendario La Ao Civil de Semestre del Calendario de Cuarta Parte de Ao del Calendario de Mes de Calendario - el Ao del Calendario de Cuarta Parte del Calendario de Mes El Indicador de Da de Fiesta y ms La Dimensin del Producto El nmero de unidad de control de inventarios de Descripcin del Producto de la Llave del producto (PK) El Tipo del Paquete de Descripcin del Departamento de Descripcin de Categora de Descripcin de Subcategora de Descripcin de Marca Content gorda El Tipo de Dieta y ms Bocadillos
Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity
La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
Almacene Dimensin La fecha por fijar Store Crucial de Primera Parte de la Regin de la Tienda del Distrito de la Tienda de Nmero de la Tienda de Nombre (PK) de la tienda Por ltimo Remodele la Fecha y ms Boston
La Dimensin de Promocin Los medios de comunicacin de Promocin de Nombre de Promocin de la Llave de promocin (PK) Mecanografan la Fecha de Fin de Promocin de Fecha de Promocin Begin y ms
Figura 2.10
Poniendo en duda el dibujo tcnico de ventas por menor.
Venda Al Por Menor Dibujo Tcnico en Actividad Con nuestro dibujo tcnico por menor y de punto de venta diseado, ilustremos cmo se vera obligado al uso en un ambiente de averiguacin. Un usuario comercial podra ser interesado en mejor comprensin volumen semanal del dlar de ventas por la promocin para el dur-ing de categora de bocadillos el enero del 2002 para tiendas en el distrito de Boston. Como ilustrados en Figura 2.10, colocaramos restricciones de averiguacin en el mes y el ao en la dimensin de fecha, distrito en la dimensin de la tienda, y categora en la dimensin del producto. Si la herramienta de averiguacin sumase la cantidad del dlar de ventas agrupada por ah la semana terminando fecha y promocin, los resultados de averiguacin se
pareceran mucho a esos debajo. Usted explcitamente puede ver la relacin entre el modelo dimensional y la averiguacin de asso-ciated. La dimensin de alta calidad que los atributos son cruciales porque son la fuente de restricciones de averiguacin y que las etiquetas del set de resultado. Semana Calendario
Cesando Fecha
Ventas El Nombre de Promocin Ninguna Promocin

Ninguna Promocin La Promocin Sper del Tazn La Promocin Sper del Tazn La Cantidad del Dlar
El 6 de Enero de 2002
El 13 de Enero de 2002 El 20 de Enero de 2002 El 27 de Enero de 2002
22,647
4,851 7,248 13,798
Si usted est usando un acceso de datos herramienta con ms funcionabilidad, los resultados pueden aparecer como un informe tabular en la cruz. Tales informes atraen ms a usuarios comerciales que los datos columnares resultando de una declaracin de lenguaje normalizado de consulta.
El Tazn Sper
Semana Calendario Cesando Fecha Las Ventas de Promocin La Cantidad del Dlar
Ninguna Promocin
El Dlar de Ventas Cantidad
El 6 de Enero de 2002
El 13 de Enero de 2002 El 20 de Enero de 2002 El 27 de Enero de 2002
0
0 7,248 13,793
22,647
4,851 0 0
Venda Al Por Menor Extensibilidad del Dibujo Tcnico Ahora que hemos completado nuestro primer modelo dimensional, revolvamos nuestro atten-tion para extender el diseo. Supongo que nuestro detallista decide implementar un programa frecuente del comprador. Ahora, en vez de en la seguridad de que un comprador sin identificar tuvo 26 artculos en su carrito de compras, podemos ver exactamente qu comprador tan especfico, digamos, Julie Kimball, compras sobre una base semanal. Simplemente imag ine el inters de usuarios comerciales en analizar ir de compras patrones por una multitud de geogrfico, demogrfico, conductista, y otro diferenciando caractersticas del comprador. El manejo de esta informacin frecuente nueva del comprador es relativamente liso y llano. Crearamos una mesa frecuente de dimensin del comprador y sumaramos otra llave extranjera en la mesa de hecho. Desde que no les podemos pedir a los compradores que traigan todos sus viejos recibos de la caja registradora para etiquetar nuestras transacciones histricas de ventas con su nmero frecuente nuevo del comprador, substituiramos un corre-sponding de la llave del comprador para uno Antes de Programa Frecuente del Comprador descripcin en nuestras filas de la mesa de hecho de his-torical. Asimismo, no todo el mundo que va de compras en la tienda de comestibles tendr una tarjeta frecuente del comprador, as es que tambin querramos incluir a un Comprador asiduo No fila Identificada en nuestra dimensin del comprador. Como intercambiamos opiniones ms temprano con la dimensin de promocin, debemos evitar llaves nulas en la mesa de hecho. Como embellecimos nuestro diseo original con una dimensin frecuente del
comprador, tambin podramos sumar dimensiones para la hora del da y el dependiente se asoci con la transaccin, como ilustr en Figura 2.11. Cualquier atributo descriptivo que tiene un solo valor en presencia de las medidas de la mesa de hecho es un buen candidato para sumarse a una dimensin existente o sea su dimensin. La decisin suponiendo si una dimensin puede estar apegada a una mesa de hecho debera ser un s /no binario basado en el grano declarado. Si usted est en la duda, es hora de volver a visitar paso 2 del diseo proceso.
Sales Transaction Fact Por Menor de punto de venta La Dimensin de Fecha La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) Frecuente Llave del Dependiente de la Llave del Comprador (FK) (FK) El tiempo de Llave de Da (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia La Dimensin Producto del
Almacene Dimensin La Dimensin de Promocin
Frecuente Dimensin del Comprador Frecuente Cdigo Postal del Comprador del Estado del Comprador de la Ciudad del Comprador de la Direccin del Comprador de Nombre del Comprador de la Llave del Comprador Frequent Frequent Frequent Frequent Frequent (PK) Segmento del Comprador Frequent y ms La Dimensin del Dependiente El dependiente de la Llave del dependiente (PK) la Fecha del Supervisor del Dependiente de Nombre Clerk Job Grade de Salario y ms El Tiempo de Dimensin de Da
El tiempo de Tiempo de la Llave de Da (PK) Hora ES Indicador / de la noche Cambie de posicin El Segmento de la Parte de Da y ms Resuelvo dibujo tcnico de ventas 2.11 Embellished de por menor.
Nuestro dibujo tcnico original graciosamente se extiende para acomodar estos dimen-sions nuevo mayormente porque elegimos modelar los datos de transaccin de punto de venta en su nivel ms granular. La adicin de dimensiones que aplican en esa granularidad no alter las llaves existentes de dimensin o hechos; Todo con-tinue preexistente de aplicaciones a correr sin desenredarse o cambiar. Si habamos declarado originalmente que el grano sera diariamente al por menor ventas (las transacciones resumieron durante el da, tienda, producto, y promocin) en vez de en el detalle de la lnea de transaccin, no habramos podido fcilmente incorporar al comprador asiduo, de tiempo de da, o las dimensiones del dependiente. El resumen prematuro o la agregacin intrnsecamente limita nuestra habilidad a sumar dimensiones suplementarias porque las dimensiones adicionales a menudo no tienen aplicacin en el grano ms alto. Obviamente, hay algo de cambios que nunca pueden ser manejados graciosamente. Si una fuente de datos deja de estar disponible y no hay substituto compatible, en ese entonces los datos almacenan aplicaciones a merced de esta fuente dejarn de funcionar. Sin embargo, la simetra previsible de modelos dimensionales deje amortiguar algunos cambios ms bien significativos en datos de la fuente y / o modelando las suposiciones sin invalidar existir aplicaciones. Describiremos varios de estas categoras inesperadas de modificacin, comenzando con lo ms simple:
Los atributos nuevos de dimensin. Si descubrimos descriptores textuales nuevos de uno prod-uct, por ejemplo, le aadimos estos atributos a la dimensin como columnas nuevas. Todas las aplicaciones existentes sern olvidadizas para los atributos nuevos y con-tinue para funcionar. Si los atributos nuevos estn disponibles slo tras un punto especfico con el tiempo, en ese entonces No Disponible o su equivalente debera estar poblado
En los viejos registros de dimensin.
Las dimensiones nuevas. Como acabamos de ilustrar en Figura 2.11, le podemos aadir un dimen-sion a una mesa existente de hecho sumando un nuevo extranjero campo de clave y popu-lating l correctamente con valores de la llave primaria de la dimensin nueva. Los hechos medidos nuevos. Si los hechos medidos nuevos se hacen disponibles, les podemos aadir graciosamente a la mesa de hecho. El caso ms simple es cuando los hechos nuevos estn disponibles en el mismo acontecimiento de medida y en el mismo grano como los hechos existentes. En este caso, el hecho que la mesa est alterada para sumar las columnas nuevas, y los valores est poblado en la mesa. Si la declaracin de la MESA ALTER no es viable, en ese entonces un segundo hecho que la mesa debe estar definida con las columnas adicionales y las filas copiadas desde el comienzo. Si los hechos nuevos son slo capacitados en la ganancia de un punto puntual compra no al contado, en ese entonces los valores nulos necesitan estar colocados en las filas mayores de hecho. Una situacin ms complicada surge cuando los hechos medidos nuevos ocurren naturalmente en un grano diferente. Si los hechos nuevos no pueden ser ubicados o asignados para el grano original de la mesa de hecho, lo es muy probablemente que los hechos nuevos corresponden a su mesa de hecho. Es casi siempre un error para mezclar granos en la misma mesa de hecho. La dimensin ponindose ms granular. Algunas veces gusta aumentar la granularidad de una dimensin. En la mayora de los casos, los atributos originales de dimensin pueden ser incluidos en la dimensin nueva, ms granular porque se remangan perfectamente en uno muchos para una relacin. La dimensin ms granular a menudo le da a entender una mesa de hecho ms granular. No puede haber nativo en Alter sino para dejar caer la mesa de hecho y reconstruirla. Sin embargo, todas las aplicaciones existentes estaran sin afectacin. La adicin de una fuente de datos completamente nueva consistiendo en existiendo dimensiones as como tambin inesperadas dimensiones nuevas. Casi siempre, una fuente nueva de datos tiene su granularidad y su dimensionalidad,
as es que creamos una mesa nueva de hecho. Deberamos evitar medidas nuevas que acomodan fuerza en una mesa existente de hecho de medidas coherentes. Las aplicaciones existentes todava funcionarn porque el hecho existente y Tablas de dimensin estn ilesos.
Resistiendo Deseos de la Zona de Comodidad Con nuestro primer diseo dimensional detrs de nosotros, djenos directamente enfrentar varios de los deseos naturales que tientan a los modeladores viniendo de un historial ms normalizado. Conscientemente quebrantamos algunas reglas tradicionales de modelado porque somos
Enfocado sobre dar valor comercial a travs de la facilidad de uso y funcin, no sobre las eficiencias de proceso de transacciones.
La Normalizacin de Dimensin (Snowflaking) La dimensin aplastada, denormalized pospone con repetir valores textuales puede hacer un modelador de normalizacin incmodo. Volvamos a visitar nuestra mesa de dimensin del producto de estudio de casos. Los 150,000 productos se remangan en 50 departamentos discretos. En vez de redundantemente almacenar la descripcin del departamento de 20 bytes en la mesa de dimensin del producto, los modeladores con un faltante normalizado de educacin para almacenar un cdigo del departamento de 2 bytes y entonces crear una dimensin nueva del departamento para el departamento descifra. De hecho, sentiran ms confortables si todos los descriptores en nuestro original que el diseo fue normalizado en dimensin separada posponen. Sostienen la opinin que este diseo ahorra espacio porque slo almacenamos cdigos secretos en nuestra mesa de dimensin de 150,000 filas, no descriptores tardados. Adems, algunos modeladores consideran que el diseo normalizado para las Tablas de dimen-sion es ms fcil de sostener que. Si un departamento que la descripcin cambia, slo necesitaran actualizar el nico ocurrencia en vez de las 3,000 repeticiones en nuestra dimensin original del producto. El mantenimiento a menudo es tratado segn disciplinas de normalizacin, pero recuerde que todo esto ocurre en la parte de atrs de la zona de estacionamiento, mucho antes de los datos est cargado en el dibujo tcnico dimensional de un rea de presentacin. La normalizacin de la mesa de dimensin tpicamente es llamado snowflaking. Redun-dant que los atributos son removidos del reventn, mesa de dimensin denormalized y acomodados de adentro normalizaron Tablas secundarias de dimensin. Figura 2.12 ilustra el snowflaking parcial de nuestro dibujo tcnico original. Si el dibujo tcnico fuera con creces snowflaked, aparecera como un diagrama de relacin de entidad de la forma normal tercera lleno. El contraste entre Figura 2.12 y el anterior diseo en Figura 2.10 es sorprendente. Mientras las Tablas de hecho en ambas figuras son idnticas, la pltora de Tablas de dimensin (aun en
nuestra representacin simplista) es apabullante.
Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia La Dimensin del Producto La descripcin del Producto de la Llave del producto (PK) El nmero de unidad de control de inventarios (la Llave Natural) Brand Key (FK) El tipo del paquete Llave Fat (FK) Content Peso Las unidades de peso de Tipo de Almacenamiento de Medida Teclea (FK) Anchura del Estante La Altura del Estante La Profundidad del Estante y ms Brand Dimension Brand Key (PK) Marque Llave de Categora Description (FK) La Dimensin de Tipo del Paquete La descripcin de Tipo del Paquete de la Llave de Tipo del paquete (PK) La Dimensin de Tipo de Almacenamiento La llave de Tipo de Tiempo Antes de Caducar de Descripcin de Tipo de Almacenamiento de la Llave de Tipo (FK) (PK) de almacenamiento La Dimensin Categorial La llave Categorial Crucial categorial (FK) (PK) del Departamento de Descripcin
La Dimensin de Tipo de Tiempo Antes de Caducar La descripcin de Tipo de Tiempo Antes de Caducar de la Llave de Tipo de tiempo antes de caducar (PK) La Dimensin del Departamento
La descripcin del Departamento de la Llave del departamento (PK)
Figura 2.12 A medias la dimensin del producto del snowflaked.
Mientras el snowflaking es una extensin legal del modelo dimensional, en general, le alentamos a resistir el deseo a copo de nieve dado nuestros dos conductores primarios del diseo, la facilidad de uso y la funcin. la multitud de Tablas del snowflaked compensa una mucha ms presentacin complicada. Los usuarios inevitablemente lucharn contra la complejidad. Recuerde que la simplicidad es uno de los objetivos primarios de un modelo denormalized dimen sional. asimismo, los optimizadores de la base de datos lucharn contra la complejidad del dibujo tcnico del snowflaked. Las numerosas Tablas y las junturas usualmente se traducen en funcin ms lenta de averiguacin. Las complejidades del specifi-cation resultante de la juntura aumentan las probabilidades que el optimizador se desviar del tema y escoger una estrategia pobre.
los ahorros menores del espacio del disco se asociaron con Tablas de dimensin del snowflaked es insignificante. Si reemplazsemos la descripcin del departamento de 20 bytes en nuestra mesa de dimensin del producto de 150,000 filas con un cdigo de 2 bytes, salvaramos un el megabyte 2.7 tamao muy grande (150,000 la x 18 bytes), pero podemos tener una mesa de hecho 10-GB! Las Tablas de dimensin son casi siempre geomtricamente ms pequeas que mesa de hecho. Los esfuerzos para normalizar ms dimensionan pospone para ahorrar espacio del disco es tiempo perdido. Snowflaking retarda la habilidad de los usuarios para hacer una lectura ligera dentro de una dimensin.
Hacer una lectura ligera a menudo implica constreir uno o ms atributos de dimensin Y considerando los valores bien definidos de otro atributo en presencia de Estas restricciones. Hacer una lectura ligera deja a los usuarios comprender la relacin Entre dimensin atribuyen valores.
Obviamente, una mesa de dimensin del producto del snowflaked respondera bien si slo quisisemos una lista de las descripciones categoriales. Sin embargo, si quisisemos ver todas las marcas dentro de una categora, necesitaramos atravesar la marca y las dimensiones categoriales. Si entonces quisisemos tambin escorar el paquete determina el tipo sanguneo para cada marca en una categora, atravesaramos aun ms Tablas. El lenguaje normalizado de consulta necesitado para realizar estas averiguaciones aparentemente simples est muy complicado, y
aun no hemos tocado las otras dimensiones o mesa de hecho. finalmente, snowflaking derrota el uso de ndices del bitmap. Los ndices Bitmap son muy tiles cuando indexar low-cardinality fildea, como la categora Y las columnas del departamento en nuestro producto dimensionan Tablas. En gran medida aceleran la funcin de una averiguacin o la restriccin en la sola columna en duda. Snowflaking inevitablemente interferira con su habilidad para apalancar esta tcnica que afina funcin.
Las Tablas de dimensin deberan quedar como el reventn posponga fsicamente. Las Tablas normalizadas de dimensin snowflaked, sancionan atributo cruzado haciendo una lectura ligera y prohben el uso de ndices de los que se traz un mapa en pedacito. Los ahorros del espacio del disco ganados por ah normalizar el ta-bles de dimensin tpicamente estn menos de 1 por ciento del disco total espacio necesitado para el dibujo tcnico global. A sabiendas sacrificamos este espacio de la mesa de dimensin en el espritu de perfor-mance y facilidad de ventajas de uso. Hay por cuando el snowflaking es permisible, como nuestro anterior ejemplo con el arbotante de fecha en la dimensin de la tienda, donde una aglomeracin de atributos correlacionados es usada repetidamente en los papeles independientes diversos. Slo los instamos a ser conservador con snowflaked disea y los usamos slo cuando son obviamente encargados. Demasiadas Dimensiones La mesa de hecho en un dibujo tcnico dimensional es con naturalidad altamente normalizada y compacta. No hay muy para fomentar normalice el sumamente complejo que muchos para muchas relaciones entre las llaves en el hecho pospone porque las dimensiones no estn correlacionadas con cada otro. Cada tienda est abierta todos los das. Tarde o temprano, casi cada producto est muy convencido a favor de promocin en la mayora o todo nuestras tiendas. Interesantemente, mientras incmodas con dimensin del denormalized las Tablas, algunos modeladores estn tentadas de denormalize la mesa de hecho. En vez de tener un producto de sin-gle llave extranjera en la mesa de hecho, incluyen llaves extranjeras para los elementos analizados fre quently sobre la jerarqua del producto, como marca, la subcategora, la categora, y el departamento. Asimismo, la llave de fecha repentinamente se convierte en una serie de llaves incorporndose a semana separada, el mes, la cuarta parte, y las Tablas de dimen-sion de ao. Antes de que lo sepas, nuestro hecho compacto que la mesa tiene, se convirti en un monstruo revoltoso que se incorpora a literalmente las docenas de Tablas de dimensin. Nosotros affection-ately nos referimos a estos diseos como ciempieses porque las Tablas de hecho parecen tener casi 100 piernas, como se muestra en
Figura 2.13. Claramente, el diseo centpedo ha entrado en la trampa de demasiados dimensiones. Recuerde, aun con su formato apretado, la mesa de hecho es el alguien muy grande en un diseo dimensional. Diseando una mesa de hecho con demasiadas pistas de dimensiones para los requisitos del espacio del disco de la mesa de hecho significativamente aumentados. Mientras estamos dispuestos a destinar espacio adicional para Tablas de dimensin, el consumo del espacio de la mesa de hecho nos concierne porque es nuestra mesa ms grande por rdenes de magnitud. No hay muy para indexar la enorme llave de la multiparte eficazmente en nuestro ejemplo centpedo. Las numerosas junturas son un asunto para la usabilidad y la funcin de averiguacin.
La Dimensin de Ao de Dimensin de Cuarta Parte de Dimensin de Mes de Dimensin de Semana de Dimensin de Fecha La Dimensin Fiscal de Ao La Dimensin Fiscal de Mes
Almacene Dimensin del Plano de Piso de la Tienda de Dimensin de la Regin de la Tienda de Dimensin del Distrito de la Tienda de Dimensin del Estado de la Tienda de Dimensin del Condado de la Tienda de Dimensin Sales Transaction Fact Por Menor de punto de venta El producto de Mes del Fiscal de Ao Fiscal de la Llave de Ao de la Llave del Cantn de la Llave de Mes de la Llave de Semana de la Llave de fecha Llave Brand (FK) (FK) (FK) (FK) (FK) (FK) (FK) (FK) Key (FK) La llave de la Tienda de la Llave de Tipo del Paquete de la Llave del Departamento de la Llave de Categora Subcategory Key (FK) (FK) (FK) (FK) (FK) Almacene Llave de Promocin del Plano de Piso de la Tienda de la Llave de la Regin de la Tienda de la Llave del Distrito de la Tienda de la Llave del Estado de la Tienda del Condado (FK) (FK) (FK) (FK) (FK) (FK) Promocin de Tipo de Reduccin de promocin (FK) Media Mecanografa (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
La Dimensin de Tipo del Paquete de Dimensin del Departamento de Dimensin de Categora de Dimensin de Subcategora de Dimensin de Marca de Dimensin del Producto
Los Medios De Comunicacin de Promocin de Tipo de Reduccin de Promocin de Dimensin de Promocin Mecanografan
Figura 2.13
La mesa centpeda de hecho con demasiadas dimensiones.
La mayora de procesos de negocio pueden ser representados menos de 15 dimensiones en la mesa de hecho. Si nuestro diseo tiene 25 o ms dimensiones, deberamos mirar pues las formas a combinar correlacionaron dimensiones en una sola dimensin. Los atributos perfectamente relatados en cor, como los niveles de una jerarqua, as como tambin los atributos con una correlacin estadstica razonable, deberan ser de la misma dimensin. Usted ha hecho una buena decisin para combinar dimensiones cuando la dimensin sola nueva resultante es marcadamente ms pequea que el producto cartesiano del sepa-rate dimensiona.
Un nmero muy grande de dimensiones tpicamente es una seal que varias dimensiones no son completamente independientes y debera estar combinado en una sola dimensin. Es un error modelador di mensional representar elementos de una jerarqua como di-mensions separado en la mesa de hecho.
Subrogue Llaves Fuertemente promovemos el uso de claves vicarias en los modelos dimensionales en vez de confiar en cdigos operacionales de produccin. Las llaves vicarias van al lado de muchos
Otros alias: Las llaves sin sentido, las llaves de entero, las llaves poco naturales, las llaves artificiales, las llaves de syn-thetic, etctera. En trminos sencillos, las llaves vicarias son enteros que son asignados secuencialmente segn se necesite para poblar una dimensin. Por ejemplo, el primer registro del producto es asignado que una llave del substituto del producto con el valor de 1, el siguiente registro de prod-uct es llave asignada del producto 2, y as sucesivamente. Las llaves vicarias meramente vienen a adjuntar las Tablas de dimensin a la mesa de hecho. Los modeladores algunas veces no tienen muchas ganas de ceder sus llaves naturales porque quieren navegar la mesa de hecho bas sobre el mando de operacin mientras evitando una juntura para la mesa de dimensin. Recuerde, sin embargo, eso dimensiona Tablas son nuestros puntos de entrada para los hechos. Si la quinta parte a travs de novenos personajes en el mando de operacin identifica el fabricante, en ese entonces el nombre del fabricante debera ser incluido como un atributo de la mesa de dimensin. En general, queremos evitar empotra suena inteligencia en las llaves del almacn de datos porque cualquier suposiciones que hacemos eventualmente pueden estar deshabilitadas. Asimismo, las averiguaciones y appli-cation de acceso de datos no deberan tener ninguna dependencia incorporada en las llaves porque la lgica tambin sera vulnerable para la invalidacin.
Cada juntura entre dimensin y Tablas de hecho en el almacn de datos debera ser Basado sobre el entero sin sentido que el substituto teclea. Usted debera evitar usar los cdigos naturales de produccin de op-erational. Ninguna de las llaves del almacn de datos deberan ser listas, Donde usted puede decir algo acerca de la fila simplemente mirando la llave.
Inicialmente, eso puede ser ms rpido implementar un modelo dimensional usando mandos de operacin, pero las llaves vicarias definitivamente darn fruto a largo plazo. Algunas veces pensamos acerca de ellos como ser similares a una vacuna antigripal para el almacn de datos como una inmunizacin, hay un poco de dolor
para iniciar y administrar claves de surro-gate, pero los beneficios a largo plazo son sustanciales. Uno de los beneficios primarios de llaves vicarias es que moderan el ambiente de la casa de loza de datos de cambios operacionales. Las claves vicarias dejan el equipo de la casa de loza mantener control del ambiente en vez de ser aserrada por reglas operacionales para generar, actualizando, suprimiendo, reciclando, y reutilizar cdigos de produccin. En muchas organizaciones, los histricos mandos de operacin (por ejemplo, la cuenta inactiva numera o cdigos obsoletos del producto) quedan reasignados despus de un perodo de letargo. Si los nmeros de cuenta obtienen fol-low reciclado 12 meses de inaccin, los sistemas operacionales no pierden una pulsacin porque sus reglas comerciales prohben datos de quedarse por ah para tan largo. Los datos almacenan, por otra parte, retendrn datos por aos. Las llaves vicarias proveen el almacn de un mecanismo diferenciar estas dos instancias de sep-arate del mismo operacional nmero de cuenta. Si confiamos solamente en mandos de operacin, tambin somos vulnerables para teclear problemas del traslapo en el caso
De una adquisicin o una consolidacin de datos. Las claves vicarias dejan al equipo de la casa de loza de datos integrar datos de sistemas operacionales mltiples de la fuente, aun si les faltan las llaves consistentes de la fuente. Hay tambin funcin que las superioridades se asocieron con el uso de substituto la teclea. La llave vicaria es un entero tan pequeo como posible al asegurar que acomodar el cardinality futuro o mximo nmero de filas en la dimensin cmodamente. A menudo el mando de operacin es una voluminosa alfanumrica cadena de caracteres. La llave vicaria ms pequea traduce en Tablas ms pequeas de hecho, mesa ms pequea de hecho indices, y ms hecho que la mesa rema por la operacin de operacin de entrada/salida del bloque. Tpicamente, un entero de 4 bytes es lo suficiente como para maniobrar la mayora de sit-uations de dimensin. Un entero de 4 bytes es un solo entero, no cuatro dgitos decimales. Tiene 32 bits y por eso pueden manejar aproximadamente 2 billones de valores positivos (2321) o Positivo de 4 billones de totales y valores negativos ( 2321 para +2321). Como dijimos, esto es ms que suficiente para simplemente acerca de cualquier dimensin. Recuerde, si usted tiene un hecho abrumador la mesa con 1 billones de filas de datos, cada byte en cada fila de la mesa de hecho se traduce en otro mil millones de bytes de almacenamiento. Como mencionamos anterior, las claves vicarias se usan para registrar con-ditions de dimensin que no puede tener un mando de operacin, como la No condicin En Vigor Promotion . Asumiendo el control de las llaves del almacn, podemos asignar una llave vicaria para identificar esta condicin a pesar de la falta de codificacin operacional. De modo semejante, usted puede encontrarse con que sus modelos dimensionales tienen las fechas eso est an por ocurrir determinado. No hay valor de fecha de lenguaje normalizado de consulta por la Fecha para estar resuelto o la Fecha No Applicable. sta es otra razn que apoyamos que utilizar llaves vicarias para sus llaves de fecha en vez del lenguaje normalizado de consulta fechan tipos de datos (como si nuestra anterior ratio-nale no fuese lo suficientemente convincente). La dimensin de fecha es el nico dimensin dnde la substituta teclea debera ser asignado en una orden significativa, secuencial. En otras palabras, el 1 de enero de la primera parte que el ao sera asign valor crucial vicario 1, el 2 de enero sera
llave vicaria asignada 2, el 1 de febrero sera llave vicaria asignada 32, etctera. No queremos empotrar inteligencia extensiva del calendario en estas llaves (por ejemplo, YYYY-MM DD) porque hacer eso puede alentar personas para bordear la mesa de dimensin de bsqueda de fecha. Y, por supuesto, en utilizador este formato listo, otra vez no tendramos la forma a representar No Ha Ocurrido an y otras situaciones comunes de fecha. Slo queremos nuestro hecho que la mesa rema para estar en orden secuencial. Tratando la llave vicaria de fecha como una secuencia de fecha que el nmero dejar la mesa de hecho estar fsicamente subdividido con base en la llave de fecha. Dividir en partes una mesa grande de hecho con base en la fecha es altamente efectivo porque deja viejos datos estar distantes graciosamente y datos nuevos para estar cargadas e indexadas sin disturbar el resto de mesa de hecho.
Finalmente, las llaves vicarias se necesitan para soportar una de las tcnicas primarias para manejar cambios para dimensionar atributos de la mesa. Esto es en verdad una de las razones ms importantes para usar al substituto teclea. Le asignaremos una seccin entera en Captulo 4 a usar llaves vicarias para lentamente cambiando dimensiones. Por supuesto, algn esfuerzo es requerido para asignar y administrar llaves vicarias, pero es ni cercanamente tan intimidador que tantas personas se supongan. Necesitaremos establecer y mantener una mesa de referencia cruzada en la zona de estacionamiento que se usar para substituir la llave vicaria correcta sobre cada hecho y mesa de dimensin reman. En Captulo 16 colocamos fuera de un diagrama de flujo de datos para administrar y procesar que sur-rogate teclea en nuestros dibujos tcnicos dimensionales. Antes de que dejamos el tema de llaves, queremos advertir contra el uso de concate-nated o combinar llaves para Tablas de dimensin. No podemos crear uno verdaderamente llave del portn de surro simplemente pegando varias llaves naturales o combinando la llave natural con una estampilla de tiempo. Tambin, queremos evitar paralelo mltiple une entre la dimensin y Tablas de hecho, junturas algunas veces de dos caones llamadas, porque tienen un impacto adverso sobre la funcin. Mientras tpicamente no hacemos cesin el substituto teclea para degenerar dimensiones, usted debera evaluar cada situacin para determinar si uno es requerido. Una llave vicaria es necesaria si los nmeros de control de transaccin no son nicos a travs de posiciones o quedan reutilizados. Por ejemplo, el SISTEMA DE TERMINALES EN EL PUNTO DE VENTA de nuestro detallista no puede asignar nmeros nicos de transaccin a travs de tiendas. El sistema puede envolver de regreso a poner en el cero y reutilizar nmeros previos de control una vez que su mximum ha sido alcanzado. Tambin, su nmero de control de transaccin puede ser una columna alfanumrica de 24 bytes voluminosa. En tales casos, sera ventajoso usar una llave vicaria. Las dimensiones de nmero de con-trol tcnicamente, modeladas en as son ya no degeneradas. Por el momento, supongamos que la primera versin del representante del dibujo tcnico de ventas por menor resiente ambos el diseo lgico y fsico de nuestra base
de datos. En otras palabras, la base de datos relacional contiene slo cinco Tablas reales: La mesa de hecho de ventas por menor y la fecha, el producto, la tienda, y el regalo publicitario dimensionan Tablas. Cada uno de las Tablas de dimensin tienen una llave primaria, y el hecho que la mesa tiene una mezcla que llave puso arriba de estas cuatro llaves extranjeras, adems del nmero degenerado de transaccin. Por las casualidades el aspecto ms notable del diseo en este punto es la simplicidad de la mesa de hecho. Si las cuatro llaves extranjeras son enteros apretadamente consecutivos administrados, podramos reservar tan poco como 14 bytes para todas las cuatro llaves (4 bytes cada uno por la fecha, producto, y la promocin y 2 bytes para tienda). El nmero de transaccin podra requerir unos bytes 8 adicionales. Si los cuatro hechos en el hecho posponen si fuesen cada enteros de 4 bytes, necesitsemos reservar slo otro 16 bytes. Esto hara nuestro hecho posponer fila slo 38 bytes anchos. Aun si tuvimos un billn de filas, la mesa de hecho ocupara slo acerca de 38 gygabyte de espacio primario de datos. Una fila de la mesa de hecho tan aerodinmica es un resultado muy tpico en un diseo dimensional.
Nuestro dibujo tcnico de ventas por menor embellecido, ilustrado en Figura 2.11, tiene tres dimensiones de addi-tional. Si ubicamos 4 bytes cada uno para comprador y el dependiente y 2 bytes para la hora del da (hasta el minuto prximo), en ese entonces nuestra anchura de la mesa de hecho aumenta para slo 48 bytes. Nuestra mesa de hecho de la fila de billn ocupa simplemente 48 gygabyte.
El Anlisis de la Canasta de Mercado El dibujo tcnico de ventas por menor nos dice en el detalle exquisito cul fuese comprado en cada tienda y debajo de qu condiciones. Sin embargo, el dibujo tcnico no nos deja muy fcilmente analizar cules los productos fueron vendidos en la misma canasta de mercado juntos. Esta nocin de analizar la combinacin de productos que venden juntos es conocida por mineros de datos como la afinidad agrupndose pero ms popularmente es llamada anlisis de la canasta de mercado. El anlisis de la canasta de mercado le da al detallista los entendimientos profundos de aproximadamente cmo promover para la venta combinaciones diversas de artculos. Si din-ners congelado de pasta vndase bien con productos de kola, en ese entonces estos dos productos quiz deberan quedar por el uno al otro o comercializados con complementaria fijacin de precios. El concepto de anlisis de la canasta de mercado puede estar extendido fcilmente para otras situaciones. En el ambiente manufacturero, es til ver qu productos son ordenados juntos porque podemos querer ofrecer manojos del producto con fijacin de precios del paquete. La mesa de hecho de ventas por menor no puede ser usada con holgura para realizar mercado que la canasta analiza porque lenguaje normalizado de consulta fue nunca diseado para constreir y el grupo a travs del hecho de rubro contable rema. Las herramientas de minera de datos y algunos productos OLAP pueden ayudar con anlisis de la canasta de mercado, pero a falta de estas herramientas, describiremos un acercamiento ms directo debajo. Sea prevenido que sta es una tcnica ms bien adelantada; Si usted no est haciendo anlisis de la canasta de mercado hoy, simplemente examine rpidamente esta seccin para llegar un sentido general de las tcnicas complejas. En Figura 2.14 ilustramos una mesa de hecho de la canasta de mercado que se deriv de transacciones de ventas por menor. La mesa de hecho de la canasta de
mercado es una foto peridica representando los pares de productos comprados juntos durante un especificado lapso de tiempo. Los hechos incluyen el nmero total de canastas (el cliente etiqueta) que incluyeron A de productos y B, el nmero total de dlares de la A del producto y las unidades en este subconjunto de compras, y el nmero total de dlares de la B del producto y unidades compradas. La cuenta de la canasta es un hecho semiaditivo. Por ejemplo, si un boleto del cliente contiene rubros contables para pasta, los refrescos, y la mantequilla de man en la mesa de hecho de la canasta de mar-ket, esta sola orden es contada una vez en la fila de hecho de bebidas suave en la pasta, una vez en la fila para el man de pasta untan con mantequilla combinacin, etctera. Obviamente, la cautela debe ser tomada para evitar cuentas de compra que resume para ms que un producto.
Sales Transaction Fact Por Menor de punto de venta La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity La Cantidad del Dlar de Ventas La Cantidad Costada del Dlar La Cantidad Vulgar del Dlar de la Ganancia
Puebla El hecho de la Canasta de Mercado de punto de venta La promocin de la Llave de la Tienda de la Llave de la B del Producto de la Llave de la A del Producto de la Llave de fecha Llave Basket (FK) (FK) (FK) (FK) (FK) Count B del Producto de Cantidad de Ventas de la A del Producto de Cantidad de Ventas B del Producto de Cantidad del Dlar de Ventas de la A del Producto de Cantidad del Dlar de Ventas
Vetee = 1 fila por punto de venta La lnea de transaccin Vetee = 1 fila para cada par de productos convencidos de un da por tienda y la promocin
Creo 2.14 el Mercado que la mesa de hecho de la canasta pobl de transacciones de compra.
Usted echar de ver que hay dos llaves generalizadas (el producto afina A y B) del producto en la mesa de hecho de la canasta de mercado. Aqu hemos construido una sola mesa de dimensin del producto que contiene entradas en niveles mltiples de la jerarqua, como productos individuales, marcas, y categoras. Esta variante especializada de nuestra mesa normal de dimensin del producto contiene un pequeo nmero de atributos ms bien genricos. El substituto teclea pues los niveles diversos de la jerarqua del producto han sido asignados a fin de que no traslapan. Conceptualmente, la idea de correlaciones de la canasta de mercado de la grabacin es simple, pero el puro nmero de combinaciones del producto hace el cuestionamiento de anlisis. Si tenemos productos de la N en nuestra cartera de productos y nosotros tratamos de hacer una mesa de cada par posible de llaves del producto encontradas en las rdenes del producto, nos acercaremos a las combinaciones del producto N2 actually N x ( N 1 ) for the mathe - maticians among you . En otras palabras, si tenemos 10,000 productos en nuestro folio de babor, habra casi 100,000,000 combinaciones pairwise. El nmero de combinaciones posibles rpidamente aborda disparate cuando tratamos de un gran nmero de productos. Si una tienda por menor vende a 100,000 SKUs, hay
10 billones de combinaciones posibles de unidad de control de inventarios.
La llave para anlisis realista de la canasta de mercado debe recordar que la meta primaria es comprender las combinaciones significativas de productos vendidos juntos. Pensando acerca de nuestra mesa de hecho de la canasta de mercado, primero tendramos inters en filas con cuentas altas de la canasta. Desde que estas combinaciones del producto son observadas frecuentemente, garantizan ms investigacin. En segundo lugar, lo haramos
Busque situaciones donde los dlares o unidades para A de productos y la B estuviera en el balance razonable. Si los dlares o unidades son poco convencionales de balance, todo lo que hemos hecho es encontrar los productos que se venden a gran altura lo acoplaron con productos secundarios insignificantes, lo cual no sera demasiado de ayuda haciendo al estudiante avanzado haciendo comercio o las decisiones de promocin. Para evitar la explosin combinatoria de producto arregla en pares en la mesa de hecho de la canasta de mercado, confiamos en un algoritmo progresivo de poda. Empezamos en lo alto de la jerarqua del producto, cul asumiremos est categorial. Nosotros primer enumer-eat todas las combinaciones de la canasta de mercado categora a categora. Si hay 25 cat-egories, este primer paso genera 625 filas de la canasta de mercado. Entonces podamos esta lista para ms anlisis seleccionando slo las filas que hacen un razonablemente alto ordenar cuenta y donde los dlares y unidades para A de productos y B (cul estn las categoras en este punto) son razonablemente simtricos. La experimentacin le dir lo que el alcance de la canasta de la cuenta del umbral y de balance debera ser. Entonces empujamos hasta el siguiente nivel de detalle, cul asumiremos es marca. Comenzando con el set podado de combinaciones del ltimo paso, profundizamos en A del producto enumerando todas las combinaciones de marca (la A del producto) por ensangrentado en la Cate (la B del producto). De modo semejante, escudriamos hasta el fondo un nivel de la jerarqua para B de prod-uct vindose alguno combinaciones de marca (la A del producto) por marca (la B del producto). Otra vez, podamos las listas para esos con las frecuencias ms altas de la cuenta de la canasta y el dlar o el balance de la unidad y entonces profundizamos para el siguiente nivel en la jerarqua. Como bajamos la jerarqua, producimos filas con cuentas ms pequeas y ms pequeas de Ba-ket. Eventualmente, no encontramos que canasta cuente ms gran que el umbral razonable para la relevancia. Es permisible detenerse en siempre que una vez que tenemos satis-fied la curiosidad del analista. Una de las ventajas de esta estrategia descendente es que las filas encontradas en cada punto son esas con el impacto y relevancia ms alta. Progresivamente podando la lista le provee ms foco a ya resultados pertinentes. Uno puede imaginar automatizar este proceso, buscar el hier-archy del producto hacia abajo, ignorando las cuentas bajas de la canasta, y
siempre luchando por dlares de bal-anced y las unidades con las cuentas altas de la canasta. El proceso podra frenar cuando el nmero de pares del producto alcanz algn umbral deseado o cundo la actividad total expresado en cuenta de la canasta, los dlares, o las unidades alcanzaron un poco ms abajo limita. Una variacin sobre este acercamiento podra comenzar con una categora especfica, marca, o podra emparejarse un producto. Otra vez, la idea era combinar este producto especfico primero con todas las categoras y entonces trabajar abajo de la jerarqua. Otra torsin era mirar la mezcla de productos comprados por un cliente dado durante un dado lapso de tiempo, sin tener en cuenta ya sea estaban en la misma canasta. En todo caso, mucho del trabajo duro se asoci con anlisis de la canasta de mercado ha sido de carga feriada para los procesos ETL de la zona de estacionamiento para simplificar los aspectos de averiguacin ltima y de presentacin del anlisis.
Resumen En este captulo tuvimos nuestra primera exposicin para disear un modelo dimensional. Sin tener en cuenta industria, fuertemente alentamos el proceso de cuatro pasos para brezo comn de tachuela los diseos modelo dimensionales. Recuerde que es especialmente importante que claramente decimos que el grano se asoci con nuestro dibujo tcnico dimensional. Cargando el hecho la mesa con datos atmicos provee la mxima flexibilidad porque podemos resumir esa informacin desordenadamente. Tan pronto como la mesa de hecho est restringida para la informacin ms agregada, entraremos corriendo a las paredes cuando las suposiciones del resumen resultan invlidas. Tambin recuerde que es de vital importancia poblar nuestras Tablas de dimensin con atributos poco concisos, robustos y descriptivos. En el siguiente captulo quedaremos dentro de la industria por menor para discutir tech-niques para abordar un segundo proceso comercial dentro de la organizacin, ensur ing que apalancamos nuestros anteriores esfuerzos al evitar toberas.
Inventario EL CARBONO HAPTE R
yo
N Chapter 2 desarrollamos un modelo dimensional para las transacciones de ventas en una cadena grande de la tienda de comestibles. Quedamos dentro de la misma industria en este captulo pero subimos la cadena de valor para abordar el proceso de inventario. El devel-oped de diseos en este captulo aplquese a un set ancho de tuberas de inventario ambos interior y fuera de la industria por menor. Aun ms importante, este captulo provee un debate cabal de la arquitectura del autobs del almacn de datos. La arquitectura del autobs es imprescindible crear un almacn integrado de datos de un set distribuido de procesos comerciales relacionados. Provee un armazn para planificar el almacn global, si bien lo construiremos incrementalmente. Finalmente, acentuaremos la importancia de usar dimensiones comunes, conformadas y los hechos a travs de los modelos de dimen-sional del almacn.
las implicaciones de la cadena de valor inventare modelo peridico de la foto, as como tambin transaccin y modelos de la foto de atesoramiento
los hechos semiaditivos los hechos realzados de inventario los datos almacenan arquitectura del autobs y matriz los hechos y dimensiones conformadas
67
La introduccin para la Cadena de Valor La mayora de organizaciones tienen una cadena subyacente de valor consistente en sus procesos comerciales cruciales. La cadena de valor identifica el flujo natural, lgico de actividades primarias de una organizacin. Por ejemplo, en el caso de un detallista, la compaa puede publicar una orden de compra para un fabricante del producto. Los productos son dados al almacn del detallista, donde estn sujetos en el inventario. Una entrega se hace entonces a una tienda individual, dnde otra vez los productos se sientan en el inventario hasta que un consumidor haga una compra. Hemos ilustrado este subconjunto de la cadena de valor de un detallista en Figura 3.1. Obviamente, el sourced de productos de un fabricante que le da directamente a la tienda minorista bordeara los pasos que alojan loza de la cadena de valor. Los sistemas operacionales de la fuente tpicamente producen transacciones o fotos en cada paso de la cadena de valor, generando interesarle mtrica de funcin por el camino adelante. El objetivo primario de la mayora de analticos sistemas de apoyo para la toma de decisiones es monitorear los resultados de funcin de procesos cruciales. Desde que cada proceso comercial produce mtrica nica a los nicos espacios de tiempo con dimensionalidad y granularidad nica, cada proceso tpicamente engendra gran cantidad de uno o ms Tablas de hecho. Con este fin, la cadena de valor provee entendimiento profundo de alto nivel en el almacn global de datos de la empresa. Dedicaremos ms tiempo a este tema ms tarde en este captulo.
Los Asuntos del Detallista Compran Pedido Las Entregas en Almacn del Detallista El Inventario del Almacn del Detallista Las entregas en Tienda Minorista
Tienda Minorista Inventario
Tienda Minorista Ventas Figura 3.1 El subconjunto de la cadena de valor de un detallista.
Modelos Inventariales Mientras tanto, ahondaremos en varios modelos inventariales complementarios. La primera parte es el inventario foto peridica. Todos los das (o a algn otro espacio de tiempo de regu-Lar), medimos los niveles de inventario de cada producto y los colocamos como la separata reme en una mesa de hecho. Estas filas peridicas de la foto aparecen con el paso del tiempo como una serie de estratos de datos en el modelo dimensional, los estratos de geo-logic muy anlogos representen la acumulacin de sedimento sobre las largas temporadas de tiempo. Exploraremos este modelo inventarial comn en algn detalle. Tambin discutiremos brevemente un segundo modelo inventarial donde registramos cada transaccin que tiene un impacto en niveles de inventario como los productos se muevan a travs del almacn. Finalmente, en el tercer modelo, trataremos superficialmente el inventario acumulando con un chasquido disparo, donde construimos una fila de la mesa de hecho para cada entrega del producto y actualizamos la fila hasta que el producto deje el almacn. Cada uno de los tres modelos inventariales dicen una historia diferente. En algunas aplicaciones de inventario, dos o aun todos los modelos de tres pueden ser apropiados simultneamente.
Inventare Foto Peridica Regresemos a nuestro estudio de casos por menor. Los niveles optimizados de inventario en las tiendas pueden tener un impacto principal sobre la rentabilidad de la cadena. Hacer seguro el producto correcto est en la provisin correcta al momento correcto minimiza fuera de acciones y reduce costos globales de carry-ing de inventario (donde lo prod-uct no est disponible en el estante a ser vendido). El detallista necesita que la habilidad analice cantidad diaria que el inventario en cuestin derriba por producto y tienda. Es hora de poner el proceso de cuatro pasos para disear modelos dimensionales para trabajar otra vez. El proceso comercial que estamos interesados en analizar es el inventario de la tienda por menor. En trminos de la granularidad, queremos ver inventario diario por producto en cada tienda individual, que asumimos es el nivel atmico de detalle provisto por el sistema operacional de inventario. Las
dimensiones inmediatamente se caen de esta declaracin del grano: La fecha, el producto, y la tienda. Somos incapaces de visualizar dimensiones descriptivas adicionales en esta granularidad. Typi-cally de inventario no es asociado con una dimensin de promocin por menor. Aunque una promocin de la tienda puede ser seguir mientras los productos se sientan en el inventario, la promocin usualmente no es asociada con el producto hasta que est en verdad vendida. Despus de que la promocin haya cesado, los productos todava pueden estar sentndose en el inventario. Tpicamente, las dimensiones de promocin son asociadas con movimiento del producto, como cuando el producto es ordenado, recibido, o es vendido. La vista ms simple de inventario implica slo un solo hecho: La cantidad a la mano. Esto conduce a un diseo excepcionalmente por completo dimensional, como se muestra en Figura 3.2.
La Dimensin de Fecha Los atributos de datos de la Llave de fecha (PK)
Almacene Dimensin Almacene Atributos De la Tienda Cruciales (PK) Almacene Hecho de la Foto de Inventario La cantidad de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) en Mano La Dimensin del Producto Los atributos del Producto de la Llave del producto (PK)
Creo que 3.2 la Tienda inventaran dibujo tcnico peridico de la foto.
La mesa de dimensin de fecha en este estudio de casos es idntica para la mesa desarrollada en el anterior caso para ventas de la tienda por menor. Las dimensiones del producto y de la tienda tambin pueden ser idnticas. Alternativamente, podemos querer fomentar decoran estas Tablas de dimen-sion con atributos adicionales que seran tiles para analy-si de inventario. Por ejemplo, la dimensin del producto podra ser realzada para incluir columnas como la cantidad mnima de nuevo pedido, suponiendo que son con-stant y descriptores discretos de cada unidad de control de inventarios del producto (la unidad de control de inventarios). Sabios a Like, en la dimensin de la tienda, adems del metraje de cuadrado de venta atribuimos que discuti en Captulo 2, tambin podramos incluir atributos a identificar los metrajes cuadrados de almacenamiento detenidos y refrigerados. Hablaremos ms acerca de las implicaciones de sumar estos atributos de dimensin ms tarde en este captulo. Si somos analticos el inventario derriba en el almacn del detallista en vez de en la posicin de memoria, el dibujo tcnico se parecera realmente mucho a la Figura 3.2. Obvi-ously, la dimensin de la tienda sera reemplazado con una dimensin del almacn. Cuando el inventario monitor derriba en el almacn, normalmente no retenemos la dimensin de la tienda como una cuarta dimensin a menos que el inven-Tory del almacn haya sido asignado a una tienda especfica. Empareje un dibujo tcnico tan simple como este puede ser muy til. Los numerosos entendimientos profundos pueden estar derivativos si los niveles de inventario estn medidos frecuentemente para muchos productos en muchas posiciones de memoria. Si analizamos los niveles de inventario en reserva de un mercader masivo, esta base de datos podra usarse para balancear inventarios de la tienda cada noche tras las tiendas cerca. Esta mesa peridica de hecho de la foto afronta un reto serio que el Captulo 2 la mesa de hecho de transaccin de ventas 's no afront. La mesa de hecho de ventas fue razonablemente escasa porque slo aproximadamente 10 por ciento de los productos en cada uno de nuestras tiendas hipotticas en verdad vendidas cada da.
Si un producto no se vendiese en una tienda en un da dado, en ese entonces no hubo reme en la mesa de hecho para esa combinacin de llaves. El inventario, por otra parte, genera Tablas densas de la foto. Desde que el detallista se esfuerza por evitar situaciones agotadas donde el producto no est disponible en venta, hay una fila en la mesa de hecho para virtualmente cada producto en cada tienda todos los das.
Bien podemos incluir las medidas de cero como registros explcitos. Para nuestro detallista de gro-cery con 60,000 productos surtidos en 100 tiendas, insertaramos aproximadamente 6 millones de filas (x de 60,000 productos 100 almacena) con cada carga de la mesa de hecho. Con una anchura de la fila de simplemente 14 bytes, la mesa de hecho crecera por 84 El megabyte cada vez que anexamos ms mesa de hecho rema. El valor de disparos concisos diarios de un ao consumira sobre 30 gygabyte. La densidad de inventario le toma instantneas algunas veces mandatos algunos acuerdos intermedios. Quiz el acuerdo intermedio ms obvio es reducir las frecuencias de la foto con el paso del tiempo. Puede ser aceptable mantener los ltimos 60 das de inventario en lo diariamente nivelado y entonces revertirse para las fotos menos semanales granulares para datos histricos. De este modo, en lugar de retener 1,095 fotos durante un perodo de 3 aos, el nmero podra ser reducido a 208 fotos totales (60 + diario 148 semanalmente le toma instantneas a en dos Tablas separadas de hecho dados su periodicidad nica). Hemos reducido el tamao total de datos por ms que un factor de 5.
Semiadditive Facts Enfatizamos la importancia de additivity de hecho en Captulo 2. Cuando modelamos el flujo de producto despus de un punto en la caja registradora de caja, slo los productos que en verdad vendi estaban medidos. Una vez que un producto fue vendido, no podra ser contado otra vez en una subsiguiente venta. Esto puso la mayora de las medidas en el dibujo tcnico de ventas por menor perfectamente aditivo a travs de todas las dimensiones. En la foto de inventario el dibujo tcnico, la cantidad en reserva puede estar resumido a travs de productos o tiendas y puede dar como resultado un total vlido. El inventario derriba, sin embargo, no lo hace aditivo de a travs pasa de moda porque representan fotos de un nivel o bal-ance en una oportunidad con el tiempo. No cabe distinguir si inven del ayer conservador extremo es lo mismo o desemejante del inventario del hoy solamente mirando niveles de inventario. Porque los niveles de inventario (y todas las formas de financieros saldos de las cuentas) son aditivos a travs de algunas dimensiones pero no todo, nos referimos a
ellos como los hechos semiaditivos. La naturaleza semiaditiva de hechos de balance de inventario est pareja ms entienden capacitados si pensamos acerca de nuestra cuenta corriente se balancea. El lunes, supongamos que usted tiene $50 en vuestra cuenta. El martes, el balance permanece inalterado. El mircoles, usted deposita otro $50 en vuestra cuenta a fin de que el balance sea ahora $100. La cuenta no tiene ms actividad a travs del fin de la semana. El viernes, usted meramente no puede sumar los saldos diarios durante la semana y puede declarar que su balance es $400 (basado en $50 + 50 + 100 + 100 + 100). La forma ms til para combinar saldos de las cuentas e inventariar derriba a travs de las fechas debe promediarlas (dando como resultado un saldo medio de $80 en el ejemplo verificador). Somos todos familiares con nuestro banco en lo referente al promedio de los saldos diarios en nuestro resumen mensual de la cuenta.
Todo mide un ese nivel de esttica (el inventario derriba, financieros saldos de las cuentas, y mide de intensidad como las temperaturas de la habitacin) sin precedente es intrnsecamente poco aditivo a travs de la dimensin de fecha y posiblemente otras dimensiones. En estos casos, los seguros pueden ser agregados tilmente a travs del tiempo, por ejemplo, promediando durante el nmero de lapsos de tiempo. Las ltimas palabras recientes en este principio del diseo contienen una trampa. Desafortunadamente, usted no puede usar la funcin de lenguaje normalizado de consulta AVG para calcular el promedio con el paso del tiempo. La funcin de lenguaje normalizado de consulta AVG promedia sobre todas las filas recibidas por la averiguacin, no simplemente el nmero de fechas. Por ejemplo, si una averiguacin pidiese el inventario medio para un grupo de tres productos en cuatro tiendas a travs de siete fechas (es decir, cul es el inventario diario promedio de una marca en una regin geogrfica durante una semana dada), la reunin social de lenguaje normalizado de consulta AVG dividira el valor sumado de inventario por ah 84 (x de 3 productos 4 almacena x 7 fechas). Obviamente, la respuesta correcta es dividir el valor sumado de inventario a las 7, lo cual es el nmero de diarios lapsos de tiempo. Porque el lenguaje normalizado de consulta no tiene funcionabilidad estndar como un oper-ator AVG_DATE_SUM que computara el promedio sobre simplemente la dimensin de fecha, los clculos de inventario son agobiados de complejidad adicional. Una aplicacin correcta de inventario debe aislar la restriccin de fecha y debe recuperar su cardinality a solas (en este caso, los 7 das comprendiendo la semana pedida). En ese entonces la aplicacin debe dividir el valor sumado final de inventario por el cardinal-ity de restriccin de fecha. Esto puede haber terminado con una llamada incrustada de lenguaje normalizado de consulta dentro de lo state-ment global de lenguaje normalizado de consulta o poniendo en duda la dimensin de fecha separadamente y entonces almacenando el valor resultante en una aplicacin que es pasada a la declaracin global de lenguaje normalizado de consulta. Los Hechos Realzados de Inventario
La vista simplista de inventario que desarrollamos en nuestra mesa peridica de hecho de la foto nos deja ver una serie temporal de niveles de inventario. Para el inventario de la mayora el anlisis, la cantidad en reserva no es suficiente. La cantidad en mano necesita ser usada en conjuncin con hechos adicionales para medir la velocidad de move-ment de inventario y desarrollar otra mtrica interesante como el nmero de vueltas, num-be del suministro de das, y el regreso vulgar del margen sobre el inventario (GMROI, jem-roy pronunciado). Si le aadisemos la cantidad vendida (o la cantidad equivalentemente, agotada o se envi si nos ocupamos de una posicin del almacn) a cada hecho de inventario rema, podramos calcular el nmero de recodos y el suministro de das. Para fotos diarias de inventario, el nmero de vueltas medidas cada da se calcula como la cantidad vendida entre la cantidad a la mano. Pues un tiempo extendido dio vueltas, como un ao, el nmero de vueltas es la cantidad total vendida entre la cantidad diariamente comn en reserva. El nmero del suministro de das es un clculo similar. Durante un perodo de tiempo, el nmero del suministro de das es la cantidad final en reserva entre la cantidad comn vendida.
Adems de la cantidad vendida, probablemente tambin podemos suministrar el valor extendido del inventario a precio de costo, as como tambin el valor en el ltimo precio de venta. Lo differ-ence entre estos dos valores es la ganancia bruta, por supuesto. El margen bruto es igual a la ganancia bruta entre el valor en el ltimo precio de venta. Finalmente, podemos multiplicar el nmero de vueltas por el margen bruto llegar lo
GMROI, tan expresado en la siguiente frmula:
La cantidad total vendi x (el valor en el ltimo precio vendedor el valor a precio de costo)
GMROI
La cantidad diariamente comn sobre el valor de la x de la mano en el ltimo precio de venta
Aunque esta frmula se ve complicada, la idea detrs de GMROI es simple. Multiplicando el margen bruto por el nmero de vueltas, nosotros cree una medida de la efectividad de nuestra inversin en existencias. Un GMROI elevado quiere decir que movemos el producto a travs de la tienda rpidamente (montones de vueltas) y ganamos buen sueldo sobre la venta del producto (el margen bruto alto). Un GMROI humilde quiere decir que movemos el producto lentamente (el punto bajo da vuelta) y no hacemos muchsimo dinero en l (el margen bruto bajo). El GMROI es un estndar mtrico usado por analistas de inven-Tory para juzgar la calidad de una compaa de inversin en su inventario. Si queremos ser ms ambiciosos que nuestro diseo inicial en Figura 3.2, en ese entonces deberamos incluir la cantidad vendida, valor a precio de costo, y el valor en las ltimas columnas vendedoras de precio en nuestra mesa de hecho de la foto, tan ilustrado en Figura 3.3. Por supuesto, si algunos de esta mtrica existe en la granularidad diferente en Tablas separadas de hecho, una aplicacin peticionaria necesitara recuperar todos los componentes de la computacin GMROI al mismo nivel. Echo de ver que la cantidad en reserva es semiaditiva sino que las otras medidas en nuestra foto peridica avanzada son todo con creces aditivas a travs de todo tres dimen-sions. La cantidad vendi cantidad est resumida para el grano particular de la mesa de hecho, lo cual est diariamente en este caso. Las columnas de valor estn extendidas, aditivo tiene importancia. No almacenamos a GMROI en la mesa de hecho porque no es aditivo. Podemos calcular a GMROI de las columnas constitutivas a travs de cualquier nmero de filas de hecho sumando las columnas antes de realizar el clculo, pero estamos estancados si intentamos almacenar a GMROI explcitamente porque no podemos usar completamente GMROIs del cartel a travs de filas mltiples.
La Dimensin de Fecha Los atributos de Fecha de la Llave de fecha (PK)
Almacene Dimensin Almacene Atributos De la Tienda Cruciales (PK) Almacene Hecho de la Foto de Inventario La cantidad de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) en Cantidad de la Mano Se Vendi El Valor Del Dlar a Precio de Costo El Valor Del Dlar en el ltimo Precio de Venta La Dimensin del Producto Los atributos del Producto de la Llave del producto (PK)
Figura 3.3 GMROI.
El inventario realzado la foto peridica para soportar anlisis
La foto peridica es el dibujo tcnico de inventario ms comn. Trataremos brevemente superficialmente dos perspectivas alternativas para complementar la foto de inventario simplemente diseada. Para un cambio de paso, en vez de describir estos modelos en el contexto del inventario en reserva por menor, subiremos el valor cadena para dis-cuss el inventario localiz en nuestros almacenes. Las Transacciones de Inventario Una segunda forma para modelar una apfisis de negocio de inventario es registrar cada transaccin que afecta inventario. Las transacciones de inventario en el almacn podran incluir lo siguiente: reciba producto coloque producto dentro de agarre de inspeccin el producto de liberacin de agarre de inspeccin devulvale el producto al vendedor debido al fracaso de inspeccin coloque producto en tarro para depsito autorice producto en venta el producto de eleccin de tarro para depsito el producto del paquete para embarque enve producto al cliente reciba producto de cliente devuelva producto para inventariar de regreso del cliente remueva producto de inventario Cada transaccin de inventario identifica la fecha, producto, el almacn, vendedor, tipo de transaccin, y en la mayora de los casos, una sola cantidad representando el impacto de cantidad de inven-Tory causado por la transaccin. Suponiendo que la granularidad de nuestra mesa de hecho es una fila por la transaccin de inventario, el dibujo tcnico resultante es ilustrado en Figura 3.4.
El Hecho de Transaccin de Inventario del Almacn La Dimensin de Fecha La llave del Producto de la Llave de fecha (FK) (FK) La Dimensin del Producto
La Dimensin del Almacn El almacn de la Ciudad del Almacn de la Direccin del Almacn de Nombre del Almacn de la Llave del almacn (PK) la Zona de Estado del Almacn de ZIP del Almacn El Metraje del Cuadrado de Total del Almacn y ms La llave del almacn (FK) La llave del vendedor (FK) La cantidad del Dlar de Transaccin de Inventario de la Llave de Tipo de Transaccin de inventario (FK) La Dimensin del Vendedor La Dimensin de Tipo de Transaccin de Inventario El grupo de Tipo de Transaccin de Inventario de Descripcin de Tipo de Transaccin de Inventario de la Llave de Tipo de Transaccin de inventario (PK)
Creo que 3.4 la transaccin de inventario del Almacn modelan.
Si bien la mesa nivelada en la transaccin de hecho es otra vez muy simple, contiene la informacin ms detallada disponible acerca del inventario porque refleja manipulaciones de inventario de escala fina. La mesa nivelada en la transaccin de hecho es muy apropiada para mea suring la frecuencia y la oportunidad del momento de transaccin especfica mecanografa. Por ejemplo, slo una mesa veteada en transaccin de hecho de inventario puede contestar las siguientes preguntas: cuntas veces hemos colocado un producto dentro de un tarro para depsito de inventario en el mismo da escogimos el producto del mismo tarro para depsito en otro momento? cmo recibieron muchos embarques separados nosotros de un vendedor dado, y cundo hicimos los obtenemos? cules productos hemos tenido ms de lo que una ronda de fracasos de inspeccin que le causaron el regreso del producto al vendedor adelante? Aun as, es imprctico destinar esta mesa como la base exclusiva para analizar funcin de inven-Tory. Aunque cabe tericamente reconstruir la posicin exacta de inventario de un momento a otro con el tiempo renovando hacia el futuro todas las transacciones posibles de un inventario sabido posicin, es demasiado difcil e impracti-cal para almacn ancho de datos duda que el intervalo sale en citas o productos.
Recuerde que eso hay ms para la vida que transacciones a solas. Alguna forma de mesa de la foto para darle una vista ms acumulativa de un proceso a menudo acompaa una mesa de hecho de transaccin.
El Inventario Acumulando Foto El modelo inventarial final que exploraremos brevemente es el atesoramiento instantnea herida de bala. En este modelo colocamos una fila en la mesa de hecho para un embarque de un producto de par-ticular al almacn. En una sola mesa de hecho remamos que rastrea la disposicin del embarque del producto hasta que ha
dejado el almacn. El modelo de la foto de accu-mulating es slo posible si de fuente fidedigna podemos distinguir prod-ucts entregado en un embarque de esos entregados posteriormente. Este acercamiento es tambin apropiado si rastreamos disposicin en lev-els muy detallado, como por ah nmero del producto de nmero de serie o del lote. Supongamos que el inventario experimenta una serie de hitos o acontecimientos bien definidos como se mueva a travs del almacn, tan receptor, inspeccin, colocacin del tarro para depsito, autorizacin a vender, escogiendo, boxeando, y el embarque. El phi-losophy detrs de la mesa de hecho de la foto de atesoramiento debe proveer un estatus actualizado del embarque del producto como se mueve a travs de estos hitos. Cada hecho que la fila de la mesa estar actualizada hasta el producto deja el almacn. Como illus-trated en Figura 3.5, el inventario acumulando mesa de hecho de la foto con su multitud de fechas y hechos mira muy desemejante de la transaccin o dibujos tcnicos de la foto de peri-odic.
El Compaero De Cita Recibi Dimensin El Compaero De Cita Inspeccion Dimensin El Compaero De Cita Coloc en la Fecha de Dimensin de Inventario Autorizado para la Dimensin Sell la Dimensin de Fecha Picked El Compaero De Cita Encajon Dimensin El Compaero De Cita Envi Dimensin La Fecha de ltima Dimensin de Ida Y Vuelta El Hecho de Atesoramiento de Inventario del Almacn El compaero de cita Recibi la Fecha Crucial (FK) la Llave Inspeccionada (FK) El compaero de cita Coloc en la Fecha de la Llave de Inventario (FK) Autorizado hasta la Fecha de la Llave Sell (FK) la Llave Escogida (FK) El compaero de cita Encajon la Fecha Crucial (FK) la Llave Enviada (FK) La fecha de ltima Llave Crucial (FK) del Producto (FK) De Ida Y Vuelta Cantidad del Llave del Vendedor del Llave del almacn Received (FK) (FK) Quantity Pas Revista La Cantidad Regres a la Cantidad del Vendedor Colocada en Bin Quantity Authorized para Cantidad Sell Picked La Cantidad Encajonada La Cantidad Enviada La Cantidad Regres por Cantidad del Cliente Returned a Cantidad de Inventario Damaged La Cantidad Perdi Cantidad Escrita Fuera del Coste por Unidad El Precio De Lista de la Unidad El Precio Medio de la Unidad El Precio de Recuperacin de la Unidad
La Dimensin del Vendedor de Dimensin del Almacn de Dimensin del Producto
Resuelvo 3.5 foto de atesoramiento de inventario del Almacn.
Fotos que acumulan son el tipo del estudiante avanzado de tercera parte de mesa de hecho. Le interesan ambos por las llaves extranjeras apreciadas en fecha mltiples al principio de la lista crucial y tambin porque volvemos a visitar y modificamos los mismos registros de la mesa de hecho repetidas veces. Desde que la foto de atesoramiento raras veces es usada procesos de inventario bastante corredores, continuamente reabastecidos, en vez de enfocar la atencin en acumular fotos a esta hora, proveeremos cobertura ms detallada en Captulo 5. El lector alerta notar la mtrica de cuatro poco aditivos al final de la mesa de hecho. Otra vez, el sostn afin para Captulo 5.
La Integracin de la Cadena de Valor Ahora que hemos completado el diseo de tres variaciones de modelo inventarial, volvamos a visitar nuestro anterior debate acerca de la cadena de valor del detallista. Ambos el negocio y ESO los organismos tpicamente siguen con mucho inters inte-gration de la cadena de valor. Los analistas de empresas de bajo nivel no pueden sentir mucho urgencia, pero esos en los rangos ms altos de gerencia se dan demasiado cuenta de la necesidad verse a travs del negocio para mejor evaluar funcin. Los numerosos datos que los proyectos del almacn tienen, canalizaron recientemente a la gerencia necesitan mejor comprender relaciones del cliente de una perspectiva unidas por los extremos. Obviamente, esto requiere que la habilidad considere consistentemente informacin del cliente a travs de los procesos, como
Citas, rdenes, la facturacin, los pagos, y el servicio al cliente. Aun si la vista de su man-agement no es tan noble, las usuarias comerciales ciertamente estn cansados de obtener informes que no hacen buena pareja de equipos o sistemas diferentes. ESO que los gerentes saben demasiado bien que la integracin se necesita para efectuar la entrega sobre las proTablas de datos almacenando. Muchos consideran eso su responsabilidad fideicomisaria para manejar los activos de informacin de la organizacin. Saben que no cumplen con sus responsabilidades si dejan autos sostenibles, poco integradas bases de datos proliferar. Adems de mejor ocuparse de las necesidades del negocio, el organismo de tecnologa de la informacin tambin saca provecho de integracin porque deja el organiza-tion mejor apalancar recursos escasos y gane eficiencias a travs del uso de componentes reusables. Afortunadamente, las personas que tpicamente estn ms interesadas en integracin tambin tienen la influencia organizativa necesaria y la econmica fuerza de voluntad para hacerlos ocurrir. Si no colocan un valor alto sobre la integracin, en ese entonces usted se est enfrentando a un mucho ms reto organizativo serio. No debera ser el responsi-bility exclusivo del gerente del almacn de datos para acumular consenso organizativo para una arquitectura integrada del almacn a travs de la cadena de valor. Lo poltico portuario en sorbo de alta gerencia tiene mucha importancia. Le quita al gerente del almacn de datos al gancho y coloca la carga del proceso decisorio sobre los hombros de la alta gerencia, donde pertenece. En Captulos 1 y 2 modelamos datos de varios procesos de la cadena de valor. Mientras el hecho separado pospone adentro se separan los centros de compras de datos representan los datos de cada proceso, la parte de modelos varias dimensiones comerciales comunes, a saber, pasan de moda, producto, y tienda. Lgicamente hemos representado esta dimensin participando en Cifra 3.6. Acostumbrar comparti, dimensiones comunes son absolutamente crticas para los centros de compras de datos de design-ing que pueden ser integrados. Nos dejan combinar medidas de funcin de procesos diferentes en un solo informe. Usamos lenguaje normalizado de consulta del multipaso para interrogar cada centro de compras de datos separadamente, y en ese entonces nosotros la juntura exterior que la averiguacin resulta basamos sobre un atributo comn de dimensin. Esta conexin, a menudo llamado taladro a travs, es franca si los atributos de la mesa
de dimensin son idnticos.
Almacene Dimensin
La Dimensin de Fecha El comercio al por menor de punto de venta El Hecho de Transaccin
Inventario Al Por Menor El Hecho de la Foto
El Inventario del Almacn El Hecho de Transaccin La Dimensin de Promocin
La Dimensin del Producto
La Dimensin del Almacn
La Dimensin del Vendedor
Figura 3.6
Compartiendo dimensiones entre procesos comerciales.
Los Datos Almacenan Arquitectura del Autobs Obviamente, construir el almacn de datos de la empresa en un paso es tambin desanima ing, pero construirle como derrotas espordicas de pedazos la meta primordial de consistencia. Para por largo tiempo xito del almacn de datos, necesitamos utilizar a un architected, acercamiento mental incre para construir el almacn de la empresa. El acercamiento que nosotros advo-cate somos los datos la arquitectura del autobs del almacn. El autobs de palabra es un viejo trmino de la industria elctrica de poder que es ahora usada comnmente en la industria de la computadora. Un autobs es una estructura comn para la cual todo est conectado y de cul todo deriva poder. El autobs en su computadora es una especificacin estndar de la interfaz que le deja enchufar una unidad de disco, CD-ROM, o cualquier nmero de otras cartas especializadas o los dispositivos. Por el estndar del autobs de la computadora, estos accesorios perifricos funcionan juntos y tilmente coexisten, si bien salieron a la luz a las veces de differ-ent por vendedores diferentes.
Definiendo una interfaz estndar del autobs para los datos ambiente del almacn, centros de compras separados de datos puede ser implementada por grupos diferentes en momentos diferentes. Los centros de compras separados de datos pueden ser taponados juntos y tilmente pueden coexistir si se le pegan al estndar. Si recordamos para la cadena de valor el diagrama en Figura 3.1, podemos visualizar muchos procesos comerciales taponando en el autobs del almacn de datos, tan ilustrados en Figura 3.7. Finalmente, todos los procesos de la cadena de valor de una organizacin crearn una familia de modelos dimensionales que comparten un set asimilativo de com-mon, conform dimensiones. Hablaremos ms acerca de dimensiones conformadas ms tarde en este captulo, sino por ahora, supondremos que el trmino quiere decir similar.
rdenes De Compra
Almacene Inventario
Almacene Ventas
Salga en citas Producto

Tienda Promocin
Almacn
Vendedor
Expedidor
Figura 3.7
Las dimensiones participativas a travs de la cadena de valor.
Los datos almacenan arquitectura del autobs le provee un acercamiento racional a decom-pose que los datos de la empresa almacenan planificar tarea. Durante la fase de arquitectura de duracin limitada, el equipo disea una suite maestra de hechos y dimensiones estndar que tienen interpretacin uniforme a travs de la empresa. Esto establece el armazn de arquitectura de datos. Entonces abordamos el imple-mentation de centros de compras separados de datos en los cuales cada iteracin de cerca se apega a la arquitectura. Como los centros de compras separados de datos vienen en lnea, calzan juntos como las pedazos de un acertijo. En algn punto, bastantes centros de compras de datos existen para cumplir la promesa de un almacn integrado de datos de la empresa. La arquitectura del autobs deja gerentes del almacn de datos tener lo mejor de ambos mundos. Tienen un armazn arquitectnico que pilotea el diseo global, pero el problema ha estado dividido en trozos del centro de compras de datos del tamao de un bocado que pueden ser implementados en realistas lmites de tiempo. Los equipos separados de desarrollo del centro de compras de datos siguen las lneas directivas de arquitectura al trabajar medianamente independientemente y asincrnicamente. La arquitectura del autobs es independiente de tecnologa y la plataforma de la base de datos. Todos los sabores de procesamiento de relaciones y en lnea y analtico (OLAP) - los centros de compras basados de datos pueden ser participantes llenos en los datos almacenan autobs si son diseados alrededor de hechos y dimensiones conformadas. Los almacenes de datos inevitablemente consistirn en numerosas mquinas separadas con sistemas operativos diferentes y los sistemas de gestin de base de datos (DBMSs). Si se disea coherentemente, compartirn una arquitectura uniforme de dimensiones conformadas y los hechos que los dejarn ser fundidas en un todo integrado.
Los Datos Almacenan Matriz del Autobs La herramienta que solemos crear, documentar, y comunicar la arquitectura del autobs es la matriz del autobs del almacn de datos, cul hemos ilustrado en Figura 3.8.
Las DIMENSIONES COMUNES
El NEGOCIO VA EN PROCESIN El Comercio Al Por Menor la Venta Al por Menor Inventara Entregas por Menor Las Entregas del Almacn de Inventario del Almacn Compran Pedidos Figura 3.8 Los datos de muestra almacenan matriz del autobs.
Trabajando en una moda tabular, diseamos los procesos comerciales del organi-zation como la matriz reme. Es importante recordar que identificamos los procesos comerciales apretadamente identificados con fuentes de datos, no los departamentos comerciales 's organiza tion. La matriz que las filas traducen a los centros de compras de datos basados en las actividades primarias de la organizacin. Empezamos por listar los centros de compras de datos que se deriv de un solo sistema primario de la fuente, comnmente conocido como centros de compras de datos de primeros niveles. Estos centros de compras de datos son complementos reconocibles para su fuente operacional.
Las filas de la matriz del autobs concuerdan con centros de compras de datos. Usted debera crear filas matriciales separadas si las fuentes son diferentes, los procesos son diferentes, o si la fila matricial representa ms que lo que razonablemente se abord en una sola iteracin de implementa-tion.
Una vez que es hora de empezar un desarrollo del centro de compras de datos proyecto, le recomendamos a start-ing la implementacin real con centros de compras de datos de primeros niveles porque minimicen el riesgo de poner una aplicacin para una implementacin que es demasiado ambiciosa. La mayor parte del riesgo del mono de fracaso proviene de arrancar con los dientes demasiado de los datos de carga de transformacin de extracto (ETL) escenificando el esfuerzo de diseo y de desarrollo. En muchos casos, los centros de compras de datos de primeros niveles proveen a usuarios de bastantes datos interesantes mantenerles feliz y quieto mientras los equipos del centro de compras de datos se mantienen trabajando sobre ms asuntos difciles. Una vez que completamente hemos enumerado la lista de centros de compras de datos de primeros niveles, en ese entonces podemos identificar centros de compras de la multifuente ms complicados como un segundo paso. Nos referimos a estos centros de compras de datos como centros de compras consolidados de datos porque tpicamente cruzan procesos comerciales. Mientras los centros de compras consolidados de datos son inmensamente beneficiosos para el orga-nization, son ms difciles de implemento porque el esfuerzo ETL aumenta alarmantemente con
cada fuente principal adicional que se integr en un solo modelo dimensional. Es medido enfocar la atencin en los centros de compras de datos de primeros niveles como bloques constructivos dimensionales antes de abordar la tarea de consolidarse. En algunos casos que el centro de compras consolidado de datos es en verdad ms que una unin simple de conjuntos de datos de los centros de compras de datos de primeros niveles. La rentabilidad es un ejemplo clsico de un centro de compras consolidado de datos dnde renta separada y los factores de costos estn combinados de centros de compras diferentes de proceso para proveer una vista completa de rentabilidad. Mientras un centro de compras de rentabilidad altamente granular es excitante porque provee la visibilidad en producto y el cliente son de beneficio a perfor-mance, no es definitivamente el primer centro de compras que usted debera tratar de implementar. Usted fcilmente podra ahogarse mientras pude tratar de escenificar todos los componentes de renta y costo. Si usted se ve absolutamente forzado a enfocar la atencin en rentabilidad como su primer centro de compras, en ese entonces usted debera empezar por ubicar costos sobre una base de regla general en vez de hacer el trabajo completo de sourcing todo el detalle costado subyacente. Aun As,
Tratar de tener consenso de organizacin sobre reglas de a dotacin le puede ser un showstopper de proyecto ddole la naturaleza sensitiva (y quiz la cartera entrando en colisin) de las dotaciones. Uno de los requisitos previos de proyecto, fuera del alcance de responsabilidades del equipo de proyecto del almacn, debera ser arreglo de negocios sobre la dotacin domina. Se puede decir sin temor a equivocarse que es mejor evitar ocuparse de las complejidades de rentabilidad hasta que usted tiene algunos datos almacenando xitos debajo de su cinturn. Las columnas de la matriz representan las dimensiones comunes usadas a travs de la empresa. Es a menudo de ayuda crear una lista asimilativa de dimensiones antes de rellenar la matriz. Cuando usted comienza con una lista grande de dimen-sions potencial, se convierte en un ejercicio creativo til para determinar si una dimensin dada posiblemente podra ser asociada con un centro de compras de datos. Las celdas sombreadas sealan que la columna de dimensin est relacionada con la fila comercial de proceso. La matriz resultante ser sorprendentemente densa. El miramiento a travs de las filas es revelador porque usted puede ver la dimensionalidad de cada centro de compras de datos a simple vista. Sin embargo, la potencia autntica de la matriz viene de mirar las columnas como bosquejan la interaccin entre los centros de compras de datos y las dimensiones comunes. La matriz es un dispositivo muy energtico para la planificacin y comunicacin. Aunque es relativamente franco disear las filas y las columnas, durante el proceso, definimos la arquitectura global de datos para el almacn. Podemos ver inmediatamente cules las dimensiones garantizan atencin especial dada su participacin en centros de compras mltiples de datos. Las ayudas de la matriz le dan prioridad cules dimen a sions le deberan ser abordados primero para la conformidad dado sus papeles conspicuos. La matriz nos deja comunicarnos de manera impresionante dentro y a travs de equipos del centro de compras de datos, as como tambin hacia arriba y hacia afuera a todo lo largo de la organizacin. La matriz es un sucinto producto a entregarse que visualmente transporta el plan entero de inmediato. Es un tributo para su simplicidad que la matriz puede estar usada eficazmente para directamente comunicar con tecnologa de la informacin de mayor categora y administracin de empresas.
Creando los datos la matriz del autobs del almacn es uno del deliv-erables adelantado ms importante de una implementacin del almacn de datos. Es un recurso hbrido que es en parte herramienta del diseo tech nical, una herramienta de administracin del proyecto de la parte, y una herramienta de comunicacin de la parte.
Huelga decir que es inaceptable construir centros de compras separados de datos que ignoran un armazn para atar los datos juntos. Los centros de compras aislados, independientes de datos son peores que simplemente una oportunidad perdida para anlisis. Le dan la va de entrada a los irreconciliables puntos de vista de la organizacin y ms all veneran los informes que no pueden ser comparados con el uno al otro. Los centros de compras independientes de datos se convierten en implementaciones del legado en su derecho; Por su misma existencia, bloquean la urbanizacin de un ambiente coherente del almacn.
Tan qu pasa si usted no comienza con una pizarra que almacena datos en blanco? Quiz varios centros de compras de datos se han construido ya sin hacer caso de una arquitectura de dimensiones conformadas. Puede rescatar usted sus toberas y las puede convertir a la arquitectura del autobs? Para contestar esta pregunta, usted debera primero comenzar con un aforamiento honesto de sus centros de compras poco integrados existentes de datos. Esto tpicamente conlleva a una serie de reuniones frontales con los equipos separados (incluyendo a los equipos clandestinos dentro de organizaciones comerciales) para determinar el boquete entre el ambiente actual y la meta architected de la organizacin. Una vez que el boquete es comprendido, usted necesita desarrollar un plan incremental para convertir los centros de compras de datos a la arquitectura de la empresa. El plan necesita estar vendido internamente. La tecnologa de la informacin de mayor categora y la administracin de empresas le deben comprender al estado actual de caos de datos, los riesgos de sin hacer nada, y los beneficios de moverse para distrito segn su juego planifican. La gerencia tambin necesita valorizarse que la conversin requerir un compromiso de soporte, recursos, y financiacin. Si un centro de compras existente de datos se basa en un diseo dimensional en buen estado, quiz usted simplemente puede trazar un mapa de una dimensin existente para una versin estndar. La mesa original de dimensin estara reconstruida usando un mapa de referencia cruzada. Asimismo, la mesa de hecho tambin necesitara ser reprocesada para reemplazar las llaves originales de dimensin con las llaves conformadas de dimensin. Por supuesto, si las Tablas originales y formadas en contra de dimensin contienen atributos diferentes, revise de las averiguaciones preexistentes es inevitable. Ms tpicamente, los centros de compras existentes de datos estn plagados de errores dimensionales de modelado ms all de simplemente la falta de adherencia para las dimensiones de standard-ized. En algunos casos, los datos de la tobera que el centro de compras ya tiene sobrevivieron a su vida til. Los centros de compras aislados de datos a menudo se construyen para un rea funcional especfico. Cuando los otros intentan apalancar el ambiente, tpicamente descubren que el centro de compras de datos fue implementado en un nivel impropio de granularidad y falta la dimensionalidad crucial. Al esfuerzo le hizo falta reconstruir con partes nuevas estos centros de compras de datos en la arquitectura del almacn puede exceder el esfuerzo para comenzar de nuevo de la nada. Como difcil como es admitir, los centros de compras de datos de la tobera a menudo tienen que ser clausurados y reconstruidos
en el armazn correcto de arquitectura del autobs.
Las dimensiones conformadas Ahora que usted comprende la importancia de la arquitectura del autobs, fomentemos explore lo estndar conform dimensiona ese saque como la piedra angular del autobs del almacn. Las dimensiones conformadas son cualesquier subconjuntos idnticos o estrictos de mathe-matical de la dimensin ms granular, detallada. Dimen-sions conformado tienen llaves consistentes de dimensin, nombres coherentes de la columna de atributo, definiciones coherentes de atributo, y valores coherentes (que traduce en etiquetas consistentes de informe y agrupamientos) de atributo. Las Tablas de dimensin no son formadas en contra si los atributos son designados diferentemente o contienen valores diferentes. Si un cliente o producto dimensiona es destacado en una manera poco conformada, entonces
Ya sea los centros de compras separados de datos no pueden ser usados juntos o, peor, intentos para usarlos juntos producirn resultados invlidos. Las dimensiones conformadas vienen en varios sabores diferentes. En las dimensiones ms bsicas y niveladas, conformadas signifique la cosa misma exacta con cada mesa posible de hecho para que estn unidas. La mesa de dimensin de fecha conectada para los hechos de ventas es idntica para la mesa de dimensin de fecha conectada para los hechos de inventario. De hecho, la dimensin conformada puede ser la misma mesa fsica dentro de la base de datos. Sin embargo, dado la complejidad tpica del environ-ment tcnico de nuestro almacn con plataformas mltiples de la base de datos, es ms probable que las dimensiones sean duplicadas sncronamente en cada centro de compras de datos. En uno u otro caso, las dimensiones de fecha en ambos centros de compras de datos tendrn el mismo nmero de filas, la misma llave aprecia, el mismo atributo designa, mismas definiciones de atributo, y mismos valores de atributo. Hay contenido coherente de datos, interpretacin de datos, y presentacin del usuario. La mayora de dimensiones conformadas estn definidas naturalmente en el nivel ms granular posible. El grano de la dimensin del cliente naturalmente ser el cliente individual. El grano de la dimensin del producto ser el nivel mnimo en el cual los productos son rastreados en los sistemas de la fuente. El grano de la dimensin de fecha ser el da individual. Algunas veces las dimensiones se necesitan en un nivel enrollado de granularidad. Quiz la dimensin de movimiento hacia arriba es requerida porque la mesa de hecho representa hechos agregados que son asociados con agregado las dimensiones. Esto sera el caso si tuvisemos una foto de inventario del peridico semanal adems de nuestra foto diaria. En otras situaciones, los hechos simplemente pueden ser generados por otro proceso comercial en un nivel ms alto de granularidad. Un proceso comercial, como las ventas, capta datos en el nivel atmico del producto, considerando pronosticar genera datos en el nivel de marca. Usted no podra compartir una sola mesa de dimensin del producto a travs de los dos dibujos tcnicos comerciales de proceso porque la granularidad es diferente. El producto y dimensiones de marca todava se conformaran si la mesa de marca fuera un subconjunto estricto de la mesa atmica del producto. Los atributos que son comunes para ambos la dimensin detallada y enrollada las Tablas, como la marca y
las descripciones categoriales, deberan estar etiquetadas, definidas, y preciadas idnticamente en ambas Tablas, tan ilustradas en Figura 3.9.
Las dimensiones de movimiento hacia arriba se conforman a la dimensin atmica de nivel de base si son un subconjunto estricto de esa dimensin atmica.
Podemos encontrar otros subconjuntos conformados legtimos de dimensin con Tablas de dimen-sion en el mismo nivel de granularidad. Por ejemplo, en el inventario dibujo tcnico con un chasquido disparado le aadimos los atributos suplementarios al producto y dimensiones de la tienda que no pueden ser tiles para el dibujo tcnico de transaccin de ventas. Las Tablas de dimensin de prod-uct usadas en estos dos centros de compras de datos todava se conforman si las llaves y
Las Dimensiones del Producto La descripcin del Producto de la Llave del producto (PK) El nmero de unidad de control de inventarios (la Llave Natural) Brand Description Subcategory Description Category Description Department Description Package Type Description Package Size El Peso Contento Grueso de Descripcin de Tipo de Dieta de Descripcin Las Unidades De Peso de Medida La Profundidad del Estante de Altura del Estante de Anchura del Estante de Tipo de Tiempo Antes de Caducar de Tipo de Almacenamiento y ms
Se conforma Brand Dimension Brand Key (PK) Marque Descripcin del Departamento de Descripcin de Categora Description Subcategory Description
Figura 3.9 subconjuntos de dimensin de movimiento hacia arriba Conforming.
Las columnas comunes son idnticas. Por supuesto, dado que el attrib-utes suplementario fuera limitado al centro de compras de datos de inventario, seramos incapaces de mirar a travs de los procesos usando estos atributos accesorios. Otra caja de dimensin conformada subsedimentndose ocurre cuando dos dimen-sions estn en el mismo nivel de detalle pero uno representa slo un subconjunto de filas. Por ejemplo, podemos tener una dimensin corporativa del producto que contiene datos para nuestro portafolio lleno de productos a travs de los mltiples dispares giros de negocios, como ilustrado en Figura 3.10. Los analistas en los negocios separados pueden querer mirar slo su subconjunto de la dimensin corporativa, restringidos para las filas del producto para su negocio. Usando un subconjunto de filas, no es estorbado con el set entero del producto para la organizacin. Por supuesto, el hecho que la mesa se asoci para esta dimensin del subsetted debe ser limitado al mismo subconjunto de productos. Si un usuario trata de usar una dimensin de subconjunto al acceder a una mesa de hecho consistente en el set completo del producto, l o ella puede encontrar desesperado averiguacin resulta. Tcnicamente, la integridad de referencia sera violada. Necesitamos ser conocedores de la oportunidad potencial para usuario la confusin o el error con dimensin rema subsedimentndose. Fomentaremos elaborados en subsets de dimensin cuando discutimos productos heterogneos en Captulo 9.
La dimensin conformada de fecha en nuestras ventas diarias y mensualmente pronosticar que sce-nario es un ejemplo nico de la fila y la columna dimensionan subsedimentarse. Obvi-ously, simplemente no podemos usar la misma mesa de dimensin de fecha por la diferencia en la granularidad de movimiento hacia arriba. Sin embargo, el mes que la dimensin puede consistir en estrictamente el mes la mesa de fecha de la seora de la limpieza de fin rema con la exclusin de todas las columnas que no aplican en la granularidad mensual. Las columnas excluidas incluiran columnas diarias de fecha como el nmero de fecha de descripcin, de da en indicador de poca, de da laborable /fin de semana, la semana terminando nmero de fecha, de da de fiesta del indicador, de da en un plazo del ao, y los otros. Usted podra considerar incluir un indicador de fin de mes en la dimensin diaria de fecha a facilitar creacin de esta mesa mensual. Las dimensiones conformadas estarn replegadas cualquier lgicamente o fsicamente a travs de fuera la empresa; Sin embargo, deberan forjarse una vez en la zona de estacionamiento. La responsabilidad para cada dimensin conformada est concedida en grupo llamamos la autoridad de dimensin. El autoridad de dimensin tiene a cargo definir, sosteniendo que, y publicar una dimensin particular o sus subconjuntos para todos los clientes del centro de compras de datos que lo necesitan. Se hacen responsables de escenificar los datos de dimensin de patrn oro. Finalmente, esto puede implicar sourcing de sistemas mltiples de opera-tional publicar una mesa completa de dimensin de calidad, alta.
Corporativo La Dimensin del Producto
Aparato Productos Vista Productos
La perforacin a travs de (conformndose) ambos productos del aparato y productos de la ropa requiere usar atributos comunes para ambos tipos. Figura 3.10 Conformando subconjuntos de dimensin en la misma granularidad.
La responsabilidad principal de la autoridad centralizada de dimensin es establecer, azogue principal, y publicar las dimensiones conformadas para todos los centros de compras de datos del cliente.
Una vez que un set de amo se conform las dimensiones han estado definidas para el apalancamiento de interlineacin, es sumamente importante que los equipos del centro de compras de datos en verdad usen estas dimensiones. El compromiso para usar conform dimensiones son ms que una decisin tcnica; Es una decisin comercial de poltica que es llave para hacer los datos de la empresa almacenar funcin. El acuerdo en dimensiones conformadas afronta mucho ms retos polticos que los obstculos tcnicos. Dados los asuntos polticos rodendolos, dimensiones conformadas deben ser soportados desde el principio por los niveles ms altos de la organizacin. Los ejecutivos deben enfatizar la importancia para sus equipos, aun si la dimensin conformada causa algunos acuerdos intermedios. El informtico en jefe tambin debera apreciar la importancia de mandato y dimensiones formadas en contra que cada equipo del centro de compras de datos tarda el compromiso en siempre usarlas.
Obviamente, las dimensiones conformadas requieren coordinacin de implementacin. Las modificaciones para los atributos existentes o la adicin de atributos nuevos deben ser revisadas con todos los equipos del centro de compras de datos utilizando la dimensin conformada. Usted tambin necesitar determinar su estrategia conformada de liberacin de dimensin. Se cambia a las dimensiones idnticas deberan estar replegadas sncronamente para todos los centros de compras asociados de datos. Este acercamiento de empujn para dimensionar la publicacin mantiene la consistencia requerida a travs de la organizacin. Ahora que hemos sermoneado acerca de la importancia de dimensiones conformadas, discutiremos la situacin donde no puede ser realista o necesaria para las dimensiones conformadas estab lish para la organizacin. Si usted es un conglomerado con sucursales que dieron vueltas ampliamente vari industrias,
puede haber poco punto en intentar integrarse. Si usted no quiere cruzarse venden los mismos clientes de una clase de negocio para otro, venden productos que se extienden a lo largo de giros de negocios, o le asigna los productos de mltiples giros de negocios a un solo vendedor, en ese entonces no puede tener sentido para intentar una arquitectura global del almacn de datos. All probablemente no es mucho percibido valor comercial para conformar sus dimensiones. La voluntad para buscar una definicin comn para producto o cliente es una prueba principal del tornasol para una organizacin tericamente intento sobre construir un almacn de datos de apalancamiento de interlineacin. Si el organismo tiene pocos deseos de convenir en definiciones comunes a travs de todos los centros de compras de datos, la organizacin no debera tratar de construir un almacn de datos que se extiende a lo largo de estos centros de compras. Usted estara mejor construyendo sep-arate, almacenes de datos autosuficientes para cada sucursal. En nuestra experiencia, mientras muchas organizaciones lo encuentran actualmente impos-sible de misin para combinar datos a travs de sus dispares giros de negocios, algn grado de integracin es tpicamente un objetivo final. En vez de echar adentro sus manos
El aire y declarando que posiblemente no puede estar terminado, nosotros sugerimos empezar abajo del camino hacia la conformidad. Quiz hay un puado de atributos que se conform a travs de los dispares giros de negocios. Aun si es meramente una descripcin del producto, la categora, y el atributo de clase de negocio que es comn para todo busi-nesses, este acercamiento de mnimo comn denominador es todava un paso en la direccin correcta. Usted no tiene que obtener todos sus negocios para convenir en todo relacionado para una dimensin antes de proceder.
Los hechos conformados Hasta ahora hemos hablado de la tarea central de establecer conformado dimen-sions para vincular nuestros centros de compras de datos. ste es 90 por ciento del esfuerzo de arquitectura de datos francos. Los dems esfuerzo ahonda en establecer conformado definiciones de hecho. Renta, ganancia, precios normales, costes estndar, medidas de calidad, medidas de satisfaccin del cliente, y otros indicadores cruciales (KPIs) de funcin son hechos que deben ser conformados. En general, los datos de la mesa de hecho no son duplicados explcitamente en centros de compras mltiples de datos. Sin embargo, si los hechos viven ms que una posicin, como adentro de primeros niveles y consolidados centros de compras, las ecuaciones y definiciones subyacentes para estos hechos deben ser lo mismo si deben ser llamadas lo mismo. Si estn etiquetados idnticamente, en ese entonces necesitan estar definidos en el mismo contexto dimensional y con las mismas unidades de medida de centro de compras de datos para centro de compras de datos.
Debemos ser disciplinados en nuestros datos nombrando costumbres. Si es imposible conformar un hecho exactamente, entonces usted le debera dar nombres diferentes a las interpretaciones diferentes. Esto hace eso menos probablemente que los hechos incompatibles sern usados en un clculo.
Algunas veces un hecho tiene una natural unidad de medida en una mesa de hecho y otra natural unidad de medida en otra mesa de hecho. Por ejemplo, el flujo de producto abajo de la cadena de valor por menor mejor puede ser medido en casos navieros en el almacn pero en unidades escudriadas en la tienda. Aun si todas las sideraciones dimensionales de contra han sido tomadas lleva las cuentas correctamente, sera difcil de usar estas dos incompatibles unidades de medida en un informe que se taladra a travs. La solucin usual para esta clase de problema debe referir al usuario a un factor de conversin enterrado en la mesa de dimensin del producto y esperar que el usuario pueda encontrar el factor de versin de contra y lo pueda usar correctamente. Esto es inaceptable en trminos de ambos gastos fijos y la vulnerabilidad para el error. La solucin correcta es acarrear el hecho en ambas unidades de medida a fin de que un informe fcilmente pueda hacer deslizar abajo de la cadena de valor, pick-ing fuera de los hechos comparables. Hablaremos ms acerca de las mltiples unidades de medida en Captulo 5.
Resumen El inventario es un proceso importante para medir y monitor en muchas industrias. En este captulo desarrollamos modelos dimensionales para los puntos de vista de tres complemen-taryes de inventario. Ya sea el peridico o atesoramiento le toman instantneas al modelo servir de un buen esbozo autnomo de inventario. La foto peridica sera escogida para sce-narios de inventario bastante corredor, continuamente reabastecido. La foto de atesoramiento servira para situaciones de inven-Tory antiguo, finitas con un comienzo definitivo y cesara. Ms aplicaciones de inventario de fondo querrn aumentar una o ambos de estos modelos con el modelo de transaccin. Introdujimos conceptos cruciales rodeando la arquitectura del autobs del almacn de datos y matriz. Cada proceso comercial de la cadena de valor, mantenido por un sistema de la fuente primario, se traduce en un centro de compras de datos, as como tambin una fila en la matriz del autobs. Los datos de los que los centros de compras comparten un nmero sorprendente compararon con un estndar, conformaron dimen-sions. Desarrollarse y pegrsele a la arquitectura del autobs es uno absoluto debe si usted tiene la intencin de construir un almacn de datos compuesto de un set integrado de centros de compras de datos.
Adquisicin EL CARBONO HAPTE R
tungsteno
La e explorar el proceso de adquisicin en este captulo. Este tema tiene splica de la industria cruzada obvia porque es aplicable para alguien que adquiere productos o ser-vice para ya sea el uso o la reventa. Adems de desarrollar varios modelos adquisitivos en este captulo, proveeremos cobertura de fondo de las tcnicas para manejar los cambios para nuestra dimensin posponen atributos. Mientras el attrib-utes descriptivo en dimensin pospone es relativamente esttico, estn sujetos a cambiar con el paso del tiempo. Las lneas de productos son reestructurado, causando jerarquas del producto para cambiar. La maniobra de Cu-tomers, causando su informacin geogrfica a cambiar. Los agentes comerciales son reorganizado, causando asignaciones del territorio para cambiar. Discutiremos varios acercamientos para ocuparnos de estos cambios inevitables en nuestras Tablas de dimensin.
el refuerzo de la cadena de valor mezclado versus dibujos tcnicos separados de transaccin lentamente cambiando tcnicas de dimensin, ambos bsico y adelantado
El Estudio De Casos de Adquisicin
Hasta ahora hemos estudiado corriente abajo ventas por menor y procesos de inventario en la cadena de valor. Comprendemos la importancia de disear la arquitectura del autobs del almacn de datos donde las dimensiones conformadas son usadas a travs de Tablas cntricas en proceso de hecho. En este captulo prolongaremos estos conceptos como trabajemos nuestro fur-ther de forma arriba de la cadena de valor para el proceso de adquisicin. 89
Para muchas compaas, la adquisicin es una actividad empresarial crtica. La adquisicin efectiva de productos en el precio correcto para la reventa es obviamente importante para los detallistas como nuestra cadena de la tienda de comestibles. La adquisicin tambin tiene implicaciones fuertemente primordiales para cualquier organizacin abrumadora que le compra los productos como materias primas a manufactureras. Las oportunidades de ahorros de costos significativas son asociadas con reducir el nmero de proveedores y negociar acuerdos con proveedores preferidos. La demanda planificando conduce eficiente administracin de materiales. Una vez que la demanda es forecasted, la meta de la adquisicin es para fuente el materials-ucts correcto en la manera ms econmica. La adquisicin implica una gran variedad de actividades de negociar contratos para publicar requisiciones de compra y pur-chase hace el pedido (POs) para rastrear recibos y autorizar pagos. La lista de follow-ing le da un mejor sentido de requisitos analticos comunes de una organizacin de adquisicin: cul materiales o productos es la mayora comprada frecuentemente? Cuntos vendedores suministran estos productos? En qu le pone precio a? En qu las unidades de medida (como masa o tambor)? considerando demanda a travs de la empresa (en vez de en una sola posicin fsica), hay oportunidades para negociar favorable fijacin de precios por proveedores de consoli-date, solo sourcing, o hacer garantizado c compran nuestros empleados de los vendedores preferidos o faldean los acuerdos negociados (el gasto inconformista) del vendedor? recibimos nosotros la negociada fijacin de precios de nuestros vendedores (la varianza de precio de compra del trecho de contra del vendedor)? cmo actan nuestros vendedores? Cul es el vendedor llena la tasa? Sobre la funcin de la entrega de tiempo? Las entregas retrasadas sobresaliendo? El por ciento de backordered de rdenes? La tasa de rechazo basada en inspeccin del recibo?
Las Transacciones de Adquisicin
Como comenzamos a penetrar a fuerza de trabajo el diseo de cuatro pasos proceso, primero decidimos que la adquisicin es el proceso comercial para ser modelada. Estudia atentamente el proceso y observa que un pequeo remolino de transacciones de adquisicin, como requi-sitions de compra, las rdenes de compra, enviando notificaciones, acusa recibo, y los pagos. Similares para el acercamiento ingerimos Captulo 3 con las transacciones de inventario, primero elegimos hacer una mesa de hecho del grano de una fila por la transaccin de adquisicin. Identificamos fecha de transaccin, producto, vendedor, plazos contractuales, y tipo de transaccin de adquisicin como nuestras dimensiones cruciales. Las unidades procuradas y la cantidad de transaccin son los hechos. El diseo resultante se parece mucho a la Figura 4.1.
El Hecho de Transaccin de Adquisicin La Dimensin de Fecha La adquisicin la Llave del Producto Transaction Date Key (FK) (FK)
La Dimensin del Producto
La Dimensin del Vendedor El nombre del Vendedor de la Llave del vendedor (PK) La Direccin de la Calle del Vendedor La Ciudad del Vendedor El ZIP del Vendedor El Estatus del Vendedor del Pas del Vendedor del Estado /provincia del Vendedor La Bandera de la Propiedad de Minora del Vendedor El Padre del Bono Corporativo del Vendedor y ms Contrato del Llave del vendedor (FK) Terms Teclea (FK) El nmero del Contrato de la Llave de Tipo de Transaccin de adquisicin (DD) (FK) La Cantidad de Transaccin de Adquisicin La Cantidad del Dlar de Transaccin de Adquisicin La Dimensin de Plazos Contractuales Los plazos contractuales de Descripcin de Plazos Contractuales de la Llave de plazos contractuales (PK) Mecanografan
La Dimensin de Tipo de Trasaccin de Adquisicin La categora de Tipo de Transaccin de Adquisicin de Descripcin de Tipo de Transaccin de Adquisicin de la Llave de Tipo de Transaccin de adquisicin (PK)
Figura 4.1 La mesa de hecho de adquisicin con transaccin mltiple determina el tipo sanguneo.
Si todava trabajamos para el mismo detallista de la tienda de comestibles, en ese entonces la fecha de transaccin y dimensiones del producto son las de la misma forma dimensiones conformadas nos desarrollamos originalmente en Captulo 2. Si estamos trabajando con adquisicin manufacturera, los productos de materias primas probablemente estn ubicados en una mesa de dimensin de materias primas de la separata en vez de incluidos en la dimensin del producto para productos de fcil venta. El vendedor, plazos contractuales, y dimensiones de tipo de transaccin de adquisicin son nuevos para este dibujo tcnico. La dimensin del vendedor contiene una fila para cada vendedor, junto con atributos descriptivos interesantes para soportar un varus-ety de vendedor analizan. La dimensin de plazos contractuales contiene una fila pues cada set generalizado de trminos hizo negociaciones con un vendedor, similar para el promo-tion dimensione en Captulo 2. La dimensin de tipo de transaccin de adquisicin nos deja grupo o el filtro sobre la transaccin determina el tipo sanguneo, como rdenes de compra. El nmero del contrato es una dimensin degenerada. Se usara para determinar que el volumen de negocio gui debajo de cada contrato otorgado sin competencia.
El Mltiplo Versus Single-Transaction Las Tablas de Hecho Como revisamos el diseo inicial del dibujo tcnico de adquisicin con usuarios comerciales, somos informados de varios detalles nuevos. Ante todo, nos enteramos de que los usuarios comerciales describen las transacciones diversas de adquisicin diferentemente. Para el busi-ness, la compra hace el pedido, enviando avisos, conocimientos de almacn, y pay-ments del vendedor son todo mirados como procesos separados y nicos. Rechaza tan varias de las transacciones de adquisicin en verdad venga de sistemas diferentes de la fuente. No hay solo sistema de adquisicin para fuente todas las transacciones de adquisicin. En lugar de eso, hay un sistema de compras que la compra de vides solicita y rdenes de compra, un sistema de almacenaje que provee
avisos de embarque y conocimientos de almacn, y un sistema de cuentas por pagar que trata con pagos del vendedor.
Ms all descubrimos tan varios de nuestros tipos de transaccin tiene dimen-sionality diferente. Los descuentos por ejemplo, tomados son aplicables para los pagos del vendedor pero no para los otros tipos de transaccin. De modo semejante, el nombre del dependiente del almacn que recibi los bienes en el almacn se aplica a los recibos pero no tiene sentido a otro sitio. Tambin nos enteramos de una coleccin variada de nmeros interesantes de control, como nmeros de cheque de la orden de compra y de pago, eso es creado en pasos diversos en el proceso de adquisicin. Estos nmeros de control son candidatos perfectos para dimensiones de degener-eat. Pues cierta transaccin mecanografa, ms de lo que un nmero de control puede tener aplicacin. Mientras buscamos desordenadamente en estos detalles nuevos, somos confrontados con una decisin del diseo. Deberamos hacer nosotros una mesa mezclada de hecho de transaccin de una dimensin de tipo de transaccin mirar todas nuestras transacciones de adquisicin juntos, o construimos Tablas separadas de hecho para cada tipo de transaccin? ste es un dilema comn del diseo que sale a la superficie en muchas situaciones transaccionales, no simplemente adquisicin. Como modeladores dimensionales, necesitamos hacer decisiones del diseo basadas en un thor-ough que comprensivo de los requisitos comerciales pes contra los trueques de las opciones disponibles. En este caso, no hay frmula simple para hacer la determinacin definitiva de ya sea usar un mltiplo solo o que el hecho pospone. Una sola mesa de hecho puede ser la solucin ms apropiada en algunas situaciones, mientras que las Tablas mltiples de hecho son ms correctas en otros. Estando afrontados con esta decisin del diseo, acudimos a las siguientes consideraciones para ayudarnos a clasificar cosas: primer, cules son los requisitos analticos de los usuarios? Como diseadores, nuestra meta es
Para reducir complejidad para presentar los datos en la forma ms efectiva Para los usuarios comerciales. Cmo la voluntad los usuarios comerciales ms comnmente ana Lisa esta informacin? Haga lo requerido analiza a menudo requiere transaccin mltiple Los tipos juntos, conducirnos a considerar a un soltero mezclaron mesa de hecho? O hace Ms seguido consideran solamente un solo tipo de transaccin en un anlisis,
Causndonos favorecer separata que el hecho pone sobre una mesa para cada tipo de transaccin?
hay procesos realmente comerciales nicos mltiples? En nuestro ejemplo de adquisicin, parece que eso comprar productos (la compra hace el pedido) es claramente dif ferent de recibir productos (los recibos). La existencia de nmeros separados de control pues cada paso durante el proceso es una pista que nos ocupamos de separan los procesos. Dadas esta situacin, nos inclinaramos por Tablas separadas de hecho. En Captulo 3 el ejemplo de inventario, todas las transacciones variadas de inventario claramente se relacionaron con un solo proceso de inventario, dando como resultado un solo propsito de la mesa de hecho. est los sistemas mltiples de la fuente involucrada? En nuestro ejemplo, tratamos con tres sistemas separados de la fuente: Comprando, almacenando, y
Cuentas por pagar. Otra vez, esto sugerira Tablas separadas de hecho. Las actividades de escenificacin de datos requirieron para fuente la sola mesa de hecho de transaccin de tres sistemas separados de la fuente es probablemente atemorizante. cul es la dimensionalidad de los hechos? En nuestro ejemplo de adquisicin descubrimos varias dimensiones tan aplicadas para algunos tipos de transaccin pero no para otros. Esto otra vez nos conduca a poner aparte Tablas de hecho. En nuestro hipottico estudio de casos que decidimos implementar transaccin mltiple que hecho pospone como ilustrado en Figura 4.2. Tenemos Tablas separadas de hecho para requisiciones de compra, rdenes de compra, avisos de embarque, conocimientos de almacn, y pagos de ven-dor. Logramos esta decisin porque los usuarios miran estos activi-tie como el negocio separado y bien definido va en procesin, los datos provienen de sistemas diferentes de la fuente, y hay dimensionalidad nica pues la transaccin diversas mecanografa. Las Tablas mltiples de hecho nos dejan proveer ms rico, ms atributos y dimen-sions descriptivo. Como progresamos de requisiciones de compra hasta los pagos del vendedor, recibimos en herencia dimensiones de fecha y degeneramos dimensiones de los pasos previos. El solo acercamiento de la mesa de hecho habra requerido generalizacin del etiquetado para algunas dimensiones. Por ejemplo, la fecha de la orden de compra y la fecha del recibo probablemente habran estado generalizadas para la fecha de transaccin. Asimismo, comprar a la sustancia qumica utilizada para hacer reaccionar a otra y el dependiente receptor se convertiran en empleado. En otra organizacin con requisitos comerciales diferentes, los sistemas de la fuente, y la dimensionalidad de datos, el soltero mesa mezclada de hecho pueden ser ms correctos. Tenemos por entendido que a las Tablas mltiples de hecho les ms tiempo pueden hacer falta ingeniarse y administrar porque hay ms Tablas para cargar, indexar, y agregar. Algunos sostendran la opinin que este acercamiento aumenta la complejidad de los datos escenificando procesos. De hecho, puede simplificar las actividades de escenificacin. Desde que los datos operacionales existen en sistemas separados de la fuente, necesitaramos mltiplo escenificando procesos en ya sea la panorama de la mesa de hecho. Cargar los datos en Tablas separadas de hecho probablemente estar menos complicado que tratar de integrar datos de las fuentes mltiples en una sola mesa de hecho.
La Adquisicin Complementaria Foto Seprese de la decisin estimando Tablas de hecho de transaccin de adquisicin, podemos encontrarnos con que tambin necesitamos desarrollar alguna suerte de mesa de hecho de la foto para completamente ocuparnos de las necesidades del negocio. Como sugerimos en Captulo 3, una foto de accumu-lating que cruza procesos sera sumamente til si se interes en el busi-ness monitorear movimiento del producto como procede a travs de la tubera de adquisicin (incluyendo la duracin o el atraso en cada etapa). Gastaremos ms tiempo sobre este tema en Captulo 5.
La Dimensin de Fecha La Dimensin del Vendedor La Dimensin del Empleado El Hecho de la Requisicin de Compra La llave de Fecha de solicitud (FK) Pidi Llave del Producto de la Llave de Fecha (FK) (FK) Los trminos de Contrato de la Llave del vendedor (FK) Teclea a (FK) Requested Por Nmero Crucial (DD) del Contrato (FK) La cantidad del Dlar de la Requisicin de Compra de Cantidad de la Requisicin de Compra de Nmero de la requisicin de compra (DD) La Dimensin del Producto La Dimensin de Plazos Contractuales La Dimensin Admitida por la Mayora de Condicin Descuente Dimensin Ocupada
El Hecho de la Orden de Compra La llave de Fecha de solicitud (FK) Pidi Llave del Producto de la Llave de Fecha de la Orden de Compra de la Llave de Fecha (FK) (FK) (FK) El vendedor los Plazos Contractuales Cruciales (FK) el Crucial (FK) Requested Por Nmero Crucial (DD) del Contrato de la Llave del Agente Comprador (FK) (FK) La cantidad de la Orden de Compra de Nmero de la Orden de Compra de Nmero de la requisicin de compra (DD) (DD) La Cantidad del Dlar de la Orden de Compra El Hecho Naviero de Avisos Enviando la Fecha de Notificacin la Llave de la Llave Ship Date (FK) (FK) La llave pedida (FK) del Producto de la Llave de Fecha (FK) El vendedor los Plazos Contractuales Cruciales (FK) el Crucial (FK) Requested Por Nmero Crucial (DD) del Contrato de la Llave del Agente Comprador (FK) (FK) El nmero de Orden de Compra de Nmero de la requisicin de compra (DD) (DD) Enviando Nmero de Notificacin (DD) Envi Cantidad El Hecho de Conocimientos de Almacn La fecha del conocimiento de almacn la Llave de la Llave Ship Date (FK) (FK) La llave pedida (FK) del Producto de la Llave de Fecha (FK) La llave del vendedor (FK) El dependiente recibido (FK) del Almacn de la Llave de Condicin (FK) El nmero de Orden de Compra de Nmero de la requisicin de compra (DD) (DD) Enviando Nmero de Notificacin (DD) Recibi Cantidad El Hecho de Pago del Vendedor La fecha de pago la Llave de la Llave Ship Date (FK) (FK) La llave del Producto de la Llave de Fecha del conocimiento de almacn (FK) (FK) Los trminos de Contrato de la Llave del vendedor (FK) Teclea (FK) Nmero Crucial Ocupado Rebajado en Precio (DD) (FK) del Contrato El nmero de Orden de Compra de Nmero de la requisicin de compra (DD) (DD) Enviando Nmero de Notificacin (DD) Las cuentas por pagar Comprueban Cantidad de Pago del Vendedor de Nmero (DD) La Cantidad del Dlar de Pago de la Red del Vendedor de Cantidad del Dlar de Descuento de Pago del Vendedor de Cantidad del Dlar de Pago de la Gruesa del Vendedor
Figura 4.2 procesin.
El mltiplo que el hecho pospone para la adquisicin va en
Lentamente Cambiando Dimensiones Hasta este punto hemos pretendido que cada dimensin es lgicamente abolladura de indepen de todas las otras dimensiones. En particular, se ha asumido que dimensiones son atemporales. Desafortunadamente, esto no es el caso en la vida real. Mientras los atributos de la mesa de dimensin son relativamente estticos, no se componen por siempre. Los atributos de dimensin cambian, si bien ms bien lentamente, con el paso del tiempo. Los diseadores dimensionales deben contratar a los diligenciadores proactivamente para ayudar al cambio apropiado que determinar maniobra estrategia. Simplemente no podemos tomar precipitadamente la conclusin que el negocio no se preocupa por cambios de dimensin solamente porque sus representantes no mencionaron eso durante el proceso de requisitos. Mientras suponemos que el rastrear preciso de cambios es innecesario, los usuarios comerciales pueden estar suponiendo que el almacn de datos los dejar ver el impacto de cada uno y cada cambio de dimensin. Si bien no podemos querer escuchar eso cambia rastreo es un artculo indispensable porque no andamos buscando cualquier trabajo adicional de desarrollo, vale obviamente ms recibir el mes-sage ms pronto en vez de ms tarde. Cuando necesitamos rastrear cambio, es inaceptable poner todo en la mesa de hecho o hacer cada dimensin dependiente en tiempo para ocuparse de estos cambios. Rpidamente se ripostaramos en una estructura normalizada en toda la extensin de la palabra con la prdida consiguiente de comprensibilidad e interrogaramos a perfor mance. En lugar de eso, nos aprovechamos del hecho que la mayora de dimensiones frisan constante con el paso del tiempo. Podemos conservar la estructura dimensional independiente con slo ajustes relativamente menores para hacerle frente a los cambios. Nos referimos a estas dimensiones casi constantes como lentamente cambiando dimensiones. Desde que la primera parte Ralph Kimball introdujo la nocin de lentamente cambiando dimensiones en 1994, algunos profesionales de tecnologa de la informacin en una bsqueda interminable a hablar en acronymese les han llamado SCDs. Para cada atributo en nuestras Tablas de dimensin, debemos especificar una estrategia para el cambio de han-dle. En otras palabras, cuando un valor de atributo cambia en el mundo operacional, cmo nos originaremos del cambio en nuestros modelos dimensionales? En la siguiente seccin describiremos tres tcnicas bsicas
para ocuparse de atributo cambia, junto con una pareja de casados acercamientos hbridos. Usted puede decidir que usted necesita utilizar una combinacin de estas tcnicas dentro de una mesa unidimensional.
Tipo 1: Sobrescriba el Valor Con el tipo 1 respuesta, meramente sobrescribimos el viejo valor de atributo en la fila de dimensin, reemplazando l con el valor corriente. En as haciendo, el atributo siempre refleja la asignacin ms reciente.
Supongamos que trabajamos para un detallista de electrnica. Los compradores de adquisicin estn aliados a lo largo de las mismas lneas departamentales como la tienda, as es que los productos que el ser adquiri se remangan en departamentos. Uno de los productos procurados es software de Intel-LiKidz. La fila existente en la mesa de dimensin del producto para Intel-LiKidz se parece a lo siguiente:
Producto El nmero de unidad de control de inventarios La Llave del Producto Descripcin Departamento (La Llave Natural)
12345
IntelliKidz 1.0
Educacin
ABC922-Z
Por supuesto, habra numerosos atributos descriptivos adicionales en la dimensin del producto, pero hemos abreviado la columna escorando dado nuestras restricciones del espacio de la pgina. Como intercambiamos opiniones ms temprano, una llave vicaria del producto es la llave de pri-mary de la mesa en vez de simplemente confiando en el nmero accionario de la unidad de cuido (la unidad de control de inventarios). Aunque hemos relegado el nmero de unidad de control de inventarios para ser un atributo del producto de ordinario, todava tiene un significado especial porque permanece la llave de nat-ural. A diferencia de todos los otros atributos del producto, la llave natural debe permanecer invi-olate. A todo lo largo del debate de todos los tres tipos SCD, suponemos que la llave natural de una dimensin permanece constante.
Supongo que una persona nueva que promueve para la venta decide que IntelliKidz debera ser movido del departamento del software de Educacin para el departamento de Estrategia el 15 de enero de 2002, en un esfuerzo para fomentar ventas. Con el tipo 1 respuesta, simplemente actualizaramos la fila existente en la mesa de dimensin con la descripcin nueva de depart-ment. La fila actualizada se parecera a lo siguiente:
Producto El nmero de unidad de control de inventarios La Llave del Producto Descripcin Departamento (La Llave Natural)
12345
IntelliKidz 1.0
Estrategia
ABC922-Z
En este caso, ninguna dimensin o llaves de la mesa de hecho fuera modificada cuando el departamento de IntelliKidz cambiado. Las filas en el hecho ponen sobre una mesa todava llave remisiva del producto 12345, sin tener en cuenta la posicin departamental de IntelliKidz. Cuando las ventas levantan vuelo siguiendo la maniobra para el departamento de Estrategia, no tenemos informacin para explicar la mejora de funcin porque lo histrico y datos ms recientemente cargados que ambos aparecen como si IntelliKidz siempre se ha arropado en la cama en la Estrategia. El tipo 1 la respuesta es el acercamiento ms simple para ocuparse de dimensin que el atributo cambia. La ventaja de tipo 1 es que es rpida y fcil. En la mesa de dimensin, meramente sobrescribimos el valor preexistente con la asignacin actual. La mesa de hecho se queda ilesa. El problema con un tipo 1 la respuesta
Es que perdemos todo lo que historia del atributo cambia. Desde sobrescribir oblitera valores de atributo de his-torical, quedamos solamente con los valores de atributo como existan hoy. Un tipo 1 la respuesta obviamente es apropiado si el cambio de atributo es un cor-rection. Tambin puede ser apropiado si no hay valor en mantener el viejo descrip-tion. Necesitamos que aporte del negocio titule retener el viejo valor de atributo; No deberamos hacer esta determinacin en la nuestra en un vac-uum de tecnologa de la informacin. Demasiado a menudo los equipos de proyecto destinan un tipo 1 respuesta como la respuesta predeterminada para de la que se ocup lentamente cambiando dimensiones y terminan completamente errar el tiro si el negocio necesita rastrear cambios histricos exactamente.
El tipo 1 la respuesta es fcil de implementar, pero no mantiene ninguna historia de anteriores valores de atributo.
Antes de que dejamos el tema de tipo 1 cambios, hay una cogida con holgura pasada por alto ms de la que usted debera darse cuenta. Cuando usamos un tipo 1 respuesta para ocuparnos de la reubicacin de IntelliKidz, cualquier agregaciones preexistentes basadas en el valor del departamento necesitar ser reconstruida. Los datos agregados deben continuar empatando para los datos atmicos detallados, donde eso ahora parece que IntelliKidz siempre se ha arropado en la cama en el departamento de Estrategia.
Tipo 2: Sume Una Fila de Dimensin Hicimos el reclamo ms temprano en este libro aqullas de las metas primarias del almacn de datos debi representar anterior historia correctamente. Un tipo 2 la respuesta es la tcnica predominante para soportar este requisito en lo que se refiere a lentamente cambiando dimensiones. Usando el tipo 2 la va de entrada, cuando el departamento de IntelliKidz cambi, publicamos una fila nueva de dimensin del producto para que IntelliKidz refleje el valor nuevo de atributo del departamento. Entonces tendramos dos filas de
dimensin del producto para Intel-LiKidz, como lo siguiente: Producto delDescripcin El nmero de Departamento unidad de control de inventarios
(La Llave Natural)
La Llave Producto 12345

25984
IntelliKidz 1.0
IntelliKidz 1.0
Educacin
Estrategia
ABC922-Z
ABC922-Z
Ahora vemos por qu no puede ser la llave de dimensin del producto la llave de nota natural de nmero de unidad de control de inventarios. Necesitamos dos llaves diferentes del substituto del producto para el cdigo de barras de unidad de control de inventarios misma o de phys-ical. Cada uno de las llaves del substituto de la separata identifican un perfil nico de atributo del producto que fue verdadero por un intervalo de tiempo. Con tipo 2 cambia, la mesa de hecho est otra vez ilesa. No volvemos a las filas histricas de la mesa de hecho para
Modifique la llave del producto. En la mesa de hecho, las filas para IntelliKidz antes de enero
15, 2002, estableceran referencias para llave del producto 12345 cuando el producto rod en lo El departamento de educacin. Luego del 15 de enero, las filas de hecho IntelliKidz tendra La llave del producto 25984 para reflejar la maniobra para el departamento de Estrategia hasta somos Forzado para hacer otro tipo 2 el cambio. Esto es lo que nosotros queremos decir cuando decimos ese Escriba 2 respuestas perfectamente la particin o la historia del segmento de la que dar razn lo Cambia.
Si constreimos slo sobre el atributo del departamento, en ese entonces nosotros mismo precisamente dif ferentiate entre las dos reseas del producto. Si constreimos slo en la descripcin de prod-uct, es decir, IntelliKidz 1.0, en ese entonces la averiguacin automticamente ir a traer ambas filas de dimensin del producto IntelliKidz y automticamente asciese para la mesa de hecho para la historia completa del producto. Si necesitamos contar el nmero de prod-ucts correctamente, entonces slo usaramos el atributo de la llave de nota natural de unidad de control de inventarios como la base de la cuenta discreta en vez de la llave vicaria. El natural campo de clave se convierte en un tipo de goma confiable que mantiene el tipo separado 2 registros por un producto de sin-gle juntos. Alternativamente, un indicador ms reciente de la fila podra ser otro atributo til de dimensin para dejar a los usuarios rpidamente constreir su averiguacin a slo las reseas actuales.
El tipo 2 la respuesta es la tcnica primaria para exactamente rastreando lentamente cambiando atributos de dimensin. Es sumamente poderoso porque la fila nueva de dimensin automticamente divide en partes historia en la mesa de hecho.
Ciertamente se sentira natural para incluir un fechador efectivo en una fila de dimen-sion con tipo 2 cambios. El fechador se referira al momento cuando los valores de atributo en la fila se vuelven vlidos o invlidos en el caso de fechas de vencimiento. Los atributos efectivos y de fecha de caducidad son menester en la zona de estacionamiento porque necesitaramos saber cul llave vicaria es vlida cuando cargamos registros histricos de hecho. En la mesa de dimensin, estos
fechadores son extras tiles que no son requeridas para la bsica particin de discos de historia. Si usted usa estos fechadores adicionales, slo recuerde que no hay necesidad para aprender de memoria tensin sobre la fecha de efectividad en la mesa de dimensin para tener la respuesta de derecho. ste es a menudo un punto de confusin en el diseo y el uso de tipo 2 lentamente cambiando dimensiones. Mientras el inclusivo el efectivo y el vencimiento salen en citas los atributos pueden sentirse confortables para los diseadores de la base de datos, deberamos ser conscientes de que la fecha de efectividad en la mesa de dimen-sion puede tener poco que ver con las fechas en la mesa de hecho. Tratando de constreir en la fila de dimensin la fecha de efectividad en verdad puede producir un resultado incorrecto. Quiz la versin 2.0 de software IntelliKidz ser soltada el 1 de mayo, 2002. Un cdigo operacional nuevo (y los datos correspondientes almacenan llave de surro-gate) de unidad de control de inventarios se le creara el producto nuevo. ste no es un tipo 2 cambio
Porque el producto es una entidad completamente fsica nueva. Sin embargo, si miramos una mesa de hecho para el detallista, no vemos una tan abrupta particin de discos de historia. La vieja versin 1.0 del software inevitablemente seguir vendida en tiendas luego del 1 de mayo de 2002, hasta que el inventario existente est agotado. La nueva versin 2.0 aparecer en los estantes el 1 de mayo y gradualmente reemplazar el viejo ver-sion. Habr un perodo de transicin donde ambas versiones del software le pasarn a las cajas registradoras en cualquier tienda dada. Por supuesto, el perodo del traslapo del producto se diferenciar de tienda para la tienda. Las cajas registradoras reconocern ambos cdigos de unidad de control de inventarios de oper-ational y no tendrn dificultad manejando la venta de ya sea versin. Si tuvisemos una fecha de efectividad en la fila de dimensin del producto, no nos atreveramos a aprender de memoria tensin en esta fecha para dividir en partes mercaderas en rebaja porque la fecha no tiene relevancia. An peor, usar tal restriccin aun nos puede dar la mala contestacin. No obstante, el compaero de cita efectivo de / vencimiento acua en la dimensin puede ser til para anlisis ms adelantado. Los compaeros de cita soportan divisin del tiempo muy precisa de la dimensin por s mismo. La fila que la fecha de efectividad es la primera fecha el descrip-tive de perfil es vlido. La fecha de caducidad de la fila estara un da menos de la fila la fecha efectiva para la siguiente asignacin, o la fecha que el producto estaba retirado del catlogo. Podramos determinar lo que el catlogo del producto se pareci a partir del 31 de diciembre de 2001, constriendo una averiguacin de la mesa del producto a recuperar todas las filas donde la fecha de efectividad de la fila para menos que o igualar hasta el 31 de diciembre de 2001, y la fecha de caducidad de la fila para ms gran que o el igual hasta el 31 de diciembre de 2001. Fomentaremos oportunidades de discos para apalancar las fechas efectivas de vencimiento y cuando ahondamos en el dibujo tcnico humano de recursos en Captulo 8. El tipo 2 la respuesta es la tcnica del caballo de tiro para soportar his-torically que consume anlisis atributos precisos. Esta respuesta perfectamente segmenta mesa de hecho su conservador porque las filas de hecho de precambio usan la llave del substituto de precambio. Otro tipo 2 la ventaja es que graciosamente podemos rastrear tantos cambios de dimensin segn se requiera. A diferencia del tipo 1 el acercamiento, no hay necesidad para volver a visitar agregacin preexistente pospone al usar el tipo 2 acercamiento.
Por supuesto, el tipo 2 la respuesta para lentamente cambiar dimensiones requiere el uso de llaves vicarias, pero usted las ya est usando de todas maneras, correcto? No es suffi-cient para usar la llave operacional subyacente con dos o tres dgitos de versin porque usted ser vulnerables para la lista entera de asuntos cruciales operacionales potenciales discutido en Captulo 2. Asimismo, es ciertamente desaconsejable anexar una fecha de efectividad para lo de otra manera la llave primaria de la mesa de dimensin para excepcionalmente identificar cada versin. Con el tipo 2 respuesta, creamos una fila nueva de dimensin con una columna sola nueva llave primaria para excepcionalmente identificar el perfil nuevo del producto. Esta sola columna clave primaria establece la conexin entre Tablas del hecho y de dimensin para un set dado de characteris-tic del producto. No hay necesidad para crear una confusa juntura secundaria basada en que el vencimiento efectivo o fecha, como hemos apuntado fuera.
Reconocemos que alguno de ustedes puede estar preocupado por la gerencia de llaves vicarias para soportar tipo 2 cambios. En Captulo 16 discutiremos un flujo de trabajos para substituto directivo lo teclea al acomodar tipo 2 cambia en ms detalle. Mientras tanto, queremos poner su mente algo descansadamente acerca de la carga administrativa. Cuando escenificamos Tablas de dimensin, recibimos a menudo una copia completa de lo ltimo, mximos datos de la fuente. Sera maravilloso si slo los cambios desde el ltimo extracto, o los deltas, fue dado a la zona de estacionamiento, pero ms tpicamente, la aplicacin de escenificacin tienen que encontrar las dimensiones cambiadas. Un campo por la comparacin del campo de cada fila de dimensin para identificar los cambios entre las versiones del ayer y el hoy seran sumamente difciles, especialmente si tenemos 100 atributos en una mesa de dimensin de la fila de varios millones. En vez de revisar cada campo para ver si algo ha cambiado, en lugar de eso computamos una suma de verificacin para la fila entera al mismo tiempo. Un algoritmo cclico de suma de verificacin de redundancia (la prueba de redundancia cclica) nos ayuda rpidamente a reconocer que una fila ancha, desordenada ha cambiado sin mirar cada uno de sus campos del componente. En nuestra zona de estacionamiento calculamos la suma de verificacin para cada fila en una mesa de dimen-sion y le aadimos a ella a la fila como una columna administrativa. En la siguiente carga de datos, computamos los CRCs en los registros entrantes para compararnos con los anteriores CRCs. Si los CRCs hacen juego, todos los atributos en ambas filas son idnticos; No hay necesidad para revisar cada campo. Obviamente, cualquier filas nuevas detonaran el cre-ation de una fila nueva de dimensin del producto. Finalmente, cuando encontramos una cambiada prueba de redundancia cclica, en ese entonces necesitaremos ocuparnos del cambio basado en nuestra estrategia de cambio de dimensin. Si estamos usando un tipo 2 respuesta para todos los atributos, en ese entonces slo crearamos otra fila nueva. Si estamos usando una combinacin de tcnicas, en ese entonces tendramos que mirar los campos en ms detalle para determinar la accin apropiada. Desde el tipo 2 la tcnica engendra las filas nuevas de dimensin, un lado de abajo de este acercamiento es crecimiento acelerado de la mesa de dimensin. Por lo tanto puede ser una tcnica de inappro-priate para dimensin pospone eso ya exceda un milln de filas. Discutiremos un acercamiento alternativo para maniobrar cambio en gran escala, Tablas de dimensin de la fila multimillonaria cuando exploramos la dimensin del cliente en Captulo 6.
Tipo 3: Sume Una Columna de Dimensin Mientras el tipo 2 la respuesta divide en partes historia, no nos deja asociar el valor nuevo de atributo con vieja historia de hecho o viceversa. Con el tipo 2 respuesta, cuando constreimos sobre = la Estrategia del Departamento, no veremos hechos de Intel-LiKidz desde antes del 15 de enero de 2002. En la mayora de los casos, esto es exactamente lo que queremos. Sin embargo, algunas veces queremos que la habilidad vea datos de hecho como si el cambio nunca ocurriese. Esto sucede ms frecuentemente con reorganizaciones de la fuerza de ventas. Los linderos de Dis-Trict han sido vueltos a dibujar, pero algunos usuarios todava quieren que la habilidad vea
Las ventas del hoy en trminos de lneas del distrito del ayer simplemente a ver cmo habran hecho debajo de la vieja estructura organizativa. Por algunos meses transicionales, puede haber un deseo para rastrear historia en trminos de los nombres nuevos del distrito e inversamente rastrear datos nuevos en trminos de los viejos nombres del distrito. Un tipo 2 la respuesta no soportarn este requisito, pero el tipo 3 la respuesta acude al rescate. En nuestro ejemplo del software, supongamos que hay una necesidad comercial legtima para rastrearlos a ambos los viejos y valores nuevos del atributo del departamento que ambos reenvan y atrs por un perodo de tiempo alrededor del cambio. Con un tipo 3 respuesta, no publicamos una fila nueva de dimensin, pero ms bien le aadimos una columna nueva a cap-ture el cambio de atributo. En el caso de IntelliKidz, alteramos la mesa de dimensin del producto para sumar un anterior atributo del departamento. Poblamos este col-umn nuevo con el valor existente (la Educacin) del departamento. Entonces tratamos el atributo de depart-ment como un tipo 1 respuesta, donde sobrescribimos reflejar el valor corriente (la Estrategia). Todas las informes existentes y averiguaciones cambian de decisin encima para la descripcin nueva del departamento inmediatamente, pero todava podemos escribir una crnica del viejo valor de depart-ment solicitando informacin usando el anterior atributo del departamento. El Producto del Producto unidad de control de inventarios
Teclee Descripcin
Anterior
El
nmero
de
El Departamento del Departamento (la Llave Natural)
12345
IntelliKidz 1.0 la Estrategia Educacin
ABC922-Z
Tipo 3 es apropiado cuando hay una necesidad fuerte para soportar dos puntos de vista de mundo simultneamente. Algunos diseadores llaman esto una realidad alterna. Esto a menudo ocurre cuando el cambio o la redefinicin es suave o cundo el atributo es una etiqueta aplicada por humano en vez de una caracterstica fsica. Aunque el cambio ha ocurrido, cabe todava lgicamente hacer como que no tiene. El tipo 3 la respuesta son distinguidos del tipo 2 respuesta porque ambos las descripciones actuales y anteriores pueden ser supuestos tan ciertos al mismo tiempo. En el caso de una reorganizacin de ventas, la gerencia puede querer que la habilidad traslape
y los resultados de ana-lyze usando ya sea asociacin de la organizacin de ventas por un perodo de tiempo. Otra variacin comn ocurre cuando sus usuarios quieren ver el valor corriente adems de retener el valor original de atributo en vez de lo anterior. El tipo 3 la respuesta es usado ms bien infrecuentemente. No sea conducido con engao a pensar que el nmero ms alto de tipo asoci con el tipo 3 respuesta seala que es el acercamiento preferido. Las tcnicas no se han replanteado adentro bien, mejores, y mejor costumbre ponen en secuencia. Hay un tiempo y lugar donde cada uno de ellos es la respuesta ms apropiada.
El tipo 3 la tcnica de dimensin lentamente cambiante nos deja ver datos nuevos e histricos de hecho por ya sea los valores nuevos o anteriores de atributo.
Un tipo 3 la respuesta es inapropiado si usted quiere rastrear el impacto de numerosos valores intermedios de atributo. Obviamente, hay limitaciones de implementacin seria y de uso para crear atributos que reflejan lo anterior menos 1, anterior menos 2, y anterior menos 3 estados de mundo, as es que prescindimos de la habilidad para ana-lyze estos valores intermedios. Si hay una necesidad para rastrear una mirada de cambios no previsibles, en ese entonces un tipo 2 la respuesta debera ser usado en lugar de eso en la mayora de los casos.
Hbrido Lentamente Cambiando Tcnicas de Dimensin En este pasaje discutiremos dos acercamientos hbridos que combinan bsico lentamente cambiando tcnicas de dimensin. Muchos profesionales de tecnologa de la informacin se vuelven enamorados de estas tcnicas porque parecen proveer lo mejor de todos los mundos. Sin embargo, el precio que pagamos para la mayor flexibilidad es a menudo mayor complejidad. Mientras algunos profesionales de tecnologa de la informacin quedan fcilmente impresionados por la flexibilidad elegante, nuestro negocio que los usuarios son igual de con holgura revueltos anticuados por la complejidad. Usted no debera perseguir estas opciones a menos que el negocio est de acuerdo que se necesitan para ocuparse de sus requisitos.
Los Cambios Previsibles con Las Capas Superpuestas Mltiples de Versin Esta tcnica es usada ms frecuentemente para tratar de realign-ments de la organizacin de ventas, as es que nos desviaremos de nuestro ejemplo IntelliKidz para presentar el concepto en una panorama ms realista. Considere la situacin donde una organizacin de ventas revisa el mapa de sus distritos de ventas elevados a cifras anuales. Sobre un perodo de 5 aos, la organizacin de ventas es reorganizada cinco veces. En la superficie, esto puede tener la apariencia de un buen candidato para un tipo 2 acercamiento, pero descubrimos entrevistas comerciales directas del usuario que tienen un ms set de complejo de requisitos, incluyendo las siguientes capacidades: reporte las ventas de cada ao usando el mapa del distrito por ese ao.
reporte las ventas de cada ao usando un mapa del distrito desde un ao diferente arbitrario. el informe un intervalo arbitrario de ventas de aos usando un solo mapa del distrito desde cualquier ao escogido. La versin ms comn de este requisito lo hara
Deba reportar el intervalo completo de datos de hecho usando el mapa actual del distrito.
No podemos poner la direccin en este set de requisitos con un tipo estndar 2 respuesta porque divide en partes historia. Un ao de datos de hecho slo puede ser reportado usando el mapa asignado en aquel momento con un tipo 2 acercamiento. Los requisitos no pueden ser por los que se responsabiliz con un tipo estndar 3 respuesta porque queremos soportar ms que dos mapas simultneos.
La Dimensin del Agente Comercial La Direccin del Agente Comercial de Nombre del Agente Comercial de la Llave del Agente Comercial ... el Distrito Actual del Distrito 2001 El distrito 2000 El distrito 1999 El distrito 1998 y ms Creo 4.3 la Muestra la dimensin la mesa con capas superpuestas mltiples de versin.
En este caso nos aprovechamos del cliente habitual, la naturaleza previsible de estos cambios por geralizing el tipo 3 el acercamiento para tener cinco versiones del atributo del distrito para cada agente comercial. La dimensin del agente comercial incluira el attrib-utes mostrado en Figura 4.3. Cada fila de dimensin del agente comercial incluira todas anteriores asignaciones del distrito. El usuario comercial podra elegir rodar arriba de los hechos de ventas con cualquier de los cinco mapas del distrito. Si un agente comercial fuera contratado en 2000, la dimensin atribuye para 1998 y 1999 contendran valores algo como No Se Aplica. Designamos la asignacin ms reciente tan el Distrito Actual. Este atributo ser usado ms frecuentemente; No queremos modificar nuestros informes y averiguaciones existentes para acomodar el cambio del ao siguiente. Cuando los distritos son vueltos a dibujar despus, alteraramos la mesa para sumar un distrito 2002 atributo. Poblaramos esta columna con los valores actuales del distrito y entonces sobrescribiramos el atributo actual con las 2003 asignaciones del distrito.
Los Cambios Imprevisibles con La Sola Capa Superpuesta de Versin Este acercamiento final tiene importancia si usted ha recibido instrucciones de conservar cambios de atributo imprevisibles que rodean accu-racy histrico mientras soportando la habilidad para reportar datos histricos segn los valores corrientes. Ninguna de lo estndar las tcnicas de dimensin lentamente cambiantes permiten este requisito independientemente. En el caso de la dimensin del producto del detallista de electrnica, tendramos dos atributos del departamento en cada fila. La columna actual del departamento representa la asignacin actual; La columna histrica del departamento representa lo his-torically valor preciso de atributo del departamento.
Cuando el software IntelliKidz es procurado inicialmente, la fila de dimensin del producto se parecera a lo siguiente:
Unidad de control de inventarios Producto Teclee Producto Descripcin La corriente Departamento Histrico Departamento El nmero (La Llave Natural)
12345
IntelliKidz 1.0 Educacin Educacin ABC922-Z
Cuando los departamentos son reestructurados e IntelliKidz es movido al departamento de Strat-Egy, usaramos un tipo 2 respuesta para captar el cambio de atributo publicando una fila nueva. En esta fila nueva de dimensin para IntelliKidz, el departamento actual ser idntico para el departamento histrico. Para todas las instancias previas de IntelliKidz la dimensin rema, el atributo actual del departamento ser sobre-escrito para reflejar la estructura actual. Ambas filas IntelliKidz identificaran el departamento de Estrategia como el departamento actual.
El producto del Producto de unidad de control de inventarios La Histrico El nmero

Teclee Descripcin
corriente
El Departamento del Departamento (la Llave Natural)
12345
25984
IntelliKidz 1.0 la Estrategia Educacin

IntelliKidz 1.0 la Estrategia Estrategia
ABC922-Z
ABC922-Z
De esta manera podemos usar el atributo histrico para segmentar historia y ver hechos segn el departamental movimiento hacia arriba en aquel momento. El trmino medio mientras, el atributo actual enrolle todos los datos histricos de hecho para producto teclea 12345 y 25984 en la asignacin actual del departamento. Si IntelliKidz fuera entonces movido en el departamento Crtico del software de Manera de Pensar, nuestra mesa del producto se parecera a lo siguiente: El nmero de unidad de control de inventarios (la
Producto
Teclee
Producto
Descripcin
La corriente Histrico
Departamento Departamento
12345
25984
IntelliKidz 1.0 Crtico

Pensando IntelliKidz 1.0 Crtico Pensando
Educacin
Estrategia
Llave Natural) ABC922-Z

ABC922-Z
31726
IntelliKidz 1.0
Crtico Pensando
Crtico Pensando
ABC922-Z
Con este acercamiento hbrido, publicamos una fila nueva para captar el cambio (mecanografe
2) Y suma una columna nueva para rastrear la asignacin actual (tipo 3), dnde
Los subsiguientes cambios son manejados como un tipo 1 respuesta. Alguien una vez sug gested que referimos a este acercamiento del combo como el tipo 6 (2 + 3 + 1). Este tech-nique nos deja rastrear los cambios histricos exactamente al tambin soportar la habilidad para enrollar historia basada en las asignaciones actuales. Podramos fomentar embellece (y se intrinca) esta estrategia por las estructuras estticas adicionales de movimiento hacia arriba del departamento de respaldo, adems del departamento actual, como los atributos separados. Otra vez, mientras esta tcnica poderosa puede estar naturalmente atrayendo a algunos lectores, es importante que siempre consideramos la perspectiva de los usuarios como nos esforzamos por lograr un balance razonable entre la flexibilidad y la complejidad.
Ms Rpidamente Cambiando Dimensiones En este captulo en el que hemos enfocado la atencin los cambios tpicamente ms bien lentos, evolucionistas para nuestras Tablas de dimensin. Qu sucede, sin embargo, cundo la tasa de cambio acelera? Si un atributo de dimensin cambia mensualmente, en ese entonces ya no nos ocupamos de una dimensin lentamente cambiante que puede ser maniobrada que se razona hbilmente con las tcnicas acabadas de discutir. Un acercamiento poderoso para manipular ms rpidamente cambiar dimensiones es suspender de pronto estos atributos rpidamente cambiantes en uno o ms separan dimensiones. En nuestra mesa de hecho entonces tendramos dos llaves extranjeras uno para la mesa primaria de dimensin y otro para el atributo (s) rpidamente cambiante. Estas Tablas de dimensin seran associ-ated con uno otro cada vez que metemos una fila en la mesa de hecho. Permanezca afinado pues ms sobre este tema cuando cubrimos cliente dimensionan en Captulo 6.
Resumen En este captulo discutimos varios acercamientos para maniobrar datos de adquisicin. La funcin de adquisicin eficazmente directiva puede tener un impacto principal sobre la ltima lnea de una organizacin.
Tambin introdujimos varias tcnicas a ocuparnos de cambios para nuestros atributos de la mesa de dimensin. Las respuestas lentamente cambiantes se extienden de meramente sobrescribir el valor (tipo 1), para aadirle una fila nueva a la mesa de dimensin (tipo 2), para el acercamiento menos frecuentemente usado en el cual le aadimos una columna a la mesa (tipo 3). Tambin intercambiamos opiniones varios poderoso, si bien acercamientos ms complicados, hbridos que combinan las tcnicas bsicas.
La Gerencia de Orden EL CARBONO HAPTE R
oh
La gerencia del rder consiste en varios procesos comerciales crticos, incluyendo orden, el embarque, y trmite de facturas. Estos procesos engendran gran cantidad de mtrica comercial importante, como el volumen de ventas y la renta de la factura, ese son indicadores cruciales de per-formance para cualquier organizacin que vende productos o servicios para los otros. De hecho, estos la mtrica de la fundacin son tan cruciales que los datos que el almacn mancomuna ms frecuentemente abordan uno de los procesos administrativos de orden para su implementacin inicial del almacn de datos. Claramente, los temas en este caso estudian trascienden linderos de la industria. En este captulo exploraremos varias transacciones diferentes de la gerencia de orden, incluyendo las complicaciones y caractersticas comunes que usted podra encontrar cundo dimensionalmente modelando estas transacciones. Nos elaboraremos en lo con-cept de una foto de atesoramiento para analizar la tubera de cumplimiento de orden de orden inicial a travs de la liberacin para confeccionar, en inven-Tory acabado de bienes, y finalmente para embarque del producto y la facturacin. Cerraremos el captulo asemejndose y contrastando los tres tipos de Tablas de hecho: Transaccin, foto peridica, y acumulando foto. Pues cada uno de estos que la mesa de hecho escribe, tambin discutiremos el manejo de requisitos
que almacenan tiempo real.

ordena dibujo tcnico de transaccin las consideraciones de normalizacin de la mesa de hecho la caracterizacin de papeles de dimensin de fecha
107
ms en dimensiones del producto Enve a facturar para las consideraciones de dimensin del cliente las dimensiones de trastos viejos las monedas circulantes mltiples y las unidades de medida el manejo de encabezado y hechos de rubro contable con granularidad diferente facturando dibujo tcnico de transaccin con hechos de ganancias y prdidas la tubera de cumplimiento de orden como dibujo tcnico de la foto de atesoramiento los clculos de atraso la comparacin de transaccin, foto peridica, y acumularse le toma instantneas a las Tablas de hecho el especial divide en partes para soportar la demanda pues acercarse datos de tiempo real almacenando
La Introduccin para Mandarle A Gerencia Si tomamos una mirada ms cercana en la funcin de la gerencia de orden, vemos que es implcita de una serie de procesos comerciales. En su forma ms simplista, podemos visualizar un subconjunto de la matriz del autobs del almacn de datos que se parece a la Figura 5.1. Como vimos en tiempo atrs captulos, los datos almacenan matriz del autobs de cerca corre sponds para la cadena de valor de la organizacin. En este captulo enfocaremos specifi-cally sobre la orden y la factura rema de la matriz. Tambin describiremos una mesa de hecho de la foto de atesoramiento que combina datos de man-agement mltiple de orden va en procesin.
Cita Embarques de rdenes Facturando Figura 5.1 El subconjunto de matriz del autobs del almacn de datos para gerencia de orden va en procesin.
La Dimensin de Fecha de Orden La fecha de Orden de la Llave de Fecha de orden (PK) El Da de Fecha de Orden de Semana El Mes de Fecha de Orden y ms La Dimensin Pedida de Fecha del Barco Ship Date Key pedido (PK) Pidi la Fecha Ship Ship Date Day Pedido de Semana El Mes Pedido de Fecha del Barco y ms El Hecho de Transaccin de Orden Ordene la Fecha la Llave del Producto de la Llave de la Llave Requested Ship Date (FK) (FK) (FK) El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) La cantidad de pedido de Nmero de la Lnea de Orden de nmero de orden (DD) (DD) La Cantidad Vulgar del Dlar de Orden La Cantidad del Dlar de Descuento de Trato de Orden La Cantidad Neta del Dlar de Orden El Barco del Cliente de Dimensin del Producto para la Dimensin del Agente Comercial de Dimensin La Dimensin de Trato
Figura 5.2
La mesa de hecho de transaccin de orden.
Ordene Transacciones El primer proceso que exploraremos es transacciones de orden. Como las compaas han crecido a travs de la adquisicin, a menudo se encuentran con sistemas operacionales mltiples de proceso de transacciones de orden en la organizacin. La existencia de sistemas mltiples de la fuente a menudo crea un grado de urgencia para integrar los resultados de dis-parate en el almacn de datos en vez de en espera de la por largo tiempo integracin aplicativa. La granularidad natural para una mesa de hecho de transaccin de orden es una fila para cada rubro contable sobre una orden. Los hechos asociados con este proceso tpicamente incluye la cantidad de pedido, cantidad vulgar extendida del dlar de orden, la cantidad del dlar de descuento de cantidad, y la cantidad neta extendida (que sea igual a la cantidad vulgar de orden menos los descuentos) del dlar de orden. El dibujo tcnico resultante se parecera mucho a la Figura 5.2. La Normalizacin de Hecho En vez de almacenar una lista de hechos, as como en Figura 5.2, algn faltante de diseadores para fur-ther normalice la mesa de hecho tan ese hay una cantidad sola, genrica de hecho, junto con una dimensin que identifica el tipo de hecho. El hecho que la dimensin indicara ya sea eso es la cantidad de orden de vulgar cantidad, de descuento de cantidad, o alguna otra medida. Esta tcnica puede tener sentido cuando el set de hechos est escasamente poblado para un hecho dado la fila y ninguna computacin se hace entre los hechos. Hemos usado esta tcnica para ocuparnos de confeccionar datos de prueba de qual-ity, donde los hechos varan ampliamente a merced de la prueba transmitida. Sin embargo, generalmente resistimos el deseo a fomentar normaliza la mesa de hecho. Como vemos con datos de rdenes, los hechos usualmente no estn escasamente poblados dentro de una fila. En este caso, si debisemos normalizar los hechos, multiplicaramos el nmero de filas en la mesa de hecho por el nmero de hecho determina el tipo sanguneo. Por ejemplo, suponga que comenzamos con 10
millones filas de la mesa de hecho de la lnea de orden, cada uno con seis llaves y cuatro
Hechos. Si normalizsemos los hechos, sacaramos en limpio 40 millones de alborotos de hecho, cada uno con siete llaves y un hecho. Adems, si realizamos cualquier funcin de aritmtica entre los hechos (como el importe del descuento como un porcentaje de cantidad de orden de la gruesa), est distante ms fcil si los hechos estn en la misma fila porque el lenguaje normalizado de consulta dificulta realizar una proporcin o una diferencia entre los hechos en filas diferentes. En Captulo 13 haremos un reconocimiento de una situacin donde una dimensin de hecho hace ms sospechar. La Caracterizacin De Papeles de Dimensin A esta hora todos nosotros sabemos que una dimensin de fecha se encuentra en cada mesa de hecho porque tenemos siempre a la vista funcin con el paso del tiempo. En un hecho veteado en transaccin la mesa, la columna primaria de fecha sea la fecha de transaccin, como la fecha de orden. Algunas veces tambin descubrimos otras fechas asociadas con cada transaccin, como la fecha pedida del barco para la orden. Cada uno de las fechas deberan ser una llave extranjera en la mesa de hecho. Sin embargo, simplemente no podemos adjuntar estas dos llaves extranjeras a la misma mesa de dimensin de fecha. El lenguaje normalizado de consulta interpretara una juntura tan simultnea de doble va tan requeridora ambos las fechas para ser idntica, lo cual no lo es muy probablemente. Si bien literalmente no podemos unir para una sola mesa de dimensin de fecha, podemos construir y podemos administrar una sola mesa de dimensin de fecha entre bastidores. Nosotros cre-eat la ilusin de dos Tablas independientes de fecha usando puntos de vista. Tenemos el cuidado excepcionalmente etiquetar las columnas en cada uno de los puntos de vista de lenguaje normalizado de consulta. Por ejemplo, el mes de orden debera estar excepcionalmente etiquetado para distinguirlo desde mes pedido del barco. Si no practicamos bien gobierno de la casa de datos, podramos encontrarnos en la posicin incmoda de no pudiendo distinguir las columnas cuando ambos son metidos sin razn en un informe. Como brevemente describimos en Captulo 2, usted definira la fecha de orden y los puntos de vista pedidos de fecha de orden como sigue:
CREE VISTA ORDER_DATE (ORDER_DATE_KEY, ORDER_DAY_OF_WEEK, ORDER_MONTH ...) COMO DATE_KEY SELECTO, DAY_OF_WEEK, MES,. . . DESDE la FECHA Y CREE VISTA REQ_SHIP_DATE (REQ_SHIP_DATE_KEY, REQ_SHIP_DAY_OF_WEEK, REQ_SHIP_MONTH ...) COMO DATE_KEY SELECTO, DAY_OF_WEEK, MES,. . . DESDE la FECHA
Nosotros ahora tenemos dos dimensiones nicas de fecha que pueden ser usadas como si fueron inde-pendent con restricciones completamente inconexas. Nos referimos a esto como la caracterizacin de papeles porque la dimensin de fecha simultneamente sirve para papeles diferentes en una sola mesa de hecho. Veremos ejemplos adicionales de dimensin que la caracterizacin de papeles roci a todo lo largo de este libro.
La caracterizacin de papeles en un almacn de datos ocurre cuando una sola dimensin simultneamente aparece varias veces en la misma mesa de hecho. La dimensin subyacente puede existir como una sola mesa fsica, pero cada uno de los papeles deberan ser presentados a las herramientas de acceso de datos en una vista separadamente designada.
Para manejar las fechas de mltiplo, algunos diseadores estn tentados de crear una sola mesa de fecha con una llave por cada fecha nica de orden y com-nation pedido de fecha del barco. Esta va de entrada se cae a pedazos en varias partes delanteras. Primer, nuestro sim-ple limpio y que la fecha diaria la mesa con aproximadamente 365 filas por el ao se soplara en el tamao si necesit maniobra todas las combinaciones de fecha. En segundo lugar, tal mesa de fecha de combina-tion ya no se conformara a nuestras otras dimensiones de fecha frecuentemente usadas y diarias, semanales, y mensuales.
La Dimensin del Producto Vuelta a Visitar Una dimensin del producto ha participado de cada uno del sented de sainetes de estudio de casos tan lejano en este libro. La dimensin del producto es una de la dimensin ms comn y ms importante pospone que usted encontrar en un modelo dimensional. La dimensin del producto describe el portafolio completo de productos vendidos por una compaa. En la mayora de los casos, el nmero de productos en el portafolio resulta ser sorprendentemente grande, al menos de perspectiva de una persona ajena. Por ejemplo, un fabricante de Estados Unidos prominente de comida del perro y del gato rastrea casi 20,000 variaciones de manu-facturing de sus productos, incluyendo productos por menor todo el mundo (o cada perro y cada gato) est familiarizado, as como tambin los numerosos productos especializados vendidos a travs de anuncio publicitario y los canales del veterinario. Hemos
trabajado con fabricantes de bienes duraderos que vende literalmente millones de configuraciones nicas del producto. La mayora de dimensin del producto pospone parte las siguientes caractersticas: Las numerosas columnas descriptivas verbosas. Para fabricantes, no es inusual mantener 100 o ms descriptores acerca de los productos que venden. Los atributos de la mesa de Dimen-Sion naturalmente describen la fila de dimensin, no varan por la influencia de otra dimensin, y son virtualmente perseverantes con el paso del tiempo, aunque como nosotros acabamos de discutir en Captulo 4, algunos atributos cambian lentamente con el paso del tiempo. Uno o ms jerarquas de atributo adems de muchos atributos no jerrquicos. Tambin limita para pensar acerca de productos tan perteneciente a una sola jerarqua. Los productos tpicamente enrollan segn hierar-chies definido mltiple. Todos los datos jerrquicos deberan replantearse en un soltero aplastado,
La mesa de dimensin del producto del denormalized. Resistimos a crear subTablas normalizadas del snowflaked para la dimensin del producto. Los costos de una presentacin ms plegada en la salida de computadora en microfilm y el intradimension ms lento haciendo una lectura ligera funcin pesan ms que las ganancias de ahorros de almacenamiento mnimas. Es engaoso pensar acerca de hacer una lectura ligera en una mesa pequea de dimensin, donde todas las relaciones pueden ser imaginadas o visualizadas. Las Tablas autnticas de dimensin del producto tienen miles de entradas, y el usuario tpico no sabe las relaciones ntimamente. Si hay 20,000 comidas del perro y del gato en la dimensin del producto, no es demasiado til pedir una lista fcilmente bajable de las descripciones del producto. Sera esencial, en este ejemplo, a tener la capacidad de constreir sobre un atributo, como el sabor, y en ese entonces otro atributo, como el tipo del paquete, antes de tratar de exhibir los listados de descripcin del producto. Echo de ver que las primeras dos restricciones no fueron extradas estrictamente de una jerarqua del producto. Cualquier de los atributos del producto, sin tener en cuenta si pertenece a una jerarqua, debera ser usado libremente para profundizar y arriba. De hecho, la mayor parte del attrib-utes en una mesa grande del producto es low-cardinality auto sostenible atribuye, no parte de jerarquas explcitas. La existencia de un amo operacional del producto auxilia en el mantenimiento de la dimensin del producto, pero un nmero de transformaciones y los pasos administrativos deben ocurrir para convertir el archivo maestro operacional en la mesa de dimensin, inclusivos: Remap la llave operacional del producto para una llave vicaria. Como discutimos en Captulo 2, este ms pequeo, ms llave de la juntura eficiente se necesita para evitar descalabro causado por el uso duplicado de la llave operacional del producto con el paso del tiempo. Tambin podra haber que integrar sourced de informacin del producto de sistemas operacionales diferentes. Finalmente, como acabamos de aprender en Captulo 4, la llave vicaria se necesita para rastrear cambiar atributos del producto en los casos donde el sistema de oper-ational no ha generado una llave maestra nueva del producto. Sume legibles del texto instrumentos de cuerda para aumentar o reemplazar cdigos numricos en el amo del producto de opera-tional. No aceptamos la excusa que el businesspeople est familiarizado con los cdigos. El nico
businesspeople de razn est familiarizado con cdigos son que se han visto forzado aes usarlos! Recuerde que las columnas en una dimensin del producto la mesa son la fuente de la suela de con-straints de averiguacin y el informe etiqueta, as es que los contenidos deben ser legibles. Tenga a la vista que las abreviaturas secretas son tan malas como cdigos numricos categricas; Tambin deberan ser aumentadas o reemplazadas con texto legible. El mltiplo abrevi cdigos en un solo campo deberan ser expandidos y debera dividirme en campos discretos. La calidad asegura todos los del texto instrumentos de cuerda para asegurar que no hay faltas de ortografa, valores imposibles, o versiones diferentes cosmetically del mismo atributo. Adems de mtodos automatizados, una trastienda simple
La tcnica para sonrojarse fuera de menores faltas de ortografa de valores de atributo es slo ordenar los valores bien definidos del atributo y recorrer con la mirada la lista. Las ortografas que difieren por un solo carcter usualmente ordenarn junto a cada otro y podrn ser encontradas con una tomografa visual de la lista. La comprobacin de seguridad de qual-ity de este gerente suplementario debera ser realizado ocasionalmente para monitorear calidad de datos. El acceso de datos interacta y reporta confe en el contenido preciso de Los atributos de dimensin. El lenguaje normalizado de consulta felizmente producir otra lnea en un informe si el valor de atributo vara de cualquier modo basado sobre el atildamiento trivial o las diferencias ortogrficas. Tambin deberamos asegurar que los valores de atributo estn completamente poblados porque atinar mal aprecia fcilmente misinterpreta-tions de causa. Los atributos textuales administrados incompletos de dimensin o pobremente conducen a los informes incompletos o pobremente producidos. Documente las definiciones de atributo del producto, interpretaciones, y orgenes en los metadatos del almacn de datos. Acurdese de que los metadatos son anlogos para la enciclopedia del almacn de datos. Debemos estar vigilantes acerca de poblar y mantener los metadatos.
El Barco del Cliente para la Dimensin El barco del cliente a la dimensin contiene una fila para cada posicin discreta para la cual enviamos un producto. El barco del cliente para dimensionar Tablas puede extenderse moderadamente dimensionado (miles de filas) sumamente grande (millones de filas) a merced de la naturaleza del negocio. Un barco tpico del cliente a la dimensin le son mostrados en Figura 5.3.
El Barco del Cliente para la Dimensin El cliente Ship To Key Customer (PK) Ship Para Idaho Customer (la Llave Natural) Ship Para el Nombre El Barco del Cliente para Barco del Cliente de la Direccin para Barco del Cliente de la Ciudad para Barco Estatal del Cliente para ZIP + 4 El Barco del Cliente para el ZIP El Barco del Cliente para la Regin de ZIP El Barco del Cliente para el ZIP el Centro Seccional La Cuenta del Cliente para el Nombre Cliente Guillermo para Direccin Atribuye Clasificacin Crediticia del Cliente de Nombre del Padre del Bono Corporativo del Cliente de Nombre de Organizacin del Cliente El Nombre Asignado del Agente Comercial Asign Nombre del Equipo del Agente Comercial Distrito Asignado de Ventas La Regin Asignada de Ventas El Hecho de Transaccin de Orden Ordene la Fecha la Llave del Producto de la Llave de la Llave Requested Ship Date (FK) (FK) (FK) El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) La cantidad de pedido de Nmero de la Lnea de Orden de nmero de orden (DD) (DD) La Cantidad Vulgar del Dlar de Orden La Cantidad del Dlar de Descuento de Trato de Orden La Cantidad Neta del Dlar de Orden La Dimensin del Producto de Dimensin de Fecha del Barco de Peticin de Dimensin de Fecha de Orden La Dimensin del Agente Comercial La Dimensin de Trato
Figura 5.3 Pruebe barco del cliente para dimensionar.
Varias jerarquas separadas e independientes tpicamente coexisten en un barco del cliente a la dimensin. La jerarqua geogrfica natural es claramente definida por el barco para la posicin. Desde que el barco para la posicin es un punto en espacio, cualquier nmero de jerarquas geogrficas pueden estar definidas anidando alguna vez mayor enti-tie geogrfico alrededor del punto. En los Estados Unidos, la jerarqua geogrfica usual es ciudad, condado, y estado. El cdigo postal de Estados Unidos identifica una anomala geogrfica secundaria. El primer dgito del cdigo postal identifica una regin geogrfica de los Estados Unidos (por ejemplo, 0 para el Noreste y 9 estados occidentales definitivos), mientras que los primeros tres dgitos del cdigo postal identifican un centro seccional de correos. Otra jerarqua comn es la jerarqua organizativa de la cliente, assum ing que el cliente es una entidad corporativa. Para cada barco del cliente para, podramos tener una cuenta del cliente para y la corporacin del cliente. Para que cada fila de nivel de base en el barco del cliente dimensin, ambos la geografa fsica y el cliente afiliacin organizativa estn bien definidos, constantes sin embargo el rollo de hierar-chies de arriba diferentemente.
Es natural y comn, especialmente para dimensiones orientadas hacia el cliente, para un para dimen-sion simultneamente soportar jerarquas mltiples del inconformista. Las jerarquas pueden tener nmeros diferentes de niveles. La perforacin arriba y profundizar dentro de cada uno de estas jerarquas deben ser soportadas en un almacn de datos.
El lector alerta puede tener una preocupacin con la suposicin implcita que el rollo mltiple de ship-tos hasta una sola cuenta para en uno muchos para una relacin. El mundo autntico est raras veces muy as de limpio y simple. Hay ship-tos de siempre algunos excepciones de envolvente que es asociado con ms que una cuenta para. Obviamente, esto quebranta la relacin jerrquica simple que hemos asumido en el anterior barco del cliente del denormalized dimensionar. Si ste es algo poco frecuente, sera razonable generalizarle el barco del cliente a
dimensionar a fin de que el grano de la dimensin sea cada barco nico para facturar para la combinacin. Si hay dos sets de cuenta para la informacin se asociaron con un barco dado para la posicin, entonces habra dos filas en la dimensin, uno para cada combinacin. Por otra parte, si muchos de lo ship-tos son asociados con muchos bill-tos en uno robusto muchos a muchos la relacin, entonces el barco para y la cuenta a probablemente necesitar ser maniobr como las dimensiones de la separata que estn vinculadas por la mesa de hecho. sta es la prerrogativa de la diseadora. Con cualquier acercamiento, la informacin exactamente igual es conservada en el nivel de rubro contable de orden de la mesa de hecho. Gastaremos ms tiempo en cliente jerarquas organizativas, incluyendo el manejo de cliente recursivo relaciones de nio en padre, en Captulo 6. Otra jerarqua independiente potencial en el barco del cliente a la dimensin podra ser la organizacin de ventas del fabricante. Los diseadores algunas veces ques tion ya sea atributos de la organizacin de ventas deberan ser modelados como una separata
La dimensin o los atributos slo debera ser aadida a la dimensin existente del cliente. Similar para el debate precedente acerca de bill-tos, el diseador debera usar su sentencia. Si los agentes comerciales estn altamente correlacionados con ship-tos de Cu-tomer en uno uno a uno o muchos para una relacin, combinando a los atributos de la organizacin de ventas con el barco del cliente a la dimensin es un acercamiento viable. La dimensin resultante es slo casi tan grande como lo ms grande de las dos dimensiones. Las relaciones entre equipos de ventas y los clientes pueden ser hechos una lectura ligera eficazmente en la sola dimensin sin atravesar la mesa de hecho. Sin embargo, algunas veces la relacin entre organizacin de ventas y Cu-tomer se envian para est ms complicado. Los siguientes factores deben ser tomados en cuenta: Lo uno a uno o muchos para una relacin puede resultar ser uno muchos para muchas relacin. Como intercambiamos opiniones ms temprano, si lo muchos para muchos la relacin el barco es una condicin excepcional, en ese entonces todava podemos estar tentados de combinar los atributos del agente comercial en el barco para dimensionar, en la seguridad de que necesitaramos tratar stos raros muchos para muchas ocurrencias publicando otro barco vicario para teclear. Si la relacin entre agente comercial y el cliente se envian para difiere sobre el tiempo o debajo de la influencia de una cuarta dimensin como producto, en ese entonces la dimensin combinada es en realidad alguna clase de hecho pospngase! En este caso, probablemente crearamos dimensiones separadas para el agente comercial y el barco de Cu-tomer para. Si el agente comercial y el cliente se envian para las dimensiones participe independientemente en otras Tablas comerciales de hecho de proceso, probablemente mantendramos separadas las dimensiones. Creando un solo barco del cliente para dimensionar con atributos del agente comercial exclusivamente alrededor de las rdenes de las que los datos pueden hacer algo de los otros procesos y relaciones difciles para el exprs. Cuando las entidades tienen un invariant fijo, de tiempo, fuertemente correlacion relacin, obviamente deberan ser modeladas como una sola dimensin. En la mayora de otros casos, su diseo probablemente ser ms simple y ms dcil cuando usted separa a las entidades en dos dimensiones (al recordar las lneas
directivas generales concirnindole dimensiones de ms). Si usted ya ha identificado 25 dimensiones en su dibujo tcnico, usted le debera dar la consideracin fuerte a combinar dimen-sions, si es posible. Cuando las dimensiones son separadas, algunas diseadoras quieren crear una mesa pequea con simplemente las dos llaves de dimensin para mostrar la correlacin fuera a usar la mesa de hecho. Esta mesa de dos dimensiones es innecesario. No hay razn para evitar que la mesa de hecho se origine de esta averiguacin de relacin. Las Tablas de hecho son increblemente effi cient porque contienen slo llaves de dimensin y medidas. La mesa de hecho fue creada especficamente para representar la correlacin entre dimensiones.
Antes de que le dejamos el tema de asignaciones del agente comercial a los clientes, los usuarios algunas veces quieren que la habilidad analice la asignacin complicada de agentes comerciales para Cu-tomers con el paso del tiempo, aun si ninguna actividad de orden ha ocurrido. En este caso, podramos construir una mesa de hecho de factless, como brevemente introdujimos en Captulo 2, a captar la cobertura del agente comercial. La mesa de cobertura le provea un mapa completo de las asignaciones histricas de agentes comerciales a los clientes, aun si algunos de las asignaciones nunca resultado en una venta. Como aprenderemos en Captulo 13, probablemente incluiramos efectivos y los compaeros de cita de vencimiento en la cobertura del agente comercial posponen porque las asignaciones de cobertura cambian con el paso del tiempo. La Dimensin de Trato La dimensin de trato es similar a la dimensin de promocin de Captulo 2. La dimensin de trato describe los incentivos que han sido ofrecidos el cliente que tericamente afectan el deseo de los clientes para comprar productos. Esta dimensin es tambin algunas veces llamado el contrato. Como se muestra en Figura 5.4, la dimensin de trato describe la combinacin llena de trminos, concesiones, y los incentivos que corresponden al rubro contable particular de orden.
Los mismos asuntos que afrontamos en la dimensin de promocin por menor tambin surgen con esta dimensin de trato. Si los trminos, las concesiones, y los incentivos son tilmente correlacionados, en ese entonces tiene sentido para empaquetarlos en una sola dimensin de trato. Si los trminos, las concesiones, y los incentivos son muy no correlacionados y nos encontramos generando el producto cartesiano de estos factores en la dimensin, en ese entonces probablemente hace sentido para dividir tal dimensin de trato en sus componentes separados. Otra vez, ste no es un asunto de lucrar o perder informacin, desde que la base de datos contiene la misma informacin en ambos casos, excepto ms bien los asuntos de conveniencia del usuario y la complejidad administrativa determinan si para representar estos factores de trato como dimensiones mltiples. En una mesa muy grande de hecho, con decenas de millones o centenares de millones de filas, el
deseo para reducir el nmero de llaves en el hecho la llave de la mezcla de la mesa favorecera keep-ing la dimensin de trato como una sola dimensin. Ciertamente cualquier dimensin de trato ms pequea que 100,000 filas sera dcil en este diseo.
La Dimensin de Trato La descripcin de Trato de la Llave de trato (PK) El Trato Llama Descripcin Las Clusulas de Trato Escriben Descripcin de Incentivo de Especial de Descripcin de Tipo de Concesin de Descripcin de Concesin de Descripcin La Descripcin Especial de Tipo de Incentivo El Hecho de Transaccin de Orden Ordene la Fecha la Llave del Producto de la Llave de la Llave Requested Ship Date (FK) (FK) (FK) El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) La cantidad de pedido de Nmero de la Lnea de Orden de nmero de orden (DD) (DD) La Cantidad Vulgar del Dlar de Orden La Cantidad del Dlar de Descuento de Trato de Orden La Cantidad Neta del Dlar de Orden La Dimensin del Producto de Dimensin de Fecha del Barco de Peticin de Dimensin de Fecha de Orden El Barco del Cliente para la Dimensin La Dimensin del Agente Comercial
Figura 5.4 Pruebe dimensin de trato.
Degenere Dimensin para Nmero De Orden Cada fila de rubro contable en la mesa de hecho de rdenes incluye el nmero de orden como una dimensin degenerada, como introdujimos en Captulo 2. A diferencia de una base de datos de nio en padre transaccional, el nmero de orden en nuestros modelos dimensionales no est atado a una mesa del encabezado de orden. Hemos desnudado todos los detalles interesantes del encabezado de orden en dimensiones separadas como el barco de orden de fecha, del cliente para, y otros campos interesantes. El nmero de orden es todava til porque nos deja agrupar los rubros contables separados sobre la orden. Nos permite contestarle a tales ques tions como el nmero comn de rubros contables sobre una orden. Adems, el nmero de orden es usado ocasionalmente para conectar el almacn de datos de regreso al mundo operacional. Desde que el nmero de orden queda sentndose por s mismo en la mesa de hecho sin asociarse para una mesa de dimensin, es llamada una dimensin degenerada.
Las dimensiones degeneradas tpicamente son confidenciales para identificadores operacionales de transaccin. No deberan ser utilizadas como una excusa para insertar un cdigo secreto en la mesa de hecho sin incorporarse a uno descriptivo descifre en una mesa de dimensin.
Si el diseador decide que ciertos datos que los elementos en verdad hacen pertenecen a la orden misma y tilmente no caen en otra dimensin comercial natural, en ese entonces el nmero de orden es ya no una dimensin degenerada pero ms bien es una dimensin normal con su columnas de la llave propia vicaria y de atributo. Sin embargo, los diseadores con un historial fuertemente de nio en padre deberan resistir el deseo simplemente a aglomerar la informacin tradicional del encabezado de orden en una dimensin de orden. En casi todos los casos, la informacin del encabezado corresponde a otras dimensiones analticas en vez de meramente siendo echada en una dimensin que de cerca se parece a la mesa del encabezado de orden de transaccin.
Las Dimensiones de Trastos Viejos Cuando somos puestos en una fuente operacional complicada de datos, tpicamente realizamos triage para rpidamente identificar campos que estn obviamente relacionados con dimen-sions, como fechadores o los atributos. Entonces identificamos el mea-surements numrico en los datos de la fuente. En este punto, quedamos a menudo con un nmero de banderas e indicadores miscelneos, cada uno del cual las tomas sobre un alcance pequeo de dis-Crete aprecian. El diseador es confrontado con varias opciones ms bien poco atractivas, inclusivo: Deje en la misma forma las banderas y los indicadores en la fila de la mesa de hecho. Esto podra inflamar la fila de la mesa de hecho alarmantemente. Era una lstima crear un diseo dimensional apretado bonito con cinco dimensiones y cinco hechos y entonces salir un puado de columnas que indica textuales no comprimidas en la fila.
Convierta cada bandera y cada indicador en su propia dimensin separada. El proceder podra causar que nuestro diseo de 5 dimensiones se sople en un diseo de 25 dimensiones. Desndese fuera de todas las banderas y los indicadores del diseo. Por supuesto, preguntamos la pregunta obligatoria acerca de quitar estas banderas miscelneas porque parecen bastante insignificantes, pero esta nocin es a menudo vetada rpidamente porque alguien los podra necesitar. Vale la pena examinar esta pregunta que se importa completamente. Si los indicadores son incomprensibles, ruidosos, poco consistentemente popu lated, o slo de significado operacional, deberan quedar fuera.
An asigne acercamiento para abordar estas banderas y estos indicadores debe estudiarlos cuidadosamente y entonces empacarlos en uno o ms echan a la basura dimensiones. Usted puede visualizar la dimensin de trastos viejos como ser semejante para la gaveta de trastos viejos en su cocina. La gaveta de trastos viejos de cocina es un suelo volcador para miscelneos artculos de menaje, como el caucho circunda, los clips, las bateras, y la cinta. Mientras puede ser ms fcil de localizar las ligas elsticas si las dedicsemos una gaveta de cocina separada, no tenemos adecuada capacidad de almacenamiento para hacer eso. Adems, nosotros no tenemos bastantes ligas elsticas perdidas, ni los necesitamos con mucha frecuencia, guerrear discurso rimbombante la dotacin de un solo espacio de almacenamiento de propsito. Los vides de la gaveta de trastos viejos nosotros con acceso satisfactorio al todava retener bastante almacenamiento de cocina para los platos ms crticos y frecuentemente a los que se accedi y la platera.
Una dimensin de trastos viejos es un agrupamiento conveniente de tpicamente punto bajo que el cardinality seala con una bandera e indi-cators. Creando una dimensin abstracta, nosotros remueva las banderas de la mesa de hecho al colocarlas dentro de un armazn dimensional til.
Un ejemplo simple de una dimensin til de trastos viejos sera quitar 10 indicadores de dos valores, como el dinero en efectivo versus el mtodo de pago de crdito, de la mesa de hecho de orden y colocarlos dentro de una sola dimensin. En el peor de los casos, usted tendra 1,024 (210) filas en esta dimensin de trastos viejos. Probablemente no es muy interesante para hacer una lectura ligera entre estas banderas dentro de la dimensin porque cada bandera cursa con cada otra bandera si la base de datos es bastante grande. Sin embargo, la dimensin de trastos viejos es un lugar til del soporte para constreir o escribir una crnica de estas banderas. Obviamente, las 10 llaves extranjeras en la mesa de hecho seran reemplazadas con una sola llave vicaria pequea. Por otra parte, si usted altamente ha descorrelacionado atributos que cobran ms numerosos valores, en ese entonces no puede tener sentido para tratarlos de forma conjunta en una sola dimensin de trastos viejos. Desafortunadamente, la decisin no es enteramente formulista. Si usted tiene cinco indicadores que cada uno toma sobre slo tres valores, la sola dimensin de trastos viejos es la mejor ruta para estos atributos porque la dimensin tiene slo
243 (35) filas posibles. Sin embargo, si el cinco descorrelacionase indicadores cada uno tiene 100 valores posibles, sugeriramos la creacin de dimensiones separadas porque Usted ahora tiene 100 milln (1005) combinaciones posibles.
La Llave El del Mtodo De Grupo Indicado Pago de r de Descripcin Mtodo Orden de Pago
1 2 3 4 5 6 7 8 9 Al contado Al contado Al contado Al contado Al contado
El Indicador de Orden / El Crdito de la Ordene Tipo con Rumbo Comisin Indicador Exterior de Indicador Entrada
Comisionable Poco Comisionable Poco Comisionable Normal El despliegue Comprobacin Normal El despliegue Normal El despliegue Comprobacin
Al contado De entrada Al contado De entrada Al contado De entrada
Al contado Con rumbo exterior Comisionable Al contado Con rumbo exterior Poco Comisionable De entrada De entrada De entrada Comisionable Poco Comisionable Poco Comisionable
Descubra Tarjeta Crdito Descubra Tarjeta Crdito Descubra Tarjeta Crdito Descubra Tarjeta Crdito
Con rumbo exterior Comisionable
Descubra Crdito Con rumbo Poco Tarjeta exterior Comisionable 11 Tarjeta de Crdito De entrada Comisionable Normal crdito MasterCard 12 Tarjeta de Crdito De entrada Poco El despliegue crdito Comisionable MasterCard 13 Tarjeta de Crdito De entrada Poco Comprobaci crdito Comisionable n MasterCard 14 Tarjeta de Crdito Con rumbo Comisionable Normal crdito exterior MasterCard Figura 5.5 Pruebe filas de una dimensin de trastos viejos del indicador de orden.
10
Normal El despliegue
Nosotros hemos ilustrado filas de muestra de una dimensin del indicador de orden en Figura 5.5. Un asunto sutil estimando trastos viejos que las dimensiones estn ya sea que usted crea le rema todas las combinaciones de antemano o crean filas de dimensin de trastos viejos para las combinaciones como usted la verdad las encuentre en los datos. La respuesta depende cuntos las combinaciones pos sible
usted espera y lo que el mximo nmero podra ser. Gener-ally, cuando el nmero de combinaciones tericas est por las nubes y usted no piensa que usted los encontrar, usted debera construir una fila de dimensin de trastos viejos en el tiempo del extracto cada vez que usted encuentra una combinacin nueva de banderas o indicadores. Otra aplicacin interesante de la tcnica de dimensin de trastos viejos debe usarlo maniobrar el campo de comentarios infrecuentemente poblado, indefinido algunas veces adjuntado a una fila de hecho. ptimamente, los comentarios han sido parameterized en una dimensin a fin de que pueden servir para anlisis robusto. Aun si esto no es el caso, los usuarios todava pueden considerar que los comentarios fildean es lo suficientemente significativo para incluir en el almacn de datos. En este caso, una dimensin de trastos viejos simplemente contiene todos los comentarios bien definidos. La dimensin de trastos viejos es marcadamente ms pequea que la mesa de hecho porque los comentarios son relativamente raros. Por supuesto, usted necesitar una llave vicaria especial que seala el Ningn Comentario fila en la dimensin porque la mayor parte de sus filas de la mesa de hecho usarn esta llave. Las Monedas Circulantes Mltiples Supongo que rastreamos las rdenes de una compaa basada en Californias multinacional grande con oficinas de ventas alrededor del mundo. Podemos captar transacciones de orden en ms de 15 monedas circulantes diferentes. Ciertamente no querramos incluir columnas en la mesa de hecho para cada moneda circulante porque theoreti-cally que hay un nmero indefinido de monedas circulantes.
El requisito ms obvio es que las transacciones de orden sean expresadas en la moneda local y la moneda circulante corporativa estndar, como dlares de Estados Unidos en este ejemplo. Para satisfacer esta necesidad, reemplazaramos cada hecho subyacente de orden con un par de hechos, uno para la moneda local aplicable y otro para la moneda circulante corporativa estndar equivalente. Esto dejara todas las transacciones fcilmente arroparse en la cama para la moneda circulante corporativa sin codificacin complicada de la aplicacin. Tambin suplementaramos el hecho que la mesa con una dimensin adicional de moneda circulante para identificar el tipo de moneda circulante asoci con los hechos de monedas locales. Una dimensin de moneda circulante se necesita aun si la posicin de la transaccin es diferente sabida porque la posicin necesariamente no garantiza cul moneda circulante fue usada. Sin embargo, usted puede encontrar que los requisitos del soporte de la moneda mltiple estn ms complicados acabamos de describir. Podemos necesitar dejar a un gerente entrar en cualquier pas para ver volumen de orden en cualquier moneda circulante. Por ejemplo, la oficina de ventas en Bangkok puede monitorear rdenes de ventas en bhat tailands, el envejecente pacfico en la Asia de hombre de la regin en Tokio puede querer considerar las rdenes de la regin en yen japons, y el departamento de ventas en California puede querer ver las rdenes basadas en dol-Lar de Estados Unidos. Embelleciendo nuestro diseo inicial con una mesa adicional de hecho de conversin de moneda, como se muestra en Figura 5.6, puede dar esta flexibilidad. Las dimensiones en esta mesa de hecho representan monedas circulantes, no pases, porque la relacin entre monedas circulantes y pases no es una para una. Las necesidades del agente comercial en Tailandia y U.S.- Lo basado administracin de ventas sera por el que se responsabiliz simplemente por query-ing la mesa de hecho de rdenes. El gerente de la regin en Tokio podra reinvertir todas las rdenes pacficas en la Asia en yen japons usando la mesa especial de conversin de moneda.
La Dimensin de Fecha El Barco del Cliente de Dimensin del Producto para la Dimensin del Agente Comercial de Dimensin La Dimensin de Trato La Dimensin de Moneda Circulante El Hecho de Transaccin de Orden La llave del Producto de la Llave de Fecha de orden (FK) (FK) El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) El nmero de orden de la Llave de Dimensin de la moneda local (DD) (FK) La cantidad de pedido de Nmero de la Lnea de orden (DD) La moneda local la Cantidad de Orden de la Gruesa de DLAR NORTEAMERICANO de la Gruesa Order Amount Local Currency Order Discount Amount Local Currency Net Order Amount Standard La cantidad estndar de Descuento de Cantidad del Dlar de USA La cantidad Estadounidense estndar de Orden de la Red del Dlar El Hecho de Conversin de Moneda La tasa de cambio de Destination-Source de Tasa de Cambio de Source-Destination de la Llave de Moneda Circulante del Destino de la Llave de Moneda Circulante de la Fuente de la Llave de Fecha de conversin (FK) (FK) (FK)
Le da apoyo a reportar de hechos en monedas circulantes mltiples
Le da apoyo a reportar de hechos en dos monedas circulantes Figura 5.6 Rastreando monedas circulantes mltiples con una mesa diaria de hecho de intercambio de divisas.
Dentro de cada fila de la mesa de hecho, la cantidad expresada en moneda local es absolutamente precisa porque la venta ocurri en esa moneda circulante en ese da. El valor del dlar de Estados Unidos equivalente se basaba en una tasa de conversin para dol-Lar de Estados Unidos por ese da. La mesa de tasa de conversin contiene todas las combinaciones de tasas de intercambio de divisas de effec-tive yendo en ambas direcciones porque las tasas simtricas entre dos monedas circulantes no son exactamente iguales.
El Encabezado y los Hechos de Rubro Contable con La Granularidad Diferente Es realmente comn en bases de datos de transaccin de nio en padre para encontrar hechos de granularidad de dif-fering. Sobre una orden, por ejemplo, puede haber un cargo naviero que se aplica a la orden entera que no est disponible en el rubro contable nivelado en producto individual en el sistema operacional. La primera respuesta del diseador debera ser intentar obligar a bajar todos los hechos para el nivel mnimo. Nos esforzamos por abemolar la relacin de nio en padre as es que tan todas las filas estn en el nivel de nio, incluyendo hechos que son cap-tured operacionalmente en el nivel ms alto del padre, como ilustrado en Figura 5.7. Este mtodo es ampliamente al que se refiri como ubicar. Asignndole a los hechos de orden del padre al nivel de rubro contable de nio es crtico si queremos que la habilidad corte en rodajas y juegue a los dados y ruede arriba de todos los hechos de orden por todas las dimensiones, incluyendo producto, cul es un requisito comn. Desafortunadamente, ubicar hechos nivelados en encabezado hasta el nivel de rubro contable puede conllevar un poltico combate de lucha. Es maravilloso si el asunto entero de dotacin es manejado por el departamento financiero, no por el equipo del almacn de datos. Colocando acuerdo organizativo en reglas de dotacin es a menudo un proceso controversial y plegado en la salida de computadora en microfilm. Los datos almacenan pareja no debera ser distrada y atrasada por la negociacin organizativa inevitable. Afortunadamente, en muchas compaas, la necesidad para racionalmente ubicar costos ha sido reconocida ya. Una fuerza de trabajo, inconformista del equipo del almacn de datos, ya pudo haber establecido medidas que cuestan activ-ity-base. ste es simplemente otro nombre para ubicar.
El Hecho de la Lnea de Orden

El Hecho del Encabezado de Orden La llave del producto (FK)
La llave de Fecha de orden (FK)
La llave de Fecha de orden (FK) El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) El embarque de Orden de nmero de orden (DD) Va a la Carga
Ubicado para aplicarle delineador a ras El cliente Ship To Key (FK) Llave del Agente Comercial (FK) La llave de trato (FK) El nmero de orden (DD) Ms Cargos de Embarque de Orden de Hechos de Rubro Contable
Note la ausencia de una dimensin del producto en esta mesa de hecho desde producto No se aplica al encabezado de orden Figura 5.7 Asignndole los hechos del encabezado al rubro contable. Cuando los hechos del encabezado son asignados al nivel de la lnea, podemos analizarlos por la dimensin del producto
Si el embarque va a la carga y otros hechos nivelados en encabezado no pueden ser suc-cessfully ubicado, en ese entonces deben replantearse en una mesa del agregado para la orden global. Claramente preferimos el acercamiento de dotacin, si es posible, porque el sepa-rate ms alto mesa nivelada de hecho tenga algunos asuntos inherentes de usabilidad. Sin alloca-tions, seramos incapaces de explorar hechos del encabezado por producto porque el producto no es identificado en una mesa de hecho del grano de encabezado. Si tenemos xito ubicando hechos hasta el nivel mnimo, el problema se desvanece.
No deberamos mezclar granularidades de hecho (por ejemplo, la orden y la orden le aplican delineador a los hechos) dentro de una sola mesa de hecho. En lugar de eso, necesitamos tampoco asignarle los hechos nivelados ms altos a un nivel ms detallado o crear dos Tablas separadas de hecho para manejar los hechos diferentemente granulados. La dotacin es el acercamiento preferido. ptimamente, unas finanzas o equipo de negocio (no los datos almacenan pareja) son el lder del esfuerzo de dotacin.
Facture Transacciones Si trabajamos para una compaa manufacturera, la facturacin tpicamente ocurre cuando los productos se envian de nuestra facilidad para el cliente. Visualizamos embarques en el muelle de carga como las cajas de producto estn cargado encima de un camin destinado para una direccin particular del cliente. La factura asociada con el embarque es cre-ated a esta hora. La factura gobierna el embarque actual de productos en ese camin en ese da para una direccin particular del cliente. La factura tiene rubros contables mltiples, cada uno correspondiente a un producto particular siendo enviada. Los precios diversos, los descuentos, y las concesiones son asociados con cada rubro contable. La cantidad neta extendida para cada rubro contable est tambin disponible. Aunque no lo mostramos en la factura al cliente, un nmero de otros hechos interesantes son potencialmente sabidos acerca de cada producto al momento de
ship-ment. Ciertamente sabemos precios de lista; La manufactura y los costos de distribucin pueden estar disponibles tambin. As sabemos mucho del estado de nuestro negocio al momento de embarque del cliente. En el hecho de la factura de embarque posponemos que puede ver a todos los productos de la compaa, todos los clientes, todos los contratos y tratos, todos los descuentos de la concesiones y factura feriada, toda la renta generada por clientes comprando productos, todos los costos variables y fijos asociados con confeccionando y entregando productos (si disponible), todo el dinero sali encima despus de entrega de producto (con-tribution), y la mtrica de satisfaccin del cliente tan en embarque de tiempo.
Para cualquier compaa que enva productos para los clientes o los clientes de cuentas para ren-dered de servicios, el lugar ptimo para echar a andar un almacn de datos tpicamente est con facturas. A menudo nos referimos a los datos resultando de facturando como la ms poderosa base de datos porque combina a los clientes de la compaa, productos, y los componentes de rentabilidad. Escogemos el grano de la mesa de hecho de la factura para ser la lnea de la factura del individuo tem. Una mesa de hecho de la factura de muestra se asoci con embarques del fabricante son ilustrados en Figura 5.8. Como usted esperaba, la mesa de hecho de la factura de embarque contiene un nmero de dimen-sions que hemos visto previamente en este captulo. La mesa conformada de dimen-sion de fecha otra vez jugara papeles mltiples en la mesa de hecho. El cliente, producto, y dimensiones de trato tambin se conformaran a fin de que podemos entrenarnos a travs de mesa de hecho para mesa de hecho y podemos comunicarnos usando atributos comunes. Tambin tendramos un degenerado nmero de orden, suponiendo que un solo nmero de orden es asociado con cada rubro contable de la factura, as como tambin la dimensin de degener-eat de nmero de factura. La mesa de hecho de la factura de embarque tambin contiene algn dimen-sions nuevo interesante que no hemos visto an en nuestros diseos. El barco de dimensin contiene una fila para cada almacn del fabricante o la posicin naviera. sta es una rela-tively dimensin simple con persona de nombre, de la direccin, de contacto, y tipo de facil-ity de almacenamiento. Los atributos estn algo reminiscentes de las tiendas de descripcin de dimensin de facilidad de Captulo 2. La dimensin del expedidor describe el mtodo y trasportador por el cual el producto se envi del fabricante para el cliente. Algunas veces una base de datos de embarque contiene slo una dimensin simple del trasportador, con atributos acerca de la compaa de transporte. Hay slo un mtodo del barco, a saber, el camin para Cu-tomer. Se interes en sin embargo, ambos fabricantes y clientes del mismo modo rastrear mtodos alternativos de la entrega, algo semejante como entrega de la tienda directa (el producto entregado en seguida para la tienda detallista), se
intersecta recortando (el producto transferido de un trasportador para otro sin colocarlo en un almacn), echa para atrs halando (el trasportador transporta el producto sobre un viaje de regreso en vez de regresar vaco), y la creacin de la cama de paja de Cu-tomer (la costumbre del producto instrumentada y envolvi en plstico en una cama de paja destinada para una tienda detallista). Desde que las inversiones son hechas en estos modelos navieros alterna tive, se los interes en los fabricantes (y sus clientes) analizar los negocios a lo largo de la dimensin del expedidor. La dimensin de satisfac-tion del cliente provee descripciones textuales que resumen las banderas numricas de sit-isfaction al pie de la mesa de hecho.
La dimensin de fecha (los puntos de vista para 3 papeles) Customer Ship To Dimension Enve de Dimensin La Dimensin de Satisfaccin del Cliente El Hecho de Transaccin de Rubro Contable de la Factura de Embarque La llave de fecha de factura (FK) Pidi a Ship Date Llave del Producto de la Llave de la Llave Actual Ship Date (FK) (FK) (FK) El cliente Ship To Key (FK) Llave de Trato (FK) La llave del Expedidor Ship From Key (FK) (FK) El nmero de factura de la Llave de Satisfaccin del cliente (DD) (FK) La cantidad de nmero de orden (DD) Se Envi La Cantidad Vulgar Extendida del Dlar de la Factura Extendi Cantidad del Dlar de Concesin la Cantidad Rebajada en Precio Extendida del Dlar la Cantidad Neta Extendida del Dlar de la Factura el Extendido Fijo Costo de Fabricacin la Variable Extendida Confeccionando Costo de Almacenamiento Extendido Costado La Distribucin Extendida Cost Lnea de Embarque de Cantidad del Dlar de Contribucin tem en Lnea de Embarque de la Cuenta de Tiempo tem Cuenta Completa El Dao de Rubro Contable de Embarque la Cuenta Gratis
La Dimensin del Expedidor de Dimensin de Trato de Dimensin del Producto
Creo que 5.8 el Embarque facturan mesa de hecho.
Los Hechos de Ganancias Y Prdidas Si su organismo ha abordado costeo basado en actividades o ha implementado a un sistema robusto de planificacin del recurso de la empresa (la tasa de proteccin efectiva), usted es probablemente en condiciones de identificar muchos de los ingresos incrementales y los costos asociaron con productos terminados de sonido corto y metlico de barco para el cliente. Es tradicional poner en secuencia stos rev-enues y costos de la lnea sobresaliente, lo cual representa el valor descontado de los productos enviados para el cliente, hasta la lnea del gato macho de larva del moscardn, lo cual representa el dinero dejado sobre despus de los descuentos, concesiones, y costos. Esta lista de ingresos y costos es designada uno state-ment de ganancias y prdidas (P y L). Tpicamente no tratamos de llevar la P y declaracin L hasta una vista completa de ganancia de compaa, incluyendo a los costos de general y de administra-tive. Por esta razn, nos referiremos al meollo del asunto en nuestra P y la declaracin L como la contribucin. En vista de que cada fila en el hecho de la factura la mesa representa un solo rubro contable en la factura de embarque, los elementos de nuestra P y la declaracin L, como se muestra en Figura 5.8, lo ha hecho las siguientes interpretaciones: La cantidad enviada. ste es el nmero de casos del producto de rubro contable particular. Trataremos el uso de cantidades equivalentes mltiples con unidades de medida de differ-ent ms tarde en el captulo. El extendido vulgar importe de factura. Esto es tambin sepa como extendido precio de lista porque es la cantidad enviada multiplicado por el precio unitario de la lista. Esto y todo los subsiguientes valores del dlar son cantidades extendidas o, en otras palabras, la unidad
Las tasas multiplicado por la cantidad enviada. Esta insistencia en val-ues aditivo simplifica la mayora de acceso y aplicaciones ponentes. Es relativamente rara para el para usuario pedir el precio de una sola fila de la mesa de hecho. Cuando el usuario quiere que un precio medio provocado muchas filas, los precios extendidos son primeros aadidos, y en ese entonces el resultado est entre la suma de las cantidades enviadas. La cantidad extendida de concesin. sta es la cantidad sustrada de lo
El importe total de la lnea de factura para las concesiones relatadas en trato. Las concesiones son Descrito en la dimensin anexada de trato. La cantidad de concesin es a menudo Designado una concesin de la factura feriada. La factura real puede tener varias Las concesiones para un rubro contable dado. En este diseo de ejemplo, aglomeramos lo Las concesiones juntos. Si las concesiones necesitan ser rastreadas separadamente y Hay potencialmente muchas concesiones simultneas sobre un rubro contable dado, En ese entonces una estructura adicional de dimensin se necesita. Un hecho de detalle de concesin La mesa podra usarse para engrandecer la mesa de hecho de la factura, sirviendo de un taladro Abajo de blanco para una explicacin detallada del cubo de concesin en lo La mesa de hecho de la factura.
El importe del descuento extendido. sta es la cantidad sustrada en la factura para el trmino de volumen o de que el pago descuenta. La explicacin de la cual los descuentos estn ocupados se encuentra tambin en la fila de dimensin de trato que seala esta fila de la mesa de hecho. Como discutido en la seccin en la dimensin de trato, la decisin para codificar la explicacin de las concesiones y descontar mecanografa juntos es la prerrogativa de la diseadora. Tiene sentido para hacer esto si las concesiones y dis-count son correlacionados y los usuarios tienen el deseo de hacer una lectura ligera dentro de la dimensin de trato Para estudiar las relaciones entre concesiones y los descuentos. Note ese el descuento para los trminos de pago es caractersticamente un vaticinio que el Cu-tomer pagar en un plazo del lapso de tiempo llam por telfono pues en el acuerdo de trminos. Si esto no ocurre, o si hay otras correcciones para la factura, en ese entonces el Departamento Financiero probablemente atrs expulsar la factura original en un subsiguiente mes y echar al correo una factura nueva. Con toda probabilidad, los datos tienen cuidado con casa ver esto como tres transacciones. Con el paso del tiempo, todos los valores aditivos en estas filas sumarn correctamente, pero cautela debe ser tomado en actuar hace avanzar con el remo a los condes para no achacar ms actividad antes que en verdad existir. Todas las concesiones y todos descuentos en este hecho posponen es representado
en el nivel de rubro contable. Como discutimos ms temprano, algunas concesiones y descuentos pueden calcularse operacionalmente en el nivel de la factura, no el nivel de rubro contable. Un esfuerzo debera ser hecho para ubicarlos hasta el rubro contable. Una factura La P y la declaracin L que no incluyen las actitudes de dimensin del producto una limitacin seria sobre nuestra habilidad a presentar L y P significativa corta en rodajas del negocio. El extendido neto importe de factura. sta es la cantidad el cliente - se espera paga por este rubro contable antes del impuesto. Es igual al vulgar importe de factura menos las concesiones y los descuentos.
Los hechos descritos hasta ahora probablemente seran exhibidos para el cliente en el documento de la factura. Las siguientes cantidades costadas, conduciendo a uno con-tribution primordial, son para consumo interno slo. La extendida manufactura fija costada. sta es la cantidad identificada por manu-facturing como el en forma proporcional costo de fabricacin fijo del producto. La variable extendida confeccionando costo. sta es la cantidad identificada confeccionando como el variable costo de fabricacin del producto. Esta cantidad puede ser ms o menos basada en actividades, reflejando el tiempo y posicin real de la manufactura corren tan a producido el producto sindoles enviados para el cliente. Inversamente, este nmero puede ser un set estndar de valor por un comit de ejecutivos. Si la manufactura cuesta o cualquier del otro almacenamiento y los costos de distribucin son demasiados promedios de promedios, en ese entonces el Ls y P detallada en el almacn de datos pueden volverse sin sentido. La existencia del almacn de datos tiende a clarificar este problema y acelerar la adopcin de mtodos basados en actividades de costeo. El almacenamiento extendido costado. ste es el costo cargado en cuenta al producto para el almacenamiento antes de enviarse para el cliente.
La distribucin extendida costada. ste es el costo cargado en cuenta al producto para el transporte del punto de manufactura al punto de embarque. Este costo no es notorio para no siendo basado en actividades. Algunas veces una compaa no quiere ver que cuesta ms negociar en Seattle porque la planta de manu-facturing est en Alabama. El coste de distribucin posiblemente puede incluir carga al cliente si la compaa paga la carga, o el acarreo puede replantearse como un rubro contable separado en la P y L. La cantidad de contribucin. ste es el clculo final de la factura neta extendida menos todos los costos acabados de discutir. sta no es la ltima lnea cierta de la compaa global porque los gastos generales y administrativos y otros ajustes de finan-cial no han sido hechos, pero es importante no obstante. Esta columna algunas veces tiene etiquetas alternativas, como margen, a merced de la cultura de compaa.
Rentabilidad Lo Ms Poderoso El Centro De Compras de Datos Deberamos dar un paso atrs y deberamos admirar el modelo dimensional que acabamos de construir. A menudo describimos este diseo como el centro de compras de datos ms poderoso. Hemos construido una vista de la P detallada y L de nuestro negocio, mostrando todos los elementos basados en actividades de renta y costos. Tenemos una ecuacin completa de rentabilidad. Sin embargo, lo que hace este diseo tan apremiante es que la P y L miran se sienta dentro de un armazn muy dimensional sustancioso de fechas del calendario, clientes, productos, y causal
Factores. Quiere usted rentabilidad del cliente de la sede? Simplemente constria y agrupe en la dimensin del cliente y meta los componentes de la P y L en su informe. Quiere usted ver rentabilidad del producto? Quiere usted ver rentabilidad de trato? Todos estos analizan es igualmente fcil y lleva la misma forma analtica en su averiguacin y herramientas que le escriben a informe. Algo machihembre en mejilla, recomendamos que usted no entrega este centro de compras de datos muy temprano en su carrera porque usted ser ascendido y no podr dedicarse directamente a ms almacenes de datos!
La Rentabilidad Expresa de Dar Aviso Debemos pesar el ltimo prrafo contra una nota ms sobria. Antes de dejar este tema, nos vemos forzados a pasar a lo largo de algunas aleccionadoras palabras de advertencia. Huelga decir que la mayor parte de sus usuarios probablemente siguen con mucho inters P granular y los datos L que puede ser enrollada para analizar al cliente y prof-itability del producto. La realidad es eso entregando estos declaraciones de la P y L a menudo son ms fciles de decirse que de hacerse. Los problemas surgen con los hechos costados. Aun con implementaciones adelantadas de tasa de proteccin efectiva, es medianamente comn ser incapaz para captar los hechos costados en este nivel atmico de granularidad. Usted afrontar un proceso complicado de hacer mapas, o ubicar, el original cuesta datos hasta la lnea de la factura a ras de la factura de embarque. Adems, cada tipo de costo puede resultar requerir una extraccin separada de algn sistema de la fuente. Diez hechos costados pueden querer decir 10 programas del extracto diferente y de transformacin. Antes de que usted se aliste para impossi-ble de misin, vaya de fijo a actuar una valoracin detallada de lo que est disponible y feasi-ble de sus sistemas de la fuente. Usted ciertamente no quiere que el equipo del almacn de datos sea ensillado con llevar la organizacin al consenso sobre el costeo basado en actividades como un proyecto lateral, en exceso de manejar un nmero de implementaciones paralelas del extracto. Si el tiempo le permite, la rentabilidad es a menudo abordada como un centro de compras de datos de consoli-date despus de los componentes de renta y el costo han sido sourced y han efectuado la entrega separadamente para los usuarios comerciales en el almacn de datos.
Los Hechos de Satisfaccin del Cliente Adems de la P y hechos L, los usuarios comerciales a menudo estn interesados en mtrica de satisfaccin del cliente, como si el rubro contable fue enviados a tiempo, enviados completos, o se envi libre de dao. Le podemos aadir las columnas separadas a la mesa de hecho pues cada uno de stos le aplica delineador tem iguala mtrica de satisfaccin. Estas columnas nuevas de hecho estn pobladas con aditivos y pone en el cero, dndole apoyo a interesarle analiza de mtrica de funcin de rubro contable como el porcentaje de rdenes enviados para un cliente particular a tiempo. Tambin aumentaramos el diseo con una dimensin de satisfaccin del cliente que combina estas banderas en una sola dimensin (el ala la dimensin de trastos viejos que discutimos ms temprano) para asociar equivalentes del texto con las banderas para reportar propsitos.
Acumulando Foto para la Orden La Tubera de Cumplimiento Podemos pensar acerca del proceso administrativo de orden como una tubera, especialmente en una constitucin para la orden confeccionando a negocio, tan ilustrados en Figura 5.9. Los clientes le hacen un pedido que ahonda en rezago de trabajo hasta eso se dosifica a la manufactura para forjarse. Los productos elaborados son colocados en inventario de productos terminados y entonces se envan a los clientes y facturado. Las transacciones nicas son gener-ated en cada espita de la tubera. Hasta ahora hemos considerado cada uno de estas actividades de la tubera como una mesa separada de hecho. El proceder nos deja decorar los hechos detallados generados por cada proceso con el mximo nmero de dimensiones detalladas. Tambin nos deja aislar nuestro anlisis para la funcin de un proceso de negocio de sin-gle, lo cual es a menudo precisamente lo que los usuarios comerciales quieren. Sin embargo, hay por cuando los usuarios ms interes en analizar la tubera entera de cumplimiento de orden. Quieren mejor comprender velocidad del producto, o qu tan rpidamente los productos se mueven por canales privados. La mesa de hecho de la foto de accumulat-ing nos provee de esta perspectiva del negocio, tan ilustrada en Figura 5.10. Nos deja ver un estatus actualizado y finalmente la disposicin final de cada orden. La foto de atesoramiento complementa nuestras perspectivas alternativas de la tubera. Si se interes en comprender la cantidad de producto fluyendo a travs de la tubera, como la cantidad ordenada, produjo, o se envi, confiamos en dibujos tcnicos de transaccin que monitorean cada uno de las espitas principales de la tubera. Las fotos peridicas nos dan entendimiento profundo en la cantidad de producto sentndose a punto de suceder, como la orden a cumplirse cuando haya inventario o inventarios de productos terminados, o la cantidad de producto fluyendo a travs de una espita durante un predeterminado lapso de tiempo. La foto de atesoramiento nos ayuda mejor a comprender al estado actual de una orden, as como tambin las velocidades de move-ment del producto para identificar cuellos de botella de la tubera e ineficiencias. Echamos inmediatamente de ver que la foto de atesoramiento mira desemejante de
las otras Tablas de hecho que tenemos, dise hasta ahora. El aprovechamiento de dimen-sions conformado es de esperarse, pero el nmero de fecha y columnas de hecho es mayor que hemos visto en el pasado. Captamos un gran nmero de fechas y hechos como lo
rdenes Rezago de trabajo Mfg La liberacin Productos Terminados Inventario Embarque Facturacin
Figura 5.9
El diagrama de la tubera de cumplimiento de orden.
La Dimensin de Fecha (Los puntos de vista para 9 papeles)
La Dimensin del Almacn de Dimensin de Trato de Dimensin del Cliente El Hecho de Atesoramiento de Cumplimiento de Orden La llave de Fecha de Rezago de Trabajo de la Llave de Fecha de orden (FK) (FK) La liberacin para Confeccionar Llave de Fecha de Colocacin de Inventario de la Llave de Fecha Finished (FK) (FK) Pidi Llave Ship Date (FK) La llave programada (FK) de Fecha de Llegada de la Llave Ship Date Key Actual Ship Date (FK) (FK) La llave de Trato de la Llave del Agente Comercial de la Llave del Cliente de la Llave del Producto de la Llave de fecha de factura (FK) (FK) (FK) (FK) (FK) Confeccionando Llave del Almacn de la Llave de Facilidad (FK) (FK) La cantidad de pedido de Nmero de Factura de Nmero de la Lnea de Orden de Nmero de Orden de la Llave del expedidor (DD) (DD) (DD) (FK) La Cantidad del Dlar de Orden La Liberacin para Confeccionar Cantidad Confeccionando Cantidad de Inspeccin del Paso Confeccionando Cantidad de Inspeccin Fail Finished Goods Inventory Quantity Authorized para la Cantidad Sell La Cantidad de la Factura de Cantidad de Regreso del Cliente de Cantidad de Dao de Embarque de Cantidad de Embarque La Cantidad del Dlar de la Factura Haga El Pedido para Confeccionar Liberacin de Manufactura de Atraso de Liberacin para el Inventario de Atraso de Inventario para el Atraso de Embarque Ordene para el Atraso de Embarque
La Dimensin del Producto La Dimensin del Expedidor de Dimensin de Facilidad de Manufactura de Dimensin del Agente Comercial
Figura 5.10 La mesa de hecho de la foto de atesoramiento de cumplimiento de orden.
Ordene progresos por canales privados. Cada fecha representa un hito principal de la tubera de cumplimiento. Manejamos cada uno de estas fechas como los papeles de dimensin creando ya sea Tablas fsicamente discretas o lgicamente los bien definidos puntos de vista. Es crtico que una llave vicaria sirva para estas dimensiones de fecha en vez de un fechador literal de lenguaje normalizado de consulta porque muchas del hecho posponen la fecha los campos sern Incgnita o Para estar resueltos cuando primero cargamos la fila. Obviamente, no necesitamos declarar todos los campos de fecha en la llave primaria de la mesa de hecho. La diferencia fundamental entre acumular fotos y otras Tablas de hecho es la nocin que volvemos a visitar y actualizamos mesa existente de hecho hace avanzar con el remo a medida que ms la informacin se hace disponible. El grano de una mesa de hecho de la foto de atesoramiento es una fila por el nivel mnimo de detalle captado como la tubera sea en la que se entr. En nuestro ejemplo, el grano igualara una fila por el rubro contable de orden. Sin embargo, a diferencia del hecho de transaccin de orden posponemos que diseamos ms temprano con la misma granularidad, la fila de la mesa de hecho en la foto de atesoramiento es modificada mientras el pedido se mueve por canales privados a medida que ms la informacin es recogida en cada etapa del lifecycle.
Fotos que acumulan tpicamente tienen las fechas mltiples en la mesa de hecho representando los hitos principales del proceso. Sin embargo, solamente porque una mesa de hecho tiene varias fechas no mandan que es una foto de atesoramiento. El diferenciador primario de una foto que acumula actinio es que tpicamente volvemos a visitar las filas de hecho como la actividad tenga lugar.
La tcnica de la foto de atesoramiento es muy til cuando el producto movindose por canales privados est excepcionalmente identificado, como un automvil con un equipo de vehi-cle de la identificacin de nmero, de electrnica con un nmero de serie, especmenes del laboratorio con un nmero de la identificacin, o el proceso confeccionando las cantidades de cosas con un nmero del lote. La foto de atesoramiento nos ayuda a entender enteramente puesto y producir. Si la granularidad de una foto de atesoramiento est en la novela por entregas o nmero del lote, podemos ver la disposicin de un producto discreto como se mueva a travs de la tubera manufacturera y experimental. El atesoramiento que la foto acomoda ms naturalmente con procesos de breve duracin que tienen un comienzo definitivo y cesan. Los procesos longevos, como el banco lleva las cuentas, son mejor modelado con Tablas peridicas de hecho de la foto.
Los Clculos de Atraso La larga lista de fecha las columnas se usa para tomar una medida los intervalos de tiempo sobre el cual el producto es procesado por canales privados. La diferencia numrica entre cualquier dos de estas fechas es un nmero, lo cual puede ser promediado tilmente sobre todas las dimensiones. Estos clculos de atraso de fecha representan medidas bsicas de la eficiencia del proceso de cumplimiento de orden. Podramos construir una vista en esta mesa de hecho tan calculada un gran nmero de estas diferencias de fecha y las podramos presentar al usuario como si fuesen almacenadas en la mesa subyacente. Estos campos de vista podran incluir tales medidas como las rdenes a la liberacin de liberacin de manufacturera atraso, de manufac-turing al atraso acabado de bienes, y le podran mandar para el atraso de embarque, a merced de los intervalos de fecha que su organizacin est
interesada en monitoreo.
Las Mltiples Unidades de Medida Las organizaciones funcionales algunas veces diferentes dentro del negocio quieren ver la misma mtrica de funcin expresada en las diferentes unidades de medida. Por ejemplo, los gerentes manufactureros pueden querer ver el producto fluir en trminos de camas de paja o los casos navieros. Sale y gerentes de mercadeo, por otra parte, pueden tener el deseo de ver las cantidades en los casos por menor, escudriar unidades (las jauras de ventas), o unidades de sumador de contra (como el individuo se atasca de goma). Los diseadores algunas veces estn tentados de enterrar los de unidad de medida factores de conversin, como el factor de caso del barco, en la dimensin del producto. Los usuarios estn entonces obligados apropiadamente multiplicar (o fue eso divide?) La cantidad de pedido por el factor de conversin. Obviamente, este acercamiento coloca una carga en usuarios comerciales,
Adems de ser susceptible para los errores de clculo. La situacin est ms all complicado porque los factores de conversin pueden cambiar con el paso del tiempo, as es que los usuarios tambin necesitaran decidir cul factor es aplicable en un punto especfico con el tiempo. En vez del riesgo calculando mal las cantidades equivalentes colocando factores de conver-sion en la mesa de dimensin, recomendamos que se guarden en la mesa de hecho en lugar de eso. En el ejemplo de la mesa de hecho de la tubera de rdenes, suponga que tuvimos 10 hechos fundamentales bsicos de cantidad, adems de cinco unidades de medida. Si fsicamente almacensemos todos los hechos expresados en las diferentes unidades de medida, sacaramos en limpio 50 (10 la x 5) hechos en cada fila de hecho. En lugar de eso, alcanzamos un compromiso haciendo una fila fsica subyacente de 10 hechos de cantidad y 4 de unidad de medida factores de conversin. Slo necesitamos cuatro de unidad de medida factores de conversin en vez de cinco desde que los hechos de base son ya expresado en una de las unidades de medida. Nuestro diseo fsico ahora tiene 14 hechos relatados en cantidad (10 + 4), como se muestra en Figura 5.11. Con este diseo, podemos ver perfor-mance a travs de la cadena de valor basada en diferentes unidades de medida. Por supuesto, le daramos esta mesa de hecho a los usuarios comerciales a travs de uno o ms puntos de vista. La computacin adicional compleja multiplicar cantidades por factores de conversin son insignificante comparado con otro sistema de gestin de base de datos (el sistema de gestin de base de datos) en lo alto. Las computaciones Intrarow son muy eficientes. La vista ms global en verdad podra mostrar todos los 50 hechos expresados en cada unidad de medida, pero obviamente, podramos simplificar la interfaz de usuario para cualquier grupo del usuario de spe-cific por slo poniendo disponibles las unidades de medida que el grupo quiere ver.
El Hecho de Cumplimiento de Orden El compaero de cita Afina (FKs) Llave del Producto (FK) Ms Llaves Extranjeras Degenere Dimensiones Cantidad De Pedido La Liberacin para Confeccionar Cantidad Confeccionando Cantidad de Inspeccin del Paso Confeccionando Cantidad de Inspeccin Fail Finished Goods Inventory Quantity Authorized para la Cantidad Sell La Cantidad de la Factura de Cantidad de Regreso del Cliente de Cantidad de Dao de Embarque de Cantidad de Embarque Venda Al Por Menor Factor de la Cama de Paja de Factor de Caso de Embarque de Factor de Caso El Factor De Carga del Coche
Los factores estn fsicamente empacados en cada fila de hecho. En la interfaz de usuario, una vista Multiplica fuera de las combinaciones.
Figura 5.11 El soporte para las mltiples unidades de medida con factores de conversin de la mesa de hecho.
Empaquetar todos los hechos y la conversin toma juntos en cuenta el mismo hecho que la fila de la mesa provee la garanta ms segura que estos factores sern usados correctamente. Los hechos conversos se replantean en una vista (s) para los usuarios.
Finalmente, otro beneficio lateral de almacenar estos factores en la mesa de hecho es que reduce la presin en la mesa de dimensin del producto para publicar filas nuevas del producto para reflejar modificaciones menores de factor. Estos factores, especialmente si evolucionan rutinariamente con el paso del tiempo, se comportan hechos ms anlogos antes que dimensionar atributos.
Ms All Del Espejo Retrovisor Mucho de lo que hemos intercambiado opiniones en este captulo enfoca la atencin en formas efectivas para analizar funcin histrica de movimiento del producto. Las personas algunas veces se refieren a estos como la mtrica de espejo retrovisor porque nos dejan vernos atrs y ver dnde hemos estado. Como la industria de corretaje nos recuerda, perfor-mance pasado no es garanta de resultados futuros. La tendencia actual es suplementar estos mtrica histrica de funcin con hechos adicionales que proveen un vislumbre de qu mentiras delante de nosotros. En vez de enfocar la atencin en la tubera a la hora que una orden es recibida, a algunos organismos estn tratando de mudarse ms atrs analice a los conductores cruciales que tienen un impacto sobre la creacin de una orden. Por ejemplo, en una organizacin de ventas, los conductores como prospectar o cotizar activ-ity pueden ser extrapolados para proveerle alguna visibilidad al volumen esperado de activ-ity de orden. Algunos organismos implementan soluciones de gestor de relaciones con el cliente (la gestor de relaciones con el cliente) en parte para ganar una mejor comprensin de gerencia de tacto de contra y otro indicadores anticipados. Mientras los conceptos son sumamente poderosos, tpicamente hay preocupaciones de viabilidad estimando esta informacin proftica anticipada, especialmente si usted se ocupa de una fuente de la coleccin de datos del legado. Porque las organizaciones construyen los productos y los clientes de la cuenta basados en
ordena y factura que los datos, a menudo hacen un trabajo mucho mejor en coleccionar la informacin de espejo retrovisor que lo que hacen los indicativos anticipados. Por supuesto, una vez que las maniobras de organizacin ms all del espejo retrovisor para de fuente fidedigna capturar dan hacia la ventana conduciendo indicadores, estos indicadores pueden agregarse graciosamente para el almacn de datos.
La Comparacin de la Mesa de Hecho Como mencionamos previamente, hay tres tipos fundamentales de Tablas de hecho: Transaccin, foto peridica, y acumulando foto. Todo saque de tres tipos un propsito til; Usted a menudo necesita que dos Tablas complementarias de hecho obtengan un cuadro completo del negocio. Mesa 5.1 compara y contrasta las variaciones.
Mesa 5.1
La Comparacin de Tipo de la Mesa de Hecho
EL ACC UMUL LA O TR ANHIDRGENO ATIN G S LE DA SACTI N GRAIPERIDICO SUN ACABADO La N NAP OT GRAIATERCIOPELA CARACTERSTI N DO Al CA HIDRGENO OT GRAI N El lapso de tiempoEl punto con elLos intervalosEl tiempo representado tiempo normales, indeterminado dio previsibles vueltas, tpicamente De breve duracin Grano Una fila por elUna fila por elUna fila por la vida acontecimiento deperodo transaccin Las cargas de laEl inserto El inserto El inserto y la mesa de hecho actualizacin Las actualizacionesNo vuelto a visitarNo vuelto aVuelto a visitar de la fila de hecho visitar cada vez que la actividad La dimensin deFecha deEl fin de fechaEl mltiplo pasa de fecha transaccin de perodo moda para hitos estndar Hechos La actividad deLa funcin porLa funcin sobre la transaccin el finita duracin de predeterminado una vida espacio de tiempo
Estas tres variaciones de la mesa de hecho no son completamente diferentes porque
comparten dimensiones conformadas, cul son las llaves para Tablas separadas edificadoras de hecho que pueden ser usadas conjuntamente con filtros comunes, consistentes y etiquetas. Mientras las dimensiones son compartidas, la gerencia y ritmo de las tres Tablas de hecho son realmente diferentes.
Las Tablas de Hecho de Transaccin El paisaje ms fundamental de las operaciones del negocio est en el nivel individual de transaccin. Estas Tablas de hecho representan un acontecimiento tan ocurrido en un punto instantneo con el tiempo. Una fila existe en la mesa de hecho para un producto o cliente dado slo si un acontecimiento de transaccin ocurriese. Inversamente, un cliente dado o producto probablemente es asociado a filas mltiples en la mesa de hecho porque esperanzadamente el cliente o el producto est involucrado en ms que una transaccin. Los datos de transaccin a menudo est estructurado muy fcilmente en un trabajo dimensional de marco. Los datos del nivel mnimo estn la mayor parte de datos naturalmente dimensionales, support-ing analiza eso no puede terminar adelante datos resumidos. Los datos nivelados en la transaccin nos dejan analizar comportamiento en el detalle extremo. Una vez que una transaccin ha sido anunciada en carteles, tpicamente no la volvemos a visitar. Habiendo hecho un caso bien fundado para el encanto de detalle nivelado en la transaccin, usted puede pensar ese todo lo que usted necesita es un grande, acelerado sistema de gestin de base de datos para manejar la transaccin ensangrentada
Las minucias, y su trabajo se han acabado. Desafortunadamente, aun con datos nivelados en la transaccin, hay todava una clase entera de preguntas comerciales urgentes que son impracti-cal para contestar usando slo detalle de transaccin. Como indicamos anterior, los modeladores de dimen-sional no pueden sobrevivir sobre transacciones a solas. Las Tablas Peridicas de Hecho de la Foto Las fotos peridicas se necesitan para ver la funcin acumulativa del busi-ness a los normales, previsibles espacios de tiempo. A diferencia del hecho de transaccin posponemos, donde cargamos una fila para cada ocurrencia de acontecimiento, con la foto peridica, sacamos una foto (por lo tanto la terminologa de la foto) de la actividad al final de un da, la semana, o el mes, en ese entonces otro cuadro al final del siguiente perodo, etctera. Las fotos peridicas son apiladas consecutivamente en la mesa de hecho. La mesa peridica de hecho de la foto a menudo es el nico lugar para fcilmente recuperar una vista normal, previsible, tendible de la mtrica comercial crucial de funcin. Las fotos peridicas tpicamente estn ms complicadas que transacciones individuales. Cuando las transacciones corresponden para pocas pedazos de renta, podemos movernos fcilmente de transacciones individuales para una foto diaria meramente sumando el transAc-tions, tan con las Tablas de hecho de la factura de este captulo. En esta situacin, la foto peridica representa una agregacin de la actividad transaccional tan ocurrida durante un lapso de tiempo. Probablemente construiramos la foto diaria slo si necesitsemos una mesa sumaria para las razones de funcin. El diseo de la mesa de la foto est de cerca relacionado con el diseo de su mesa de transaccin del compaero en este caso. La parte de Tablas de hecho que muchas Tablas de dimensin, aunque la foto usualmente tienen menos dimensiona en conjunto. Inversamente, a menudo hay ms hechos en una mesa peridica de la foto que encontramos en una mesa de transaccin. En muchos negocios, sin embargo, las transacciones no son componentes de renta. Cuando usted usa su tarjeta de crdito, usted genera transacciones, pero la fuente primaria de renta del cliente del emisor de la tarjeta de crdito ocurre cuando las retribuciones o los cargos son evaluadas. En esta situacin, no podemos confiar en transacciones a solas analizar funcin de renta. No slo gateando a travs de las
transacciones sera que consume mucho tiempo, pero tambin la lgica requerida para interpretar el efecto de diferentes tipos de transacciones sobre la renta o la ganancia puede estar horrorosamente complicada. La foto peridica otra vez acude al rescate para proveer a gerencia de una vista rpida, flexible de renta. Si Dios quiere, los datos para este dibujo tcnico de la foto es sourced directamente de un sistema operacional. Si no lo es, la zona de estacionamiento de la casa de loza debe incorporar lgica muy complicada para interpretar el impacto de finan-cial de cada tipo de transaccin correctamente en el tiempo de carga de datos. Acumulando Tablas de Hecho de la Foto Por ltimo, pero no menos, el tercer tipo de mesa de hecho es la foto de atesoramiento. Mientras quiz no como comn como los otros dos tipos de la mesa de hecho, atesoramiento
Las fotos pueden ser muy perceptivas. Como acabamos de observar en este captulo, las fotos de accumu-lating representan un indeterminado perodo de tiempo, cubriendo la vida completa de una transaccin o el producto discreto (o el cliente). Fotos que acumulan casi siempre tienen fechadores mltiples, represent-ing los acontecimientos principales previsibles o las fases que tienen lugar durante el curso de toda una vida. A menudo hay una columna adicional de fecha que indica cundo la fila de la foto fue actualizada por ltima vez. Desde muchas de estas fechas no son sabidas cuando la fila de hecho es primera beodas, debemos usar llaves vicarias de fecha para manejar las fechas indefinidas. No hay que acomodar el sce-nario ms complicado que podra ocurrir muy infrecuentemente. El anlisis de estos personas que vive lejos raros siempre puede hacerse en la mesa de hecho de transaccin. En el contraste bien definido para el otro hecho la mesa determina el tipo sanguneo, a propsito volvemos a visitar filas de la mesa de hecho de la foto de accumulat-ing para actualizarlas. A diferencia de la foto peridica, donde estamos guindando encima de la anterior foto, la foto de atesoramiento meramente refleja la mtrica y estatus acumulado. Algunas veces acumulndose y las fotos peridicas funcionan en conjuncin con uno otro. Algo semejante es el caso cuando construimos el incremen-tally mensual de la foto aadindole el efecto de las transacciones de cada da a un atesoramiento disparo conciso. Si normalmente pensamos acerca del almacn de datos como almacenar 36 meses de datos histricos en la foto peridica, en ese entonces el mes actual del rodamiento sera el mes 37. Idealmente, cuando el ltimo da del mes ha sido alcanzado, la foto de atesoramiento simplemente viene bien el mes normal nuevo en la serie temporal, y una foto nueva de atesoramiento comienza al da siguiente. El mes nuevo del rodamiento se convierte en la ola principal de ruptura del almacn. Las transacciones y las fotos son el yin y yang de casas dimensionales de loza de datos. Usadas juntos, la transaccin del compaero y las Tablas de hecho de la foto proveen una vista completa del negocio. Les necesitamos ambos porque haya a menudo ninguna forma simple para combinar estas dos perspectivas contrastantes. Aunque hay algo de redundancia terica de datos entre la transaccin y Tablas de la
foto, no desaprobamos tal redundancia porque como los datos almacenan a los editores publicistas nuestra misin son publicar datos a fin de que el organismo lo pueda analizar eficazmente. Estos los tipos separados de Tablas de hecho que cada uno provee una perspectiva diferente en la misma historia.
Las Particiones de Tiempo Real de Diseo En el pasado asocie los aos, un requisito nuevo principal ha estado aadido que los datos almacenan lista del diseador. El almacn de datos ahora debe prolongar su existente serie temporal histrica como una sola pieza correcta hasta el instante actual. Si el cliente ha hecho un pedido adentro la ltima hora, necesitamos ver esta orden en el contexto de
La relacin entera del cliente. Adems, necesitamos rastrear el estatus de cada hora de esta orden ms actual como cambia durante el da. Si bien el boquete entre los sistemas de procesos de transacciones operacionales y el almacn de datos se ha encogido en la mayora de los casos hasta 24 horas, las necesidades rapaces de nuestros usuarios mercadotcnicos requieren que el almacn de datos llene este boquete con datos de tiempo real cercanos. La mayora de datos almacenan a los diseadores son escpticos ese el extracto existente transforma carga (ETL) que los trabajos simplemente pueden estar de los que se apresur la marcha de un ciclo de 24 horas tiempo para un tiempo ciclista de 15 minutos. Aun si los datos limpiando gradas son pipelined para ocurrir en el paralelo con los datos finales cargando, las manipulaciones fsicas rodeando el hecho ms grande y las Tablas de dimensin simplemente no pueden estar terminadas cada 15 minutos. Los datos almacenan a los diseadores se originan de este crujido construyendo una particin de tiempo real delante del almacn esttico convencional de datos.
Los requisitos para el Tiempo Real La particin
Para lograr informacin de tiempo real, construimos una particin especial que es puesta aparte fsicamente y desde la perspectiva administrativa de las Tablas estticas convencionales del almacn de datos. En verdad, la divisin de nombre es un poco engaoso. La particin de tiempo real en muchos casos no debera ser una particin literal de la mesa en el sentido de la base de datos. Ms bien, la particin de tiempo real es un tema separado de la mesa para la averiguacin y actualizacin especial domina. La particin de tiempo real idealmente debera chocar con el siguiente set escaso de requisitos. Debe:
contiene toda la actividad tan ocurrida desde la ltima actualizacin del almacn esttico de datos. Supondremos que las Tablas estticas estn actualizadas cada noche a la medianoche. conecte tan como una sola pieza como posible para el grano y contenido de los datos estticos almacena Tablas de hecho. sea tanto ligeramente index que los datos entrantes pueden ser continuamente rebotados rpidamente. En este captulo acabamos de describir los tres tipos principales de Tablas de hecho: El grano de transaccin, el grano peridico de la foto, y acumularse le toman instantneas al grano. La particin de tiempo real hace una estructura diferente correspondiente a cada hecho posponer tipo. El Grano de Transaccin la Particin de Tiempo Autntico Si los datos estticos almacenan mesa de hecho tiene un grano de transaccin, en ese entonces contiene exactamente un registro para cada transaccin individual en el sistema de la fuente de
El comienzo de historia grabada. Si ninguna actividad ocurre adentro un lapso de tiempo, no hay registros de transaccin. Inversamente, puede haber una ventisca de cerca transaccin relacionada registra si la actividad nivel es alta. La particin de tiempo real tiene estructura dimensional exactamente igual como su mesa esttica subyacente de hecho. Slo contiene las transacciones que han ocurrido desde la medianoche, cuando cargamos las Tablas normales del almacn de datos. La particin de tiempo real puede ser com-pletely unindexed ambos porque necesitamos mantener una ventana continuamente abierta para cargar y porque no hay serie temporal (desde que slo guardamos hoy los datos en esta mesa). Finalmente, evitamos construir agregados en esta mesa porque queremos un minimalist panorama administrativa durante el da. Adjuntamos la particin de tiempo real a nuestras aplicaciones existentes entrenndose en frente de la mesa esttica de hecho para la particin de tiempo real. Las agregaciones de series temporales (por ejemplo, todas las ventas para el mes corriente) necesitarn enviar las averiguaciones idnticas a las dos Tablas de hecho y sumarlas. En un ambiente relativamente por menor grande experimentando 10 millones de transacciones al da, la mesa esttica de hecho sera bonita grande. Suponiendo que cada registro del grano de transAc-tion es 40 bytes anchos (ventaja de 7 dimensiones 3 hechos, todo apiado en campos de 4 bytes), acumulamos 400 megabyte de datos cada da. Durante un ao a que esto equivaldra acerca de 150 el gygabyte de datos sin procesar. Tal mesa de hecho estara pesadamente indizada y soportada por agregados. Sin embargo, el tranche diario de 400 el megabyte para la particin de tiempo real podra ser prendido con alfileres en la memoria. Se les olvida los ndices, excepto por una B-Tree indexe en la mesa de hecho llave primaria para facilitar la carga ms eficiente. Olvide agregaciones tambin. Nuestra particin de tiempo real puede permanecer biselada hacia la funcin de carga muy rpida pero al mismo tiempo puede proveer funcin rpida de averiguacin. Desde que enviamos las averiguaciones idnticas a la mesa esttica de hecho y el parti-tion de tiempo real, nos relajamos y dejamos salir al tipo del navegante del agregado ya sea cualquier de las Tablas tienen soportar agregados. En el caso del que acabamos descrito, slo la mesa esttica grande los necesita.
La Foto Peridica la Particin de Tiempo Autntico Si los datos estticos almacenan mesa de hecho tiene un grano peridico (digamos, mensualmente), en ese entonces la particin de tiempo real puede ser mirada como el mes que comienza a rodar caliente actual. Supongo que trabajamos para un banco minorista grande con 15 millones de cuentas. La mesa esttica de hecho tiene el grano de cuenta por el mes. Una serie temporal de 36 meses resultara adentro 540 mesa de hecho de milln registros. Otra vez, esta mesa sera indexada extensamente y contara con el respaldo de agregados proveer buena funcin de averiguacin. La particin de tiempo real, por otra parte, es simplemente una imagen del mes actual de revelado, actualizada continuamente como el mes progresa. Semiadditive se balancea y los hechos completamente aditivos estn ajustados tan frecuentemente como son reportados. En un banco minorista, lo
La mesa de hecho de fondo extendindose a lo largo de todo lo que la cuenta escribe tiene probabilidad de ser muy estrecho, con por casualidades 4 dimensiones y 4 hechos, dando como resultado una divisin de tiempo real de 480 megabyte. La particin de tiempo real otra vez puede ser prendida con alfileres en la memoria. Las aplicaciones de averiguacin entrenndose en frente del hecho esttico posponen para la par-tition de tiempo real tiene una lgica ligeramente diferente comparada con el grano de transaccin. Aunque la cuenta se balancea y otras medidas de intensidad pueden ser tendidas directamente a travs de las Tablas, los totales aditivos acumulados durante el perodo actual del rodamiento pueden necesitar ser escamosos hacia arriba para el equivalente de un mes completo para mantener los resultados lejos de verse anmalos. Finalmente, en el ltimo da del mes, esperanzadamente el atesoramiento par-tition de tiempo autntico slo puede estar cargado encima del almacn esttico de datos como el mes ms actual, y el proceso puede comenzar de nuevo con una particin de tiempo real vaca. Acumulando Foto La Particin de Tiempo Real Fotos que acumulan sirven para procesos de breve duracin como las rdenes y los embarques. Un registro se le crea cada rubro contable sobre la orden o el embarque. En la mesa principal de hecho este registro est actualizado repetidamente como la actividad ocurre. Nosotros cre-eat el registro para un rubro contable cuando la orden es primera colocamos, y en ese entonces lo actualizamos cada vez que el artculo es enviado, entregado para el destino final, est pagado, o tal vez es devuelto. Acumulando Tablas de hecho de la foto tiene un set caracterstico de fecha llaves extranjeras correspondiente a cada uno de estos pasos. En este caso es engaosa llamar la esttica principal de la mesa de hecho de atesoramiento porque ste es el nico tipo de la mesa de hecho que est deliberadamente actualizado, a menudo repite edly. Sin embargo, supongamos que pues la funcin de averiguacin razona esta actualizacin ocurre slo a la medianoche cuando los usuarios son no en la Internet. En este caso, la particin de tiempo real consistir slo esos rubros contables que han estado actualizados hoy.
Al final del da, los registros en la particin de tiempo real sern precisamente las nuevas versiones de a los registros que necesitan para estar escritos encima del hecho principal posponen ya sea insertando los registros si son completamente nuevos o sobrescribiendo registros de exist-ing con las mismas llaves primarias. En muchas orden y situaciones de embarque, el nmero de rubros contables en la particin de tiempo real ser significativamente ms pequeo en los primeros dos ejemplos. Por ejemplo, un fabricante puede ir en procesin acerca de 60,000 facturas de embarque al mes. Cada factura puede tener 20 rubros contables. Si una lnea de la factura tiene una normal duracin de una vida de 2 meses y est actualizada 5 veces en este intervalo, entonces nos ocuparamos de 7,500 rubros contables actualizados adelante un promedio da de trabajo. Aun con los registros ms bien de 80 bytes anchos tpicos de Tablas de hecho de atesoramiento de la factura de embarque, slo tenemos 600 kB (7,500 actualizaron rubros contables por x de da 80 bytes) de datos en nuestra particin de tiempo real. Esto obviamente encajar en memoria. Olvide ndices y agregaciones en esta particin de tiempo real.
Las averiguaciones en contra de una foto de atesoramiento con una necesidad de la particin de tiempo real para ir a traer los rubros contables apropiados de ambos el hecho principal posponen y la particin y tampoco pueden entrenarse a travs de las dos Tablas realizando una clasificacin por fusin (la juntura exterior) en los encabezados idnticos de la fila o realizan una unin de las filas de las dos Tablas, presentando la vista esttica aumentada con filas suplementarias ocasionales en el informe representando la actividad caliente de hoy. En este pasaje hemos defendido la causa de cancelar lo require-ment de tiempo real nuevo con extensiones especialmente construidas pero no obstante familiares para nuestras Tablas existentes de hecho. Si usted deja caer todos los ndices (excepto por un ndice anticido de B-Tree para actualizar) y agregaciones en estas Tablas nuevas especiales y los prende con alfileres en la memoria, usted debera poder tener la actualizacin combinada e interrogar a perfor mance necesitado.
Resumen En este captulo cubrimos una larga lista del lavandero de temas del contexto del proceso administrativo de orden. Discutimos mltiplos en varias partes delanteras: Las referencias mltiples para la misma dimensin en una mesa de hecho (la caracterizacin de papeles de dimensin), unidades equivalentes de mul-tiple de medida, y las monedas circulantes mltiples. Exploramos sev-eral de los retos comunes encontrados cuando datos de rdenes que modelando, incluyendo hechos en niveles diferentes de granularidad y las dimensiones de trastos viejos. Tambin hicimos un reconocimiento del set sustancioso de hechos asociados con transacciones de la factura. Usamos la tubera de cumplimiento de orden para ilustrar el poder de Tablas de hecho de la foto de atesoramiento. Fotos que acumulan nos dejan ver el sta-tus actualizado de una orden o producto especfico como se mueve a travs de una tubera finita. El captulo cerr con un resumen de las diferencias entre los tres tipos de funda-mental de Tablas de hecho, junto con sugerencias para manipular cerca de informacin de tiempo real con cada tipo de la mesa de hecho.
EL CARBONO HAPTE R
La Relacin del Cliente

Gerencia
El ong antes de gestor de relaciones con el cliente (la gestor de relaciones con el cliente) fue una expresin de moda, organiza-tions diseara y fuera desarrollar modelos dimensionales cntricos en cliente para mejor comprender comportamiento de sus clientes. Pues casi dos decenios estos modelos se han usado para responder para las averiguaciones de la gerencia acerca de las cuales a clientes les fue solicitados, que respondi, y cul fue la magnitud de su respuesta. El percibido valor comercial de comprender la spec-trum llena de las interacciones de clientes y las transacciones ha propulsado gestor de relaciones con el cliente para la parte superior de las grficas. La gestor de relaciones con el cliente ha tomado forma de una estrategia comercial crtica para la misin que muchas vista como la condicin para la supervivencia de una compaa. En este captulo que discutimos las implicaciones de gestor de relaciones con el cliente en el mundo de datos tiene cuidado con alojando. Dado el inters amplio en la gestor de relaciones con el cliente, hemos ubicado ms espacio que usual para una visin general de los principios bsicos. Desde que los clientes desempean un papel en tantos procesos comerciales dentro de nuestras organizaciones, en vez de dibujos tcnicos de develop-ing para reflejar toda interaccin del cliente y la
transaccin que los hechos capturaron, le asignaremos la mayor parte de este captulo a la mesa de dimen-sion del cliente de mucha importancia.
la visin general de gestor de relaciones con el cliente, incluyendo sus papeles operacionales y analticos el nombre del cliente y la direccin analizando gramaticalmente, junto con consideraciones internacionales los atributos comunes de dimensin del cliente, como las fechas, los atributos de segmentacin, y agregados los arbotantes de dimensin para grupos grandes de atributos de low-cardinality
141
Minidimensions para el atributo haciendo una lectura ligera y el cambio que el rastreo en gran escala dimensiona, as como que sets de atributo de anchura variable las implicaciones de tipo utilizador 2 desacelerar tcnica de dimensin cambiante de adelante dimensionan tiene importancia el estudio de comportamiento se agrupa para rastrear un set de clientes que exhiben comportamientos o character-istics comn las consideraciones comerciales de jerarqua del cliente, incluir ambos arreglaron y profundidad variable combinando datos del cliente de fuentes mltiples de datos los datos analizadores del cliente a travs de los procesos comerciales mltiples
La visin general de gestor de relaciones con el cliente Sin tener en cuenta la industria, las organizaciones viajan en tropel para el concepto de gestor de relaciones con el cliente. Se arriman al sol que ms calienta en un intento a emigrar de una orientacin cntrica en producto para una que es conducido por cliente necesita. Mientras los trminos que abarca todo como gestor de relaciones con el cliente algunas veces parecen ambiguos o excesivamente ambiciosos, la premisa en pos de la gestor de relaciones con el cliente est muy distante de ciencia del cohete. Se basa en la nocin simple que mientras mejor usted conoce a sus clientes, lo que mejor usted puede mantener relaciones bastante duraderas, valiosas con ellos. La meta de gestor de relaciones con el cliente es maximizar relaciones con su Cu-tomers sobre su duracin de una vida. Conlleva enfocar todos los aspectos del negocio, de comercializar, las ventas, las operaciones, y el servicio, para las relaciones establecedoras y sustentadoras y mutuamente propicias del cliente. Para hacer eso, la organizacin debe desarrollar una vista sola, integrada de cada cliente. La gestor de relaciones con el cliente promete regresos significativos pues las organizaciones que se abrazan eso en trminos de ambos aument renta y mayores eficiencias operacionales. La alternacin para un Cu-tomer-tomer-drive a la que la perspectiva puede conducir aument efectividad de ventas y tasas de cierre, crecimiento de renta, productividad realzada de ventas en el coste reducido, mrgenes mejorados de rentabilidad del cliente, satisfaccin ms alta del cliente, y
aument retencin del cliente. Finalmente, cada organismo quiere ms clientes leales, ms provechosos. Desde que a menudo requiere que una inversin considerable atraiga a los clientes nuevos, no podemos permitirnos el lujo de tener los provechosos permiso de ausencia. Asimismo, uno de objetivos de gestor de relaciones con el cliente debe convertir a clientes poco lucrativos en provechosos. En muchas organizaciones, la vista del cliente vara a merced de la lnea de productos, unidad comercial, funcin comercial, o posicin geogrfica. Cada grupo puede usar datos diferentes del cliente de diferentes maneras con resultados diferentes. La evolucin de los silos existentes para un obvi-ously ms perspectivo integrado requiere compromiso organizativo. La gestor de relaciones con el cliente es como un cartucho de dinamita que derriba las paredes del silo. Requiere la integracin correcta de procesos comerciales, recursos de personas, y tecnologa aplicativa ser efectivo.
En muchos casos, los procesos comerciales existentes para interacciones del cliente han evolucionado con el paso del tiempo como la organizacin operacional o circunvene. El set resultante de la labor hecha con trozos de varios colores de procesos relatados por cliente es a menudo torpe en el mejor de los casos. Meramente mejor automatizando los procesos cntricos en cliente ineficientes actuales en verdad puede hacer ms dao que sin hacer nada del todo. Si usted es confrontado con procesos arruinados, los ajustes operacionales son menester. Desde que es naturaleza humana resistir cambio, no es de extraar que los asuntos relatados por personas a menudo desafan implementaciones de gestor de relaciones con el cliente. La gestor de relaciones con el cliente implica nuevos mtodos de interactuarle a sus clientes. A menudo conlleva cambios radicales para los canales de ventas. La gestor de relaciones con el cliente requiere que flujos de informacin nuevos sean basados en la diseminacin y adquisicin completa de datos del punto de toque del cliente. A menudo las estructuras organiza tion y los sistemas de incentivos estn alterados dramticamente. Desafortunadamente, usted slo no puede comprar un producto de gestor de relaciones con el cliente disponible en estantes y puede esperar que eso sea una bala de plata que soluciona todos sus problemas. Mientras muchas organizaciones canalizan su atencin a tecnologa de gestor de relaciones con el cliente, al fin ste puede ser el componente ms simple con el cual para contender se compar a otros mayores asuntos. Obviamente, el mejor lugar para iniciar gestor de relaciones con el cliente est con una estrategia y un plan. Abordar la adquisicin de tecnologa primero en verdad puede impedir progreso para un imple-mentation atinado de gestor de relaciones con el cliente. La tecnologa debera mantener, no debera conducir, su solucin de gestor de relaciones con el cliente. Apagada a With una estrategia cuerda de gestor de relaciones con el cliente, una tecnologa meramente puede acelerar caos organizativo a travs de la implementacin de silos adicionales. Ms temprano en este libro que manifestamos que es imperativa que ambas heces de mayor categora y tecnologa de la informacin administrativa soporten una iniciativa que almacena datos. Enfatizamos este consejo otra vez en lo que se refiere a una implementacin de gestor de relaciones con el cliente por las implicaciones de su foco funcional en la cruz. La gestor de relaciones con el cliente requiere vista comercial evidente. Sin estrategia de busi-ness, se provea, y la autorizacin a
cambiar, la gestor de relaciones con el cliente se convierte en un ejercicio en la futilidad. Ni la comunidad de tecnologa de la informacin ni el mundo de los negocios son capaces de implementar gestor de relaciones con el cliente exitosamente en el suyo; Exige un compromiso unido de soporte.
La operacional y Analtica gestor de relaciones con el cliente Podra decirse que la gestor de relaciones con el cliente padezca de un sndrome hendido de personalidad porque se ocupa de ambos requisitos operacionales y analticos. La efectiva gestor de relaciones con el cliente confa en la recopilacin de datos en cada interaccin que tenemos con un cliente y en ese entonces el apalancamiento de esa anchura de datos a travs de anlisis. En la parte delantera operacional, las llamadas de gestor de relaciones con el cliente para la sincronizacin de procesos que miran hacia cliente. A menudo los sistemas operacionales deben ser uno u otro actualiz o supple-mented para coordinar a travs de las ventas, comercializando, las operaciones, y el servicio. Piense acerca de todas las interacciones del cliente que ocurren durante la compra y uso de un producto o el servicio del contacto inicial de prospecto, se abre comillas generacin,
La transaccin de compra, el cumplimiento, la transaccin de pago, y el servicio de Cu-tomer en curso. En vez de pensar acerca de estos procesos como silos independientes (o los silos mltiples que difieren por lnea de productos), la gestor de relaciones con el cliente establecida en mente es para inte-grate estas actividades del cliente. Cada punto de toque en el ciclo de contacto del cliente representa una oportunidad para coleccionar ms mtrica del cliente y characteris-tic, as como tambin efecto de palanca existiendo datos del cliente para extractar ms valor de la relacin. Como datos es creado en el lado operacional de la ecuacin de gestor de relaciones con el cliente, obviamente necesitamos almacenar y analizar el histrico mtrica resultando de nuestro sistemas del cliente de interaccin y de transaccin. Los sonidos familiares, no hace eso? El almacn de datos se sienta al corazn de gestor de relaciones con el cliente. Hace las funciones del confidente para la colecta e integra la anchura de informacin del cliente encontrada en nuestro sys-tems operacional, as como tambin de fuentes externas. El almacn de datos es la fundacin que soporta la vista de 360 grados panormica de nuestros clientes, incluyendo datos de Cu-tomer de las siguientes fuentes tpicas: Los datos transaccionales, los datos de interaccin (las solicitaciones, el centro de llamada), los datos demogrficos y conductistas (tpicamente aumentado por tercera parte festeja), y los datos que se proveen solos del perfil. La analtica gestor de relaciones con el cliente est habilitada por datos precisos, integrados del cliente, y asequibles en el almacn. Podemos medir la efectividad de decisiones hechas en el pasado para optimizar interacciones futuras. Los datos del cliente pueden ser apalancados para mejor identificar arriba venda y crcese venden oportunidades, localizan con precisin inef-ficiencies, generan exija mucho, y mejore retencin. Adems, podemos palanquear edad los datos histricos, integrados para generar modelos o puntuaciones que cierran la autoconexin para el mundo operacional. Recordando los componentes principales de un ambiente de la casa de loza de Captulo 1, podemos visualizar los resultados modelo empujados de regreso a donde la relacin es operacionalmente administrado (por ejemplo, el agente comercial, el centro de llamada, o la Web sita), como ilustrado en Figura 6.1. El modelo que la salida puede traducir a las especficas tcticas proactivas o reactivas recomend para el siguiente punto de contacto del cliente, como la respuesta apropiada de siguiente producto de oferta o de antiat-trition. Los
resultados modelo tambin son retenidos en los datos almacena para subsiguiente anlisis. En otras situaciones, la informacin debe alimentarse de regreso al sitio Web operacional o debe llamar a los sistemas centrales sobre una base ms de tiempo real. Este tipo de soporte operacional es apropiadamente la responsabilidad de la tienda operacional (los desarrollos organizativos) de datos, tan descrita en Captulo 1. En este caso, el circuito cerrado est mucho ms apretado que Figura 6.1 porque sea cuestin de coleccin y almacenamiento y entonces la informacin retroactiva para el sistema de col-lection. Los desarrollos organizativos generalmente no requieren la anchura o la profundidad de informacin de Cu-tomer disponible en el almacn de datos; Contiene un subconjunto de datos requeridos por las aplicaciones del punto de toque. Asimismo, lo require-ments de integracin no es tpicamente tan escaso.
Intgrese (Los Datos Escenificando)
Cobre (el Sistema Operacional de la Fuente) Tienda (La Presentacin de Datos)
Modelo (Los Datos Acceden a las Herramientas)
Analice e Informe
Figura de gestor de relaciones con el cliente de 6.1 Circuitos Cerrados de analtico.
Obviamente, como la organizacin se pone ms centrada en el cliente, as es que debe el almacn de datos. La gestor de relaciones con el cliente inevitablemente conducir cambio en la casa de loza de datos. Los almacenes de datos cultivarn aun ms rpidamente como coleccionamos ms y ms informacin acerca de nuestros clientes, especialmente de fuentes de oficinas centrales como la fuerza del campo. Nuestros procesos de escenificacin de datos cultivarn ms complicado como correspondamos e integremos datos de fuentes mltiples. Ms importante, la necesidad para una dimensin conformada del cliente se pone aun ms suprema.
La empacada gestor de relaciones con el cliente En respuesta a la necesidad urgente de negocio para la gestor de relaciones con el cliente, los equipos de proyecto pueden forcejear con una compra versus la decisin de la constitucin. A largo plazo, el acercamiento de la constitucin puede corresponder a requisitos de la organizacin mejor que el applica-tion empacado, pero la implementacin probablemente tomar ms tiempo y requerir ms recursos, potencialmente en un costo ms alto. Comprar una aplicacin empacada dar una solucin prcticamente lista para arrancar, pero no puede enfocar la atencin en el integra-tion y asuntos de la interfaz necesitados que l funcione en el mayor contexto de tecnologa de la informacin. For-tunately, algunos proveedores es intercambio comn de datos de respaldo a travs del Lenguaje Extensible (XML) del Apunte, publicando sus especificaciones de datos a fin de que pueda extraer datos de dimensin y de hecho, y soportando dimensiones conformadas creadas por
el usuario. Comprando una solucin empacada, sin tener en cuenta su anchura aplicativa, no nos da una excusa para capear el reto de crear conformado dimensiones,
Incluyendo la dimensin del cliente. Si fracasamos en darle la bienvenida al appli-cation empacado como un miembro lleno del almacn de datos, en ese entonces tiene probabilidad de convertirse en un centro de compras de datos de la tobera. La aplicacin empacada no debera tener importancia para la informacin del cliente de dis-connect estando sentada sobre otra isla de datos. La alharaca publicitaria reciente de gestor de relaciones con el cliente se basa en la nocin que tenemos una vista integrada del Cu-tomer. Cualquier componente comprado debe ser asociado a una casa comn de loza de datos y dimensiones conformadas. De otra manera, recin hemos armado a nuestros analistas de empresas con acceso para los datos del cliente ms inconsistentes, resultando en ms anlisis inconsistente del cliente. La a ltima hora cualquier organizacin necesita es otra tobera de datos, as tambin vaya de fijo a integrar cualquier solu-tion empacado correctamente.
La Dimensin del Cliente La dimensin conformada del cliente es un elemento crtico para la efectiva gestor de relaciones con el cliente. Un pozo bien mantenido, destacado conformar dimensin del cliente es el cor-nerstone de anlisis cntrico en cliente cuerdo.
La dimensin del cliente es tpicamente la dimensin ms desafiante para cualquier almacn de datos. En una organizacin abrumadora, la dimensin del cliente puede ser sumamente profunda (con millones de filas), sumamente ancha (con docenas o aun centenares de atributos), y algunas veces puede supeditarse ms bien cambio rpido. Un comercializador directo delantero sostiene que sobre 3,000 atributos acerca de sus clientes. Cualquier organizacin que se ocupa del pblico general necesita una dimensin individual del ser humano. Los detallistas ms grandes, compaas de la tarjeta de crdito, y organismos gubernamentales tienen dimensiones del cliente del monstruo cuyos tamaos exceden 100 filas de milln. Para fomentar materias complejas, la dimensin del cliente a menudo representa una amalgamacin de datos de mltiples sistemas internos y externos de la fuente. En esta siguiente seccin que canalizamos al numeroso diseo de dimensin del
cliente aprende de memoria sideraciones. Los datos del cliente que mantenemos diferirn segn que manejamos en un ambiente del cliente negocio a negocio (B2B), como distribuidores, versus un modo negocio a consumidor (B2C). Independientemente, muchas de estas consideraciones se aplican a ambas panoramas. Comenzaremos con nombre /direccin analizando gramaticalmente y otro cliente comn atribuye, incluyendo cobertura de arbotantes de dimensin. Desde all discutiremos Tablas de minidimensin para ocuparnos de funcin de averiguacin y cambio rastreador en dimensiones muy grandes de Cu-tomer. Tambin describiremos el uso de dimensiones del grupo de estudio de comportamiento para rastrear actividad en curso para un grupo de clientes que comparten una caracterstica comn. Finalmente, trataremos con jerarquas del cliente del anuncio publicitario de profundidad fija y variable.
El Nombre y el Anlisis Gramatical de la Direccin Sin tener en cuenta si trata con seres humanos individuales o entidades de com-mercial, tpicamente captamos nombre de nuestros clientes y ponemos la direccin en attrib-utes. El manejo operacional de nombre e informacin de la direccin es usualmente demasiado simplista para ser muy til en el almacn de datos. Muchos diseadores consideran que un diseo generoso de columnas de uso general para los nombres y direcciones, como Name-1 a travs de Name-3 y Address-1 a travs de Address-6, puede manejar cualquier situacin. Desafortunadamente, estas columnas del catchall son virtualmente una porquera en lo que se refiere a mejor entender y segmentar la base del cliente. Design-ing a lo que el nombre y columnas de la posicin en una forma genrica en verdad pueden contribuir problemas de calidad de datos. Considere el diseo de muestra en Mesa 6.1 con columnas de uso general. En este diseo, la columna de nombre est mucho ms limitada. No hay mecanismo consistente para manejar saludos, ttulos, o sufijos. No podemos identificar lo que el nombre de pila de la persona es o cmo debera ser ella dirigida la palabra en una person-alized saludando. Si mirsemos datos de muestra adicionales de este sistema operacional, potencialmente encontraramos que los clientes mltiples apuntaron en la lista un campo de sola firma. Tambin podramos encontrar informacin descriptiva adicional en el campo de nombre, como Confidential, el fideicomisario, o UGMA (el Regalo Uniforme para Minors Act). En nuestros campos de direccin de muestra, las abreviaturas inconsistentes son usadas en lugares diversos. Las columnas de la direccin pueden contener espacio suficiente para cualquier direccin, pero no hay disciplina impuesta por las columnas que garantizarn conformidad con reglas de administracin de Correos o direccin del soporte haciendo buena pareja o la identificacin de latitud /longitud.
Mesa 6.1 la Dimensin del Cliente de Muestra con Columnas Excesivamente Generales
LA B DI M ENSION ATTRI UTE Nombre Address-1 Address 2 Ciudad El estado CDIGO POSTAL Nmero De Telfono maestra, 555-4444
EL EXAMEN P LE VALU ES Seora R. Juana Smith, Atty 123 Main Rd, al norte al oeste, Ste 100A apartado postal 2348 Kensington Arca. 88887-2348 El fax 888-555-3333 x776 de caera
En lugar de usar algunos campos de uso general, el nombre y los atributos de la posicin deberan estar arruinados abajo en tantas partes elementales tan posible. El proceso del extracto necesita realizar anlisis gramatical significativo sobre los nombres sucios originales y las direcciones. Una vez que los atributos han sido analizados gramaticalmente, en ese entonces pueden ser standard-ized. Por ejemplo, Rd se convertira en Va y Ste vendra bien la Suite. Los atributos tambin pueden verificarse, como validar eso el cdigo postal y la combinacin estatal asociada est en lo correcto. Afortunadamente, el nombre y los datos de la direccin limpiando y fregando herramientas estn disponibles en el mercado para ayudar analizando gramaticalmente, estandarizacin, y verificacin. Una muestra colocada de nombre y atributos de la posicin para individuos en a los Estados Unidos le son mostrados en Mesa 6.2. Hemos suplido cada atributo para hacer el diseo ms claro, excepto ninguna sola instancia autntica se parecera a esta fila.
Mesa 6.2 la Dimensin del Cliente de Muestra con Nombre Analizado Gramaticalmente y los Elementos de la Direccin
DI M ENSION ATTRI BUTE Saludo Bienvenida a Nombre los Segundos Nombres
EL EXAMEN P LE VALU ES El Seora Informal Dndole la Juana Nombre Formal de Saludo La Seora Primera Parte Smith y R. Jane Surname Smith Suffix Jr. Etnicidad El Ttulo Ingls El Nmero de la Calle del 123 Principal Va El norte al oeste 2348 100A Kensington District El El Estado Berkeleyshire Arkansas Region Sur Estados Unidos
Abogado Titular Genrico El Tipo Callejero La Direccin Callejera Buzn Suite Ciudad Distrito de Segundo del Cornwall Pas
(Contina)
Mesa 6.2 Continuada. DI M ENSION ATTRI BUTE Continent Norte Primary Postal El cdigo postal Postal secundario El Tipo Postal de Cdigo El Cdigo Del Pas del Telfono de la Oficina El Cdigo De rea del Telfono de la Oficina El Nmero De Telfono de la Oficina La Extensin de la Oficina El cdigo del pas del Telfono del FAX El cdigo de rea del Telfono del FAX El nmero de telfono del FAX Direccin de correo electrnico Customer Idaho7346531 El EXAMEN P LE VALU ES El cdigo postal de Amrica del 88887 2348 Estados Unidos 1 888 5553333 776 1 888 5554444 RSitio WebEl wwUnique
Los clientes comerciales tpicamente tienen direcciones mltiples, como el reconocimiento mdico y las direcciones navieras; Cada uno de estas direcciones seguiran mucho la misma lgica como la estructura de la direccin que acabamos de desarrollar. Antes de dejar este tema, es digno de reparar en que algunos organismos mantienen la coleccin completa de nombre y se ocupan de caractersticas en su dimen-sion del cliente para producir direcciones listas en correo, as como tambin canales de com-munication del otro del soporte como telfono, enve un fax, y el correo
electrnico, en seguida del almacn de datos. Aqu los datos almacenan dimensin del cliente se convierte en un tipo de sistema operacional porque es la autoridad ancha en la empresa para direcciones vlidas. Esto tiene ms probabilidad de ocurrir cuando ningn otro sistema operacional se ha hecho responsable de consolidar informacin del cliente a travs del apalancamiento de interlineacin. En otros casos, los organismos ya han decidido captar solicitacin y comunicacin tocan puntos en un sistema operacional. En estos environ-ments, la dimensin del cliente en el almacn puede consistir en un subconjunto ms reducido de atributos significativos para anlisis, a distincin de la coleccin completa de atributos necesarios para generar las etiquetas de correo o detalles de la lista de llamada. La Direccin y Nombre Internacional Consideraciones El cliente que los atributos geogrficos se ponen ms complicados si tratamos con clientes de pases mltiples. Aun si usted no tiene internacional
Clientes, usted puede necesitar hacerle frente a las direcciones y nombres internacionales en alguna parte de su almacn de datos para proveedores internacionales o los registros humanos del personal de recursos. Al idear una solucin para nombres internacionales y las direcciones, necesitamos tener a la vista lo siguiente, adems del nombre y direccin analizando gramaticalmente requisitos discutimos ms temprano: La representacin universal. El diseo debera ser consistente de pas para pas a fin de que los datos similares que los elementos aparecen en lugares previsibles, similares en el cliente dimensionen mesa. La exactitud cultural. Esto incluye el saludo apropiado y personal-ization para una carta, correo electrnico, o telfono saludando. Las diferencias en direcciones. Las direcciones diferentes pueden ser requeridas ya sea son envos postales extranjeros del pas de origen para el coun-try del destino (incluyendo idiosincrasias tan presentante la ciudad del destino y el pas en maysculas), envos postales domesticados dentro del coun-try del destino, y los servicios a domicilio del paquete (cul no acoge apartados de correos). Los atributos que describimos ms temprano son todava aplicables para lo direcciones y nombres internacionales. Adems, deberamos incluir un atributo del bloque de la direccin con una direccin postal vlida completa incluyendo suspensiones de la lnea dadas en el orden adecuado segn las reglas del pas del destino. Creando este atributo una vez en el proceso de escenificacin, basado en el pas correcto por reglas de formacin de la direccin del pas, simplifica corriente abajo uso. Similares para direcciones internacionales, los nmeros de telfono deben ser dif-ferently presentado a merced de donde la llamada telefnica es originada. Necesitamos proveer atributos para representar la secuencia extranjera completa de discado, completar al domstico marcando secuencia, y la secuencia local de discado. Desafortunadamente, la secuencia extranjera completa de discado variar por pas de origen. Apenas hemos rasguado la superficie concirnindole las complejidades de nombres de interna-tional y las direcciones. Para la cobertura ms detallada,
recomendamos el libro de Toby Atkinson sobre el tema, el Gua de Merriam-Webster a International Busi ness Communications (Merriam-Webster, 1999).
Otros Atributos Comunes del Cliente Mientras los atributos geogrficos son una cierta cantidad de los atributos ms comunes encontraron en una dimensin del cliente, aqu son otros que usted probablemente encontrar. Por supuesto, la lista de cliente atribuye tpicamente es muy largo. La ms informacin descriptiva que captamos acerca de nuestros clientes, lo ms robusto la dimensin del cliente sern y lo ms interesante el anlisis.
La Mesa de Hecho La llave del Cliente Transasction Date Key (FK) (FK) Ms Hechos Extranjeros de Llaves
La Dimensin del Cliente El cliente la Ciudad del Cliente de Apellido del Cliente de Nombre de Pila del Cliente de Saludo del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) Los atributos del Cliente del Estado del cliente Pasan de Moda de Compra 1 (FK)
Creo que 6.2 el Compaero de Cita dimensiona arbotante.
Fechas La fecha de Dimensin 1 de Compra La fecha de Fecha 1 de la Llave de Compra (PK) de Compra 1 La fecha de Mes 1 de Compra
La fecha de Ao 1 de Compra La fecha de Fecha 1 de Mes del Fiscal de Compra de Fecha 1 del Cantn del Fiscal de Compra de Compra 1 Fiscal Year Date del 1 Purchase Season y ms
A menudo encontramos que las fechas en la dimensin del cliente, como la fecha de primera compra, pasan de moda de ltima compra, y la fecha de nacimiento. Aunque estas fechas inicialmente pueden ser campos del formato de fecha de lenguaje normalizado de consulta, si queremos tomar ventaja completa de nuestra dimensin de fecha con la habilidad a resumir estas fechas por los atributos especiales del calendario de nuestra empresa, como las estaciones, aloja, y los perodos fiscales, las fechas deberan variarse para las referencias cruciales extranjeras para la dimensin de fecha. Necesitamos ser cuidadosos que todas tales fechas caen en un plazo del intervalo de nuestra dimensin corporativa de fecha. Estas copias de dimensin de fecha son declaradas como semnticamente bien definidos puntos de vista, como una Primera Fecha de Compra mesa de dimensin con etiquetas nicas de la columna. El sistema se comporta como si hay otra mesa fsica de fecha. Las restricciones en cualquiera de estas Tablas no tienen nada que ver con restricciones en la mesa primaria de dimensin de fecha. Mostrado de adentro Figura 6.2, este diseo es un ejemplo de un arbotante de dimensin, cul discutiremos ms all ms tarde en este captulo. Las fechas fuera del intervalo de nuestra dimensin de fecha de corpo-rate deberan ser representadas como campos de fecha de lenguaje normalizado de consulta.
La Segmentacin del Cliente Los Atributos y las Puntuaciones Algunos de los atributos ms poderosos en una dimensin del cliente son clasificaciones de segmenta-tion o puntuaciones. Estos atributos obviamente varan en gran medida por el contexto de busi-ness. Para un cliente individual, pueden incluir: gnero etnicidad la edad u otras clasificaciones de etapa de vida el ingreso u otras clasificaciones de estilo de vida estatus (por ejemplo, la voz activa nueva,, inactiva, ) referente a fuente
recencia (por ejemplo, la fecha de ltima compra), frecuencia (por ejemplo, demuela cuenta de transaccin de compra), e intensidad (por ejemplo, demuela cantidad neta de compra), as como tambin etiquetas del grupo generadas por la minera de datos aglomera analy-si de estos recencia, frecuencia, y medidas de intensidad el especfico en negocio segmento de mercado (como un identificador preferido del cliente) las puntuaciones caracterizando al cliente, como el comportamiento de compra, el comportamiento de pago, las preferencias del producto, la propensin a hacer mantequilla, y la probabilidad de default. Los modelos estadsticos de segmentacin tpicamente generan estas puntuaciones, cules estn entonces etiquetados encima de cada fila de dimensin del cliente como un atributo.
Los Hechos Agregados como los Atributos Se los interes en usuarios a menudo constreir la dimensin del cliente basada en agregado mtrica de funcin, tan basada en para filtrar en que todos los clientes que gastaron sobre una cierta cantidad del dlar durante el ao pasado. Para empeorar las cosas, quiz quieren constreir basado de adelante cunto el cliente ha comprado durante su duracin de una vida. Proveer agreg hechos como atributos de dimensin son de seguro una persona atractiva a las mayoras con los usuarios comerciales. En vez de publicar una averiguacin separada para determinar a todos los clientes que satisficieron los criterios de hbitos de gasto y entonces publicando otra averiguacin de hecho para fomentar intersese por ese grupo de clientes, almacenando un hecho agregado como un atributo le permite a los usuarios simplemente constreir sobre ese atributo de gasto, as como podran sobre un atributo de geo-graphic. Estos atributos deben servir para constreir y etiquetar; No deben ser usados en clculos numricos. Mientras hay ventajas de averiguacin de usabil-ity y de funcin para almacenar estos atributos, las cadas de la guarida de abrojo del lado de abajo en la trastienda escenificando procesos para asegurar que los atributos son precisos, modernos, y consistente con el hecho real rema. En otras
palabras, requieren alimentacin y cautela significativa. Si usted opta por incluir algunos hechos de aggre-gated como atributos de dimensin, vaya de fijo a enfocar la atencin en esos que sern usados frecuentemente. Adems, usted debera esforzarse por minimizar la frecuencia con la cual estos atributos necesitan estar actualizados. Por ejemplo, un atributo por el gasto del ao pasado requerira mucho menos mantenimiento que uno eso identifica el ao para fechar comportamiento. En vez de almacenar atributos hasta el valor especfico de dol-Lar, estn algunas veces repuestos (o suplementado) con ms mean-ingful valores descriptivos, como Gastador elevado, como acabamos de intercambiar opiniones con atributos de segmentacin. Estos valores descriptivos minimizan nuestra vulnerabilidad para el hecho que los atributos numricos no pueden vincular de regreso exactamente para las Tablas de hecho de appropri-eat. Adems, aseguran que todos los usuarios tienen un defini-tion consistente para gastadores elevados, por ejemplo, en vez de recurrir a sus reglas comerciales individuales.
Los arbotantes de dimensin para uno El Atributo de Low-Cardinality Colocado Como dijimos en Captulo 2, se dice que una dimensin es snowflaked cuando las columnas de car-dinality bajo en la dimensin han estado distantes para poner aparte Tablas normalizadas que entonces se acoplan de vuelta a la mesa original de dimensin. Generalmente, snowflaking no es recomendado en un ambiente del almacn de datos porque casi siempre hace la presentacin del usuario ms complicado, adems de hav-ing un impacto negativo sobre hacer una lectura ligera funcin. A pesar de esta prohibicin en contra de snowflaking, hay algo de situaciones donde usted debera construir un arbotante de dimensin que tiene la apariencia de una mesa del snowflaked. Los arbotantes tienen caractersticas especiales que causan que ellos sean permisibles copos de nieve. En Figura 6.3, el arbotante de dimensin es un set de datos de un proveedor externo de datos consistente en 150 atributos demogrficos y socioeconmicos estimando el condado de los clientes de residencia. Los datos para todos los clientes residenciado en un condado dado son idnticos. En vez de repetitivo este bloque grande de datos para cada Cu-tomer dentro de un condado, optamos por modelarlo como un arbotante. Hay varios fac-tor que la causa nosotros para doblar nuestro ninguna regla del copo de nieve. Ante todo, los datos demogrficos estn disponibles en un grano significativamente diferente que los datos primarios (el condado versus cliente individual) de dimensin. Los datos son administrados y cargados en momentos diferentes que el resto de datos en la dimensin del cliente. Tambin, nosotros en realidad ahorramos espacio significativo en este caso si el dimen-sion subyacente del cliente es grande. Si usted tiene una averiguacin herramienta que insiste en un dibujo tcnico de la estrella clsico sin copos de nieve, sin usted puede esconder el arbotante debajo de una declaracin de vista.
Los arbotantes de dimensin son permisibles, pero deberan ser la excepcin en vez de la regla. Una bandera roja de advertencia debera subir si su diseo est plagado de arbotantes; Usted pudo haber sucumbido para la tentacin para excesivamente normalizar el diseo.
La Mesa de Hecho La llave del cliente (FK) Ms Foreign Teclea Hechos
La Dimensin del Cliente El cliente la Ciudad del Cliente de Apellido del Cliente de Nombre de Pila del Cliente de Saludo del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) El Condado del Cliente Las caractersticas demogrficas del condado Teclean a (FK) el Estado del Cliente y ms
La Dimensin del Arbotante de Caractersticas Demogrficas del Condado Las caractersticas demogrficas del condado Teclean a (PK) la Poblacin Total La Poblacin Debajo de 5 Aos El % Demogrfico Debajo de 5 Aos La Poblacin Debajo de 18 Aos El % Demogrfico Debajo de 18 Aos Aos 65 Demogrficos y Ms Viejo La Poblacin del % 65 Aos y Ms Viejo La Poblacin Hembra La Poblacin de la Hembra del % La Poblacin Masculina La Poblacin del Varn del % El Nmero de Graduados de la Escuela Secundaria Numeran de Universidad los Graduados el Nmero de Alojar Proporcin de Dueos de Hogar Propio de Unidades y ms
Figura 6.3 el snowflaking Permisible con un arbotante de dimensin para grupo de atributos de low-cardinality.
El Cliente Cambiante Grande Dimensiones La fila multimillonaria que el cliente dimensiona retos nicos dos presentes que el tratamiento de especial de la autorizacin. Aun si una mesa limpia, plana de dimensin ha sido imple-mented, generalmente se toma mucho tiempo para constreir o hacer una lectura ligera entre los barcos de relacin en una mesa tan grande. Adems, es difcil de usar nuestras tcnicas probadas y ciertas de Captulo 4 para rastrear cambios en estas dimensiones grandes. Probablemente no queremos usar el tipo 2 lentamente cambiando tcnica de dimensin y le aadimos ms filas a un cliente dimensionan eso ya tiene millones de filas en eso. Desafortunadamente, las enormes dimensiones del cliente estn an ms probables para cambiar que lo que dimensiones bastante dimensionadas. Algunas veces llamamos esta situacin una dimensin del monstruo rpidamente cambiante! Los usuarios comerciales a menudo quieren rastrear la mirada de cambios de atributo del cliente. En algunos negocios, el cambio rastreador no es meramente uno agradable para tener capa-bility analtico. Las compaas de seguros, por ejemplo, deben actualizar informacin acerca de sus clientes y sus autos asegurados especficos o sus casas porque es criti-cal para tener un cuadro preciso de estas dimensiones cuando una poltica es aprobada o el reclamo es hecho. Afortunadamente, una sola tcnica acude al rescate para poner la direccin en ambos la brow-ing-ing-performance y cambiar rastrear retos. La solucin es suspender de pronto frecuentemente analizado o frecuentemente convirtiendo atributos en un dimen-sion separado, referido como una minidimensin. Por ejemplo, podramos crear una minidimensin separada para un paquete de atributos demogrficos, como la edad, el gnero, el nmero de nios, y el nivel de ingreso, suponer que estas columnas se quedan usado extensamente. Habra una fila en esta minidimensin para cada combinacin nica mayor, engendrara, numerara de nios, y encoun-tered del nivel de ingreso en los datos, no una fila por cliente. Estas columnas son las que son analizadas para seleccionar un subconjunto interesante de la base del cliente. Adems, los usuarios quieren rastrear cambios para estos atributos. Dejamos atrs ms atributos constantes o menos seguido puestos en duda en la mesa enorme original del cliente.
Las filas de la muestra para una minidimensin demogrfica son ilustradas en Mesa 6.3. Al crear la minidimensin, atributos continuamente variables, como el ingreso y demuela compras, deberan ser convertidos a alcances vendados. En otras palabras, obtenemos a la fuerza los atributos en la minidimensin para cobrar un nmero relativamente pequeo de valores discretos. Aunque esto restringe uso a un set de bandas predeterminadas, drsticamente reduce el nmero de combinaciones en la minidimensin. Si almacensemos ingreso en un el valor del dlar especfico y de centavos en la minidimensin, estando combinados con los otros atributos demogrficos, podramos sacar en limpio tantos alborotos en la minidimensin as como en el cliente principal dimensin misma. El uso de alcances de la banda es probablemente el acuerdo intermedio ms significativo asociado
Ponga sobre una mesa 6.3 Filas De Muestra de un Demographic Minidimension EL HIDRGENO DEE de la AG G E N D E R LA O D E M G R AP YO CARBONO K EY 1 2 3 18 19 20-24 20-24 20-24 25-29 25-29 El varn El varn El varn El varn El varn YO EL CO DE LA N M E LEVE L
<$20,000 $20,000-$24,999 $25,000-$29,999 $20,000-$24,999 $25,000-$29,999
Con la tcnica de minidimensin porque una vez que nos decidimos por el valor se agrupa, es muy imprctico cambiarse a un set diferente de bandas posteriormente. Si los usuarios insisten en el acceso para un valor crudo especfico de datos, como una puntuacin de la oficina de crditos que est actualizado mensualmente, tambin debera ser incluida en la mesa de hecho, adems de estar representada como una banda de valor en la minidimensin demogrfica. En Captulo 9 veremos cmo construir averiguaciones que se agrupan valor al vuelo en contra de los hechos en el hecho pospone, aunque tales averiguaciones son mucho menos eficientes que lo que directamente constrie el valor banda en nuestra mesa de minidimensin. Cada vez que construimos una mesa de hecho fila, incluimos dos llaves extranjeras relacionadas con el cliente: La llave de dimensin del cliente regular y los grficos de demo de minidimensin teclean. Como se muestra en Figura 6.4, las caractersticas demogrficas teclean debera ser del set de la mesa de hecho de llaves extranjeras para proveerle el acceso eficiente a la mesa de hecho a travs de los atributos de caractersticas demogrficas. Este diseo efecta la entrega que haciendo una lectura ligera y constreir funcin se beneficia de con tal que un punto ms pequeo de entrada para los hechos. Las averiguaciones pueden evitar la enorme mesa de dimensin del cliente enteramente a menos que los atributos de esa mesa sean embarazosos. Cundo las caractersticas demogrficas teclean participa como una llave extranjera
en la mesa de hecho, otro beneficio es que el hecho que la mesa sirve para captar lo demogrfico de perfil cambia. Supongamos que cargamos datos en una mesa peridica de hecho de la foto sobre una base mensual. Referente a de regreso a nuestras filas de muestra minidi mension demogrficas de muestra en Mesa 6.3, si uno de nuestros clientes, John Smith, tuviese 24 aos de edad con un ingreso de $24,000, empezaramos por asignar llave de caractersticas demogrficas 2 al cargar la mesa de hecho. Si John tiene un cumpleaos varias semanas ms tarde, asignaramos llave de caractersticas demogrficas 18 cuando la mesa de hecho fue la siguiente cargada. Las caractersticas demogrficas teclean en las anteriores filas de la mesa de hecho pues John no cambiara. De esta manera, la mesa de hecho rastrea el cambio de edad. Continuaramos asignando llave de caractersticas demogrficas 18 cuando la mesa de hecho tiene mucho dinero hasta hay otro cambio en el perfil demogrfico de John. Si John recibe un aumento hasta los meses $26,000 sev eral ms tarde, una llave nueva de caractersticas demogrficas se reflejara en la siguiente carga de la mesa de hecho. Otra vez, las anteriores filas estaran inalteradas. Las reseas grficas en demo histricas para cada cliente pueden forjarse en cualquier momento refiriendo
Para el hecho que la mesa y recogiendo la llave simultnea del cliente y su llave temporal en la contra de caractersticas demogrficas, que en general ser diferente a las caractersticas demogrficas ms recientes teclean. Las dimensiones del cliente son nicas en lo referente a que los atributos del cliente frecuentemente son puestos en duda independientemente de la mesa de hecho. Por ejemplo, los usuarios pueden querer saber cuntos clientes hembras viven en Dade County por la categora de edad. Las cuentas como estos son sumamente comunes con segmentacin del cliente y perfilando. En vez de forzarle cualquier anlisis que combinan solamente a datos del cliente y grficos en demo para conectar a travs de la mesa de hecho, el valor ms reciente de la llave de grficos de demo tambin puede existir como una llave extranjera en la mesa de dimensin del cliente. En este caso, nos referimos a la mesa de caractersticas demogrficas como un outrig-ger de dimensin del cliente, como intercambiamos opiniones ms temprano en este captulo.
La minidimensin que la terminologa se refiere a cuando la llave de caractersticas demogrficas es de la llave de la mezcla de la mesa de hecho; Si las caractersticas demogrficas teclean es una llave extranjera en el di-mension del cliente, nos referimos a ella como un arbotante.
Si usted empotra las caractersticas demogrficas ms recientes teclean en la dimensin del cliente, usted le debe tratar a ella como un tipo 1 atributo. Si usted rastrease todos los cambios de caractersticas demogrficas con el paso del tiempo como un tipo 2 lentamente cambiando dimensin, usted habra vuelto a introducir el problema de dimensin del monstruo rpidamente cambiante que hemos estado surtiendo efecto para evitar! Con un tipo 1 cambio, como discutimos en Captulo 4, sobrescribimos la llave de caractersticas demogrficas en la fila del cliente cada vez que cambia en lugar de crear una fila nueva del cliente. Tambin recomendamos que estos atributos demogrficos outrig ger sean etiquetados como ms recientes o los valores actuales para la confusin de min-imize. Aun con el etiquetado nico,
estn conscientes que regalndole a los usuarios dos avenidas para acceder a datos demogrficos, a travs de ya sea el minidi-mension o el arbotante, pueden dar ms funcionabilidad y ms complejidad que algunos usuarios puede manipular.
La Dimensin del Cliente El cliente el Nombre del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) La fecha del Cliente de la Direccin del cliente de Fecha del Cliente de Nacimiento de Orden 1 El Gnero de Edad El Nmero Anual de Ingreso de Estado Civil de Nios
Viene bien ... La Dimensin del Cliente El cliente el Nombre del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) La fecha del Cliente de la Direccin del cliente de Fecha del Cliente de Nacimiento de Orden 1 La Dimensin de Caractersticas Demogrficas del Cliente Las caractersticas demogrficas del cliente Afinan (PK) Banda de Edad del Cliente El Gnero del Cliente La Banda de Ingreso del Cliente El Nmero del Cliente de Nios Se Agrupa El Estado Civil del Cliente La Mesa de Hecho La llave del cliente (FK) Cliente Demographics Teclea (FK) Ms Llaves Extranjeras Hechos
Figura 6.4 la minidimensin Demogrfica con una dimensin del cliente.
La Dimensin del Cliente La llave del cliente (PK) Los atributos relativamente constantes
La Dimensin de Caractersticas Demogrficas del Cliente Las caractersticas demogrficas del cliente Teclean (PK) atributos de Caractersticas Demogrficas La Mesa de Hecho La llave del cliente (FK) Las caractersticas demogrficas del cliente Afinan (FK) Llave de Purchase-Credit del Cliente (FK) Ms Llaves Extranjeras Hechos
La Dimensin de Crdito de Compra del Cliente La llave de Purchase-Credit del cliente (PK) El crdito y el pago los atributos conductistas Creo 6.5 Separados las minidimensiones demogrficas y conductistas.
La dimensin demogrfica misma no puede estar permitido volverse demasiado grande. Si tenemos 5 atributos demogrficos, cada uno con 10 valores posibles, en ese entonces la dimensin de grficos de demo podra tener 100,000 (105) filas. ste es un lmite superior razonable para el nmero de filas en una minidimensin. Sin embargo, hay ciertamente casos donde necesitamos soportar ms que 5 atributos demogrficos con 10 valores cada uno. En este caso, construiramos una dimensin de caractersticas demogrficas de segundo, como se muestra en Figura 6.5. Por ejemplo, podemos tener un set de con-cerning de atributos que el ingreso demogrfico tradicional y el estilo de vida atribuye y que otro estableci eso enfoca la atencin en compra y acredita puntuaciones conductistas. La direccin mltiple de minidi-mensions el asunto de crecimiento de minidimensin al tambin el agrupamiento de estrellas como los atributos juntos para un usuario ms intuitivo la presentacin. Otro motiva-tion para crear estas dos minidimensiones es que son potencialmente sourced de dos proveedores diferentes de datos con frecuencias diferentes de actualizacin. Sin embargo, acurdese de tener en mente nuestro consejo de Captulo 2 concerniente a dimensiones de ms. Ciertamente no queremos crear una minidimensin separada con una llave extranjera en la mesa de hecho para cada atributo demogrfico, como una dimensin de edad, la dimensin de gnero, y la dimensin de ingreso. Asimismo, no deberamos saltar inmediatamente sobre la tcnica de minidimensin a menos que nos ocupemos de una dimensin grande o rpidamente cambiante; No podemos olvidar las ventajas de main-taining un reventn simple,, mesa de dimensin denormalized.
El mejor acercamiento para eficazmente haciendo una lectura ligera y rastreando cambios de atributos cruciales en dimensiones realmente enormes es romper uno o
ms minidimensiones de la mesa de dimen-sion, cada uno consistente en parte pequea anda con pasos fuertes de atributos que han sido administrados para tener un nmero limitado de valores.
El Atributo de Anchura Variable Colocado Finalmente, una minidimensin puede crearse manejar un nmero variable de atributos del cliente. Obviamente, mientras ms largo tenemos una relacin con un cliente, la ms informacin descriptiva nosotros sabe de l o de ella. Si pensamos acerca de que las ventas se ciclan, tenemos un montn de ms prospectos que lo que hagamos Cu-tomers; Sin embargo, sabemos mucho menos de los prospectos que lo que hagamos acerca de nuestros clientes. Podemos tener 10 millones de prospectos iniciales, descritos por un puado de caractersticas, quienes estn trabajados a travs de lo even-tually de la tubera de ventas para resultar en 1 millones de clientes oficiales con un set mucho ms ancho de caractersticas sabidas. Al usar listas externas de prospecto, a menudo somos permitidos slo un antiguo uso de la lista y no tenemos el derecho legal de almacenar la informacin de prospecto internamente. Sin embargo, si hemos generado nuestra informacin de prospecto, ciertamente puede guardarse en el almacn de datos. Supongamos que captamos mtrica, quiz se asoci con solicitacin o citamos acontecimientos de la generacin que se aplican a ambos prospectos y clientes. Podramos almacenar los prospectos y clientes juntos en una sola dimensin de contacto; Sin embargo, hay una disparidad significativa entre los nmeros de atributos para prospectivo versus cliente contacta. Como ilustrados en Figura 6.6, podemos conocer slo un puado de identificacin y atributos de loca-tion acerca de nuestros prospectos. Por otra parte, podemos saber que 50 atributos de addi-tional para un cliente, cubriendo comportamientos de compra, de pago, de crdito y de servicio, directamente produjeron como respuesta atributos del perfil, y el tercero compr atributos grficos en demo. En el mundo de venta al menudeo electrnica, podemos igualar prospectos para ser las visitas annimas del sitio Web a distincin de nuestros clientes matriculados.
Contacte Dimensin La llave de contacto (PK) El contacto el ZIP de Contacto Idaho (la Llave Natural) El Estado de Contacto La llave extendida (FK) del Cliente La Mesa de Hecho La llave de contacto (FK) Cliente extendido Key (FK) Ms Foreign Teclea Hechos
La Dimensin Extendida del Cliente El cliente extendido el Nombre del Cliente de la Bandera del Cliente de la Llave Empty (PK) El Cliente de la Ciudad del Cliente de la Direccin del Cliente el ZIP Estatal del Cliente El Indicador de Condicin de Ser Dueo de Hogar Propio de Puntuacin de Comportamiento de Crdito de Puntuacin de Comportamiento de Pago de Puntuacin de Comportamiento de Compra y ms Figura 6.6 los atributos del cliente de Anchura Variable manipularon como una minidimensin y dimensin de base.
Si asumimos tantos de los atributos 50 finales del cliente son textuales, nosotros eas-ily podramos hacer un total hacer avanzar con el remo anchura de 1,000 bytes. Supongo que tenemos 10 contactos del len de milipulgada (9 millones de prospectos y 1 millones de clientes oficiales). Obviamente, estamos preocupados que las columnas 50 de arrastre en 90 por ciento de nuestros contactos no tienen datos. Esto tiene nuestra atencin cuando tratamos de una mesa de dimen-sion 10-GB. En este caso, podemos tener el deseo de introducir una minidimensin. Si tratamos de una plataforma de la base de datos que mantiene la anchura variable rema, como Orculo, podemos poder hacer una sola dimensin del com-plement lleno de atributos si el total que los atributos listan no es demasiado largo; En algunos de estos casos, no necesitamos preocuparnos por todas las columnas nulas de los prospectos porque suben virtualmente espacio del disco de cero. Sin embargo, si tenemos una base de datos de ancho fijo, o si los atributos escoran es largusimo, somos incmodos con todas las columnas vacas para los prospectos. En este caso, como se muestra en Figura 6.6, cortamos la dimensin en una mesa baja de dimensin de 10 millones de filas consistente en attrib-utes que es comn para ambos prospectos y los clientes, junto con una minidimensin del cliente de 1 millones de filas que contiene los atributos adicionales que sabemos acerca de nuestros clientes. Otra vez, incluimos dos llaves extranjeras en la mesa de hecho. Nueve de diez filas de la mesa de hecho se incorporaran a una fila vaca del cliente en la minidimensin extendida del cliente.
Las Implicaciones de Tipo 2 el Cliente La Dimensin Cambia Quiz su organismo vende para las decenas de miles de clientes en vez de decenas de millones. En este caso, las tcnicas que discutimos en Captulo 4 para los cambios de dimensin de track-ing son todava viables. El tipo de dimensin lentamente cambiante 2 la tcnica, donde otra fila se suma a la mesa de dimensin, permanecera la tcnica predominante para rastrear cambio en dimensiones del cliente con menos de 100,000 filas. Aun si tenemos una dimensin del cliente verdaderamente grande, probablemente necesitaremos todava usar el tipo 2
respuesta para manipular muy lentamente cambiando los atributos dejaron atrs en la dimensin del cliente. Como mencionamos ms temprano, los usuarios frecuentemente quieren contar a los clientes basados en sus atributos sin asociarse para una mesa de hecho. Si acostumbrsemos un tipo 2 la respuesta para rastrear dimensin del cliente cambia, necesitaramos evitar sobre-contantes porque podemos tener filas mltiples en la dimensin del cliente para el mismo individuo. Hacer un CARGO BIEN DEFINIDO en un identificador nico del cliente es una posibilidad, suponiendo que el atributo es ciertamente nico y tambin no ha estado alterado. Un indicador ms reciente de la fila en el dimen-sion del cliente es tambin de ayuda para hacer cargos basados en el val-ues ms descriptivo moderno para un cliente.
Las cosas se ponen ms complicadas si necesitamos hacer un cargo del cliente en un punto dado de his-torical con el tiempo acostumbrando fechas efectivas de vencimiento y en la dimensin del cliente. Por ejemplo, si necesitamos saber el nmero de clientes tuvimos al principio de 2002, podramos constreir la fecha de efectividad de la fila a menos que o el igual a 1/1/2002 y la fecha de caducidad de la fila a ms gran que o el igual para 1/1/2002 para restringir el set de resultado a slo esas filas que fueron vlidas el 1 de enero de 2002. Reparo en que los telefonistas de comparacin dependen de las reglas comerciales usadas para colocar nuestras fechas efectivas de / vencimiento. En este ejemplo, la fecha de la racin de expi de la fila en la fila del cliente no vlida ms largo es un da menos de la fecha de effec-tive en la fila nueva. Alternativamente, como intercambiamos opiniones ms temprano, las fechas pueden ser llaves vicarias de fecha unidas para una mesa del arbotante de dimensin de fecha. En este caso, usaramos junturas desiguales entre las Tablas de fecha del arbotante y las fechas de / vencimiento de effec-tive en la dimensin del cliente.
El Estudio de Comportamiento del Cliente Se Agrupa Con anlisis del cliente, las averiguaciones simples, como qu tan hemos vendido mucho para los clientes en este rea geogrfico en el ao pasado, rpidamente evolucionamos para las averiguaciones ms complicadas, tan cuntos clientes compraron ms el mes prximo pasado que su cantidad mensual comn de compra desde ao pasado. La pregunta ms reciente est demasiado complicada para usuarios para comerciales para expresar en una sola peticin de lenguaje normalizado de consulta. Algunos vendedores de la herramienta de acceso de datos permiten subaveriguaciones incrustadas, mientras que los otros hayan implementado capacidades de lenguaje normalizado de consulta del multipaso, en el cual las peticiones de estructuras entrelazadas de com son cortadas en declaraciones selectas mltiples y entonces combinadas en un subsiguiente paso. En otras situaciones, podemos querer captar el set de clientes de una averiguacin o el informe de excepcin, como los clientes 100 sobresalientes desde ao pasado, los clientes que gastaron ms que $1,000 el mes pasado, o los clientes que recibieron una solicitacin experimental especfica, y en ese entonces usa ese grupo de clientes, que llamamos un estudio de comportamiento agrupa, para subsiguiente
para anlisis sin reprocesar para identificar la condicin inicial. Para crear un grupo de estudio de comportamiento, corremos una averiguacin (o la serie de averiguaciones) para identificar el set de clientes que queremos fomentar analice y entonces capture las llaves del cliente del resultado establecido como una mesa fsica real. Entonces usamos esta mesa especial de dimensin del grupo de estudio de comportamiento de identificadores del cliente cada vez que tenemos el deseo de constreir cualquier anlisis a ese set de clientes especialmente definidos, como se muestra en Figura 6.7.
El secreto para construir averiguaciones conductistas complicadas del grupo de estudio es captar las llaves de los clientes o los productos cuyo comportamiento usted rastrea. Usted entonces usa las llaves de cap-tured para estrangular otras Tablas de hecho sin tener que reestrenar el anlisis original de behav-ior.
La dimensin del grupo de estudio de comportamiento est adjunta con un equijoin para la llave de nat-ural (denominado Customer Idaho en Figura 6.7) de la dimensin del cliente. Esto puede ser incluso hecho en una vista que esconde la juntura explcita para el dimen-sion de comportamiento. De este modo, el modelo dimensional resultante mira y se comporta como un dibujo tcnico elemental. Si la mesa de dimensin del grupo de estudio est escondida debajo de una vista, debera estar etiquetada para identificarla como ser asociado con los clientes 100 sobresalientes, por ejemplo. Virtualmente cualquier datos acceden a la herramienta debera poder analizar este dibujo tcnico especialmente restringido sin sintaxis rentable o penas de interfaces de usuario para el complejo procesando eso defini el subconjunto original de clientes. Como muchos disean decisiones, este representa ciertos acuerdos intermedios. Primer, este acercamiento requiere una interfaz de usuario para capturar, creando, y las Tablas del grupo de estudio de comportamiento de reconocimiento mdico de administer-ing en el almacn de datos. Despus de que un informe de excepcin de com-plex haya sido definido, necesitamos que la habilidad capte las claves resultantes en un applet para crear el dimen-sion especial del grupo de estudio de comportamiento. Estas Tablas del grupo de estudio deben vivir en el mismo espacio como la mesa primaria de hecho porque van a ser adjuntadas a la mesa de dimensin del cliente directamente. Esto obviamente afecta las responsabilidades del administrador de base de datos.
Las Jerarquas Comerciales del Cliente Uno de los aspectos ms desafiantes de tratar con clientes comerciales es modelar su jerarqua organizativa interna. Los clientes comerciales a menudo tienen una jerarqua anidada de entidades extendindose desde organizaciones o posiciones individuales arriba de oficinas regionales directas, el centro de operaciones comercial de la unidad, y las casas matrices ltimas. Estas relaciones jerrquicas pueden cambiar fre-quently como los clientes se reorganicen internamente o estn involucrados en adquisiciones y despojos.
El Estudio de Comportamiento del Cliente Sales Transaction Fact Por Menor de punto de venta La Dimensin del Cliente La llave del Producto de la Llave de fecha (FK) (FK)
Agrupe Dimensin
La llave del cliente (PK)
La llave del cliente (FK)
El cliente Idaho (la Llave Natural) El cliente Idaho (la Llave Natural) y ms Almacene Llave (FK) La llave de promocin (FK) La transaccin de punto de venta Nmero Sales (DD) Quantity La Cantidad del Dlar de Ventas
Creo 6.7 dimensin del grupo de estudio de Comportamiento consistente en llaves seleccionadas unidas en seguida para la llave natural de la dimensin del cliente.
Hablaremos de dos acercamientos para las jerarquas manipuladoras del cliente. La primera parte es franca pero confa pesadamente en fuerza bruta en vez de la elegancia. Todava, puede ocuparse de sus requisitos adecuadamente con un acercamiento simplista. El segundo acercamiento est ms adelantado y complicado pero tambin muy ms extensible. Si usted no se ocupa de jerarquas imprevisibles, harapientas (como el cliente variable y el costo centran jerarquas o explo-sion manufacturero de partes), usted puede querer examinar rpidamente la cobertura sobre las jerarquas de profundidad variable porque es un poquito de un rompecabezas. Las Jerarquas de Profundidad Fija Aunque esto ocurre relativamente desacostumbradamente, los afortunados entre nosotros algunas veces son puestos en una dimensin del cliente que es altamente previsible con un nmero fijo de niveles. Supongo que rastreamos un mximum de tres niveles de movimiento hacia arriba, como el padre corporativo postremo, el centro de operaciones comercial de la unidad, y las oficinas regionales (de arriba abajo). En este caso, tenemos tres atributos bien definidos en la dimensin del cliente correspondiente a estos tres niveles. Para clientes comerciales con jerarquas organizativas complicadas, nosotros pop-ulate todos los tres niveles para apropiadamente representar a las tres entidades diferentes consisti en cada nivel de movimiento hacia arriba. . De este modo, todas las oficinas regionales sumarn para la suma de todo centro de operaciones comercial de la unidad, lo cual sumar para la suma de todos los padres corporativos postremos. Podemos reportar por cualquier nivel de la jerarqua y podemos ver la base del cliente completa representada. Como acusamos recibo arriba de parte delantera, este acercamiento simplista necesariamente no se ocupa de complejidad del mundo real adecuadamente; Sin embargo, no seramos negligentes adentro no mencionndolo porque eso provee una solucin satisfactoria para una cierta cantidad. El tech-nique descrito despus es ms robusto, pero la robustez se origina con equipaje. En algunas situaciones, el mtodo ms complicado puede ser imprctico o puede destruir con ms fuerza nuclear de la necesaria. Las Jerarquas de Profundidad Variable
Representar una jerarqua arbitraria, harapienta de organizacin es uno intrnsecamente tarea dif ficult en un ambiente de relaciones. Por ejemplo, podemos querer reportar los ingresos para un set de clientes comerciales que tienen relaciones intrincadas con cada otro, como adentro Figura 6.8. Cada cuadrado en el diagrama representa a una entidad del cliente individual conectada en un rbol organizativo. La organizacin de illus-trated tiene cuatro niveles; Otras organizaciones del cliente pueden tener uno, diez, o ms niveles. Supongamos que vendemos nuestros productos o servicios para cualquier de estos clientes comerciales. As las filas de dimensin del cliente pueden desempear el papel de padre as como tambin nio. Podemos querer mirar a los clientes y su ingreso por ventas individualmente. En otras veces, podemos querer para la renta de summa-rize para cualquier nodo en el en conjunto rbol organizativo.
El acercamiento de informtica para manipulador esta jerarqua imprevisible debera incluir un puntero recursivo de la llave del cliente del padre en cada fila de dimensin de Cu-tomer. Aunque esto es una forma compacta y efectiva para representar una jerarqua arbitraria, esta estructura un poco recursiva no puede ser usada eficazmente con estndar lenguaje normalizado de consulta. El GRUPO POR la funcin en el lenguaje normalizado de consulta no puede fol-low la estructura del rbol recursivo hacia abajo resumir un hecho aditivo en una mesa de hecho del compaero como la renta en una organizacin. De Oracle EST CONECTADO POR el lenguaje normalizado de consulta la extensin puede navegar un puntero recursivo en una mesa de dimensin, pero lo EST CONECTADO POR la frase. Mientras podemos engaar el analizador gramatical y podemos realizar la juntura escondindose lo EST CONECTADO POR AH en una declaracin de VISTA, la funcin probablemente sufrira significativamente. En lugar de usar un puntero recursivo, insertamos un cuadro puente entre las Tablas de Cu-tomer de dimensin y de hecho, como bosquejado en Figura 6.9. El cuadro puente ha sido llamado un ayudante o mesa asociativa en el pasado, pero siguiendo adelante, nosotros el uso de con-sistently la terminologa del puente. El uso del cuadro puente es optativo; Ni el cliente que la mesa de dimensin ni el hecho posponen tiene que ser modificado de cualquier modo. Si el cuadro puente queda fuera, la mesa de dimensin del cliente se asocia para la mesa de hecho usualmente. Podemos reportar renta por cliente, pero somos incapaces de navegar la jerarqua de organizacin. Cuando el cuadro puente est inserto entre la dimensin del cliente y el hecho pospone, podemos analizar resultados de renta en cualquier nivel jerrquico usando estndar lenguaje normalizado de consulta, si bien por medio de una presentacin ms complicada. El cuadro puente contiene una fila para cada senda en Figura 6.8 de una entidad del cliente para cada sucursal debajo de ella, as como una fila para la senda de longitud de cero
Cliente 1
Cliente 2 Cliente 7
Cliente 3 Cliente 4 Cliente 8
Cliente 5 Cliente 6
Figura 6.8 el diagrama de Organizacin de padre y las compaas subsidiarias.
De un cliente para s mismo. Cada fila de la senda contiene la llave del cliente de la entidad de movimiento hacia arriba de par-ent, la llave del cliente de la entidad subsidiaria, el nmero de niveles entre el padre y la sucursal, una bandera que se llega al fondo ms que identifica a una sucursal sin ms nodos debajo de ella, y finalmente, una bandera que se sobrepasa ms a sealar que no hay ms nodos por encima del padre. El cuadro puente de muestra rema correspondiente a la jerarqua en a Figura 6.8 son mostrados as como en Mesa 6.4. El nmero de filas en el cuadro puente tpicamente est varias veces ms grande que el nmero de filas en la dimensin del cliente. El padre de ocho individuos y clientes subsidiarios en la Figura 6.8 que la jerarqua tradujo en 22 filas en la Mesa 6.4 el cuadro puente. Como un aparte, una forma rpida para calcular el nmero total de filas para una organizacin dada del cliente es multiplicar el nmero de valores a cada veces niveladas la profundidad del nivel (el conteo desde lo alto), y entonces resumir los productos resultantes. Refirmonos a la Figura 6.8 diagrama de organizacin otra vez. En niveles sobresaliente 1 de la jerarqua, tenemos a 1 cliente (el cliente 1), cul los lates en 1 = (1 x 1) fila en el cuadro puente. En el segundo nivel, tenemos 2 Cu-tomers (los clientes 2 y 7), cul traduzca en otra 4 = (2 la x 2) filas en el puente. En nivel 3, tenemos a 3 clientes (los clientes 3, 4, y 8), cul se traduce en 9 = (3 la x 3) alborotos del cuadro puente. Finalmente, en el nivel ms bajo (cuarto), tenemos 2 clientes (los clientes 5 y 6), cul se traducen en unos alborotos 8 adicionales = (4 la x 2). El nmero de suma total de filas es 22 = (1 + 4 + 9 + 8). Si usted no le cree a nosotros, siga adelante y cuente el nmero de filas de muestra en Mesa 6.4. Cuando queremos bajar la jerarqua de organizacin, ensamblamos las Tablas como se muestra en Figura 6.9. Nosotros ahora podemos estrangular la mesa del cliente para un cliente particular del padre y podemos pedir cualquier medida del agregado de todos los sidiaries en o debajo de ese cliente. Podemos utilizar al # de Niveles de Padre columna en el cuadro puente de organizacin para controlar la profundidad del anlisis. Constreir a un valor de 1 le dara a todas las sucursales directas del Cu-tomer. Un valor mayor que el cero le dara a todos los clientes subsidiarios pero no el padre original. Podemos usar la Bandera ms bajo columna para lanzarnos directamente a todas las entidades que se llegan al fondo ms del cliente pero podemos omitir todas las entidades del cliente del nivel ms alto.
La Dimensin del Cliente El cliente el Nombre del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) La Direccin del Cliente Los Atributos del Cliente El Puente de Jerarqua del Cliente La Llave del Cliente del Padre La Llave Subsidiaria del Cliente El # Derriba de Padre Iguale Bandera de la Parte Superior de la Bandera de Fondo de Nombre La Mesa de Hecho La llave del Cliente de la Llave de fecha (FK) (FK) Ms Foreign Teclea Hechos
La definicin optativa de vista para parecerse a mesa normal de hecho Con llaves de valores solo Figura 6.9 la dimensin del Cliente y cuadros puentes con configuracin de la juntura para bajar el rbol.
Mesa 6.4 el de Muestra Bridge Table Rows Corresponding para la Jerarqua en Figura 6.8 LA EL #LEVE EQUIVALEN ANTEPROYEC DE CIA E NT TO-INTERNET PADRE LA LLAVES U BS IARY ADUANERA CUSTOM ER ER TECLEE 1 1 1 1 1 1 1 1 2 2 2 2 2 3 4 4 4 5 6 7 7 8 1 2 3 4 5 6 7 8 2 3 4 5 6 3 4 5 6 5 6 7 8 8 0 1 2 2 3 3 1 2 0 1 1 2 2 0 0 1 1 0 0 0 1 0 LS LLEGUE ALLLEGUE FONDO DEAL BANDERA FINAL BANDER A N N Y N Y Y N Y N Y N Y Y Y N Y Y Y Y N Y Y Y N N N N N N N N N N N N N N N N N N N N N
Cuando queremos subir por la jerarqua de organizacin, ponemos al revs las
junturas conectando la dimensin del cliente llave primaria para la llave de la sucursal del puente, como se muestra en Figura 6.10. Constriendo al # de Niveles columna en el cuadro puente por valor de 1, nosotros encuentre al padre inmediato del cliente en la dimensin de Cu-tomer. Cuando la bandera que se sobrepasa ms es Y, hemos seleccionado al padre postremo para un cliente dado. Al publicar declaraciones de lenguaje normalizado de consulta usando el cuadro puente, necesitamos ser cautelosos acerca de sobre-contar los hechos. Al conectar las Tablas como se muestra en cifras
6.9 y 6.10, debemos constreir la dimensin del cliente a un solo valor y
Entonces asciese para el cuadro puente, cul es entonces adjuntado a la mesa de hecho. Si quisisemos resumir renta en el hecho mesa para un cliente dado y todas sus sucursales, el cdigo de lenguaje normalizado de consulta mirara algo as como lo siguiente: ESCOJA A _ NOMBRE C.CUSTOMER, SUMA (F.REVENUE) entre B del CLIENTE de carbono, del PUENTE, FACT F, FECHA D WHERE C.CUSTOMER _ LLAVE de la _ LLAVE = B.PARENT Operador booleano AND B.SUBSIDIARY _ LLAVE de la _ LLAVE = F.CUSTOMER Operador booleano AND F.DATE _ LLAVE de la _ LLAVE = D.DATE // junto con junturas para otras dimensiones _ el NOMBRE de operador booleano AND C.CUSTOMER ' abecedario General International ' // por ejemplo El operador booleano AND D.MONTH 'el el Enero del 2002 ' el GRUPO POR _ el NOMBRE C.CUSTOMER Podemos pedir toda la renta de las organizaciones asociadas con muchos padres de inmediato, pero tenemos que obtener las llaves subsidiarias claramente o arriesgar dou-ble contando. En el siguiente ejemplo recuperamos el enero del 2002 renta de todas las organizaciones cuyos padres estn ubicados en San Francisco. El cdigo de lenguaje normalizado de consulta es ms desordenado, pero trabaja para ambos clientes nicos y mltiples del padre. SELECCIONE a ' San Francisco ', SUME (F.REVENUE) DE FACT F, DATE D DONDE _ la LLAVE F.CUSTOMER Indiana
(ESCOJA A _ LLAVE DISCRETA B.SUBSIDIARY entre B del CLIENTE de carbono, del PUENTE DONDE C.CUSTOMER _ LLAVE de la _ LLAVE = B.PARENT Operador booleano AND C.CUSTOMER _ CIUDAD ' San Francisco ') // para sumar todos los padres de ciencia ficcin El operador booleano AND de la _ LLAVE de la _ LLAVE de operador booleano AND F.DATE = D.DATE D.MONTH 'el el Enero del 2002 ' el GRUPO POR ' San Francisco '
La Dimensin del Cliente El cliente el Nombre del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) La Direccin del Cliente Los Atributos del Cliente El Puente de Jerarqua del Cliente La Llave del Cliente del Padre La Llave Subsidiaria del Cliente El # Derriba de Padre Iguale Bandera de la Parte Superior de la Bandera de Fondo de Nombre La Mesa de Hecho La llave del Cliente de la Llave de fecha (FK) (FK) Ms Foreign Teclea Hechos
La definicin optativa de vista para parecerse a mesa normal de hecho Con llaves de valores solo Creo que 6.10 el cuadro puente Diferente se le unen a la configuracin para escalar el rbol organizativo.
Hay un nmero de asuntos administrativos en construir y mantener un cuadro puente de orga-nization. Quiz la pregunta ms grande es, de dnde la informacin viene? Cmo identifica usted que un cambio organizativo ocurri, y entonces cmo usted manipula el cambio? Si una historia completa de cambiar organiza-tional muchos para muchas necesidades de relaciones a ser mantenido, en ese entonces el cuadro puente de organizacin puede estar generalizado para incluir fechas efectivas de vencimiento y en cada fila, como explicaremos en detalle en Captulo 13. Un indicador ms reciente para identificar el ms actual organizativo movimiento hacia arriba tambin sera til. Si estas fechas son administradas correctamente, en ese entonces cada aplicacin peticionaria tendra que aprender de memoria tensin en una fecha especfica entre las fechas efectivas de vencimiento y. Cuando un grupo de nodos es movido de una parte de una jerarqua organizativa para otro, slo las filas del cuadro puente que se refieren a los caminos de padres exteriores para la estructura conmovida necesitan estar alteradas. Todas las filas en lo referente a caminos dentro de la estructura conmovida estn sin afectacin. Por supuesto, necesitaramos sumar filas si la estructura conmovida tuviese ascendencia nueva. sta es una ventaja sobre otros dibujos tcnicos de representacin de rbol que a menudo requieren uno global volviendo a numerar para manejar un cambio como esto. Si dos o ms padres conjuntamente poseen a una sucursal, en ese entonces le podemos aadir un factor que oprime al cuadro puente para reflejar la propiedad fraccionada. Fomentaremos elab-orate en cuadros puentes cargados en Captulo 13. Las explosiones pequeas de partes y medianas en una aplicacin manufacturera pueden ser modeladas usando la misma clase de cuadro puente entre una mesa de dimensin de la parte /asamblea y una mesa de hecho. La limitacin principal para destinar este acercamiento para confeccionar partes explosiones es el puro nmero de subasambleas y las partes. Una manufactura muy grande divide explosin con centenares de miles o millones de partes podran resultar en un cuadro puente con ms filas que hay molculas en el universo.
Las jerarquas de organizacin y las jerarquas de explosin de partes pueden ser representadas con la ayuda de un cuadro puente. Esta va de entrada permite el normal lenguaje normalizado de consulta agrupndose y las funciones de sum-marizing para avanzar con dificultad a travs de ordinario ponen en duda herramientas.
Habiendo hecho el caso para un cuadro puente para manejar jerarquas de profundidad variable recursivas, seramos los primeros en admitir que no es una solucin perfecta. El acercamiento trata de cruzar dos estructuras intrnsecamente bien definidas, rectangu-Lar fijo Tablas de relaciones y formaciones jerrquicas de formas independientes, lo cual es semejante para mezclar petrleo y agua. Mientras el cuadro puente puede ser navegado lo
El cdigo de lenguaje normalizado de consulta estndar generado por muchas herramientas de averiguacin, no es para el desmayo de corazn. Las aplicaciones analticas deberan estar preconstruidas para escudar a usuarios de este cdigo poco trivial de lenguaje normalizado de consulta. Afortunadamente, un nmero de herramientas OLAP poco de relaciones son provid-ing ms soporte incorporado robusto para navegar estas jerarquas molestosas para parte pequea para las dimensiones medianas tpicamente con menos de 64,000 miembros.
Combinando Fuentes Mltiples de Los Datos del Cliente Ahora que hemos diseado la dimensin del cliente, es hora de poblarlo. Es probable que la dimensin conformada del cliente sea una destilacin de datos de varios sistemas operacionales y posiblemente fuera de fuentes. Si pasa lo peor, un cliente nico tiene identificadores mltiples en series mltiples sistemas operacionales del punto de toque. Obviamente, uno de objetivos de operacional gestor de relaciones con el cliente es crea un identificador nico del cliente y restringe la creacin de identificadores innecesarios. Mientras tanto, los datos almacenan pareja probablemente se encontrar responsable para sort-ing apagado e integrante las fuentes dispares de informacin del cliente. Desafortunadamente, no hay arma secreto para abordar esta consolidacin de datos. Los atributos en la dimensin del cliente deberan representar la mejor fuente disponible para esa informacin en la empresa. Querremos integrar un cambio nacional de proceso de la direccin (NCOA) para asegurar que los cambios de la direccin son captados. Mucho del alzamiento pesado se asoci con Cu-tomer-tomer-match de demandas de consolidacin de datos del cliente o lgica deduplicating. Cambiar de direccin duplica o direcciones no vlidas de cliente grande listan es crtico para eliminar los costos de satisfaccin del cliente financieros y asociados con redundantes, descaminados, o las comunicaciones de undeliv-erable, adems de evitar cuentas del cliente de desavo. La ciencia de corresponder a clientes es ms sofisticada que primero podra aparecer. Implica lgica confusa, algoritmos que analizan gramaticalmente direccin, y los enormes directorios de consulta para validar ponen la direccin en
elementos y cdigos postales, cul difiera significativamente por pas. Hay especializado comercialmente ofertas del software disponible y de servicio que pueden representar al cliente individual o entidad comercial igualando a exactitud notable. A menudo estos productos cotejan los componentes de la direccin con cdigos estndar de censo, como cdigos estatales, cdigos del pas, trechos de censo, bloquee grupos, reas estadsticas metropolitanas (los pases ms gravemente afectados), y latitud /longitud, lo cual facilita la anexin de archivo de datos externos. Como discutiremos en Captulo 9, hay tambin capacidades del householding que agrupan o clientes del enlace que comparten informacin de nombre similar y de la direccin. En vez de meramente realizar intrafile correspondiendo, algunos servicios mantienen un enorme externo archivo de referencias de todo el mundo en los Estados Unidos a quien corresponder en contra. Aunque estos productos y servicios son potencialmente caros y complicados, vale la pena hacer la inversin si el corresponder a clientes (as como en la fundacin de rudimentaria gestor de relaciones con el cliente) es estratgico para su organizacin. Al fin, la consolidacin efectiva de datos del cliente depende de un balance de capturar
Los datos tan exactamente como posibles en los sistemas de la fuente se acoplaron con herramientas energticas de purificacin /anexin de datos en el proceso de escenificacin.
Analizando Datos del Cliente de Mltiplo El Negocio Va en Procesin Como indicamos en tiempo atrs captulos, los almacenes de datos deberan ser proceso construido por el proceso, no departamento por departamento, en una fundacin de dimensiones conformadas para soportar integracin de proceso de cruz. Podemos imaginar poner en duda las ventas o Tablas de hecho de servicio de apoyo para mejor comprender un cliente historia de compra o de servicio. Desde las ventas y Tablas del soporte ambos le contienen a un cliente llave extranjera, podemos fomentar imagine adjuntar ambas Tablas de hecho a una dimensin comn del cliente simultneamente resumir hechos de ventas junto con los hechos del soporte para un Cu-tomer dado, as como en Figura 6.11. Desafortunadamente, lo muchos para un para muchas juntura devolver la mala contestacin en un ambiente de relaciones por las diferencias en cardinality de la mesa de hecho. Considere el caso en el cual tenemos una mesa de hecho de solicitaciones del cliente y otra mesa de hecho con las respuestas del cliente resultando ambos del solici-tations y otras fuentes independientes. Hay uno que est para muchas relacin entre cliente y solicitacin y otro un para muchas relacin entre cliente y la respuesta. La solicitacin y Tablas de hecho de respuesta tienen cardinalities diferentes; En otras palabras, no cada solicitacin da como resultado una respuesta (desafortunadamente para el departamento de ventas), y algunas respuestas son recibidas para las cuales no hay solicitacin. Simultneamente adjuntando la mesa de hecho de solic-itation a la dimensin del cliente, cul es a su vez adjuntado a la mesa de hecho de respuesta, no devuelve la respuesta correcta en un sistema de gestin de base de datos de relaciones por las diferencias del cardinality. Afortunadamente, este problema es con holgura eludido. Simplemente publicamos cdigo de lenguaje normalizado de consulta del multipaso para poner en duda la
solicitacin y Tablas de respuesta en las averiguaciones separadas y en ese entonces la juntura exterior que la dos respuesta coloca. El acercamiento del multipaso tiene beneficios adicionales en trminos de mejores parmetros de funcin que controla, adems de soportar averiguaciones que combinan datos de Tablas de hecho en posiciones fsicas diferentes.
Los Hechos de Solicitacin del Cliente La llave del Cliente de la Llave de Fecha de solicitacin (FK) (FK) Ms Llaves Extranjeras ... Hechos de Solicitacin Las Dimensiones del Cliente El cliente los Atributos del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) Los Hechos de Respuesta del Cliente Cliente de Llave de Fecha de respuesta (FK) Key (FK) Ms Foreign Teclea ... Hechos de Respuesta
Creo que 6.11 que Many-To-One-To-Many uni Tablas no deberan ser puestos en duda con un soltero SELECCIONE declaracin.
Tenga mucho cuidado al simultneamente adjuntar una mesa unidimensional a dos Tablas de hecho de cardinality diferente. En muchos casos, los sistemas de relaciones devolvern la mala contestacin. Un problema similar surge al ensamblar dos Tablas de hecho de granularidad diferente en seguida.
Si los usuarios son frecuentemente datos que combinan de procesos comerciales mltiples, en ese entonces una mesa adicional de hecho puede forjarse que los carteles los datos una vez en una mesa que se secunda a ras, consolidada de hecho en vez de confiar en usuarios para combinar los datos consistentemente y exactamente en el de ellos. Discutiremos Tablas consolidadas de hecho ms all en Captulo 7. Meramente usando cdigo de lenguaje normalizado de consulta para taladrar a travs de Tablas de hecho para combinar las marcas de resultados ms sentido cuando los procesos subyacentes estn menos apretadamente correlacionados. Por supuesto, al construir la mesa consolidada de hecho, nosotros todava necesitaramos establecer el negocio domina tratar del car-dinality discrepante (por ejemplo, incluye la mesa combinada de hecho todas las solicitaciones y las respuestas o slo esos donde una solicitacin y una respuesta ocurrida?).
Resumen En este captulo que canalizamos exclusivamente al cliente, a partir de una visin general de fundamentos de gestor de relaciones con el cliente. Entonces ahondamos en asuntos del diseo rodeando la mesa de dimensin del cliente. Discutimos anlisis gramatical de nombre y de la direccin dnde los campos operacionales est descompuesto para sus elementos bsicos a fin de que pueden ser estndar y validados. Exploramos varios otros tipos de atributos comunes de dimensin de Cu-tomer, como las fechas, los atributos de segmentacin, y los hechos de aggre-gated. Los arbotantes de dimensin que contienen un bloque grande de atributos del cardinality relativamente bajo fueron descritos como permisibles copos de nieve en nuestros diseos dimensionales.
En los casos donde nuestra dimensin del cliente tiene millones de filas, nosotros recom-mend creando una minidimensin de frecuentemente analizado o frecuentemente atributos chang ing. Una minidimensin es tambin apropiada para sets de atributo de anchura variable. La mesa de hecho entonces tiene dos llaves extranjeras relacionadas por cliente, uno para la dimensin primaria del cliente y otro para la minidimensin. Discutimos las implicaciones de contar dentro de una dimensin del cliente dnde tipo adicional 2 filas se le crean manejar cambio. Tambin exploramos la nocin de crear dimensiones conductistas del grupo de estudio, cul meramente consiste en llaves del cliente que comparten una experiencia o rasgo comn. Finalmente, abordamos el manejo de jerarquas simples y complicadas y comerciales del cliente. Las jerarquas no previsibles del cliente de profundidad, variable comnmente requieren que el uso de un cuadro puente refleje la jerarqua recursiva en una manera que puede ser puesta en duda por cdigo estndar de lenguaje normalizado de consulta.
Brevemente discutimos el uso de las ofertas del software externo y de servicio para la informacin del cliente de con-solidate de manera impresionante al manejar datos duplicados. Finalmente, dimos un paso atrs en el mundo de Tablas de hecho por un momento para discutir las cadas potenciales de poner en duda a travs de dos hecho que las Tablas unieron a travs de un cliente comn dimensiona mesa.
Contabilidad EL CARBONO HAPTE R
El anlisis del inancial se extiende a lo largo de una coleccin variada de aplicaciones de contabilidad, incluyendo el libro mayor de gen-eral y los sublibros mayores detallados para comprar y las cuentas por pagar, la facturacin y las cuentas por cobrar, y los activos fijos. Desde que ya nos hemos tocado en rdenes de compra y las facturas en este libro, enfocaremos la atencin en el libro mayor de gen-eral en este captulo. Los libros mayores generales fueron una de las primeras aplicaciones para ser hace decenios informatizados, dado la necesidad para el manejo preciso de los registros financieros de un com-pany. Quiz alguno de ustedes est silencio corriendo su negocio en un sistema del libro mayor de veinte aos de edad. En este captulo discutiremos los datos coleccionados por el libro mayor general en trminos de ambas transacciones del asiento de diario y las fotos en el final de un ejercicio fiscal. Tambin hablaremos del proceso de presupuestacin.
el libro mayor general las transacciones y fotos peridicas El ao para fechar hechos el fiscal mltiple llevando las cuentas calendarios
presupuestando proceso y datos asociados, incluyendo granularidad neta de cambio el hecho consolidado pospone que la mtrica del cartel de mltiple negocio va en procesin, como datos reales y de presupuesto el papel de soluciones financieras analticas en lnea analticas procesadoras (OLAP) y empacadas
173
Llevando Las Cuentas Estudio de Casos Desde que las finanzas fueron una adoptadora antigua de tecnologa para mejor correr negocios, no es de extraar que las soluciones anticipadas del soporte de decisin enfocaron la atencin en el anlisis de datos financieros. Los analistas financieros son algunos de la mayor parte de individuos literatos en datos y sabios en la hoja contable alrededor. A menudo su anlisis es dissemi-nated o apalancado por muchos otros en una organizacin. Los gerentes en todos los niveles necesitan que acceso oportuno teclee mtrica financiera. Adems de los informes estndar receptores, la necesidad de gerentes la habilidad para analizar tendencias de funcin, discordias, y las anomalas con pariente aceleran y esfuerzo mnimo. Desafortunadamente, el rezago de trabajo de peticiones especiales para datos financieros es a menudo muy largo. Como observamos frecuentemente en sistemas operacionales de la fuente, los datos en el libro mayor general se esparcen probablemente entre centenares de Tablas. Ganar acceso a los datos financieros y crear informes ad hoc pueden requerir que un anillo del decodificador navegue a travs del laberinto de pantallas. Esto est en contra del objetivo de muchos orga-nizations para empujar responsabilidad del fiscal y responsabilidad para aplicarle delineador a los gerentes. El almacn de datos puede proveer una sola fuente de informacin financiera utilizable, comprensible, asegurando que todo el mundo trabaja con los mismos datos basados en mtrica y definiciones comunes. La audiencia para datos financieros es muy diversa en muchas organizaciones, extendindose de analistas para los gerentes operacionales para los ejecutivos. Para cada grupo, necesitamos decidir cul subconjunto de datos financieros corporativos es necesitado, en cul formato, y con qu frecuencia. Los analistas y los gerentes querrn mirar informacin en un nivel alto y entonces profundizar para asientos de diario para ms detalle. Para ejecutivos, los datos financieros de los datos almacenan a menudo piensos su consola o su tanteador de indicadores cruciales de per-formance. Armados con acceso directo para la informacin, los gerentes pueden obtener respuestas para cuestiona ms fcilmente que cuando le es forzado a avanzar con dificultad a travs de un intermediario. Entretanto, el departamento financiero puede fijar la atencin en diseminacin de informacin y anlisis de valor agregado en vez de enfocar la atencin en creacin de informe.
Los beneficios de acceso mejorado para datos financieros enfocan la atencin en oportunidades para bet-ter manejan riesgo, aerodinamizan operaciones, e identifican potenciales ahorros de costos. Mientras el anlisis financiero tiene organizacin cruzada impacto, muchos negocios canalizan su implementacin inicial del almacn de datos a oportunidades que generan renta estratgica. Consecuentemente, los datos de contabilidad no son a menudo el tema primersimo rea abordado por el equipo del almacn de datos. Dado su pericia con technol-ogy, el departamento financiero a menudo ya ha realizado magia con hojas de anlisis y las personales bases de datos para crear trabajo alrededor de soluciones analticas, quiz para su dao de corto plazo, desde que estos apuros interinos imperfectos probablemente son enfatizados para los lmites.
Los Datos Generales del Libro Mayor El libro mayor general (G/L) es un sistema financiero de la fundacin de fondo porque vincula la informacin detallada coleccionada por la compra, efectos a pagar (lo que usted le debe a los otros), y sublibros mayores de efectos por cobrar (qu otros le deben) o sys-tems. En este estudio de casos que canalizaremos al libro mayor general en vez de los sublibros mayores, cul sera manipulado como procesos comerciales separados y hecho pospone. Como avanzamos con dificultad a travs de un diseo anticido para datos G/L, descubrimos, otra vez, esos dos dibujos tcnicos complementarios con foto peridica y las Tablas veteadas en transaccin de hecho funcionando juntos son requeridos.
El Libro Mayor General la Foto Peridica Empezamos por excavar en el suelo en una foto de las cuentas G/L al final de cada perodo de fis-cal (o el mes si su contabilidad fiscal perodo se pone al lado de los meses de calendario). Referente a otra vez para nuestro proceso de cuatro pasos para disear que dimen-sional modela, el proceso comercial obviamente enfoca la atencin en la G / L. El grano de esta foto peridica es una fila por el ejercicio fiscal para el nivel ms granular en el plan contable de G/L.
Plan Contable La piedra angular del G/L es el plan contable. El plan contable de G/L es el eptome de una llave automatizada porque usualmente consiste en una serie de identificadores. Por ejemplo, la primera parte establecida de dgitos puede identificar la cuenta, tipo de la cuenta (por ejemplo, el activo, el adeudo, la equidad, el ingreso, o el gasto), y otra cuenta se remanga. Algunas veces la inteligencia est incrustada en la cuenta numerando plan. Por ejemplo, los nmeros de cuenta de 1,000 a travs de 1,999 podran ser cuentas de activo, considerando nmeros de cuenta extendindose desde 2,000 para 2,999 puede identificar adeudos. Obviamente, en el almacn de datos, incluiramos el tipo de la cuenta como un atributo de dimensin en vez de forzarle a usuarios a filtrar sobre el primer dgito del nmero de cuenta.
El plan contable tambin probablemente provee entendimiento profundo suponiendo el organizativo centro costado asociado con la cuenta. Tpicamente, los elementos organizativos le proveen un completo movimiento hacia arriba de centro de costos al departamento a la divisin, por ejemplo. Si el G/L corporativo combina datos a travs de unidades comerciales mltiples, el plan contable tambin indicara la unidad comercial o compaa subsidiaria. Obviamente, los planes contables se diferencian de compaa para compaa. Estn a menudo sumamente complicados. En nuestra vieta de estudio de casos que asumimos que la grfica de
Lleva las cuentas naturalmente se descompone en dos dimensiones. Focos de una dimensin sobre los atributos del G/L financiero llevan las cuentas, mientras que el otro representa el organizativo movimiento hacia arriba. El movimiento hacia arriba de organizacin puede ser un hierar-chy de profundidad fija, donde podemos maniobrar los niveles de jerarqua como los atributos separados en el coste de constitucin centren dimensin. Si la jerarqua organizativa est harapienta con rboles de movimiento hacia arriba del imbalanced, en ese entonces necesitaremos recurrir a la tcnica del cuadro puente de Captulo 6 para ocuparnos de jerarquas de profundidad variable. El G/L algunas veces rastrea resultados financieros para mltiples juegos de libros o sublibros mayores para soportar requisitos diferentes, como agencia tributaria o reguladora reportando. Trataremos esto como una dimensin separada porque es un filtro tan fundamental.
El Final de Perodo
Al final de cada ejercicio fiscal, el organismo de finanzas es responsable de finalizar los resultados financieros a fin de que pueden ser oficialmente reportadas internamente y externamente. Tpicamente toma hacia varios das al final de cada perodo reconcilian y balancean los libros antes de que pueden ser terminados con el sello oficial de aprobacin del departamento financiero. Desde all, las vueltas de foco de las finanzas para reportar e interpretar los resultados. El departamento financiero a menudo produce incontables informes y se origina de incontables variaciones sobre las mismas preguntas cada mes. Los analistas financieros estn todo el tiempo esperando aerodinamizar los procesos para el fin de perodo cerrando, conciliacin, y reportando de resultados G/L. Mientras / Sistemas Lindenmeyeres de opera-tional G a menudo soportan estas capacidades requeridas, pueden ser difciles, especialmente si usted no est tratando con una G moderna / L. En esto chap-ter que enfocaremos la atencin ms fcilmente analizar los resultados financieros cerrados en vez de facilitar el final. Sin embargo, en muchas organizaciones, los balances de comprobacin G/L estn
cargados en los datos almacena para apalancar las capacidades del rea de presentacin de la casa de loza de datos para encontrar las agujas en el pajar G/L y entonces hacer los ajustes operacionales apropiados antes de que el perodo cesa. El dibujo tcnico de muestra en Figura 7.1 soporta el acceso y anlisis de saldos de las cuentas G/L al final de cada perodo de la cuenta. Eso sera muy til para muchas clases de anlisis financiero, como ordenaciones por rango de la cuenta, tendiendo patrones, y comparaciones perodos a perodo. Por el momento, estamos simplemente hechos reales representadores en la Figura 7.1 dibujo tcnico; Fijaremos nuestra atencin en datos de presupuesto ms tarde en este captulo. Obviamente, la cantidad de bal-ance es un hecho semiaditivo. Aunque tpicamente tratamos de evitar hechos semiaditivos, tiene sentido para almacenar el balance en este dibujo tcnico porque muchas de las cuentas son rastreadas como un balance. De otra manera, necesitaramos retroceder al principio de hora de calcular un saldo al final del ejercicio preciso.
La Dimensin de Ejercicio Fiscal La descripcin de Perodo de Contabilidad de Nmero de Perodo de Contabilidad de la Llave de ejercicio fiscal (PK) Llevando las Cuentas Ao Fiscal de Perodo G/L Dimensin Account G/L Account Tipo de la Llave G/L Account Name G/L Account Category G/L Account (PK) G/L Tmele Instantneas a Fact El ejercicio fiscal Llave G/L (FK) Key (FK) G/L Llave Account (FK) G/L Cantidad de Adeudo de Perodo de Cantidad de Balance de Fin de Perodo de la Llave Organization (FK) La Cantidad de Crdito de Perodo La Cantidad de Cambio Neto de Perodo G/L Dimension G/L Teclee (PK) G/L Anote en Libros Nombre
G/L Dimensin Organization G/L Llave Organization (PK) Cost Nombre del Centro El Nombre De La Compaa de Nombre de la Unidad de Negocio de Nombre de Divisin de Nmero del Departamento de Nombre del Departamento de Nmero del Centro de Costo
Figura de foto de 7.1 Libros Mayores Generales (G/L) de peridico.
El Ao para Fechar Hechos Los diseadores estn a menudo tentados de tienda fechar columnas en Tablas de hecho. Piensan que sera de ayuda almacenar cuarta parte a fechar o el ao para fechar totaliza en cada fila de hecho a fin de que los usuarios no necesiten calcularlos. Necesitamos recordar que los hechos numricos deben estar consistente con el grano. Salir en citas fildea no es cierto para el grano y est cargado de peligro. Cuando los alborotos de hecho son puestas en duda y summa-rized en formas arbitrarias, estos falso para los hechos del grano producen absurdos, los resultados exagerados. Deberan ser dejados sin el diseo del dibujo tcnico de relaciones y calculados en la aplicacin de acceso de datos en lugar de eso.
En general, fechar totales no debera estar calculado, almacenado en la mesa de hecho.
Las Monedas Circulantes Mltiples Vueltas a Visitar Si el libro mayor general consolida datos que han sido captados en curren-cies mltiple, lo maniobraramos por mucho que discutisemos en Captulo 5. Con datos financieros, tpicamente queremos representar los hechos en trminos de ambos la moneda local y una moneda circulante corporativa estndar. En este caso, cada fila en la mesa de hecho representara un set de cantidades de hecho expresadas en moneda local y un set separado de cantidades de hecho expresadas en la moneda circulante corporativa equivalente. El proceder nos deja resumir los hechos en una moneda circulante corporativa comn fcilmente sin saltar a travs aros en nuestras aplicaciones de acceso. Por supuesto, tambin sumaramos una dimensin de moneda circulante como una llave extranjera en la mesa de hecho para identificar el tipo de la moneda local.
Las Transacciones Generales de la Publicacin del Libro Mayor Mientras el fin de foto de perodo se ocupa de una multitud de anlisis financieros, muchos usuarios necesitan bucear en los detalles subyacentes. Si la foto peridica
La Dimensin de Fecha del Poste La llave de Fecha del poste (PK) Los Atributos de Fecha del Poste G/L Dimensin Account G/L Llave Account (PK) G/L Atributos Account El Hecho del Asiento de Diario G/L La fecha del poste Llave G/L (PK) Key (FK) G/L Llave Account (FK) G/L Llave Organization (FK) Cantidad Crucial Que Indica (FK) del Asiento de Diario de Nmero del Asiento de Diario (DD) De Debe Y Haber G/L Dimension G/L Teclee (PK) G/L Attributes G/L Dimensin Organization G/L Llave Organization (PK) G/L Atributos Organization
La Dimensin Que Indica de Debe Y Haber La Llave Que Indica de Debe Y Haber La Descripcin Que Indica de Debe Y Haber Figura 7.2 transacciones Generales del asiento de diario del libro mayor (G/L).
Los datos dan la apariencia de estar inusuales o no como esperado, los analistas querr considerar las transacciones detalladas para buscar desordenadamente en el asunto. Los otros querrn acceso para los detalles porque lo resumido mensualmente se balancee puede obscurecer dispari-tie grande en el nivel granular de transaccin. Otra vez, complementamos la foto peridica con un dibujo tcnico detallado de transaccin del asiento de diario. Por supuesto, las cuentas por pagar y sublibros mayores a cobrar pueden contener transacciones en aun niveles ms bajo de detalle, lo cual sera captado en separata que el hecho pone sobre una mesa con dimensionalidad adicional. En esta situacin estamos todava enfocados al proceso G/L; Sin embargo, el grano de la mesa de hecho es ahora una fila para cada transaccin del asiento de diario G/L. La transaccin de entrada de jour-nal identifica la cuenta G/L y la cantidad de adeudo aplicable o de crdito. Como ilustrados en Figura 7.2, reutilizaremos varias dimensiones del ltimo dibujo tcnico, incluyendo la cuenta y dimensiones de organizacin. Si nuestro G/L rastrease mltiples juegos de libros, tambin incluiramos la dimensin del libro mayor. Estamos captando transacciones del asiento de diario por la transaccin anunciando en carteles fecha, as es que usaremos una mesa de fecha diariamente granulada en este dibujo tcnico. A merced de las reglas de negocio nos asociamos con los datos de la fuente, podemos necesitar que una segunda dimensin de fecha de caracterizacin de papeles distinga la fecha de asiento de la efectiva fecha de la contabilidad. El nmero del asiento de diario probablemente es una dimensin degenerada sin conexin para una mesa asociada de dimensin. A merced de los datos de la fuente, podemos tener un tipo de transaccin del asiento de diario y podemos emparejar una descripcin. En esta situacin crearamos una dimensin separada de transaccin del asiento de diario. Suponiendo que las descripciones no son simplemente texto
del freeform, esta dimensin tendra significativamente menos filas que la mesa de hecho, lo cual tendra una fila por lnea del asiento de diario. El especfico asiento de diario como el que el nmero todava sera tratado degenerado. El Hecho Mecanografa Cada fila en la mesa de hecho del asiento de diario sera identificada tan cualquier un crdito o un adeudo. Dado este sparsity inherente, probablemente almacenaramos un solo asiento de diario
La cantidad con un indicador de adeudo /crdito, a menos que estamos usando una plataforma de la base de datos, como Orculo, que mantenga columnas de anchuras variables a fin de que las columnas vacas suben espacio mnimo del disco. El indicador de adeudo /crdito cobrara dos y slo dos valores. Podemos crear un adeudo /crdito de dos filas descifra mesa de dimen-sion, o si su base de datos mantiene a indices de los que se traz un mapa en pedacito, slo podemos incluir la abreviatura estndar en la industria (/ el retorno de carro DR) de adeudo /crdito en la mesa de hecho con un ndice del que se traz un mapa en pedacito para el filtrado rpido o a constreir. No queremos que usted perciba que sta es una excusa para bordear mesa de dimensin descifran pospone para todas las dimensiones de low-cardinality. Tiene sentido en este caso porque las abreviaturas son comprendidas universalmente, lo cual no es usualmente el caso con nuestras abreviaturas y cdigos internos. Noventa y nueve por ciento del tiempo que continuaremos creando Tablas de dimensin que contiene textual, descriptivo descifra.
El Fiscal Mltiple Llevando las Cuentas Calendarios En este dibujo tcnico que capturamos datos por la fecha de asiento, pero que los usuarios probablemente tambin quieren que la habilidad resuma los datos por el perodo fiscal de la cuenta. Desafortunadamente, los ejercicios fiscales de fis-cal a menudo no se ponen al lado de los meses estndar del calendario gregoriano. Por ejemplo, una compaa puede tener 13 ejercicios fiscales de cuatro semanas en un ao fiscal empezando el 1 de septiembre en vez de 12 perodos mensuales empezando el 1 de enero. Si tratamos de un solo calendario fiscal, entonces cada da en un ao concuerda con un solo mes de calendario, as como tambin uno solo ejercicio fiscal. Dados estas relaciones, el calendario y ejercicios fiscales son atributos meramente jerrquicos en la dimensin diaria de fecha, como vimos en Captulo 2. La mesa diaria de dimensin de fecha obviamente se conformaba a una mesa de dimensin de mes de calendario, as como tambin a una mesa de dimensin de ejercicio fiscal del fiscal. En otras situaciones podemos tratar de calen-dars fiscal mltiple de contabilidad eso sea diferente por sucursal o la clase de negocio. Si el nmero de calendarios fiscales nicos es un nmero fijo, bajo, en ese entonces podemos incluir cada set de
atributos del calendario excepcionalmente fiscales designados en una sola dimensin de fecha. Una fila dada en la dimensin diaria de fecha podra ser identificada como perteneciente al ejercicio fiscal
1 para subsidiario Uno, excepto el ejercicio fiscal 7 para B subsidiaria.
En una situacin ms complicada con un gran nmero de calendarios fiscales diferentes, podramos identificar el calendario fiscal corporativo oficial en la dimensin de fecha. Entonces tenemos varias opciones para poner la direccin en los calendarios fiscales especficos en la sucursal. El acercamiento ms comn es crear un arbotante de dimensin de fecha con una llave de mul-tipart consistente en la fecha y llaves subsidiarias. Habra una fila en esta mesa por cada da para cada sucursal. Los atributos en este arbotante consistiran en agrupamientos fiscales (como el compaero de cita fiscal de fin de semana y el fin fiscal de perodo pasan de moda). Necesitaramos un mecanismo para filtrar en una sucursal especfica en el arbotante. El proceder a travs de una vista entonces dejara el arbotante ser
Presentado como si fuese lgicamente de la mesa de dimensin de fecha. Un segundo acercamiento para abordar los calendarios especficos en la sucursal debera crear dimensiones de fecha de reconocimiento mdico de sep-arate, en lugar de los puntos de vista, para cada calendario subsidiario usando un conjunto comn de llaves vicarias de fecha. Esta opcin probablemente sera usada si sus datos de hecho estuviesen descentralizados por sucursal. A merced de sus datos acceden a las capacidades de la herramienta, puede ser ms fcil tampoco filtrar en el arbotante subsidiario tan descrito en la primera opcin o asegurar uso de la mesa fsica especfica en la sucursal correcta (la segunda opcin) de dimensin de fecha. Finalmente, le podramos asignar otra llave extranjera en la mesa de hecho a una mesa fiscal subsidiaria de dimensin de perodo. El nmero de filas en esta mesa era el nmero de perodos fiscales (aproximadamente 36 por tres aos) por el nmero de calendarios nicos. Esta va de entrada simplifica acceso del usuario pero pone torcedura adicional en la zona de estacionamiento porque debe insertar la llave fiscal correcta de perodo durante el proceso de transforma-tion. Estados Financieros Una de las funciones primarias de un / Sistema Lindenmeyer de la G es producir los reportes financieros oficiales de la organizacin, como el balance de situacin y el estado de prdidas y ganancias. Typ-ically, las agarraderas operacionales del sistema la produccin de estos informes. No querramos que el almacn de datos trate de reemplazar los informes publicados por el sistema financiero operacional. Sin embargo, los datos que el almacn mancomuna algunas veces crean una complementaria base de datos de datos agregados para proveer simplific accede a reportar informacin que puede ser ms ampliamente diseminada a todo lo largo de la organizacin. Las dimensiones en la base de datos del estado financiero incluiran el ejercicio fiscal y centro de costos. En vez de mirar a G/L datos que se llevan las cuentas a ras, los datos de hecho seran agregados y etiquetados con el nmero apropiado de la lnea del estado financiero y etiqueta. De esta manera, los gerentes fcilmente podran considerar tendencias de funcin para una lnea dada en el estado financiero con el paso del tiempo para su organizacin. Sim ilarly, indicadores cruciales de funcin y ratios financieros pueden ser hechos disponibles en el mismo nivel de detalle.
Presupuestando Proceso / Sistemas Lindenmeyeres modernos de la G tpicamente incluyen la habilidad a integrar datos de presupuesto en la G / L. Sin Embargo, si nuestro G/L o carece esta capacidad o nosotros hemos elegido no implementarla, necesitamos proveer un mecanismo alternativo para soportar las comparaciones de presupuestacin de proceso y de discordia. Dentro de la mayora de organizaciones, el proceso de presupuestacin es mirado como una serie de acontecimientos. Antes del principio de un ao fiscal, cada gerente central costado tpicamente
Crea un presupuesto, pelusa quebrada por artculos de lnea presupuestaria, lo cual es entonces aprobado. En realidad, la presupuestacin es rara vez simplemente uno una vez por el acontecimiento de ao ms. Bud llega se est volviendo ms dinmico porque hay ajustes de presupuesto como los progresos de ao, los cambios reflectantes en las condiciones de negocios o las realidades de gasto real versus el original refrenen los gastos. Los gerentes quieren ver el estatus del presupuesto corriente, as como tambin cmo ha estado el presupuesto alterado desde la primera versin aprobada. Como el ao se desarrolla, los compromisos para gastar los monies presupuestados se hacen. Finalmente, los pagos son tramitados. Como modeladores dimensionales, miramos la cadena de presupuestacin como una serie de Tablas de hecho. Comenzaremos con una mesa de hecho de presupuesto. Para un rubro contable de presupuesto de gastos, cada fila identifica lo que una organizacin en la compaa est permitido gastar para qu el propsito durante un dado lmite de tiempo. De modo semejante, si el rubro contable reflexiona un vaticinio de ingreso, cul es simplemente otra variacin de un presupuesto, lo hara iden-tify lo que un organismo tiene la intencin de ganar por qu causa durante un lmite de tiempo. Podramos fomentar identifica el grano para ser una foto de estatus de cada rubro contable en cada presupuesto cada mes. Aunque este grano le tiene un anillo familiar para l (porque siente como un informe de gestin), es una eleccin pobre como el grano de la mesa de hecho. Los hechos en tal informe de situacin son todo lo que el semiaditivo balancea en vez de los hechos completamente aditivos. Tambin, este grano dificulta decidir cmo ha cambiado mucho desde el mes previo o alojar porque tenemos que obtener los registros desde varios lapsos de tiempo y entonces sustraerlos el uno del otro. Finalmente, esta eleccin del grano requerira que la mesa de hecho contenga muchos registros de dupli-cated cundo los cambios insignificantes adentro los meses sucesivos para un rubro contable dado. En lugar de eso, el grano en el que estamos interesados es el cambio neto de la lnea presupuestaria tem en un centro de costos tan ocurrido durante el mes. Mientras esto sacia para el presupuesto reportando propsitos, los contadores eventualmente necesitarn empatar para la lnea presupuestaria tem de regreso a una cuenta especfica G/L que es afectada, as es que nosotros tambin bajaremos al nivel de la
cuenta G/L. Dado el grano, las dimensiones asociadas incluira el mes efectivo, la organizacin, la lnea presupuestaria tem, y la cuenta G/L, como ilustrado en Figura 7.3. La dimensin de organizacin es idntica para el mismo usado ms temprano con los datos G/L. La dimensin G/L es tambin una dimensin reutilizada. La nica complicacin estimando la dimensin de la cuenta G/L es que algunas veces un solo artculo de lnea presupuestaria tiene un impacto en ms que una cuenta G/L. En tal caso, necesitaramos asignarle la lnea presupuestaria a las cuentas individuales G/L. Desde que el grano de la mesa de hecho de presupuesto est al lado de G/L cuenta, una sola lnea presupuestaria para un centro de costos puede ser representada como varias filas en la mesa de hecho.
La Dimensin Efectiva de Fecha El presupuesto el Ao de Fecha de Efectividad de Presupuesto de Mes de Fecha de Efectividad de Presupuesto Effective Date Key (PK) y ms G/L Dimensin Account G/L Llave Account (PK) G/L Atributos Account El Hecho de Presupuesto El presupuesto la Llave del Artculo de Lnea Presupuestaria Effective Date Key (FK) (FK) G/L Llave Account (FK) G/L Cantidad de Presupuesto de la Llave Organization (FK) La Dimensin del Artculo de Lnea Presupuestaria El ao presupuestario de Descripcin de Lnea Presupuestaria de la Llave del Artculo de lnea presupuestaria (PK) La Descripcin de Subcategora de Lnea Presupuestaria La Descripcin de Categora de Lnea Presupuestaria G/L Dimensin Organization G/L Llave Organization (PK) G/L Atributos Organization
Resuelvo 7.3 dibujo tcnico Anual de presupuesto.
El artculo de lnea presupuestaria identifica el propsito del gasto propuesto, como sueldos del empleado o tiles de oficina. Tpicamente, varios niveles de categoras del resumen son asociados con una lnea presupuestaria tem. Como discutimos en Captulo 5, todos los artculos de lnea presupuestaria no pueden tener el mismo nmero de niveles en su jerarqua de sum-marization, como cuando algunos tienen slo un categorial movimiento hacia arriba pero no una subcategora. En este caso podemos poblar los atributos de dimensin por replus-cating el nombre categorial en la columna subcategorial para evitar que tiene rollo de rubros contables hasta un No cubo subcategorial Aplicable . El dimen-sion de rubro contable de presupuesto tambin identificara el ao presupuestario y versin de presupuesto. El mes efectivo es el mes durante el cual los cambios de presupuesto son anunciados en carteles. Las primeras entradas para un ao presupuestario dado saldran a la vista el mes efectivo cuando el presupuesto es primero aprobado. Si el presupuesto est actualizado o modificado como el brote llega el ao llega en camino, los meses efectivos ocurriran durante el ao presupuestario. Si no ajustamos el presupuesto del todo a todo lo largo del ao, en ese entonces las nicas entradas seran las primeros cuando el presupuesto es aprobado. Esto es lo que nosotros quisimos decir cuando especificamos el grano para ser el cambio neto. Es crtico que usted comprenda este punto, o usted no comprender lo que est en esta mesa de hecho de presupuesto o cmo es usada. Algunas veces los presupuestos son creados como el gasto anual planifica; A otras veces que son doblegados por el mes o por cuarta parte. El dibujo tcnico en Figura 7.3 supone que el presupuesto es una figura anual, con el ao presupuestario identificado en la dimensin de rubro contable de presupuesto. Si necesitamos expresar los datos de presupuesto gastando mes, necesitaramos incluir una segunda mesa de dimensin de mes que desempea el papel del mes de gasto. La mesa de hecho de presupuesto hace a un soltero presupuestar hecho de cantidad que es con creces aditivo. Si presupuestamos una organizacin multinacional, la
cantidad de presupuesto puede ser etiquetada con el factor esperado de conversin de moneda para planificar propsitos. Si la cantidad de presupuesto para una lnea presupuestaria dada y cuenta G/L es modificada
Durante el ao, una fila adicional se suma a lo represent-ing de la mesa de hecho de presupuesto el cambio neto. Por ejemplo, si el presupuesto original fuese $200,000, podramos tener otra fila en junio para un incremento de $40,000 y en ese entonces otro en octubre para un $25,000 negativo como nos apretemos nuestros cinturones ahondando en fin de ao. Una vez que el ao presupuestario comienza, los gerentes hacen compromisos para gastar el brote pasan a travs de rdenes de compra, rdenes de trabajo, u otras formas de contratos. Los envejecentes hombres con entusiasmo interes en monitorear sus compromisos y compararlos con el presupuesto anual para manejar su gasto. Nosotros envi-sion un segundo hecho podemos posponer para los compromisos que las acciones las mismas dimensiones, adems de dimensiones identificando el documento especfico (la orden de compra, la orden de trabajo, o el contrato) de compromiso y el compromiso festeja. En este caso el hecho sera la cantidad cometida. Finalmente, los pagos son hechos como los monies sean transferidos para la fiesta nombrada en el compromiso. De un prctico punto de vista, el dinero puede ya no en el presupuesto cuando el compromiso es hecho. Sin embargo, el departamento financiero est interesado en la relacin entre los compromisos y pay-ments porque maneja el dinero en efectivo de la compaa. Las dimensiones se asociaron con la mesa de hecho de pagos incluira que el dimen-sions de la mesa de hecho de compromiso y una dimensin de pago a identificarle el tipo de pago y el portador a quin el pago en verdad fue hecho. En la cadena de presupuestacin expandimos la lista de dimensiones como nos movamos del presupuesto para los compromisos para los pagos. Con este diseo, podemos crear un nmero de interesarle analiza. Mirar la corriente presupuest cantidad por departamento y el rubro contable, constreimos en todas las fechas hasta ahora, sumando las cantidades por departamento y el rubro contable. Porque el grano es el cambio neto en los rubros contables, sumar todas las entradas sobre el tiempo hace exactamente la cosa correcta. Sacamos en limpio la cantidad aprobada actual de presupuesto, y tenemos exactamente esos rubros contables en los departamentos dados que tienen un presupuesto. Para pedir todos los cambios para el presupuesto para rubros contables diversos,
simplemente aprendemos de memoria tensin en un solo mes. Reportaremos slo esos rubros contables que experimentaron un cambio durante el mes. Para comparar compromisos actuales con el presupuesto corriente, separadamente sumamos las cantidades de compromiso y las cantidades de presupuesto desde principio de hora de la fecha actual (o cualquier fecha de inters). Entonces combinamos los dos sets de respuesta en los encabezados de la fila. sta es una aplicacin que se taladra a travs estndar usando lenguaje normalizado de consulta del multipaso. De modo semejante, podramos entrenarnos a travs de los compromisos y los pagos. Si se interes en usted leer ms acerca de construir y acostumbrar la cadena de presupuestacin, nosotros recomendamos que los Datos Almacenen Soluciones Lquidas del Diseo (Wiley 1998) por Chris Adamson y Mike Venerable.
Las Tablas Consolidadas de Hecho En la ltima seccin discutimos a los usuarios comparando mtrica generada por los procesos de negocio de sepa-rate entrenndose a travs de Tablas de hecho, como el presupuesto y com-mitments. Si este tipo de anlisis que se taladra a travs es sumamente comn en la comunidad del usuario, probablemente tiene sentido para crear una sola mesa de hecho que combina la mtrica una vez que en vez de confiar en usuarios o sus aplicaciones ponentes para coser sets de resultado, especialmente dado los asuntos inherentes de capacidades de complejidad, de exactitud, de la herramienta, y funcin. Se interes en ms los tpicamente, los gerentes comerciales comparacin real para estar en cierne tienen discordias. En este punto presumimos eso nuestros presupuestos anuales y / o los moldes delanteros han estado quebrados abajo por el ejercicio fiscal. En Figura 7.4 vemos las cantidades reales y de presupuesto, as como tambin la discordia (cul es un dif-ference calculado) por las dimensiones comunes. Como intercambiamos opiniones ms temprano, efectuamos la entrega lo para fechar campos apalancando los atributos de movimiento hacia arriba en la dimensin de ejercicio fiscal. Otra vez, si trabajamos para una organizacin multinacional, probablemente veramos las cantidades reales en la moneda circulante locales y equivalente y estndar, basadas sobre la efectiva tasa de conversin. Adems, podemos convertir los resultados reales basados en el factor planificado (como descritos durante el proceso de presupuesto) de conversin de moneda. Dado la naturaleza imprevisible de fluctuaciones de moneda circulante, es til monitorear funcin bas sobre ambos las tasas efectivas y planificadas de versin de contra. De esta manera, los gerentes remotos no son sancionados pues el tipo de cambio de una divisa cambia fuera de su control. Asimismo, lo bet-ter del departamento financiero comprende el impacto del cuadro grande de fluctuaciones inesperadas de conversin de moneda sobre el plan anual de la organizacin. Como introdujimos en Captulo 3, nos referimos a las Tablas de hecho que combinan mtrica en una granularidad comn como las Tablas consolidadas o que se secundan a ras (o los centros de compras consolidados de datos) de hecho. Mientras las Tablas consolidadas de hecho pueden ser muy tiles en trminos de la
funcin y usabilidad, a menudo representan un acuerdo intermedio de dimensionalidad porque consolidan hechos en el mnimo comn denominador establecido de dimen-sions. Un potencial que el riesgo se asoci con consolid Tablas de hecho son que los equipos de proj-ect algunas veces basan sus diseos solamente sobre la granularidad de la mesa consolidada de hecho al fracasar en responsabilizarse por requisitos del usuario que exigen que la habilidad bucee en datos ms granulares. Estos dibujos tcnicos tambin se topan con problemas de seri-ous si proyectan intento de equipos para forzarle una correspondencia uno a uno para consolidar informacin con dimensionalidad o granularidad diferente.
La Dimensin de Ejercicio Fiscal Los atributos de Ejercicio Fiscal de la Llave de ejercicio fiscal (PK) G/L Dimensin Account G/L Llave Account (PK) G/L Atributos Account El Hecho de Varianza Presupuestaria El ejercicio fiscal la Llave de la Llave G/L Account (FK) (FK) La varianza presupuestaria de Ejercicio Fiscal de Cantidad de Presupuesto de Ejercicio Fiscal de Cantidad de Ejercicio Fiscal de la Llave G/L Organization Actual (FK)
G/L Dimensin Organization G/L Llave Organization (PK) G/L Atributos Organization
Resuelvo 7.4 que Actual versus el presupuesto consolid mesa de hecho.
Cuando los hechos de procesos comerciales mltiples estn combinados en una mesa consolidada de hecho, deben vivir en el mismo nivel de granularidad y la dimensionalidad. ptimamente, los hechos separados naturalmente viven en un grano comn. De otra manera, nos vemos forzados a eliminar o agregar algunas dimensiones para soportar la correspondencia uno a uno o guardarlas en Tablas separadas de hecho. Los equipos de proyecto no deberan crear hechos artificiales o dimen-sions en un intento para obtener a la fuerza ataque la consolidacin de datos de hecho diferentemente granulados.
El papel de Soluciones OLAP y Analytic Empacado Mientras hemos estado discutiendo almacenes financieros de datos en el contexto de bases de datos relacional, es digno de reparar en que los vendedores multidimensionales OLAP por mucho tiempo han desempeado un papel en esta arena. Los productos OLAP han sido exten-sively usado para declaracin de datos financieros, refrenando los gastos, y las aplicaciones de consolidacin. A menudo vemos alimentacin dimensional de modelos de relaciones cubos financieros de datos OLAP. Los cubos OLAP estn precalculados, lo cual da como resultado funcin acelerada de averiguacin que es crtica para el uso ejecutivo. Los volmenes de datos, especialmente para el bal-ances G/L o el estado financiero agregan, tpicamente no abrume las restricciones prcticas de tamao de un producto multidimensional. OLAP est bien agradado maniobrar complic organizativo movimiento hacia arriba, as como tambin calcula-tions complicado, incluyendo manipulaciones de la interfila. Ven-dors OLAP ms multidimensional proveen capacidades especficas en la finanzas, como funciones financieras (por ejemplo, el valor presente neto o el crecimiento compuesto), el manejo apropiado de datos del estado financiero (en la orden secuencial esperada, como el ingreso antes de los gastos), y el tratamiento correcto de adeudos y los crditos a merced de la
cuenta escriben, as como tambin las funciones ms adelantadas como la consolidacin financiera.
Dado la naturaleza estndar de G/L yendo en procesin, comprando un paquete G/L en vez de tratar de fortalecer a una de la nada ha sido una ruta popular por aos. Casi todos los proveedores operacionales del paquete tambin ofrecen una solucin analtica complemen tary, algunas veces en asociacin con uno de los vendedores de multidimen-sional OLAP. En muchos casos que estos enlataron analiza basado sobre la experiencia acumulativa del vendedor es una forma cuerda para poner en marcha una implementacin financiera del almacn de datos con costo potencialmente reducido y el riesgo. Las soluciones analticas a menudo tienen herramientas para ayudar con la extraccin y escenificando de datos financieros operacionales, as como tambin las herramientas para ayudar con anlisis e interpre-tation. Sin embargo, como intercambiamos opiniones en Captulo 6, al apalancar empaquet soluciones lquidas, necesitamos ser cautelosos acerca de aplicaciones de la tobera que evita. Uno fcilmente podra encontrarse en una situacin con separata financiera, gestor de relaciones con el cliente, recursos humanos, y la tasa de proteccin efectiva empaquet soluciones lquidas analticas de tantos ven-dors diferente, ninguno del cual se integra con otros datos internos. Necesitamos conformar dimensiones a travs del ambiente entero del almacn de datos sin tener en cuenta ya sea estamos construyendo nuestra solucin o implementando nuestros paquetes. Las soluciones lquidas analticas envejecidas en paquete turbocharge sus datos pueden almacenar implementa-tion; Sin embargo, no alivian la necesidad para la conformidad. La mayora de organismos inevitablemente confiarn en una combinacin de construir, comprando, e integrarse para una solucin completa.
Resumen En este captulo que canalizamos primordialmente a los datos financieros G/L en trminos de ambas fotos peridicas y transacciones del asiento de diario. Discutimos el manejo de retos comunes de datos G/L, monedas circulantes mltiples inclusivas, mltiplo los aos fiscales, los rboles organizativos desequilibrados, y el deseo para crear para fechar totales. Exploramos la serie de acontecimientos en una cadena de proceso de
presupuestacin. Describimos el uso de granularidad de cambio neto en esta situacin en vez de crear disparos concisos de los totales de datos de presupuesto. Tambin discutimos el concepto de hecho consolidado las Tablas que combinan los resultados de separe que el negocio procesa cuando son analizados juntos frecuentemente. Finalmente, discutimos el ataque natural de productos multidimensionales OLAP para el anlisis financiero. Tambin enfatizamos la importancia de integrar paquetes analticos en el almacn global de datos a travs del uso de dimensiones conformadas.
EL CARBONO HAPTE R
Administracin De Recursos Humanos
Su captulo, que enfoca la atencin en datos humanos de recursos (HR), es lo ltimo en la serie que trata de aplicaciones de negocio de la industria cruzada. Similar para la contabilidad y datos de finanzas descritos en Captulo 7, la informacin HR es dis-seminated ampliamente a todo lo largo de la organizacin. A diferencia de las finanzas, sin embargo, tpicamente no encontramos a un grupo directivo de analistas de tech-savvy HR en muchas organizaciones. La mayor parte de nosotros operamos en un rpidamente cambiante, competitivo ambiente de negocio. Necesitamos mejor comprender las caractersticas demogrficas de nuestros empleados, nuestras habilidades, ganancias, y funcin para maximizar su impacto. En este captulo exploraremos varias tcnicas dimensionales de modelado en el contexto de datos HR.
la dimensin pospone para rastrear hechos de transaccin del empleado
la dimensin de auditora el arbotante colocado en habilidad de dimensin de palabra clave el manejo de datos del cuestionario de encuesta
187
El rastreo de sello de tiempo de Transaccin en una Dimensin As de lejos los modelos dimensionales que hemos diseado de cerca se parecen en lo referente a que el hecho que las Tablas tienen, contuvo mtrica crucial de funcin que tpicamente puede agregarse a travs de todas las dimensiones. Es fcil que modeladores dimensionales queden calmados en un tipo de complacencia aditiva. En la mayora de los casos, esto es exactamente cmo se supone que surte efecto. Sin embargo, con datos del empleado HR, muchos de los hechos no son aditivos. La mayor parte de los hechos no son nmeros pares, pero cambian todo el tiempo. Tramar el problema con una vieta comercial, nos dej suponer que trabajamos en el departamento HR de una empresa grande con ms que 100,000 empleados. Cada empleado tiene un perfil detallado HR con en menos 100 atributos, incluyendo la fecha de grado del salario, de trabajo, sueldo, fechas retrospectivas, resultados retrospectivos, entitle-ment vacacional, organizacin, educacin, direccin, plan de seguros, y muchos otros. En nuestra organizacin hay un caudal de transacciones en contra de esta informacin del empleado. Los empleados estn todo el tiempo siendo contratados, transferidos, y ascendidos, as como tambin ajustando sus reseas de diversos modos. El requisito comercial prioritario ms alto es rastrear y analizar estos acontecimientos de transaccin del empleado exactamente. Esta historia detallada de transaccin es la verdad fundamental de datos HR; Le debera proveer la respuesta a cada averiguacin posible del perfil del empleado. Mientras estas preguntas imprevistas pueden ser com-plex, debemos ser confiados los datos estn disponibles y de espera para ser analizados. Inmediatamente visualizamos un dibujo tcnico tan bosquejado en Figura 8.1 donde cada acontecimiento de transaccin del empleado es captado en una mesa veteada en transaccin de hecho. La granularidad de esta mesa de hecho sera una fila por la transaccin del empleado. Desde ninguna mtrica numrica es asociado con la transaccin, la mesa de hecho es factless. Las medidas se asociaron con transacciones del empleado son los cambios hechos para el perfil del empleado, como una direccin nueva o promocin de grado de trabajo.
La Dimensin del Empleado El empleado los Atributos del Empleado de la Llave Employee Idaho (la Llave Natural) (PK)
Cada cambio para la dimensin del empleado manipul como un tipo SCD 2 La Mesa de Hecho de Transaccin del Empleado La llave del Empleado de la Llave de Tiempo de Transaccin de la Llave de fecha de transaccin (FK) (FK) (FK) La llave de Tipo de Transaccin del empleado (FK)
Grano: Una fila por la transaccin del empleado La Dimensin de Fecha de Transaccin La Dimensin De Tiempo de Transaccin La Dimensin de Tipo de Transaccin del Empleado La descripcin de Tipo de Transaccin del Empleado de la Llave de Tipo de Transaccin del empleado (PK)
Creo que 8.1 la Inicial redactan para transacciones rastreadoras de cambio del empleado.
En este dibujo tcnico en borrador inicial, las dimensiones incluyen la fecha de transaccin y el tiempo, el tipo de transaccin, y empleado. La fecha de transaccin y dimen-sions de tiempo se refieren al tiempo y fecha exacta de la transaccin del empleado. Suponemos que estas fechas y estas veces son lo suficientemente de grano fino que garantizan unicidad de la fila de transaccin para un empleado dado. La dimensin de tipo de transaccin se refiere a la variedad de transaccin que caus la creacin de esta fila particular, como una promocin o un cambio de la direccin. El dimen-sion del empleado es sumamente ancho con muchas columnas de atributo. El identificador del empleado usado en el sistema de produccin HR como un constante identificador para el empleado es incluido en esta mesa de dimensin como un atributo. Visualizamos usar el tipo 2 lentamente cambiando tcnica de dimensin pues track-ing cambi de perfil atribuye en la dimensin del empleado. Consecuentemente, con cada transaccin del empleado en el hecho posponga en Figura 8.1, tambin creamos un tipo nuevo 2 fila en la dimensin del empleado que representa el perfil del empleado como resultado del acontecimiento de transaccin. Contina exactamente describiendo al empleado hasta que la siguiente transaccin del empleado ocurre en algn tiempo indetermi nate en el futuro. El lector alerta se da prisa para sealar que hemos diseado una mesa de hecho de transaccin del empleado y un tipo 2 mesa de dimen-sion del empleado con el nmero mismo exacto de filas, cules estn casi siempre unidos el uno para el otro. En este punto las alarmas dimensionales de modelado deberan estar apagndose. Ciertamente no queremos tener tantas filas en una mesa de hecho como hacemos en una mesa relacionada de dimensin. En lugar de usar el dibujo tcnico inicial, podemos simplificar el diseo embelleciendo la mesa de dimensin del empleado para hacerlo ms energtico y por consiguiente deshacindose de la mesa de hecho de acontecimiento de transaccin. Como bosquejada en Figura 8.2, la dimensin de transaccin del empleado contiene una foto del perfil del empleado siguiendo cada transaccin individual del empleado. Incluimos la descripcin de tipo de transaccin en la dimensin del empleado a rastrear la razn para el cambio del perfil. No hay numrico mtrico asociado con una transaccin del perfil; La transaccin meramente da como resultado un set nuevo de caractersticas del perfil del empleado. En algunos casos, las caractersticas fingidas son numricas. Si los
atributos numricos estn resumidos simplemente constreido en, corresponden a una mesa de hecho en lugar de eso. Como usted esperara, la llave vicaria de transaccin del empleado es la llave primaria de la mesa de dimensin, aunque la llave natural es la empleada constante Idaho. Resistimos el deseo a confiar en una clave lista consistente en el empleado Idaho, cdigo de transaccin, y fecha de transaccin. Todos estos los atributos son de valor, pero son simplemente columnas en la transaccin del empleado fila que participan de averiguaciones y las restricciones les gustan todas las otras columnas de atributo.
La Dimensin de Transaccin del Empleado La transaccin del empleado el Nombre del Empleado de la Llave Employee Idaho (la Llave Natural) (PK) La Direccin del Empleado Job Califique Educacin Salarial El aforamiento original de Fecha de Revisin de la Horma de Fecha del Salario (FK) (FK) Evaluando Plan de Vacacin de Plan de Seguro Mdico La Descripcin de Tipo de Transaccin del Empleado La Fecha De Transaccin del Empleado El Tiempo de Transaccin del Empleado La Mayora de Hora de Expiracin de Transaccin del Empleado de Fecha de Caducidad de Transaccin del Empleado Indicador Reciente de Transaccin
Indica la transaccin tan causada otra fila del Empleado para ser creada
Figura 8.2 la dimensin de transaccin del Empleado.
Un componente crucial de este diseo es la segunda fecha y la entrada de tiempo, la fecha de caducidad de transaccin. Esta fecha /tiempo representa la fecha /tiempo de la siguiente transaccin para ocurrir para este empleado, cada vez que eso puede ser. De este modo estos dos la fecha /veces en cada fila define un intervalo durante el cual el empleado de perfil es preciso. La dos fecha /veces puede ser un segundo aparte (si una secuencia rpida de transacciones est siendo tramitada en contra de un perfil del empleado) o muchos meses aparte. La fecha de caducidad de transaccin en el empleado ms actual de perfil debe ser colocada para un tiempo arbitrario en el futuro. Aunque parecera ms elegante establecer la fecha de caducidad para esta fila para nula, este probablemente los hara a la averiguacin y aplicaciones ponentes ms complejo porque podran tener que experimentar separadamente para el valor nulo. El indicador ms reciente de transaccin identifica la ltima transaccin hecha en contra de un perfil del empleado. Esta columna deja el estatus ms reciente o final de cualquier empleado ser recuperada rpidamente. Si una transaccin nueva del perfil ocurre para este empleado, el indicador en la anterior fila del perfil necesita estar actualizado para sealar que es ya no la ltima transaccin. Aun en una organizacin abrumadora, este acercamiento no requiere almacenamiento significativo. Supongo que tenemos a 100,000 empleados y realizamos un promedio de 10 transacciones del perfil HR en cada empleado cada ao. Aun si tenemos un modo de palabra completa La fila de transaccin de 2,000 bytes, 5 aos de datos del perfil slo asciende a 10 el gygabyte (x de 5 aos 100,000 la x de empleados 2,000 la x de bytes 10 transacciones al ao) de datos sin procesar en la dimensin de transaccin del empleado.
En el suyo, este tipo de sello de tiempo 2 la dimensin de transaccin del empleado puede contestar un nmero de interesarle averiguaciones HR. Obviamente podemos usar esta mesa para considerar en detalle la secuencia de transacciones en contra de cualquier empleado dado. Fcilmente podemos perfilar al empleado demogrfico a cualquier instante preciso con el tiempo. Podemos escoger una fecha exacta en cualquier punto histrico en el tiempo y podemos preguntar cuntos empleados nosotros tenemos y a lo que sus reseas detalladas fueron en esa fecha por la contra esforzndose la fecha y hora de ser iguales o ms gran que la fecha de transaccin y menos de la fecha de caducidad de transaccin. La averiguacin puede realizar cuentas y restricciones en contra de todas las filas devueltas de estas restricciones de fecha. Dado que las filas de dimensin son fotos en su derecho, evitamos examinar cuidadosamente un set complicado de transacciones en secuencia para construir una foto por una fecha particular en el pasado.
Sumando efectiva y fecha de caducidad que los timbres, junto con un descrip-tion de transaccin, en cada fila pueden embellecer el diseo de un tipo 2 lentamente cambiando dimensin para permitir divisin del tiempo muy precisa de la dimensin por s mismo.
Antes de entrar precipitadamente en este diseo para una aplicacin HR, necesitamos ser think-ful acerca de la dimensin de transaccin. El sistema subyacente de la fuente HR puede tener una nocin muy complicada de una transaccin que no es en realidad lo que queremos en el almacn de datos. Por ejemplo, una promocin de empleado puede ser imple-mented en el sistema de la fuente por muchos microtransactions correspondiente a cada cambio en un campo individual en el registro del empleado. No queremos ver este detalle en el almacn de datos. Ms bien, queremos narrar de forma resumida toda la serie de microtransactions del sistema subyacente de la fuente y tratarlos como una transaccin sper llam promocin de empleado. El registro nuevo en nuestro tipo 2 el empleado que la dimensin refleja todos los campos cambiados pertinentes en un paso. Iden-tifying estas supertransacciones puede tener su truco. Quiz la mejor forma para identificarlos es asegurarse de que hay un campo en el HR aplicacin operacional que capta la accin de alto nivel.
La Dimensin de Sello De Tiempo con Los Hechos Peridicos de la Foto Alguno de ustedes puede preguntarse si la mesa de dimensin de transaccin del empleado no es en realidad un tipo de mesa de hecho porque es de sello de tiempo. Mientras tcnicamente esto puede ser cierto, esta mesa de transaccin del empleado principalmente contiene val-ues textual; Es la fuente primaria de restricciones de averiguacin e informe etiqueta. As es correcto pensar acerca de esta mesa como una mesa de dimensin que sirve del punto de entrada en el hecho HR pospone. La mesa de transaccin del empleado puede ser usada con cualquier mesa de hecho que requiere una dimensin del empleado con tal de que la llave de surro-gate del empleado est extendida para ser la transaccin del empleado llave vicaria.
Adems de perfilar al empleado bajo en HR, tambin necesitamos reportar los estatus de sum-mary del empleado basan sobre una base normal, mensual. Somos interesados en cuentas, estadsticas, y totales, incluyendo cosas as como nmero de empleados, totalizan sueldo pagados durante el mes, los das vacacionales tomados, los das vacacionales acumulado, el nmero de salarios nuevos, y el nmero de promociones. Queremos analizar los datos por todas las rebanadas posibles, organizacin y tiempo inclusivo. Necesitamos acceder a los totales al final de cada mes, an cuando no hay actividad de transAc-tion en el perfil de un empleado dado durante ese mes. Como se muestra en Figura 8.3, el HR foto peridica consiste de una mesa de hecho de miramiento medianamente comn con tres dimensiones: Mes, transaccin del empleado, y organizacin. La mesa de dimensin de mes contiene los descriptores usuales para el calendario corporativo en el grano de mes. La llave de transaccin del empleado en un hecho que la fila de la mesa sea la llave de transaccin del empleado que fue efectivo en el ltimo da del mes dado de informacin. Esto garantiza que el informe de fin de mes es un esbozo correcto de todo lo que el empleado perfila. La dimensin de organizacin contiene una descripcin de la organizacin para la cual el empleado tiene un sitio en el final del mes pertinente. Los hechos en esta foto HR consisten resmenes mensualmente numricos que son difciles de hacer clculos de las transacciones subyacentes. Estos cuentas mensuales y totales cancelan la masa de averiguaciones de la gerencia estimando estadsticas mensuales del empleado. Todo lo que los hechos son aditivos a travs de todo lo que las dimensiones o la dimensin atribuyen, excepto por los hechos etiquetados como se balancea. Estos balances, como todos los balances, son semiaditivos y deben ser promediados a travs de la dimensin de tiempo despus de sumar a travs de las otras dimensiones.
La Dimensin de Transaccin del Empleado La transaccin del empleado los Atributos del Empleado de la Llave Employee Idaho (la Llave Natural) (PK) La Descripcin de Tipo de Transaccin del Empleado La Fecha De Transaccin del Empleado El Tiempo de Transaccin del Empleado La Mayora de Hora de Expiracin de Transaccin del Empleado de Fecha de Caducidad de Transaccin del Empleado Indicador Reciente de Transaccin Los Recursos Humanos Le Toman Instantneas al Hecho La llave de mes (FK) La llave de Organizacin de la Llave de Transaccin del empleado (FK) (FK) El Sueldo Pag Tiempo Extra el Fondo de Retiro Pagado de Horas de Tiempo Extra Pagado La Contribucin del Empleado de Fondo de Retiro Tome Vacaciones Que los Das Acopiaron los Das Vacacionales el Da Vacacional Ocupado la Cuenta del Empleado de Balance La Cuenta Nueva de Promocin de la Cuenta de Traslado de la Cuenta del Salario La Dimensin de Mes Los atributos de Mes de la Llave de mes (PK) La Dimensin de Organizacin Los atributos de Organizacin de la Llave de organizacin (PK)
La transaccin del empleado y las llaves extranjeras Organization son esas vlidas en el fin de mes Figura 8.3 HR foto peridica con dimensin de transaccin del empleado.
La Dimensin de Auditora
Cada vez que construimos una mesa de hecho conteniendo medidas de nuestro negocio, rodeamos la mesa de hecho de todo sabemos ser verdaderos. Podemos extender esto todo lo que sabemos el acercamiento para nuestras Tablas de hecho por pedazos cruciales inclusivas de metadatos que son sabidos para ser ciertos cuando una fila individual de hecho es creada. Por ejemplo, cuando creamos una mesa de hecho fila, sabemos lo siguiente: lo que el sistema de la fuente suministr los datos de hecho qu la versin del software del extracto cre la fila qu versin de lgica de dotacin, si cualquier, se us para crear la si uno especfico No columna Aplicable de hecho es desconocida, imposible, corrompida, o no disponible an si un hecho especfico estaba alterado despus de la carga inicial y, si es as, si la fila contiene hechos ms que 2, 3, o 4 desviaciones tpicas del trmino medio o, equivalentemente, fuera de los saltos diversos de confianza se deriv de algn otro anlisis estadstico
Los primeros tres detalles describen el linaje de la fila de la mesa de hecho; En otras palabras, de dnde vinieron los datos? Los ltimos tres detalles describen nuestra confianza en calidad de datos para esa fila de la mesa de hecho. Como ilustrada en Figura 8.4, la forma ms eficiente para aadirle esta informacin a un hecho mesa debe crear una sola auditora llave extranjera en la mesa de hecho. La belleza de este diseo es que el linaje de escenificacin de datos y metadatos de confianza ahora se han convertido en datos normales, lo cual puede ser puesto en duda y analizado junto con las otras dimensiones ms familiares. Los indicativos en la dimensin de auditora consisten de textual descifra. Vamos a constreir y escribir una crnica de estos atributos diversos de auditora, as es que queremos que ellos aparezcan como texto comprensible. Quiz el atributo del software del extracto podra contener el valor la versin del extracto del Empleado 5 usando liberacin ETL vendorABC 6.4. El atributo alterado de estatus podra
contener valores tan No alterados o Altered debido a la reafirmacin. En nuestro proceso de carga de transformacin de extracto de escenificacin (ETL), rastreamos estos indicadores y los hacemos alistar cuando la fila de la mesa de hecho es ensamblada en su estado de cierre. Si cargamos un gran nmero de filas cada da, casi todas las filas tendrn la misma auditora llave extranjera porque probablemente casi todas las filas sern normales.
La Dimensin de Transaccin del Empleado La transaccin del Empleado de la Llave de Transaccin del empleado (PK) Atribuye Atributos del Empleado La Dimensin de Auditora La llave de auditora (PK) El Estatus del Extracto de Tiempo de Terminacin del Extracto de Fecha de Terminacin del Extracto El Nmero de Terminacin de Transformacin de Fecha de Terminacin de Transformacin de Registros Extracted Cronometra Estatus de Transformacin El Nmero de Registro Transformed Numera de Transform la Fecha de Terminacin de Carga de Registros Rejected El Tiempo de Terminacin de Carga El Estatus de Carga El Nmero de Registro Loaded El Nmero de Carga Registran A Rejected Los Recursos Humanos Le Toman Instantneas al Hecho La llave de mes (FK) La llave de Organizacin de la Llave de Transaccin del empleado (FK) (FK) El tiempo extra de Sueldo de la Llave de auditora Paid (FK) Mereci la Pena las Horas de Tiempo Extra El Fondo De Retiro Pagado La Contribucin del Empleado de Fondo de Retiro Tome Vacaciones Que los Das Acopiaron los Das Vacacionales el Da Vacacional Ocupado la Cuenta del Empleado de Balance La Cuenta Nueva de Promocin de la Cuenta de Traslado de la Cuenta del Salario La Dimensin de Mes Los atributos de Mes de la Llave de mes (PK) La Dimensin de Organizacin Los atributos de Organizacin de la Llave de organizacin (PK)
Figura 8.4 HR foto peridica con dimensin de auditora.
La Dimensin del Arbotante de Palabra Clave Supongamos que el DEPARTAMENTO DE INFORMTICA quiere suplementar la dimensin del empleado con informacin colocada en habilidad tcnica descriptiva. El departamento quiere poder determinar cualquiera de las habilidades tcnicas cruciales en las cuales un empleado es diestro. Es altamente probable que muchos empleados de tecnologa de la informacin tengan exper-tise en una variedad ancha de habilidades. Podemos considerar que estas habilidades tcnicas son palabras claves que describen a nuestros empleados. Habr un nmero de palabras claves diferentes, pero habr pronosticabilidad o estructura para ellas. Algunas palabras claves describirn lenguajes de programacin (por ejemplo, Cobol, carbono +, y pascal), mientras que los otros describirn sistemas operativos (por ejemplo, Unix, Ventanas, y Linux) o plataformas de la base de datos. Queremos buscar el empleado de tecnologa de la informacin poblacin por estas palabras claves descriptivas, cul etiquetaremos como las habilidades en nuestro diseo. Desde que cada empleado tendr un nmero variable, imprevisible de habilidades, la dimensin de habilidades es una candidata primera para ser una dimensin multipreciada. Las palabras claves, por su naturaleza, usualmente estn indefinidas. Las palabras claves nuevas son creadas regularmente y se suman a la base de datos. Mostraremos dos que modelado lgicamente equivalente urde para manipular sets indefinidos de palabras claves al al mismo tiempo mantenerse ambos poniendo en duda y la gerencia simple. Resuelva 8.5 funciones un diseo multipreciado de dimensin para manejar las palabras claves de habilidades como uno
El Hecho Humano de Recursos La llave del empleado (FK) Ms Foreign Teclea Hechos Humanos de Recursos La Dimensin del Empleado El empleado de la Llave del empleado (PK) Atribuye Clave del Grupo de Habilidad del Empleado (FK)
El Arbotante del Grupo de Habilidad del Empleado La categora de Habilidad del Empleado de Descripcin de Habilidad del Empleado de la Llave de Habilidad del Empleado de la Llave del Grupo de Habilidad del empleado (PK) (PK)
Creo que 8.5 Habilidades agrupen arbotante de dimensin de palabra clave.
El arbotante para la mesa de dimensin del empleado. Como veremos en Captulo 13 cuando ms all explicamos en detalle atributos multipreciados de dimensin, algunas veces la dimensin de mul-tivalued est unida directamente para una mesa de hecho. Las habilidades se agrupan identifica un set dado de palabras claves de habilidades. Todos los empleados de tecnologa de la informacin que es diestro en Orculo, Unix, y el lenguaje normalizado de consulta sera asignado que las mismas habilidades agrupan llave. En el arbotante del grupo de habilidades, estaran tres filas para este grupo de par-ticular, uno para cada uno de las habilidades asociadas (el Orculo, Unix, y lenguaje normalizado de consulta) de palabra clave. En este caso, simplemente dos atributos son asociados con cada habilidad, descripcin y categora, as es que incluimos estos atributos en el arbotante directamente.
/ la investigacin de operaciones de operador booleano AND Dilemma Suponiendo que hemos construido el dibujo tcnico como se muestra en Figura 8.5, quedamos todava con un problema serio de averiguacin. Las peticiones de averiguacin en contra de las palabras claves establecidas en habilidad tcnicas probablemente se subdividirn en dos categoras. El Oregon pone en duda (por ejemplo, la experiencia Unix Oregon Linux) puede quedar satisfecho por una restriccin simple de Oregon en la columna de descripcin de habilidades en el arbotante. Sin embargo, el operador booleano AND pone en duda (para exam-ple, la experiencia de operador booleano AND Unix Linux) es difcil porque la restriccin de operador booleano AND es una restriccin a travs de dos filas en el arbotante de habilidades. El lenguaje normalizado de consulta es notablemente flojo en manejar restricciones a travs de filas. La respuesta es crear cdigo de lenguaje normalizado de consulta usando uniones e intersecciones, probablemente en una interfaz aduanera que esconde el com-plex lgico del usuario comercial. El cdigo de lenguaje normalizado de consulta se parecera a esto: (ESCOJA A EMPLOYEE_ID, EMPLOYEE_NAME entre EMPLEADO,
HABILIDADES DONDE la HABILIDAD de operador booleano AND EMPLOYEE.SKILLSGROUP SKILLS.SKILLSGROUP UNIX ) la unin /interseccin (ESCOJA A EMPLOYEE_ID, EMPLOYEE_NAME entre EMPLEADO, HABILIDADES DONDE la HABILIDAD de operador booleano AND EMPLOYEE.SKILLSGROUP SKILLS.SKILLSGROUP LINUX )
Utilizando los empleados SINDICALES de listas con experiencia Unix Oregon Linux, considerando INTERSECCIN utilizadora identifican empleados con experiencia de operador booleano AND Unix Linux.
Yendo En Busca De Subcadenas Podemos quitar lo muchos para muchos la juntura y la necesidad para el lenguaje normalizado de consulta de unin /interseccin cambiando el diseo para una forma ms simple, como se muestra en Figura 8.6. Ahora cada fila en el arbotante de la lista de habilidades contiene una larga cuerda del texto con todo lo que las palabras claves de habilidades para esa lista afina. Usamos un delimitador especial como una barra inversa al principio de la columna de la lista de habilidades y despus de cada habilidad en la lista. As las habilidades listan cuerda conteniendo a Unix y el carbono + se parecera a \Unix\C + +\. Suponemos ese un nmero de parte de empleados una lista comn de habilidades. Si las listas no estn reutilizadas frecuentemente, podramos sufrir un colapso las habilidades listan arbotante en la dimensin del empleado meramente incluyendo la cuerda de la lista de habilidades como acabamos de describir directamente en la dimensin del empleado. Las bsquedas de la cuerda pueden ser desafiantes por la ambigedad causadas por search-ing en superior o la letra minscula. Es eso UNIX o Unix o unix? Podemos resolver esto uno u otro cambiando todas las palabras claves para un caso o usando una funcin especial de bsqueda de la cuerda del texto de la base de datos que es insensible en caso. Con el diseo en Figura 8.6, el dilema de / investigacin de operaciones de operador booleano AND puede ser del que se ocup en una sola declaracin SELECTA. A la apariencia de restriccin de Oregon le gusta esto:
SKILL_LIST COMO ' % %\UNIX\ Oregon SKILL_LIST COMO ' % %\LINUX\ ' Entretanto, la restriccin de operador booleano AND tiene estructura exactamente igual: SKILL_LIST COMO ' % %\UNIX\ ' operador booleano AND SKILL_LIST COMO ' % %\LINUX\ ' El smbolo del % es un carcter de comprobacin de configuraciones del comodn
definido en el lenguaje normalizado de consulta que corresponde al cero o ms personajes. El delimitador de la barra inversa es usado explcitamente en las restricciones para exactamente corresponder a las palabras claves deseadas y no obtener fsforos errneos. El acercamiento de la lista de palabra clave mostrado en Figura 8.6 surtir efecto en cualquier base de datos relacional porque se basa en estndar lenguaje normalizado de consulta. Sin embargo, las bsquedas principales del comodn son notorias para ser lentas cuando la mesa de dimensin de palabra clave se agranda. Si la funcin se vuelve objetable, usted puede perseguir dos acercamientos si su base de datos da rienda suelta a que. Primero, usted puede prender con alfileres el arbotante de la lista de palabra clave en mem-ory tan tan si bien la restriccin puede conjurar una bsqueda exhaustiva de la dimensin, puede estar bastante acelerada. En segundo lugar, usted puede construir un ndice especial del patrn en la columna de la lista de palabra clave que le provee una bsqueda del ndice a cada subcadena de conceiv-able, con tal que su base de datos pueda soportar este tipo de ndice.
El Hecho Humano de Recursos La llave del empleado (FK) Ms Foreign Teclea Hechos Humanos de Recursos La Dimensin del Empleado El empleado de la Llave del empleado (PK) Atribuye Clave del Grupo de Habilidad del Empleado (FK)
El Arbotante del Grupo de Habilidad del Empleado La lista de Habilidad del Empleado de la Llave de la Lista de Habilidad del empleado (PK)
Creo que 8.6 que las habilidades Delimitadas listan dimensionen arbotante.
Los Datos del Cuestionario de Encuesta El departamento HR a menudo recoge datos de encuesta en la base entera del empleado, especialmente al recoger mirada fija y / o datos retrospectivos administrativos. Lo depart-ment quiere analizar estas respuestas del cuestionario para determinar la valuacin promedia para un empleado revisado y la valuacin promedia dentro de un departamento. Para analizar datos del cuestionario, creamos una mesa de hecho con una fila para cada pregunta en la encuesta de un demandado, tan ilustrados en Figura 8.7. Habra dos caracterizacin de papeles que la empleada dimensiona en el dibujo tcnico correspondiente al empleado que responde y el empleado revisado. El dimen-sion de encuesta consiste en descriptores acerca del instrumento de encuesta. El dimen-sion de pregunta proveera la pregunta y su categorizacin. Probablemente, la misma pregunta es preguntada sobre las encuestas de mltiplo. Las dimensiones de encuesta y de pregunta pueden ser agarraderas tiles para ir en busca de temas especficos en una ancha base de datos de cuestionarios. La dimensin de respuesta contiene las respuestas y quiz las categoras de respuestas, tan favorable u hostil.
La Encuesta Envi la Fecha la Encuesta de Dimensin la Dimensin Admitida por la Mayora de Fecha Respondiendo Empleado la Dimensin la Dimensin del Empleado Revisado Cuestione Dimensin La pregunta la Categora de la Llave Question Label Question (PK) El Hecho de Encuesta de Evaluacin del Empleado La encuesta de la Llave de Fecha de encuesta Sent (FK) Recibi Llave de Encuesta de la Llave de Fecha (FK) (FK) Responder Llave del Empleado (FK) Revis Llave de Pregunta de la Llave del Empleado (FK) (FK) La respuesta de Nmero de Encuesta de la Llave de Categora de respuesta (DD) (FK) Examine Dimensin El ao de Revisin de Objetivo de Encuesta de Tipo de Encuesta del Ttulo de Encuesta de la Llave de encuesta (PK) La Dimensin de Categora de Respuesta La descripcin de Categora de Respuesta de la Llave de Categora de respuesta (PK)
Figura 8.7 el dibujo tcnico de encuesta HR.
Creando el dibujo tcnico simple en Figura 8.7 soportes la caladura robusta y jugando a los dados de datos de encuesta. Las variaciones de este diseo del dibujo tcnico seran muy apropiadas para analizar todos los tipos de datos de encuesta, incluir satisfaccin del cliente y pienso de uso del producto de regreso.
Resumen En este captulo discutimos varios conceptos en el contexto de datos HR. Primero, ms all explicamos en detalle las ventajas de embellecer una mesa de dimensin a fin de que no slo capte todos los atributos pertinentes pero tambin rastree transacciones que causan de perfil cambios. En el mundo de HR, esta sola mesa se usar para poner la direccin en un nmero de preguntas estimando el estatus y perfilar del empleado bajo en cualquier punto con el tiempo. Describimos el uso de un dimen-sion de auditora para rastrear linaje de datos y metadatos de calidad dentro de una mesa de hecho HR. Esta tcnica obviamente es ampliamente aplicable ms all de la arena HR. Nosotros intro-duced el uso de grupo de palabra clave o la lista delimitada dimensionamos arbotantes para anlisis portuario en sorbo sobre los atributos multipreciados. Finalmente, provemos una visin general breve suponiendo el anlisis de datos coleccionadas de encuestas o cuestionarios.
Servicios Financieros EL CARBONO HAPTE R
l la industria financiera de servicios abarca una variedad ancha de negocios, incluyendo compaas de la tarjeta de crdito, las empresas de corretaje, y los proveedores hipotecarios. Este captulo enfocar primordialmente la atencin en bancos minoristas dado que la mayora de lectores tienen algn grado de familiaridad personal con este tipo de instituto financiero. Un banco de servicios completos ofrece una anchura de productos, incluyendo revisando cuentas, las cuentas de ahorros, los prstamos hipotecarios, los prstamos personales, las tarjetas de crdito, y las cajas de seguridad. Este captulo comienza con un dibujo tcnico muy simplista. Entonces exploramos varias extensiones del dibujo tcnico, incluyendo manejo del portafolio ancho del banco de productos heterogneos que difieren significativamente por la clase de negocio. Como nos embarcamos en una serie de captulos enfocados en industria, queremos recordarle que no estn dirigidos a proveer soluciones de la industria en gran escala. Mientras las tcnicas dimensionales diversas de modelado se discutirn en el contexto de una industria dada, las tcnicas ciertamente son aplicables para otros negocios. Si usted no trabaja en los servicios financieros, usted todava necesita leer este captulo. Si usted trabaja en los servicios financieros, recuerde que los dibujos tcnicos en este captulo no deberan ser mirados como completos.
el triage de dimensin a evitar las demasiado pocas dimensiones la trampa las dimensiones de toda la casa asociar a clientes individuales con lleva las cuentas usando un cuadro puente Las minidimensiones mltiples en una sola mesa de hecho
199
aprecie agruparse de hechos para reportar propsitos El punto en el tiempo contrarresta usar datos de transaccin los productos heterogneos manipuladores, cada uno con mtrica nica y los atributos de dimensin, a travs de los giros de negocios
Poniendo En El Banco Estudio de Casos La meta inicial del banco es construir la capacidad para mejor analizar las cuentas del banco. Los usuarios quieren que la habilidad corte en rodajas y el individuo de dados lleva las cuentas, as como tambin los agrupamientos de toda la casa residenciales para los cuales pertenecen. Uno de objetivos principales del banco es comercializar ms eficazmente ofrecindole los productos adicionales a los grupos familiares que ya tienen uno o ms cuentas con el banco. Despus de transmitir entrevistas con gerentes y los analistas alrededor del banco, nos desarrollamos el siguiente set de requisitos: 1. Los usuarios comerciales quieren ver 5 aos de datos mensuales histricos de la foto en todos los aspectos. 2. Cada cuenta tiene un saldo primario. El negocio quiere agrupar differ-ent determina el tipo sanguneo de cuentas en lo mismo analiza y compara saldos primarios. 3. Cada tipo de cuenta (conocido como productos dentro del banco) hace un set de costumbre dimensionar atributos y hechos numricos que tienen tendencia a ser muy dif ferent de producto para producto. 4. Se estima que cada cuenta le pertenece a un solo grupo familiar. Hay una cantidad de sur-prise de volatilidad en relaciones de toda la casa en la cuenta debido a cambios en el estado civil y otra vida que la etapa factoriza. 5. Adems de la identificacin de toda la casa, los usuarios estn interesados en informacin grfica en demo como le competa a ambos clientes individuales y grupos familiares. Adems, el banco capta y almacena puntuaciones de comportamiento referente a la actividad o las caractersticas de cada cuenta y el grupo familiar.
El Triage de Dimensin Basados sobre los requisitos comerciales justamente listados, el grano y la dimensionalidad del modelo inicial comienzan a emerger. Comenzamos con una mesa de hecho de fondo que registra los saldos primarios de cada cuenta al final de cada mes. Claramente, el grano de la mesa de hecho es una fila para cada cuenta al final de cada mes. Basados en esta declaracin del grano, inicialmente visualizamos un diseo con slo dos
Dimensiones el mes y la cuenta. Estas dos llaves extranjeras forman la mesa de hecho llave primaria, como se muestra en Figura 9.1. Un diseador cntrico en datos podra discutir tan toda la otra informacin de descripcin, como grupo familiar, la rama, y las caractersticas del producto, deberan estar incrustadas como atributos descriptivos de la dimensin de la cuenta porque cada cuenta tiene slo a un grupo familiar, la rama, y el producto se asoci con ella. Mientras este dibujo tcnico exactamente representa lo muchos para uno y muchos para muchas relaciones en los datos de la foto, adecuadamente no refleja las dimensiones comerciales naturales. En vez de colapsar todo en la enorme mesa de dimensin de la cuenta, las dimensiones analticas adicionales como el producto y la rama reflejan la forma instintiva que los usuarios bancarios piensan acerca de su busi-nesses. Estas dimensiones suplementarias le proveen mucho puntos ms pequeos de entrada a la mesa de hecho. As se ocupan de ambos la funcin y objec-tives de usabilidad de un modelo dimensional. Finalmente, dado que el dimen-sion maestro de la cuenta en un banco grande puede acercarse a 10 millones de miembros, nos preocupamos por tipo 2 lentamente cambiando efectos de dimensin (SCD) creciendo como hongos esta enorme dimensin en algo inexplotable. El producto y atributos de la rama son grupos de conve-nient de atributos para quitar de la dimensin de la cuenta para recortar el tipo 2 efectos SCD. Ms tarde en este captulo apretaremos las caractersticas demogrficas cambiantes y los atributos conductistas fuera de la cuenta dimen sion para las mismas razones. El producto y dimensiones de la rama son dos dimensiones separadas porque hay uno muchos para muchos la relacin entre productos y ramas. Ambos cambian lentamente pero sobre los ritmos diferentes. Los usuarios ms importantes, comerciales piensan acerca de ellos como dimensiones bsicas, bien definidas del negocio bancario. En general, la mayora de modelos dimensionales terminan con entre 5 y 15 o as las dimensiones. Si nos encontramos en o debajo del borde inferior de este alcance, deberamos ser sospechosos que las dimensiones pueden haber sido dejada sin el diseo inadvertidamente. En este caso deberamos considerar que cuidadosamente si cualquiera de las clases de fol-low de dimensiones es suplementos correctos para un dimen-sional en borrador modelo:
La Dimensin de Mes Los atributos de Mes de la Llave de Fecha de Fin de mes (PK) El Hecho Mensual de la Foto de la Cuenta La llave de la Cuenta de la Llave de Fecha de Fin de mes (FK) (FK) El Mes Primario Terminando Balance La Dimensin de la Cuenta el producto de Atributos de la Cuenta de la Llave de la cuenta (PK) Atribuye Atributos de Estatus de Atributos Attributes Branch De Toda la Casa
Creo 9.1 la foto de Balance con tambin pocas dimensiones.
Las dimensiones causales. Estas dimensiones, como la promocin, contraen, distribuyen, almacenan condicin, o aun clima, provee entendimiento profundo adicional en la causa de un acontecimiento. La fecha mltiple o las dimensiones de la estampilla de tiempo. Refirase al Captulo 5 para Tablas de hecho de muestra con fechadores mltiples, especialmente cuando la mesa de hecho es una foto de accu-mulating. Degenere dimensiones. Estas dimensiones identifican que los nmeros operacionales de control de transaccin, como una orden, facturan, conocimiento de embarque, o etiquetan, como illus-trated inicialmente en Captulo 2. Las dimensiones de caracterizaciones de papeles. La caracterizacin de papeles ocurre cuando una sola dimensin fsica aparece varias veces en una mesa de hecho, cada uno representada como una mesa lgica separada con nombres nicos de la columna a travs de los puntos de vista. Las dimensiones de estatus. Estas dimensiones identifican el estatus actual de un transAc-tion o una foto mensual dentro de algn mayor contexto, como un estado de cuenta. La dimensin de auditora. Como discutida en Captulo 8, esta dimensin es diseada para rastrear linaje de datos y calidad. Las dimensiones de trastos viejos. Estos consisten en banderas e indicadores correlacionados, tan descritos en Captulo 5. Estas dimensiones suplementarias tpicamente pueden agregarse graciosamente para un diseo, aun despus de que el almacn de datos haya ahondado en produccin, porque no cambian el grano de la mesa de hecho. La adicin de estas dimensiones usualmente no altera las llaves existentes de dimensin o hechos medidos en la mesa de hecho. Todas las aplicaciones existentes deberan continuar corriendo sin cambio.
Cualquier atributo descriptivo que es de valor solo en presencia de las medidas en el hecho la mesa es una buena candidata para sumarse a una dimensin existente o para ser su dimensin.
Basado sobre ms all estudia de requisitos del banco, finalmente escogemos las
siguientes dimensiones para nuestro dibujo tcnico inicial: La fecha de fin de mes, la cuenta, el agarre de casa, la rama, el producto, y el estatus. Como ilustrado en Figura 9.2, en el intersec-tion de estas seis dimensiones, tomamos una foto mensual y registramos el saldo primario y alguna otra mtrica que hacen sentido a travs de todos los productos, como los intereses pagados, intersele cargado a la cuenta, y la cuenta de transaccin. Recuerde que los saldos de las cuentas estn algo as como balances de inventario en lo referente a que no son aditivos a travs de cualquier medida de tiempo. En lugar de eso, debemos promediar los saldos de las cuentas dividiendo la suma de balance por el nmero de meses.
La Dimensin de Mes Los atributos de Mes de la Llave de Fecha de Fin de mes (PK) Branch Dimension Branch Key (PK) Los Atributos del Rollup de la Rama de Atributos de la Direccin de la Rama Bifurcan Descripcin del Formato La Dimensin del Producto La categora del Producto de Tipo del Producto de Descripcin del Producto de la Llave del producto (PK) La Dimensin del Estado de Cuenta El grupo del Estado de Cuenta de Descripcin del Estado de Cuenta de la Llave del estado de cuenta (PK) El Hecho Mensual de la Foto de la Cuenta La fecha de Fin de mes Llave Branch (FK) Key (FK) La llave del Grupo Familiar de la Llave del Estado de Cuenta de la Llave de la Cuenta de la Llave del producto (FK) (FK) (FK) (FK) El Mes Primario Terminando Balance El Comn Daily Balance Number de Inters de Transacciones Pag El Inters Cargado a la Cuenta Las Cuotas Cargadas a la Cuenta La Dimensin de la Cuenta La llave de la cuenta (PK) El Nmero De Cuenta (la Llave Natural) el Nombre Primario del Cuentacorrentista el Discurso Secundario de la Cuenta de Nombre del Cuentacorrentista Atribuye Fecha por Fijar de la Cuenta La Descripcin de Tipo de la Cuenta La Categora de Tipo de la Cuenta y ms La Dimensin de Toda la Casa La llave de toda la casa (PK) La Direccin del Grupo Familiar de Nombre del Cabeza de Familia Atribuye Tipo de Toda la Casa El Ingreso de Toda la Casa
El Indicador de Condicin de Ser Dueo de Hogar Propio de Toda la Casa La Presencia de Toda la Casa de Nios y ms
Figura 9.2 la mesa de hecho de la foto De Fondo para todas las cuentas.
La dimensin del producto consiste en una jerarqua simple del producto que describe todos los productos del banco, incluyendo el nombre del producto, tipo, y categora. La necesidad para construir una categorizacin genrica del producto en el banco es la misma necesidad que causa que las tiendas de comestibles construyan una jerarqua genrica de la mercanca. La diferencia principal entre el banco y la tienda de comestibles almacenan ejemplos son que el banco tambin desarrolla un gran nmero de atributos aduaneros del producto para cada tipo de prod-uct. Diferiremos debate estimando el manejo de estos attrib-utes aduanero hasta el fin de este captulo. La dimensin de la rama es similar a la facilidad o dimensiones de la posicin que discutimos ms temprano en este libro, como la tienda minorista o almacn del centro de distribucin. La dimensin del estado de cuenta es una dimensin til para registrar la condicin de la cuenta al final de cada mes. El estatus registra si la cuenta est activa o inactiva o ya sea un cambio de estado ocurri durante el mes, como una cuenta nueva abrindose o un cierre de la cuenta. En vez de aserrar la dimensin grande de la cuenta o meramente empotrar un cdigo secreto de estatus o abreviatura en seguida en la mesa de hecho, tratamos estatus como un dimen-sion hecho y derecho con estatus descriptivo descifra, los agrupamientos, y el estatus razonan a descrip tions segn el caso. De muchas formas podramos considerar que la dimensin del estado de cuenta es otro ejemplo de una minidimensin, como introdujimos en Captulo 6.
La Dimensin de Toda la Casa En vez de enfocar solamente la atencin en las cuentas del banco, los usuarios tambin quieren que la habilidad analice la relacin del banco con una unidad econmica entera, o el grupo familiar. Se interes en comprender el perfil global de un grupo familiar, la magnitud de la relacin existente con el grupo familiar, y qu los productos addi tional deberan estar vendidos para el grupo familiar. Tambin quieren captar caractersticas demogrficas cruciales estimando lo de toda la casa, como el ingreso de toda la casa, ya sea el grupo familiar posee o alquila la casa, y ya sea hay nios en el grupo familiar. Estos atributos demogrficos cambian con el paso del tiempo; Como usted sus-pect de fuerza, los usuarios faltante para rastrear los cambios. Si el banco enfoca la atencin en cuentas para entidades comerciales en vez de consumidores, probablemente tiene requisitos similares para identificar y vincular a las familias corporativas. De perspectiva del banco, un grupo familiar puede ser comprendido de varias cuentas y cuentacorrentistas individuales. Por ejemplo, considere a John y Mary Smith como un solo grupo familiar. John tiene cuenta de depsito, y Mary tiene una cuenta de ahorros. Adems, John y Mary tienen una cuenta corriente unida, una tarjeta de crdito, e hipoteca con el banco. Todo cinco de estas cuentas es consid-ered para ser una parte del mismo grupo familiar Smith a pesar de que las inconsecuencias menores pueden existir en el nombre operacional y pueden poner la direccin en informacin. El proceso de individuo correspondiente lleva las cuentas para los grupos familiares (o el equivalente comercial comercial de un grupo familiar residencial) no debe ser tomado a risa. Householding requiere que el desarrollo de algoritmos y reglas comerciales le asigne las cuentas a los grupos familiares. Como discutimos en Captulo 6, all estn productos de spe-cialized y servicios para hacer el apareamiento necesario para determinar asignaciones de toda la casa. Es muy comn que un orga-nization financiero grande de para servicios invierta recursos significativos de adentro especializado capacidades para soportar sus necesidades del householding. La decisin para tratar considera y grupos familiares como dimensiones separadas son alguno qu materia de la prerrogativa del diseador. A pesar de que las cuentas
y los grupos familiares estn correlacionados intuitivamente, decidimos tratarles separadamente por el tamao de la dimensin de la cuenta y la volatilidad de los componentes de la cuenta dentro de una dimensin de toda la casa, como establecido referencias para ms temprano. En un banco grande, la dimensin de la cuenta es enorme, con fcilmente sobre 10 millones de filas que se agrupan en varios grupos familiares de milln. La dimensin de toda la casa provee un punto algo ms pequeo de entrada en la mesa de hecho sin atravesar uno La mesa de dimensin de la cuenta de 10 millones de filas. Adems, dada la naturaleza cambiante de la relacin de en medio lleva las cuentas y grupos familiares, elegimos para usar la mesa de hecho para captar la relacin en vez de meramente incluir los atributos de toda la casa en cada fila de dimensin de la cuenta. De este modo evitamos usar el tipo 2 acercamiento SCD con la dimensin grande de la cuenta.
Multivalued Dimensions Como acabamos de ver en el John y ejemplo Mary Smith, una cuenta puede tener uno, dos, o ms cuentacorrentistas individuales, o ms clientes, asociado con ella. Obviamente, meramente no podemos incluir al cliente como un atributo de la cuenta; El proceder viola la granularidad de la mesa de dimensin porque ms de lo que un individuo puede ser asociado con una cuenta. Asimismo, no podemos incluir al cliente como una dimensin adicional en la mesa de hecho; El proceder viola la granularidad de la mesa de hecho (una fila por cuenta al mes) otra vez porque ms de lo que un individuo puede ser asociado con cualquier cuenta dada. ste es un ejemplo clsico de una dimensin multipreciada, cul desarrollaremos con creces en Captulo 13. Por ahora, scielo para decir que para asociar a una dimensin individual del cliente a un hecho veteado en cuenta que la mesa requiera el uso de una cuenta para cuadro puente del cliente, como se muestra en Figura 9.3. En un mnimo, la llave primaria del cuadro puente consiste en el cliente y cuenta vicaria llaves extranjeras. Discutiremos selladura de fecha /tiempo de filas del cuadro puente en Captulo 13 para captar cambios de relacin. Adems, explicaremos en detalle el uso de un factor que oprime en el cuadro puente para permitir ambos correctamente informes oprimidos e informes de impacto.
Un atributo de muchos valores indefinido puede ser asociado con una fila de dimensin usando un cuadro puente para asociar los atributos de muchos valores con la dimensin.
En algunas compaas financieras de servicios, el cliente individual es identificado y asociado con cada transaccin. Por ejemplo, las compaas de la tarjeta de crdito a menudo publican nmeros nicos de la tarjeta para cada tenedor de tarjeta. John y Mary Smith pueden tener una cuenta unida de la tarjeta de crdito, pero los nmeros en sus pedazos respectivas de plstico son nicos. En este caso no hay necesidad para una cuenta para cuadro puente del cliente porque los hechos atmicos de transaccin estn en casa del grano discreto del cliente. La cuenta y la cliente ambos seran llaves extranjeras en esta mesa de hecho.
El Hecho de la Foto de la Cuenta de Mes La fecha de Fin de mes Llave Branch (FK) Key (FK) La llave del Grupo Familiar de la Llave del Estado de Cuenta de la Llave de la Cuenta de la Llave del producto (FK) (FK) (FK) (FK) El Mes Primario Terminando Balance El Comn Daily Balance Number de Inters de Transacciones Pag El Inters Cargado a la Cuenta Las Cuotas Cargadas a la Cuenta
La Dimensin de la Cuenta La llave de la cuenta (PK) El Nmero De Cuenta (la Llave Natural) el Nombre Primario del Cuentacorrentista el Discurso Secundario de la Cuenta de Nombre del Cuentacorrentista Atribuye Fecha por Fijar de la Cuenta La Descripcin de Tipo de la Cuenta y ms
La Cuenta para Puente del Cliente La llave del Cliente de la Llave de la cuenta (FK) (FK) Oprimiendo Factor
La Dimensin del Cliente La fecha del Cliente de Nombre del Cliente de la Llave del cliente (PK) de Nacimiento y ms
Creo que 9.3 el puente de Account-To-Customer posponen para asociar a clientes mltiples con hechos que se llevan las cuentas a ras.
Minidimensions Revisited Similar para nuestro Captulo 6 el debate estimando la dimensin del cliente, hay una variedad ancha de atributos para describir las cuentas del banco, clientes, y los grupos familiares, inclusiva mensual oficina de crditos atribuye, los datos grficos en demo externos, y las puntuaciones calculadas para identificar su comportamiento, su retencin, prof-itability, y caractersticas de delincuencia. Se las interes en de organizaciones financieras servicios tpicamente entender y originarse de cambios en estos atributos con el paso del tiempo.
Es irrazonable confiar en el tipo 2 tcnica SCD para rastrear cambios en la dimensin de la cuenta dado la volatilidad de dimensin de la fila de la cuenta y de atributo, como la actualizacin mensual de atributos de la oficina de crditos. En lugar de eso, suspendemos de pronto los atributos capaz de haceres una lectura ligera y cambiables en minidimensiones mltiples, como oficina de crditos y minidimensiones de caractersticas demogrficas, cuyas llaves son incluidas en la mesa de hecho. Esta recomendacin fue ilustrada en Figura 6.4. Las minidimensiones nos dejan rebanada y los dados que los datos de hecho basaron en una larga lista de atributos mientras el atributo fcilmente rastreador cambia con el paso del tiempo, si bien pueden estar actualizados en frecuencias diferentes. Mientras las minidimensiones son sumamente poderosas, necesitamos ser precavidos que no empleamos demasiada la tcnica. Sin embargo, los servicios financieros orientados en cuenta son un buen ambiente para usar la tcnica de minidimensin porque la mesa primaria de hecho es una foto muy peridica encendida larga. As una fila de la mesa de hecho existe para cada cuenta todos los meses. Esta fila de hecho provee una casa para todas las llaves extranjeras y las conecta juntos a fin de que siempre podemos ver la cuenta conjuntamente con todo el otro minidimen-sions por cualquier mes.
Minidimensions debera consistir en aglomeraciones correlacionadas de atributos; Cada atributo no debera ser su minidimensin o nosotros sacaramos en limpio demasiadas dimensiones en la mesa de hecho.
Como descrito en Captulo 6, una de los acuerdos intermedios asociados con minidi-mensions es la necesidad para vendar atributo aprecia para sostener que la fila razonable de minidimensin cuenta. En vez de almacenar ingreso sumamente discreto tiene importancia, como $31,257.98, almacenamos alcances de ingreso, como $30,000-$34,999 en la minidimensin. De modo semejante, las puntuaciones de rentabilidad pueden extenderse desde 1 a travs de 1,200, cul nos agrupamos en los alcances fijos como menos que o el igual para
100, 101-150, 151-200, y de igual manera en adentro la minidimensin.
La mayora de organizaciones se encuentran con que estos valores vendados de atributo soportan su rou-tine requisitos analticos; Sin embargo, hay dos situaciones dnde los valores vendados pueden ser inadecuadas. Primero, la minera de datos que el anlisis a menudo requiere que los valores discretos en vez de bandas fijas sean ms efectivos. En segundo lugar, un nmero limitado
De poder los analistas pueden querer analizar los valores discretos a determinar si las bandas seleccionadas son correctas. En este caso todava mantenemos nuestros atributos de minidimensin de valor vendado para soportar informacin analtica cotidiana coherente, pero tambin almacenamos los valores numricos discretos cruciales como hechos en la mesa de hecho. Por ejemplo, si la puntuacin de rentabilidad de cada cuenta es calculada de nuevo cada mes, asignamos la minidimensin apropiada de alcance de rentabilidad para esa puntuacin cada mes. Adems, captamos la puntuacin discreta de rentabilidad como un hecho en la mesa mensual de hecho de la foto de la cuenta. Finalmente, estando necesitados, podramos incluir el alcance ms reciente de rentabilidad o la puntuacin en la dimensin de la cuenta, donde cualquier cambios son manejados por ah deliberadamente sobrescribiendo el atributo. Cada uno de estos elementos de datos en un dibujo tcnico deberan estar excepcionalmente etiquetados a fin de que son distin-guishable. Los diseadores siempre cuidadosamente deben balancear el valor incremental de incluir algo atributos y hechos redundantes versus el costo en trminos de la complejidad adicional para ambos la presentacin de escenificacin de la aplicacin y del usuario. El Arbitrario Value Agrupndose de Hechos Supongo que los usuarios comerciales quieren que la habilidad represente banda musical de valor escribiendo una crnica de un hecho numrico estndar, como el saldo de cuenta, excepto no est dispuesta a estar viviendo con bandas musicales predeterminadas. Pueden querer crear un informe que se ve simi-Lar para lo siguiente basado en la foto de saldo de cuenta:
El Alcance de Balance
El Nmero de Cuentas
El Total de Balances
0-1,000
1,001-2,000 2,001-5,000 5,001-10,000 10,001 y arriba
45,678
36,788 11,775 2,566 477
$10,222,543
$45,777,216 $31,553,884 $22,438,287 $8,336,728
Usando el dibujo tcnico en Figura 9.2, es difcil de crear este informe directamente
de la mesa de hecho. El lenguaje normalizado de consulta no tiene generalizacin del GRUPO POR clusula que el aditivo de aglomeraciones aprecia en los alcances. Para fomentar materias complejas, los alcances son de tamao desigual y tienen nombres textuales como 10,001 y arriba . Tambin, los usuarios tpicamente necesitan que la flexibilidad redefina las bandas en el tiempo de averiguacin con diferentes niveles aries en salto o de precisin. El diseo del dibujo tcnico mostrado en Figura 9.4 nos deja hacer banda flexible de valor reportando. La mesa de definicin de la banda puede contener tantos sets de bandas ponentes diferentes segn se desee. El nombre de un grupo particular de bandas se guarda en la columna del grupo de la banda. La mesa de definicin de la banda es adjuntada al hecho de balance usando un par de menos que y ms gran que junturas. El informe usa el nombre de alcance de la banda como el encabezado de la fila y ordena el informe en la columna de tipo de la banda.
El Hecho de la Foto de la Cuenta de Mes La fecha de Fin de mes Llave Branch (FK) Key (FK) La llave del Grupo Familiar de la Llave del >= Estado de Cuenta de la Llave de la Cuenta de la Llave del producto (FK) (FK) (FK) (FK) El Mes Primario Terminando Balance El Comn Daily Balance Number de Inters de Transacciones Pag El Inters Cargado a la Cuenta Las Cuotas Cargadas a la Cuenta
La Mesa de Definicin de la Banda
La llave del Grupo de la banda (PK) El nombre del Grupo de la Banda de Orden de Tipo del Grupo de la banda (PK) La Banda de Nombre de Alcance de la Banda Ms Abajo la Banda de Valor el Valor Superior < Creo 9.4 Arbitrary aprecian la banda reportando usando una mesa de definicin de la banda.
Controlar la funcin de esta averiguacin puede ser un reto. Por definicin, una averiguacin de la banda de valor est muy de prisa constreida. Nuestro informe de ejemplo necesit escandir los balances de ms que 90,000 cuentas. Quiz slo el dimen-sion de fecha estaba constreido para el mes corriente. Adems, la juntura poco convencional para la mesa de definicin de estrechamiento con una banda de nylon no es la base de uno con-straint agradable que restringe; Todo lo que est haciendo es agrupar los 90,000 balances. En esta situacin usted puede necesitar colocar un ndice directamente sobre el hecho de balance. La funcin de una averiguacin que constrie o los grupos sobre el valor de un hecho, como el balance, ser mejorada enormemente si el sistema de gestin de base de datos (el sistema de gestin de base de datos) puede ordenar y puede condensar el hecho individual eficazmente. Tal acercamiento fue en el que se marc nuevos rumbos por el producto de cociente intelectual Sybase en los inicios de 1990s y se est ahora volviendo una opcin estndar de indexacin en varios de los DBMSs irreconciliables.
El Punto en el Tiempo Se Balancea Hasta ahora hemos restringido que nuestros debates en este captulo financiero de servicios al fin de mes balancean fotos porque este nivel de detalle tpicamente es suficiente para anlisis. Estando requeridos, podramos suplementar la mesa de hecho de la foto mensualmente granulada con una segunda mesa de hecho que provee meramente la instantnea ms actual dispar a partir de la ltima actualizacin nocturna o quiz est extendido para proveer fotos de saldos diarios por la ltima semana o el mes. Sin embargo, qu ocurre si afrontamos el requisito a reportar el balance de una cuenta en cualquier punto arbitrariamente histrico escogido con el tiempo? Crear fotos de saldos diarios para un banco grande durante un tardado histrico perodo de tiempo sera apabullante dado la densidad de los datos de la foto. Si el banco tiene 10 millones de cuentas, las fotos diarias traducen en aproximadamente
3.65 billones de filas de hecho al ao.
Suponiendo que los requisitos comerciales ya han conducido la necesidad para hacer transaccin detallar datos disponibles para anlisis, podramos apalancar este detalle de transAc-tion para determinar un punto arbitrario en el balance de tiempo. Para simplificar mat-ters, reduciremos por coccin la mesa de hecho de transaccin de la cuenta a un diseo sumamente simple, tan ilustrados en Figura 9.5. La llave de tipo de transaccin se asocia para una mesa pequea de dimensin de tipos permisibles de transaccin. El nmero de secuencia de transaccin es un nmero continuamente numrico creciente corriendo en busca de la duracin de una vida de la cuenta. La bandera de cierre indica si sta es la ltima transaccin para una cuenta en un da dado. La cantidad de transaccin es obvia. El hecho de balance es el final saldo de cuenta siguiendo el acontecimiento de transaccin. Como todas las Tablas veteadas en transaccin de hecho, le aadimos una fila a la mesa de hecho en Figura 9.5 slo si una transaccin ocurre. Si una historia estuviera quieta para las dos semanas, quiz el 1 de enero a travs de 14, all no sera filas en la mesa de hecho para la cuenta durante ese perodo de tiempo. Sin embargo, supone que queremos saber qu todos los saldos de las cuentas fuera el 5 de enero? En este caso necesitamos buscar la fila previa ms reciente de hecho de transaccin para cada cuenta a ms tardar a nuestra fecha pedida. Aqu hay cdigo de lenguaje normalizado de consulta de muestra que resuelve el problema: ESCOJA a A.ACCTNUM, F.BALANCE entre FACT F, CUENTA UNO DONDE el operador booleano AND de la _ LLAVE de la _ LLAVE F.ACCOUNT = A.ACCOUNT _ la LLAVE F.DATE (SELECCIONE a MAX (_ la LLAVE G.DATE) DE FACT G DONDE _ la LLAVE de operador booleano AND de la _ LLAVE de la _ LLAVE G.ACCOUNT = F.ACCOUNT G.DATE Indiana (ESCOJA A _ LLAVE D.DATE entre DATE D DONDE D.FULLDATE 'el el 5 de Enero de 2002 '))
En este ejemplo nos aprovechamos de una situacin especial que existe con la llave vicaria de fecha. Como discutimos en Captulo 2, el compaero de cita llave es un crculo de enteros corredores de 1 hasta N con una secuencia significativa, previsible. Le asignamos los enteros consecutivos a la fecha llave vicaria a fin de que fsicamente podamos dividir en partes una mesa de hecho grande basada en la
fecha. Esto pulcramente segmenta la mesa de hecho a fin de que podamos realizar actos administrativos discretos sobre ciertos alcances de fecha, como datos del archived en movimiento para el almacenamiento no en la Internet o cayndose y reconstruyendo ndices. La dimensin de fecha es la nica dimensin cuyo surro-gate teclea tiene cualquier semiinteligencia incrustada. Debido a su secuencia previsible, es la nica dimensin en la cual nos atrevemos a colocar con-straints aplicativo. Usamos este ordenamiento en el cdigo precedente de lenguaje normalizado de consulta para hallar el ms reciente anterior fin de transaccin de da.
La Dimensin de Fecha de Transaccin
La Dimensin de Tipo de Transaccin La descripcin de Tipo de Transaccin de la Llave de Tipo de transaccin (PK)
La Mesa de Hecho de Transaccin de Balance La llave de la Cuenta de la Llave de fecha de transaccin (FK) (FK) Ms Foreign Afina Secuencia de Transaccin de la Llave de Tipo de Transaccin (FK) Bandera de Nmero Final (DD) Cantidad De Transaccin El Balance de Final de Transaccin La Dimensin de la Cuenta
Figura 9.5 Usar una mesa de hecho de transaccin para punto en el tiempo balancea.
Palanquear la mesa de hecho de transaccin para propsitos duales pide que la mesa de hecho es absolutamente completa y precisa. Cada transaccin en contra de la cuenta debe aparecer en esta mesa de hecho, o si no el saldo corriente no ser preciso. Una fila que llega tarde de transaccin requerira pasar rpidamente adelante del punto de insercin en esa cuenta e incrementar todos los balances y la
secuencia de transaccin numeran. Reparo en que explcitamente no hemos usado el nmero de secuencia de transaccin en este debate, aunque se necesita en este diseo para reconstruir la secuencia cierta de transacciones de fuente fidedigna y proveer la base de la llave primaria de la mesa de hecho, lo cual es la fecha, cuenta, y nmero de secuencia. Preferimos usar el nmero de secuencia en vez de un tiempo de estampilla de da porque las diferencias entre los nmeros de secuencia son uno vlido seguro en la Mea de actividad de cuenta. Esta tcnica es viable en alguna parte porque el sys-tem de proceso de transacciones fcilmente le puede dar fuera del balance actual mtrico para el almacn con cada registro de transaccin. A diferencia del el ao para fechar hechos discutimos en Captulo 8, en este caso de saldos de las cuentas que no tenemos muy para determinar los balances meramente resumiendo transacciones recientes a solas. Ms bien, necesitaramos estudiar el impacto de todas las transacciones desde principio de la existencia de la cuenta para cal-culate los vlidos saldos de las cuentas. Para algunos negocios dentro de la arena financiera de ser-vice, aun si los balances estn previstos siguiendo cada transaccin, todava no pueden valer para punto en el balance de tiempo reportando. Por ejemplo, en el caso de una empresa de corretaje, si un balance de valoracin est actualizado siguiendo cada transaccin de invest-ment, no podemos confiar en ese balance para punto en el tiempo reportando porque la valoracin cambia constantemente. En este caso probablemente crearamos una mesa de hecho de la foto para proveer a usuarios de fin normal de balances de valoracin de inversin de perodo.
Los Dibujos Tcnicos Heterogneos del Producto En muchos negocios financieros de servicio, un dilema surge por la naturaleza de hetero-geneous de los productos o servicios ofrecidos por la institucin. Como nosotros
Mencionado en la introduccin para este captulo, un banco minorista tpico ofrece un myr-iad de productos dismiles, de revisar las cuentas para las hipotecas, para los mismos clientes. Aunque cada cuenta en el banco tiene un saldo primario y la cantidad de inters se asoci con l, cada tipo del producto tiene un nmero de atributos especiales y hechos medidos que no son compartidos por otros productos. Por ejemplo, las cuentas de comprobacin tienen balances mnimos, lmites del giro en descubierto, y ser-vice va a la carga; Los depsitos a plazo como los certificados de depsito tienen pocos traslapos de atributo con comprobacin pero en lugar de eso tienen las fechas de madurez, combinando fre-quencies, y la tasa de inters corriente. Los usuarios comerciales tpicamente requieren dos perspectivas diferentes que son difciles de presentar en una sola mesa de hecho. La primera perspectiva es la vista global, incluyendo la habilidad a cortar en rodajas y dados todas las cuentas simultneamente, sin tener en cuenta su tipo del producto. Como describimos en Captulo 6, esta vista global se necesita para planificar cruz apropiada de gestor de relaciones con el cliente (la gestor de relaciones con el cliente) venda y arriba vende estrategias en contra de la base del cliente del agregado extendindose a lo largo de todos los productos posibles. En esta situacin necesitamos que la sola mesa de hecho de fondo cruzando todas las lneas de busi-ness provea entendimiento profundo en el portafolio completo de la cuenta, como mentidor ilustrado de oreja en Figura 9.2. Nota, sin embargo, que la mesa de hecho de fondo le pueda slo donar a limit nmero de hechos que tienen sentido para virtualmente cada clase de negocio. Somos incapaces de acomodar hechos incompatibles en la mesa de hecho de fondo porque, en el caso de operar en bancos, all puede ser varios centenares de estos hechos cuando toda la cuenta posible que los tipos son considerados. De modo semejante, la dimensin del producto de fondo le provee un punto sumamente analtico til de entrada a los hechos pero es limitada al subconjunto de atributos comunes del producto. La segunda perspectiva requerida por usuarios es la vista de clase de negocio especfica que enfoca la atencin en los detalles de fondo de un negocio, como revisar. Como describimos, hay una larga lista de hechos especiales y los atributos que slo tienen sentido para el negocio verificador. Estos hechos especiales no pueden ser incluidos en la mesa de hecho de fondo; Si hicisemos esto para cada clase de negocio en un banco minorista, sacaramos en limpio cien hechos
especiales, la mayora de la cual tendran los valores nulos en cualquier fila especfica. Asimismo, si tratsemos de incluir los atributos de clases de negocio especficos en la mesa de dimensin del producto, tendra centenares de atributos especiales, casi todo que seran huecos para cualquier fila dada. Las Tablas de result-ing se pareceran al queso suizo, tir basura con huecos de datos. La solucin para este dilema debe crear un dibujo tcnico aduanero para la verificadora clase de negocio a que se le limita simplemente revisar las cuentas, como se muestra en Figura 9.6. Ahora ambos la mesa de hecho de comprobacin de costumbre y la dimensin correspondiente del producto de comprobacin son ensanchadas para describir todos los hechos especficos y attrib-utes que slo tiene sentido para revisar productos. Estos dibujos tcnicos aduaneros tambin contienen los atributos y hechos de fondo a fin de que podamos evitar unir Tablas de los dibujos tcnicos de fondo y aduaneros para obtener la coleccin completa de hechos y
Atributos. Asimismo, construiramos Tablas de hecho aduanero y del producto para los otros giros de negocios para soportar sus requisitos de anlisis a fondo. Aunque crear dibujos tcnicos especficos para un producto suena complicado, slo el administrador de base de datos ve todas las Tablas de inmediato. De la perspectiva de usuarios, ya sea eso un anlisis del producto cruzado eso confa en la mesa de hecho de fondo y su mesa de prod-uct de fondo acompaante o los focos de anlisis en un producto particular escribe, en cuyo caso uno de los subesquemas de clases de negocio aduaneros es usado. En general, no tiene sentido para combinar datos de uno o ms subesquemas aduaneros porque, por definicin, los hechos y los atributos son disjuntos (o casi as). Las llaves de las dimensiones aduaneras del producto son las mismas llaves usadas en la dimensin del producto de fondo, lo cual contiene todo lo que el producto posible teclea. Por ejemplo, si el banco ofrece un balance mnimo de $500 sin por producto de comprobacin de cargo del cheque, el producto le tendra al mismo substituto llave en ambos el corazn y las dimensiones del producto de comprobacin de costumbre. Como discutimos en Captulo 3, estab-lishing conform dimensiones es esencial para una arquitectura extensible del almacn de datos. Cada dimensin aduanera del producto es un subconjunto de filas de la mesa de dimensin del producto de fondo. Cada dimensin aduanera del producto contiene atributos especficos para un tipo particular del producto. Esta tcnica heterognea del producto obviamente se aplica a cualquier negocio que las ofertas ampliamente variaron productos a travs de los mltiples giros de negocios. Si trabajsemos para una compaa de tecnologa que vende hardware, el software, y los servicios, podemos imaginar construir hecho de ventas de fondo y Tablas de dimensin del producto para dar la perspectiva global del cliente. Las Tablas de fondo incluiran todos los hechos y todos atributos de dimensin que son comunes a travs de los giros de negocios. Las Tablas de fondo entonces seran suplementadas con dibujos tcnicos que traducen una zambullidura profunda a atributos y hechos aduaneros que difiere por el negocio. Otra vez, un producto especfico sera asignado la misma llave vicaria del producto en ambos las dimensiones del producto de fondo y aduaneras.
El Hecho Mensual de la Foto de Comprobacin La llave de la Cuenta de la Llave de Fecha de Fin de mes (FK) (FK) La llave del producto (FK) Ms Llaves Extranjeras de Fondo Los Hechos de Fondo El Nmero de Cheque Cleared Numera de Nmero Electrnico de Transacciones de Giros en Descubierto El nmero de Usos del cajero automtico El Nmero de Depsitos La Dimensin Especfica En La Comprobacin del Producto La llave del producto (PK) Los Atributos del Producto de Fondo El Requisito Mnimo de Balance de Comprobacin Per Revise Indicador de Retribucin por Jaque Indicador de Cargo Mensual de Cantidad de Retribucin Mensualmente Cantidad de Cargo Mensual de Base de Retribucin El Indicador Libre del Estampado del Cheque La Tarjeta De Dbito el Indicador Elegible
Figura 9.6 el dibujo tcnico aduanero de clase de negocio Especfico para revisar productos.
Una familia de Tablas de hecho de fondo y aduaneras se necesita cuando un negocio tiene productos de heteroge-us que los tienen con naturalidad descriptores y hechos diferentes pero un solo cliente base que exige una vista integrada.
Podemos considerar manejar los atributos de clases de negocio especficos como un arbotante dependiente en contexto para la dimensin del producto, tan ilustradas en Figura 9.7. Hemos aislado los atributos de fondo en la mesa de dimensin del producto bajo, y podemos incluir una llave del copo de nieve en cada registro bajo que seala su arbotante del producto extendido correcto. La llave del copo de nieve debe conectarse a la mesa particular del arbotante que un tipo especfico del producto define. Usualmente, usted accom-plish esta tarea construyendo una vista de relaciones para cada producto puede escribir que los hardwires el camino correcto de la juntura. En el caso de los servicios financieros orientados en cuenta, cuando un producto es vendido para un cliente, una cuenta nueva es abierta. En el caso de algunos productos bancarios, como hipotecas, ms informacin descriptiva especfica en la cuenta es coleccionada cuando la historia abrindose ocurre. Por ejemplo, el banco puede ofrecer una hipoteca de tasa de inters fija de 15 aos en una tasa dada. Cuando la hipoteca se origina, el banco sabr ms acerca de la propiedad especfica, incluyendo la direccin, valuacin fiscal, el metraje cuadrado, tipo (por ejemplo, el marco de madera, el ladrillo, el estuco) de tipo hogareo (por ejemplo, townhouse familiar en soltero,, con-dominium, remolque), de la construccin, la fecha de construccin, y el nmero de acres. Estos valores de atributo difieren por cuenta, as es que no pertenecen adentro lo lo que el banco vende dimensin del producto. Como se muestra en Figura 9.7, podemos visualizar un arbotante de dimensin de la cuenta para algunos tipos de la cuenta. Si los giros de negocios en nuestro banco minorista son fsicamente separados a fin de que cada uno tiene su centro de compras de datos, el hecho aduanero y las Tablas de dimensin probablemente no lo harn
La Dimensin del Producto La llave del producto (PK) Los Atributos del Producto de Fondo
Especfico En La Hipoteca El Arbotante del Producto La llave especfica en la hipoteca (PK) del Producto Se Veng de / Adjustable / El Jumbo Convencional Tasa Trmino La Direccin Federal de la Vivienda Compliant / Eligible Virginia Compliant / Eligible
Mensualmente Hipoteque Hecho de la Foto

Las Dimensiones de la Cuenta La llave de Fecha de Fin de mes (FK)
La llave de la cuenta (PK) Los Atributos de la Cuenta de Fondo Especfico En La Hipoteca El Arbotante de la Cuenta La direccin especfica en la hipoteca de la Propiedad de la Llave de la Cuenta (PK) El Tipo Elogiable de la Construccin de Tipo de la Casa de Metraje del Cuadrado de Valor El Ao Construido Completado Nmero de acres La llave del Producto de la Llave de la cuenta (FK) (FK) Ms Llaves Extranjeras de Fondo Los Hechos de Fondo La Cantidad Original de Prstamo Sobresaliendo Cantidad de Inters de Cantidad de Prstamo La Cantidad de Custodia de Impuesto sobre Bienes La Cantidad de Custodia de Seguro La Cantidad de Seguro Hipotecario de la Propiedad La Custodia de Impuesto sobre Bienes Pagada La Custodia de Seguro Pagada El Seguro Hipotecario de la Propiedad Pag Retribucin del Pago Atrasado de Cantidad de Mercancas Excedentes /escasez de Custodia El Jefe Adicional Asalariado
Figura 9.7 arbotantes dependientes en contexto de dimensin.
La Mesa de Hecho Restringida para Checking Accts La llave de la Cuenta de la Llave de Fecha de Fin de mes (FK) (FK) La llave del producto (FK) Ms Foreign Teclea Hechos De Fondo La llave especfica en la comprobacin (FK) de Hecho
El Comprobar Costumbres Extendi Mesa de Hecho El nmero especfico en la comprobacin de la Llave de Hecho (PK) de Cheque Cleared Numera de Nmero Electrnico de Transacciones de Giros en Descubierto El nmero de Usos del cajero automtico El Nmero de Depsitos Ms Hechos Especficos En La Comprobacin Resuelva 9.8 dibujo tcnico Heterogneo de productos usando una mesa extendida de hecho.
Radique en el mismo espacio como el hecho de fondo y dimensione Tablas. En este caso los datos en la mesa de hecho de fondo seran duplicados exactamente una vez para implementar todas las Tablas aduaneras. Recuerde que las Tablas aduaneras proveen que un parti-tioning disjunto de los productos tan ese no hay traslapo entre los dibujos tcnicos aduaneros. Si los giros de negocios comparten el mismo espacio fsico de la mesa, podemos evitar dupli-cating ambos las llaves de hecho de fondo y hechos de fondo en las Tablas de hecho de clase de negocio aduaneras. Hacemos eso asignando una llave especial de la juntura para cada fila de hecho de fondo que excepcionalmente identifica una sola cuenta en un solo mes. Usando esta llave de la juntura, fsicamente asociamos los hechos aduaneros extendidos a la mesa de hecho de fondo, como se muestra en Figura 9.8. Al usar esta tcnica, necesitamos asegurar que el optimizador resuelve las restricciones en la mesa de hecho de fondo antes de adjuntar a la mesa extendida de hecho usando la juntura especial crucial. La herramienta de averiguacin o la aplicacin debe saber usar esta llave especial de la juntura a conectar para la mesa extendida correcta de hecho para cada clase de negocio. Mientras esto suena complicado, es en verdad muy natural. Por definicin con hechos heterogneos, casi nunca tiene sentido para incorporarse a ms de lo que uno extendi mesa de hecho representando una clase de negocio en una sola expresin de lenguaje normalizado de consulta. Los nombres de los hechos en la separata extendieron que las Tablas de hecho, por definicin, son diferentes; Ninguna sola expresin de lenguaje normalizado de consulta puede hablar para Tablas extendidas mltiples de hecho. As una aplicacin peticionaria analizando una especfica clase de negocio, tan verificadora, siempre sera de engao duro para conectar para la mesa extendida correcta de hecho.
Los Productos Heterogneos con Los Hechos de Transaccin La tcnica del producto heterognea acabada de discutir es apropiada para Tablas de hecho en las cuales una sola fila lgica contiene muchos hechos especficos para un producto. Las fotos usualmente equipan este patrn. Por otra parte, las Tablas veteadas en transaccin de hecho a menudo tienen un solo hecho que es genricamente el blanco de una transaccin particular. En tales casos el hecho que la mesa tenga una dimensin asociada de transaccin que interpreta la columna de cantidad. En el caso de Tablas veteadas en transaccin de hecho, tpicamente no necesitamos Tablas de hecho de clase de negocio especficas. Podemos pasar slo una mesa de hecho de fondo porque hay slo un hecho. Sin embargo, todava podemos tener un set sustancioso de productos heterogneos con atributos diversos. En este caso generaramos el portafolio completo de Tablas aduaneras de dimensin del producto y las usaramos segn el caso, a merced de la naturaleza de la aplicacin. En un anlisis del producto cruzado, usaramos la mesa de dimensin del producto de fondo porque es capaz de extenderse a lo largo de cualquier grupo de productos. En un solo anlisis del producto, optativamente nos pudimos uso la mesa de dimensin del producto aduanero en lugar de la dimensin de fondo si quisisemos aprovecharnos de los atributos aduaneros especficos para ese tipo del producto.
Resumen Empezamos este captulo discutiendo la situacin en la cual una mesa de hecho tiene tambin pocas dimensiones. Provemos sugerencias para buscar a fondo dimen-sions adicional usando un proceso de triage. Se acerca para manipular la rela-tionship a menudo complicada entre cuentas, clientes, y los grupos familiares estaban descritos. Tambin discutimos el uso de minidimensiones mltiples en una sola mesa de hecho, lo cual es medianamente comn en dibujos tcnicos financieros de servicios. Ilustramos una tcnica para aglomerar hechos numricos en bandas arbitrarias de valor para reportar los propsitos a travs del uso de una mesa de la banda separada.
Tambin tratamos superficialmente un acercamiento para palanquear una mesa existente de hecho de transaccin para suministrar punto en los balances de tiempo. Finalmente, provemos recomendaciones para cualquier organizacin que le ofrece los productos de het-erogeneous al mismo set de clientes. En este caso creamos una mesa de hecho de fondo que contiene mtrica de funcin que es comn a travs de todos los giros de negocios. El compaero que la mesa de dimensin de fondo contiene rema para la completa cartera de productos, pero los atributos son limitados a esos que son aplicables a travs de todos los productos. Los dibujos tcnicos aduaneros mltiples, uno para cada clase de negocio, complementa este dibujo tcnico de fondo con atributos y hechos especficos para un producto.
El carbono HAPTE R10
Las Telecomunicaciones y los Servicios Pblicos
Su captulo fluir un poco diferentemente que preceder captulos. Todava comenzaremos con una visin general de estudio de casos, pero no disearemos un modelo dimensional de la nada esta vez. En lugar de eso, entraremos en un medio del ro de proyecto para transmitir una revisin del diseo, buscando oportunidades para mejorar el dibujo tcnico en borrador inicial. Recuerda usted leer los Rayos del Cabello para revista de Nios en su clnica dental esperando cuarto hace mucho tiempo? Si es as, recuerda usted lo qu el agravio con estos papeles de trabajo del cuadro donde usted identific todos los artculos fuera de lugar, como el pollo conduciendo un coche o un mueco de nieve en la playa? La masa de este captulo enfocar la atencin en un modelado dimensional lo que est mal con este ejercicio del cuadro donde legamos desperfectos del diseo fuera de lugar iden tify. Usaremos una vieta facturadora sacada de la industria de telecomunicaciones como la base para el estudio de casos; Sin embargo, comparte caractersticas similares con los datos facturadores generados por una compaa de servicios pblicos. Al final de este captulo que explicaremos en detalle manejar y apalancar
la informacin geogrfica de la posicin en el almacn, sin tener en cuenta la industria.

disee ejercicio retrospectivo el diseo comn equivoca para mirar pues en una revisin la dimensin geogrfica de la posicin, incluyendo su tratamiento como un arbotante del snowflaked y su interaccin con geogrficos sistemas de informacin
217
El Estudio De Casos de Telecomunicaciones Dado su experiencia extensiva en el modelado dimensional (nueve captulos hasta ahora), usted ha sido reclutado para una posicin nueva como un modelador dimensional en el equipo del almacn de datos para una compaa inalmbrica grande de telecomunicaciones. En su primer da, luego de algunas horas de trabajo de oficina humano de recursos y orienta-tion (incluyendo la posicin de la mquina prxima de caf), usted estn listos a ponerse a trabajar. Los datos almacenan pareja est ansiosa por escoger su cerebro estimando su diseo dimensional inicial. Hasta ahora tal parece ser que el proyecto va con rumbo hacia un buen principio. La compaa tiene un comit de patrocinio de tecnologa de la informacin fuertemente comercial y que acept el concepto que un almacn de datos debe ser conducido en negocio; Como tal, el com-mittee fue con creces solidario del proceso que congrega requisitos comerciales. Basado sobre la iniciativa de requisitos, el equipo redact una matriz inicial del autobs de la casa de loza de datos. Es el primer rotafolio, tan ilustrado en Figura 10.1, para darle la pared durante el diseo de revisin con durante con usted. El equipo identific que varios corazones de comercial va en procesin y un nmero de dimensiones comunes. Por supuesto, la matriz ancha en la empresa completa era muy mayor en trminos de ambos el nmero de filas y el nmero de columnas, pero usted es muy cmodo que los requisitos principales de datos de los cruciales cuerpos de electores hayan sido captados. El comit de patrocinio conjuntamente decidi enfocar la atencin en la primera fila de la matriz, el cliente facturando proceso, para la fase inicial del almacn de datos. La administracin de empresas determin ese mejor acceso para la mtrica resultando del proceso facturador le daban impacto significativo sobre el negocio, espe-cially el foco reciente del negocio sobre la gestor de relaciones con el cliente, como discutimos en Captulo 6. La gerencia quiere que la habilidad vea uso mensual y mtrica facturadora (conocido como la renta) por cliente, organizacin de ventas, y el plan de tasa para representar a agente comercial y el anlisis de rendimiento del canal y la tasa planifican analy-si. Afortunadamente, el equipo de tecnologa de la informacin consider que fue factible abordar este proceso comercial durante la primera iteracin del almacn.
Algunas personas en la organizacin de tecnologa de la informacin pensaron que sera preferible abordar rcords individuales de detalle de llamada, como cada llamada iniciada o recibida por cada telfono. Mientras este nivel de datos altamente granulares proveera entendimientos profundos interesantes, fue determinado por el negocio unido y l el patrocinio comete meta que los presentes asociados de datos que ms viabilidad desafa mientras no dando tanto valor comercial de corto plazo.
El Cliente Facturando Trfico de Detalle de Llamada Comprando Mercaderas en Rebaja Distribuidoras del Canal de Inventario El Servicio Llama por Telfono
Repare Artculos Creo que 10.1 el Subconjunto del almacn de datos llevan en autobs matriz.
Basado sobre la direccin provey por el comit de patrocinio, el ceeded del equipo para verse ms de cerca en el cliente facturando datos. Cada mes, el sistema facturador oper ational genera una cuenta para cada nmero de telfono, tambin conocido como lnea de saque. Desde que la compaa inalmbrica tiene millones de lneas de saque, este repre-sents una cantidad significativa de datos. Cada lnea de saque es asociada con una sola cliente. Sin embargo, un cliente puede hacer mltiplo radiotelegrafiar lneas de saque, cul aparezca como los rubros contables separados en la misma cuenta; Cada lnea de saque tiene su set de facturar mtrica, como el nmero de minutos usado y mensual recargo por servicios. Hay un solo plan de tasa asociado con cada lnea de saque en una cuenta dada; Este plan puede cambiar como los hbitos de uso de los clientes evolucionen. Finalmente, un agente comercial (y su respectiva organizacin de ventas y canal) es asociado con cada lnea de saque para evaluar la gen-erated de la corriente de renta de la facturacin en curso por cada socio del representante y del canal. El equipo dise una mesa de hecho al hilo siendo una fila por cuenta cada mes. Los datos almacenan pareja con altanera desenrolla su obra maestra dimensional de mod-eling en borrador, como se muestra en Figura 10.2, y le mira impacientemente. Qu piensa usted? Antes de que sigamos adelante, por favor gaste varios minutos estudiando el diseo en Figura 10.2. Intente identificar los desperfectos del diseo y sugerir improve-ments en esto qu est mal con este cuadro ejercicio antes de rezar delante.
La Dimensin del Cliente El cliente Idaho (PK y Natural Teclean) Bill # (FK) Facturando Hecho Bill Dimension Bill # (PK)
La Dimensin de la Lnea de Saque
El Nombre del Cliente El Cliente de la Ciudad del Cliente el ZIP Estatal del Cliente La fecha de Servicio 1 La Puntuacin Original de Crdito de la Autorizacin La Dimensin del Agente Comercial El cliente Idaho (FK) Sales Rep Number Sales Org (FK) Idaho (FK) La tasa la Tasa de Plan de Cdigo (FK) el Nmero de Clave de Tipo de Plan de Llamadas El Nmero de Minutos Totales El Nmero de Minutos de Vagabundeo
El Nmero de Minutos de Gran Distancia
Bill Date El nmero de la lnea de saque (FK)
La Tasa la Dimensin de Plan El cdigo de rea de Nmero de la lnea de saque (PK) El Cdigo De rea y el Prefijo La Fecha de Activacin de la Lnea de Saque
El nombre del Agente Comercial Sales Rep Number (PK y Natural Teclean) Sales Org Idaho La Dimensin del Org de Ventas Sales Org Idaho Sales Channel Idaho El Mensual Service Charge Prior Month Service Charge Year hasta la Fecha Service Charges Roaming Charge El Cargo de Gran Distancia Impuestos Los Cargos Reguladores La tasa el Cdigo de Plan (PK y Natural Teclean) La Tasa la Abreviatura de Plan
Creo que 10.2 el dibujo tcnico En Borrador antes de diseo repasan.
Las Consideraciones Generales de Revisin del Diseo Antes de que discutimos los asuntos especficos y las recomendaciones potenciales para Fig Ure 10.2, tardaremos un momento en esbozar los asuntos del diseo que comnmente encontramos cundo transmitiendo una revisin del diseo. Para no dejar entrever que la pareja del almacn de datos en nuestro estudio de casos ha entrado en todas estas trampas, pero puede ser culpable de violar varios. Otra vez, el ejercicio de revisin del diseo ser una ms herramienta efectiva de aprendizaje si usted tomara un momento para apuntar sus ideas personales estimando Figura 10.2 antes de proceder.
Granularidad Una de las preguntas de primera parte que siempre preguntamos durante una revisin del diseo es, Cul es el grano de la mesa de hecho? Sorprendentemente, a menudo tenemos respuestas inconsistentes para esta averiguacin del equipo de proyecto. Declarando un claro y definicin sucinta del grano del hecho la mesa es crtica para un esfuerzo productivo de modelado. Asimismo, el equipo de proyecto y enlaces comerciales deberan compartir una comprensin comn de esta declaracin del grano. Por supuesto, si usted ha ledo hasta aqu, usted es consciente de que fuertemente creamos que usted debera construir su mesa de hecho en el nivel mnimo de granularidad posible. Sin embargo, la definicin del nivel mnimo de granularidad posible depende del proceso comercial que usted modela. En este estudio de casos no necesitamos que detalle que se llama a ras con la granularidad de una fila para cada llamada se ocupe de los requisitos comerciales. En lugar de eso, una mesa facturadora de hecho es ms correcta. Queremos implementar los datos ms granulares disponibles
Para el proceso seleccionado de la facturacin, no simplemente los datos ms granulares disponibles en la empresa. Por supuesto, si los requisitos comerciales prioritarios altos enfocasen la atencin en red conmutativa anlisis de trfico y de capacidad, en ese entonces los datos de detalle de llamada de bajo nivel seran apropiados.
Ir al nivel mnimo de granularidad no implica encontrar la mxima cantidad de datos detallados disponibles en la organizacin.
La Granularidad de Hecho Una vez que la granularidad de la mesa de hecho ha sido establecida, los hechos deberan estar identificados que est consistente con la declaracin del grano. En un esfuerzo para mejorar perfor-mance o reducir complejidad de averiguacin, hechos agregados tan como el ao con el que salir en cita saca el total algunas veces acusn en la fila de hecho. Estos totales son peligrosos porque no son perfectamente aditivos. Mientras un ao para fechar total reduce la complejidad y el tiempo de ejecucin de algunas averiguaciones especficas, tenerla en la mesa de hecho llama una averiguacin para duplicar cuenta el ao para fechar columna (o peor) cuando ms de lo que un compaero de cita de la cuenta es incluida en una averiguacin. Tiene mucha importancia que una vez que el grano de una mesa de hecho est escogido, todos los hechos aditivos se replantean en un grano uniforme.
La Granularidad de Dimensin Cada uno de las dimensiones asociadas con una mesa de hecho debera cobrar un solo valor con cada fila de medidas de la mesa de hecho. Asimismo, cada uno del dimen-sion que los atributos deberan cobrar un valor para una fila dada de dimensin. Si los atributos tienen un que est para muchas relacin, entonces esta relacin jerrquica puede ser representada dentro de una sola dimensin. Generalmente deberamos buscar oportunidades para colapsar jerarquas de
dimensin siempre que sea posible. En general, desalentamos el snowflaking o normalizacin de Tablas de dimensin. Mientras el snowflaking puede reducir el espacio del disco consumido por Tablas de dimensin, los ahorros son usualmente insignificantes cuando son comparados con el almacn entero de datos y rara vez son contrarrestados las desventajas en la facilidad de funcin de uso o de averiguacin. A todo lo largo de este libro nosotros ocasionalmente hemos discutido arbotantes como copos de nieve de permissi-ble. Los arbotantes pueden jugar un papel til en sus diseos dimensionales, pero pueden tener a la vista que el uso de arbotantes para un grupo de cardinality relativamente bajo o atributos frecuentemente reutilizados debera ser la excepcin en vez de la regla. Evite abusar de la tcnica del arbotante emplendolos demasiado en sus dibujos tcnicos.
La Dimensin de Fecha Los equipos del diseo algunas veces adjuntan una dimensin genrica de fecha a su mesa de hecho porque saben es la dimensin ms comn pero entonces no puede articular a lo que la fecha refiere. No hay ni que decirlo, esto presenta retos autnticos para el equipo que escenifica datos. Mientras advertimos contra dimensiones superfluas de fecha, promovemos la inclusin de los atributos de fecha de robusta movimiento hacia arriba y del filtro en una mesa de dimensin de fecha de mean-ingful.
Los Cubos de Series Temporales Fijos en Lugar de Eso de La Dimensin de Fecha Otros diseadores algunas veces evitan una mesa de dimensin de fecha enteramente representando una serie temporal de cubos mensuales de hechos en una sola fila de la mesa de hecho. Los sistemas operacionales mayores pueden contener sets mtricos que estn repetidos 12 veces en un disco sencillo a representar mes 1, el mes 2, etctera. Hay varios problemas con este acercamiento. Primero, la identidad de engao duro de las ranuras de tiempo es inflexible. Cuando usted llena todos los cubos, usted queda con elecciones desagradables. Usted podra alterar la mesa para expandir la fila. De otra manera, usted podra desviar todo encima por una columna, dejando caer los ms viejos datos, pero esto hace estragos con sus aplicaciones existentes de averiguacin. El segundo problema con este acercamiento es que todos los atributos de la fecha misma son ahora la responsabilidad de la aplicacin, no la base de datos. No hay dimensin de fecha en la cual para colocar descripciones de acontecimiento del calendario para constreir. Finalmente, el acercamiento de la ranura fija es ineficiente si las medidas son slo llevadas en un particular lapso de tiempo, resultando en columnas nulas en muchas filas. En lugar de eso, estos cubos de tiempo recurrentes deberan replantearse como la separata reme en la mesa dimensional de hecho.
Degenere Dimensiones En vez de tratar nmeros operacionales de transaccin, como la factura o nmero de orden, como las dimensiones degeneradas, mancomuna algunas veces quiera crear una dimensin separada para el nmero de transaccin. Los atributos de la
dimensin de nmero de transaccin entonces incluyen que los elementos del registro del encabezado de transaccin, como la fecha de factura, facturan tipo, y trminos de la factura. Recuerde, los nmeros de transaccin son ms convenientes tratados como las dimensiones degeneradas. En sus revisiones del diseo, est a la bsqueda de una mesa de dimensin que tiene como muchas (o casi tan muchos) filas como la mesa de hecho. ste debera ser un aviso de emergencia que puede haber una dimensin degenerada acechando dentro de una mesa de dimensin.
La Dimensin Descifra y Descripciones Todos los identificadores y todos cdigos en las Tablas de dimensin deberan estar acompaados por ah descriptivos descifra. Simplemente necesitamos descartar la mal-percepcin que el negocio
Los usuarios prefieren trabajar con cdigos. Para convencerse, usted debera pasearse hasta sus oficinas para ver lo descifran listados llenando sus tableros de anuncios o aplicndole delineador a sus monitores de la computadora. La mayora de usuarios no aprenden de memoria los cdigos fuera de algunos favoritos. Los salarios nuevos son dado indefenso cuando son asaltados con una larga lista de cdigos sin sentido. Las buenas noticias son que usualmente enlatamos fuente descifra de sistemas operacionales con esfuerzo adicional mnimo o los gastos fijos. Ocasionalmente, las descripciones no estn disponibles de un sistema operacional sino necesitan ser provistas por socios comerciales. En estos casos, es importante determinar una estrategia de mantenimiento en curso para mantener calidad de datos. Finalmente, algunas veces trabajamos con equipos de proyecto que optan por empotrar fil-tering complicado o etiquetado lgico en la aplicacin de acceso de datos en vez de soportar l por una mesa de dimensin. Mientras las herramientas de acceso pueden proveer la habilidad para descifrar dentro de la averiguacin o la aplicacin ponente, recomendamos eso descifra sea almacenado como elementos de datos en lugar de eso. Las aplicaciones deberan ser conducidas en datos para minimizar el impacto de descifran adiciones y cambios. Por supuesto, descifra eso radica en la base de datos tambin asegura mayor informe designando consistencia.
Subrogue Llaves En lugar de confiar en identificadores o claves operacionales, recomendamos el uso de substituto teclea a todo lo largo de su diseo dimensional. Si usted es poco claro acerca de las razones para perseguir esta estrategia, sugerimos que usted vuelve hacia atrs para Captulo 2 para renovar su memoria.
Demasiadas (o Demasiado Pocas) Dimensiones Como hemos mencionado, un modelo dimensional tpicamente tiene 5 para 15 dimensiones. Si su diseo tiene slo dos o tres dimensiones, en ese entonces usted debera volver a visitar Chap Ter 9 para un debate sobre consideraciones de triage
de dimensin. Si su diseo tiene 25 o 30 dimensiones, sugerimos que usted revisa el diseo centpedo en Captulo 2 o la dimensin de trastos viejos en Captulo 5 para las ideas para reducir el nmero de dimensiones en su dibujo tcnico.
Redacte Debate de Ejercicio del Diseo Ahora que hemos repasado varios peligros insospechados dimensionales comunes de modelado durante las que encontramos frecuentemente disean revisiones, volvmonos a mirar hacia el diseo en borrador en Figura 10.2. Varios artculos inmediatamente saltan fuera en nosotros quizs muchos que es difcil de saber dnde empezar.
La primera cosa en la que enfocamos la atencin es el grano de la mesa de hecho. El equipo del diseo dijo que el grano sea una fila para cada cuenta cada mes. Sin embargo, basado sobre nuestra comprensin del esfuerzo de descubrimiento de datos, el nivel mnimo de facturar datos sera una fila por lnea de saque en una cuenta. Cuando sealamos esto al equipo de proj-ect, el equipo nos dirige a la dimensin de nmero de la cuenta, lo cual incluye el nmero de la lnea de saque. Cuando se le recuerda que cada lnea de saque tiene su set de facturar mtrica, el equipo est de acuerdo que la declaracin del grano ms apropiada sera una fila por lnea de saque por cuenta. Movemos la llave de la lnea de saque en la mesa de hecho como una llave extranjera a la dimensin de la lnea de saque. Al discutir la granularidad, la dimensin de nmero de la cuenta es escudriada, cuanto ms que acabamos de mover la lnea de saque crucial en la mesa de hecho. Como el modelo en borrador fue originalmente extrado en Figura 10.2, cada vez que una fila de la cuenta est cargada en la mesa de hecho, una fila tambin estara cargada en la mesa de dimensin de nmero de la cuenta. No se requiere demasiado para convencer al equipo que algo est equivocado con este cuadro. Aun con la granularidad modificada para incluir lnea de saque, todava sacaramos en limpio casi tan muchos alborotos en ambos el hecho y las Tablas de dimensin de nmero de la cuenta. En lugar de eso, optamos por tratar el nmero de la cuenta como una dimensin degenerada. Al mismo tiempo, nos mudamos a la fecha de la cuenta la mesa de hecho y nos le unimos a ella para una dimensin robusta de fecha, lo cual desempea el papel de un compaero de cita de la cuenta en este dibujo tcnico. Hemos sido molestados desde que el primer miramiento en el diseo por el doble une la mesa de dimensin de organizacin del agente comercial. Ante todo, el agente comercial que la jerarqua organizativa ha sido snowflaked innecesariamente. Optamos por colapsar la jerarqua incluyendo la organizacin del agente comercial y los identificadores del canal (junto con descriptores ms significativos, esperanzadamente) como los atributos adicionales en el agente comercial dimensionan mesa. Adems, podemos eliminar la organizacin no necesitada del agente comercial llave extranjera en la mesa de hecho. El diseo inadecuadamente trata el cdigo de tipo de plan de tasa como un hecho textual. Los hechos del Tex Tual son rara vez una eleccin del diseo del sonido. Casi siempre suben ms espacio en nuestras Tablas de hecho que una llave vicaria.
Ms importante, los usuarios generalmente quieren poner en duda, constreir, y reportar en contra de estos hechos textuales. Podemos proveer respuesta ms rpida y ms acceso flexible manejando estos valores textuales en una mesa de dimensin. Adems, los adicionales atributos descriptivos usualmente son asociados con el hecho textual. En este estudio de casos, la tasa cdigo de tipo de plan y su descifran puede ser tratado como atributos de movimiento hacia arriba en la mesa de dimensin de plan de tasa. El equipo gast algn tiempo discutiendo la relacin entre la lnea de saque y el cliente, el agente comercial, y evala dimensiones de plan. Desde que hay un solo cliente, un agente comercial, y el plan de tasa se asoci con un nmero de la lnea de saque, las dimensiones tericamente pudieron estar derrumbadas y pude modelar como attrib-utes de la lnea de saque. Sin embargo, colapsar las dimensiones resultaba en un dibujo tcnico con simplemente dos dimensiones (la fecha de la cuenta y el servicio le aplican delineador a). Adems, la dimensin de la lnea de saque ya tiene millones de filas en ella y crece rpidamente. Al fin, optamos para
Trate al cliente, el agente comercial, y plan de tasa como minidimensiones de la lnea de saque, como describimos en Captulo 6. Echamos de ver que las llaves vicarias estn usadas poco consistentemente a todo lo largo del diseo. Muchas de las Tablas de dimensin del borrador usan identificadores operacionales o llaves del sistema como llaves primarias. Alentamos al equipo a implementar claves vicarias para toda la dimensin llaves primarias y mesa de hecho llaves extranjeras. El diseo original estaba plagado de mandos de operacin e identificadores. En gen-eral, sumando nombres descriptivos har los datos ms legibles para los usuarios comerciales. Estando requeridos por el negocio, los cdigos operacionales pueden continuar acompaando los descriptores como atributos de dimensin, pero no deberan ser la dimensin llaves primarias. Finalmente, vemos que hay un ao para fechar hecho almacenado en la mesa de hecho. Mientras el equipo sinti que esto le permitira a los usuarios reportar el ao para fechar resuelve ms eas-ily, en realidad, el ao para fechar hechos puede ser confuso y propenso para el error. Optamos por cambiar de direccin el ao para fechar hecho. En lugar de eso, los usuarios pueden hacer clculos el ao para fechar cantidades al vuelo usando una restriccin en el ao en la dimensin de fecha o palanqueando las capacidades de la herramienta de acceso de datos. Luego de un da agobiante, nuestra revisin inicial del diseo es completa. Por supuesto, all es ms molido para cubrir, incluyendo el manejo de cambios a los atributos de dimen-sion. Mientras tanto, todo el mundo en el equipo est de acuerdo ese el diseo modernizado, ilustr en Figura 10.3, es una vasta mejora. Consideramos que hemos ganado nuestro la paga de primera semana en nuestro empleador nuevo.
La Dimensin del Cliente El cliente el Nombre del Cliente de la Llave Customer Idaho (la Llave Natural) (PK) El Cliente de la Ciudad del Cliente el ZIP Estatal del Cliente La fecha de Servicio 1 La Puntuacin Original de Crdito de la Autorizacin ms atributos La Dimensin del Agente Comercial Sales Rep Key (PK) El Nombre del Agente Comercial de Nmero del Agente Comercial (la Llave Natural) La organizacin de ventas de la organizacin de ventas Idaho Name Sales Channel Idaho La Ventas Canalizan Nombre Facturando Hecho La tasa de la Llave del Agente Comercial de la Llave de la Lnea de Saque de la Llave del Cliente Bill Date Key (FK) (FK) (FK) (FK) la Llave de Plan (FK) El nmero Bill Number (DD) de Llamadas El Nmero de Minutos Totales El Nmero de Minutos de Vagabundeo El Nmero de Minutos de Gran Distancia Mensualmente Repare Carga Vagando Por Carga El Cargo de Gran Distancia Impuestos El Cargo Regulador Guillermo Feche Dimensin Bill Date Key (PK) Envele la Factura a Date Guillermo Salga en Citas el Ao ms atributos La Dimensin de la Lnea de Saque La llave de la lnea de saque (PK) El Cdigo De rea de la Lnea de Saque de Nmero de la Lnea de Saque (la Llave Natural) El Cdigo De rea de la Lnea de Saque y el Prefijo El Prefijo de la Lnea de Saque
La Fecha de Activacin de la Lnea de Saque La Tasa la Dimensin de Plan La tasa la Llave de Plan (PK) La Tasa la Tasa de Cdigo de Plan (la Llave Natural) la Abreviatura de Plan La Tasa la Descripcin de Plan La Tasa el Cdigo de Tipo de Plan La Tasa la Descripcin de Tipo de Plan
Creo que 10.3 Schema despus del diseo repasan.
La Dimensin Geogrfica de la Posicin Cambiemos de velocidad y supongamos que ahora trabajamos pues una compaa telefnica con lneas terrestres empat para una posicin fsica especfica. En general, la industria de telecommu-nications tiene una nocin muy bien desarrollada de posicin. Lo mismo podra decirse para la industria de servicios pblicos. Muchas de sus dimensiones contienen una posicin geogrfica precisa como parte del set de atributo. La posicin puede resolverse para una calle fsica, la ciudad, estatal, y el cdigo postal o aun para una latitud especfica y lon-gitude. Usando nuestra tcnica de caracterizacin de papeles de dimensin, imaginamos construir una sola mesa maestra de la posicin donde los datos es estndar una vez y entonces reutilizado. La mesa de la posicin podra ser del inventario de la lnea de saque de nmero de telfono, de equip-ment de inventario, de la red de inventario (incluir polos y el interruptor boxea), de bienes races, posicin de servicio, posicin de despacho, derecho de paso, y aun entidades del tomer de cobres. Cada fila en la mesa maestra de la posicin es un punto especfico en espacio que se remanga para cada agrupamiento geogrfico concebible, como trechos de censo y condados. Una posicin podra reinvertir para group-ings geogrfico nico mltiple simultneamente.
El Arbotante de la Posicin La posicin ms naturalmente es considerada como un componente de una dimensin, no como una dimensin auto sostenible. El uso de un papel incrustado, como la posicin, en una coleccin variada de dimensiones mayores inconexas es uno de la minora coloca donde soportamos arbotantes del snowflaked. Recomendamos a crear una juntura de cada uno de las Tablas primarias de dimensin que necesitan describir posicin para un clon de la mesa de subdimensin de la posicin. Los asuntos en clones de la posicin que crea son exactamente igual como los que describimos en Captulo 5 para crear dimensiones de caracterizacin de papeles de fecha. Necesitamos separar puntos de vista para cada uso de la mesa de la posicin, teniendo el cuidado de crear nombres distinguibles de la columna. Una ventaja posible de este acercamiento es que si ms
tarde embellecemos las dimensiones geogrficas con la informacin de censo o demogrfica, hacemos eso en un lugar, sin tocar todas las dimensiones primarias que incluyen un descrip-tion de la posicin. Por otra parte, no hemos ganado mucho con este acercamiento si hay poco traslapo entre las posiciones geogrficas empotradas en dimensiones diversas. En esta situacin depositaramos un precio de funcin para consoli-date todas las direcciones dispares en una sola dimensin. Asimismo, deberamos revisar con nuestro sistema de gestin de base de datos para determinar su treat-ment (y la pena asociada, si aplicable) de la construccin de vista. Finalmente, necesitamos permanecer canalizados a nuestros dos principios controlantes del diseo: La facilidad de uso y la funcin.
El Apalancamiento Geogrfico Sistemas De Informacin Mientras estamos sobre el tema de dimensiones de la posicin, muy pocos almacenes convencionales de datos actualmente aprovechan bien sus datos con un acercamiento conducido en mapa para la visualizacin y la presentacin. Los datos que el almacn puede aprovecharse de herramientas geogrficas interesantes de sistema de informacin (GIS) entregar el informa-tion y que entendimientos profundos contuvieron espacialmente orientaron datos de la direccin o de la ruta. Esto en verdad puede promover realces del diseo y extensiones para incluir attrib-utes que habilitan anlisis ms sustancioso de nuestros datos del almacn por medio de una capacidad GIS. Usando herramientas GIS, eficazmente podemos explotar las direcciones de millones que ya almacenamos. Podemos invocar herramientas grficas nuevas de presentacin que nos dejan ver patrones de dos dimensiones en un mapa que simplemente no puede ser detectado en hojas contables y los informes convencionales. Adems, podemos adjuntar algunos verbos nuevos a nuestras existentes bases de datos que nos dejan preguntar espacialmente preguntas habilitadas, como Descubrimiento todas las lneas de saque O los interruptores que estn dentro o cercano un grupo de condados, con fuera de modificar los datos subyacentes. El proceso para integrar los datos del almacn con una capacidad GIS variar a merced de cul herramienta GIS es usada. Esencialmente, en la orden para que el GIS interprete direcciones callejeras comunes, primero estandariza el informa-tion crudo de la direccin de la dimensin de la posicin en una forma analizada gramaticalmente. Geocoder de la herramienta GIS entonces trata de cotejar las direcciones analizadas gramaticalmente con una estndar callejera base de datos de red de puntos geogrficos. Si todo va bien, usted recupera un set de objetos de la posicin que pueden ser representados grficamente visualmente. En otros casos que usted puede elegir fsicamente alterar y poblar la dimensin subyacente de la posicin con geospecific attrib utes como puntos, le aplica delineador, y los polgonos. Usted tambin puede querer considerar las capacidades espaciales que se implement dentro de algunos DBMSs.
Si usted es un profesional GIS sedente en parte superior de montculos de datos del geospatial, este acercamiento no es probablemente para usted; Usted probablemente necesita acostumbrar uno se inyecta droga en la vena solu-tion GIS en lugar de eso. Sin embargo, si usted es un texto y gerente del almacn de datos de nmeros ya almacenando millones de direcciones y otros atributos de posiciones fsicas, entonces considera esta tcnica para escoge la fruta que ahorca punto bajo que nuestro col-league GIS generosamente ha provisto sin modificar sus datos existentes almacenan aplicaciones o arquitectura de datos.
Resumen Este captulo provey la oportunidad para transmitir una revisin del diseo usando un estudio de casos de ejemplo. Provemos una lista del lavandero de desperfectos comunes del diseo para
El explorador para al realizar una revisin. Le alentamos a usar esta lista del lavandero para revisar sus dibujos tcnicos del borrador en busca de mejoras potenciales. Tambin discutimos la posicin geogrfica como un arbotante permisible si es usada repetidamente en diseos dimensionales. Finalmente, sugerimos que oportunidades fomenten efecto de palanca esta informacin geogrfica a travs del uso de una herramienta GIS.
Transporte El carbono HAPTE R11
Los oyages ocurren cada vez que una persona o la cosa viaja de un punto para otro, quiz con paradas en el medio. Obviamente, esto se aplica directamente a organiza-tions involucrado en la industria de viaje. Los expedidores, as como tambin las internas funciones logsticas, tambin se relacionarn con el debate, como empaquetar servicios a domicilio y agencias de renta de carros. Algo inesperadamente, muchas de las caractersticas en el dibujo tcnico de este captulo son tambin aplicables a anlisis de la ruta de la red de telecomunicaciones. Una red telefnica puede ser considerada como un mapa de voy-age posible que una llamada hace entre el origen y que telfono del destino numera. En este captulo le restaremos fuerza a una aerolnea estudio de casos frecuente del aviador para explorar viajes y rutas porque muchos lectores estn familiarizados con (quiz demasiado familiar) la materia. El estudio de casos se presta a un debate de Tablas mltiples de hecho en las granularidades diferentes. Tambin nos explayaremos sobre varios conceptos, como caracterizacin de papeles de dimensin y fecha adicional y sideraciones de contra de dimensin de tiempo. Como siempre, la audiencia pretendida para este captulo no debera ser lim-ited para las industrias simplemente listadas.
el hecho pospone en niveles diferentes de granularidad combinando dimensiones de caracterizaciones de papeles en una superdimensin en ciertas situaciones las dimensiones especficas en pas de fecha el tiempo de da como un hecho versus dimensin las fechas y las veces en series mltiples cronometran zonas
229
La Aerolnea el Estudio de Casos Frecuente del Aviador En este caso el departamento de ventas de la aerolnea quiere analizar la actividad de vuelo de cada miembro de su programa frecuente del aviador. El departamento es interesado en ver qu vuelos los aviadores asiduos de la compaa toman, cul cepilla que vuelan, qu la base de tarifa que pagan, cada cunto mejoran, cmo ganan y redimen sus millas frecuentes del aviador, ya sea se originan de promociones especiales de tarifa, cunto tiempo sus estadas expresas son, y qu proporcin de estos aviadores asiduos tiene titanio, platino, oro, o estatus de aluminio. Como siempre, penetramos a fuerza de trabajo el proceso de cuatro pasos para abordar el diseo de este dibujo tcnico frecuente del aviador. Para este estudio de casos, el proceso comercial sera actividad real de vuelo. No estamos enfocando la atencin en reservacin o etiquetando datos de actividad que no resultaron en un aviador asiduo abordando un avin. Los datos almacenan pareja le har frente a esas otras procedencias de datos en subsiguientes fases.
Las Granularidades Mltiples de la Mesa de Hecho En lo que se refiere al grano, encontramos una situacin en este caso donde se nos propone niveles potenciales mltiples de granularidad de la mesa de hecho. Cada uno de estos niveles de granularidad tienen mtrica diferente asociada con a ellos. En el nivel ms granular, la aerolnea capta datos en el nivel de la pierna. La pierna representa una aeronave levantando vuelo en un aeropuerto y aterrizando en otro sin cualquier paradas intermedias. La capacidad planificando y analistas que ponen en agenda vuelo siguen con mucho inters este nivel discreto de informacin porque pueden mirar el nmero de asientos para calcular factores de carga por pierna. Tambin podemos incluir hechos estimando la duracin de vuelo de la pierna as como tambin el nmero de minutos tarde en la partida y la llegada. Quiz hay aun una dimensin para fcilmente identificar sobre las llegadas de tiempo. El siguiente nivel de granularidad concuerda con un segmento. En este caso tenemos a la vista la porcin de un viaje en una sola aeronave. Los segmentos
pueden tener uno o ms piernas se asociaron con ellos. Si usted quita un vuelo de San Francisco a Minneapolis con una parada en Denver pero ninguna aeronave cambie, usted ha hecho volar un segmento (SFO-MSP) pero dos piernas (SFO-DEN y DEN-MSP). Inversamente, si el vuelo volase sin escalas de San Francisco para Minneapolis, usted habra hecho volar un segmento as como tambin una pierna. El segmento representa el rubro contable en un cupn del boleto de la aerolnea; La renta y el kilometraje acreditan es generado en el nivel de seg-ment. Despus, podemos analizar actividad de vuelo por el viaje. El viaje provee un pic-ture preciso de demanda del cliente. En nuestro anterior ejemplo, suponen que los vuelos de San Francisco para Minneapolis requirieron que el aviador cambie aeronave en Denver. Adentro
Este caso que el viaje de San Francisco para Minneapolis conllevara dos seg ments correspondiente a la dos aeronave consisti en. En realidad, el pasajero acaba de pedir ir de San Francisco a Minneapolis; El hecho que l o ella necesit detener en Denver fue meramente una maldad necesaria pero ciertamente no fue pedido. Por esta razn, las ventas y los analistas mercadotcnicos estn interesados en datos que se viajan a travs de a ras. Finalmente, la aerolnea recolecta datos en ayuda del itinerario, lo cual equivale al boleto entero de la aerolnea o nmero de afirmacin de reservacin. Los datos que el equipo del almacn y los diligenciadores deciden empezar en el grano que se segmenta a ras para el que satisfacer la necesidad mejoraron anlisis frecuente del aviador. Esto representa el nivel mnimo de datos con mtrica significativa para el departamento de mar-keting. Los datos almacenan pareja inevitablemente abordar los datos ms nivelados en la pierna granulares para los proyectistas de capacidad y los planificadores de vuelo en algn punto futuro. Las dimensiones que se conforma construidas durante este primer cer-tainly de iteracin sern apalancadas en aquel entonces. Habr una fila en la mesa de hecho pues cada tiquete de abordaje efectu cobros de aviadores asiduos. La dimensionalidad asociada con esta informacin es muy extensiva, tan ilustrada en Figura 11.1. Si en lugar de eso habamos escogido el grano para ser el viaje como un acontecimiento del segmento mltiple, todos los detalles especficos estimando la aeronave, base de tarifa, la clase, y otras circunstancias de cada vuelo se habran suprimido. Vemos que el dibujo tcnico usa la tcnica de caracterizacin de papeles extensamente. La fecha mltiple, dimensiones de tiempo, y del aeropuerto enlace para los puntos de vista de una sola fecha subyacente de reconocimiento mdico, mesa de dimensin del aeropuerto de tiempo, y, respectivamente, como intercambiamos opiniones originalmente en Captulo 5.
La dimensin de fecha (los puntos de vista para 2 papeles)
Frecuente Dimensin del Aviador Dimensin Frecuente de Vuelo de Dimensin del Perfil del Aviador Clasifique Dimensin La Ventas Canalizan Dimensin El Hecho Que Se Segmenta A Ras de Actividad de Vuelo La llave programada (FK) de Fecha de Partida Program Clave del Aviador de la Llave de Tiempo de Partida de la Llave de Fecha de Partida de la Llave de Tiempo de Partida Actual Actual Frequent (FK) (FK) (FK) (FK) Frecuente Llave de Vuelo de la Llave del Aeropuerto de Destino del Segmento de la Llave del Aeropuerto de Origen del Segmento de la Llave del Perfil del Aviador (FK) (FK) (FK) (FK) La llave de Clase de la Llave de la aeronave (FK) (FK) La base de tarifa el Nmero del Boleto de Nmero del Itinerario de la Llave de la Llave Sales Channel (DD) (DD) (FK) (FK) La renta del Segmento de la Gruesa de Nmero de Secuencia del segmento (DD) Segmente Millas Millas a las Que Se Hizo Volar del Segmento Duracin Devengada de Vuelo del Segmento El Nmero de Minutos Tarde en la Partida El Nmero de Minutos Tarde en la Llegada El Nmero Neto de Minutos Tarde
El Tiempo de Dimensin de Da (La vista para 2 papeles)
La Dimensin del Aeropuerto (Los puntos de vista para 2 papeles)
La Dimensin de la Aeronave
La Dimensin de Base de Tarifa
Figura de dibujo tcnico de actividad de vuelo de 11.1 Iniciales de que se segmenta a ras.
La dimensin frecuente del aviador es una dimensin del cliente de variedad de huerto con todos los atributos captados acerca de nuestros aviadores ms valiosos. Interesantemente, en este caso los aviadores asiduos estn motivados para ayudar usted mantiene esta dimensin exactamente porque quieren asegurar que reciben crdito apropiado de kilometraje. Para una aerolnea grande, esta dimensin tendra decenas de millones de filas en ella. El mercadeo quiere analizar actividad por hilera frecuente del aviador, lo cual puede cambiar durante el curso de un ao. Adems, aprendimos durante el proceso de requisitos que los usuarios estn interesados en cortar en rodajas y jugar a los dados basado en los aeropuertos anfitriones de los aviadores y ya sea le pertenecen al club del aeropuerto de la aerolnea. Por consiguiente, optamos por crear un minidimen-sion frecuente separado del perfil del aviador, como discutimos en Captulo 6, con una fila para cada combinacin nica de hilera frecuente de la elite del aviador, aeropuerto anfitrin, y estatus de la asociacin del club. La dimensin de vuelo contiene informacin acerca de cada vuelo, como lo artesanal utilizado. Aunque hay un origen especfico y destino se asociaron con cada vuelo, anunciamos en voz alta estas dimensiones del aeropuerto cruciales separadamente para simplificar la vista del usuario de los datos y hacer acceso ms eficiente. La clase de servicio al que se hizo volar describe si el pasajero se sent en vagn de pasajeros, busi-ness, o primera clase. La dimensin de base de tarifa describe los trminos rodeando la tarifa. Identificara si es una tarifa completa, una tarifa irrestricta, una tarifa de compra adelantada de 21 das con penas de cambio y de cancelacin, o una tarifa de 10 por ciento de feriado debido a una promocin especial disponible para boletos comprados en el sitio Web de la compaa durante un dado lapso de tiempo. En este estudio de casos optamos por no separar la nocin de promocin de base de tarifa. Despus de entrevistar a los usuarios comerciales en la aerolnea, concluimos que la base de tarifa y la promocin estn inseparablemente vinculadas y que no tiene sentido para separarlos en los datos. La dimensin del canal de ventas identifica cmo fue el boleto comprado, ya sea a travs de una agencia de viajes, en seguida del nmero de telfono sin costo de conexin de la aerolnea o boletera de la ciudad, del sitio Web de la aerolnea, o por medio de otro proveedor de ser-vice de viaje de la Internet. Adems, varios nmeros
operacionales son asociados con los datos de actividad de vuelo, incluyendo el nmero del itinerario, el nmero del boleto, y el nmero de secuencia del segmento. Los hechos captados en el segmento nivelado de granularidad incluyen la renta vulgar de seg-ment, segmentan millas a las que se hizo volar, y millas del segmento otorgadas (en esos casos donde un nmero mnimo de millas es otorgado sin tener en cuenta la distancia de vuelo). Para monitorear niveles de servicio al cliente, tambin podramos incluir tales hechos como los minutos tarde en la partida y la llegada, lo cual estara resumido en el caso de un segmento de la multipierna.
El Eslabonamiento Se Segmenta en los Viajes A pesar del armazn dimensional energtico acabamos de disear, somos incapaces fcilmente contestar una de las preguntas ms importantes acerca de nuestro fly-ers frecuente, a saber, dnde marchan ellos? La cantidad muy pequea del segmento enmascara la naturaleza cierta del viaje. Si vamos a traer todos los segmentos del viaje de la aerolnea y los ponemos en secuencia por nmero del segmento, frisa todava imposible discernir el principio de viaje y partes finales. La mayora de itinerarios completos empiezan y cesan en el mismo aeropuerto. Si una parada tardada fuera utilizada como un criterio para un destino significativo de viaje, requerira extensivo y el procesamiento tramposo cada vez que probamos para resumir un nmero de viajes por las paradas significativas. La respuesta es introducir dos dimensiones de caracterizaciones de papeles del aeropuerto ms: El destino de viaje de ori-gin y de viaje, al mantener el grano en el nivel del segmento de vuelo. Estos estn resueltos durante la extraccin de datos mirando en el boleto para cualquier parada de ms que cuatro horas, lo cual es la definicin oficial de la aerolnea de una parada temporal. A la apariencia realzada del dibujo tcnico le gusta la Figura 11.2. Necesitaramos para exer-cise alguna cautela al resumir datos por el viaje en este dibujo tcnico. Algunos de las dimensiones, como la base de tarifa o la clase de servicio al que se hizo volar, no tienen aplicacin en el nivel de viaje. Por otra parte, puede ser til ver cmo incluyeron muchos viajes de San Francisco para Minneapolis una tarifa irrestricta en un segmento.
Frecuente Dimensin del Aviador Frecuente Dimensin del Perfil del Aviador La Dimensin de Vuelo Clasifique Dimensin La Ventas Canalizan Dimensin El Hecho Que Se Segmenta A Ras de Actividad de Vuelo La llave programada (FK) de Fecha de Partida Program Clave del Aviador de la Llave de Tiempo de Partida de la Llave de Fecha de Partida de la Llave de Tiempo de Partida Actual Actual Frequent (FK) (FK) (FK) (FK) Frecuente Llave del Aeropuerto de Origen de Viaje de la Llave del Aeropuerto de Destino del Segmento de la Llave del Aeropuerto de Origen del Segmento de la Llave del Perfil del Aviador (FK) (FK) (FK) (FK) El viaje la Llave de Vuelo Destination Airport Key (FK) (FK) La llave de Clase de la Llave de la aeronave (FK) (FK) La base de tarifa el Nmero del Boleto de Nmero del Itinerario de la Llave de la Llave Sales Channel (DD) (DD) (FK) (FK) La renta del Segmento de la Gruesa de Nmero de Secuencia del segmento (DD) Segmente Millas Millas a las Que Se Hizo Volar del Segmento Duracin Devengada de Vuelo del Segmento El Nmero de Minutos Tarde en la Partida El Nmero de Minutos Tarde en la Llegada El Nmero Neto de Minutos Tarde
El Tiempo de Dimensin de Da (La vista para 2 papeles)
La Dimensin del Aeropuerto (Los puntos de vista para 4 papeles)
La Dimensin de la Aeronave La Dimensin de Base de Tarifa
Figura 11.2 el dibujo tcnico que se viaja a travs de a ras de actividad de vuelo.
Adems de conectar segmentos en viajes como Figura 11.2 ilustra, si los usuarios comerciales estn todo el tiempo mirando informacin en el nivel de viaje, en vez de por seg-ment, podramos estar tentados de crear una mesa de hecho del agregado en el grano de viaje. Algunos de las anteriores dimensiones intercambiaron opiniones, como la clase de servicio, la base de tarifa, y el vuelo, obviamente no seran aplicables. Los hechos incluiran tal mtrica como el ingreso bruto de viaje y los hechos adicionales que aparecera slo en este com-plementary viaja a travs de mesa sumaria, como el nmero de segmentos en el viaje. Sin embargo, slo nos tomaramos el trabajo de crear tal mesa del agregado si hubo asuntos de funcin obvia o de usabilidad cuando destinamos la mesa que se segmenta a ras como la base para enrollar los mismos informes. Si un viaje tpico consistiese en tres segmentos, en ese entonces apenas podramos ver uno improve-ment de funcin de tres veces con tal mesa del agregado, querer decir que no puede valer la molestia.
Las Extensiones para Otras Industrias Utilizar el estudio de casos frecuente del aviador para ilustrar un dibujo tcnico de viaje hace a intu itive sospechar porque la mayor parte de nosotros hemos abordado un avin a la vez u otro. Brevemente trataremos superficialmente varias otras variaciones sobre este tema.
El Expedidor del Cargamento El dibujo tcnico para un expedidor del cargamento se parece realmente mucho a los dibujos tcnicos del aviador frecuentes simplemente desarrollados. Supongo que una compaa naviera transocenica transporta mercanca a granel en envases de extranjero para puertos domesticados. Los artculos en los envases se envian de un expedidor original para un consignador de cierre. El viaje puede tener paradas de mul-tiple en puertos intermedios. Es posible que los envases pueden ser de cargas feriada de un barco para otro en un puerto. Asimismo, es posible que uno o ms de las piernas pueden estar al lado de camin en vez de barco. Como ilustrado en Figura 11.3, el grano de la mesa de hecho es el envase en un nmero de conocimiento de embarque spe cific en una pierna particular de su viaje.
La dimensin de modo del barco identifica al tipo de compaa naviera y vasija especfica. La dimensin del artculo contiene una descripcin de los artculos en un envase. La dimensin del envase describe el tamao del envase y ya sea requiere refrigeracin o poder elctrico. La dimensin del artculo describe un tipo de artculo en el envase. Casi cualquier cosa que puede enviarse puede estar descrito por artculo armonizado codifica, cul es un tipo de dimensin formada en contra maestra acostumbr por agencias, incluyendo a U.S. Customs. El consignador,
La Dimensin del Artculo de Dimensin del Envase de Dimensin de Modo del Barco Enviando Hecho de Transporte La llave del Puerto de Origen de la Pierna de la Llave del Puerto del Destino de Viaje de la Llave del Puerto de Origen de Viaje de la Llave de Fecha de Partida de la Pierna de la Llave de Fecha de Partida de viaje (FK) (FK) (FK) (FK) (FK) El puerto del Destino de la pierna la Llave del Remitente de la Llave del Artculo de la Llave del Envase de la Llave de la Llave Ship Mode (FK) (FK) (FK) (FK) (FK) El transportador extranjero la Llave del Expedidor de la Llave del Consolidador de la Llave Foreign (FK) (FK) (FK) La llave domesticada (FK) del Consignatario de la Llave del Transportador del Domstico de la Llave del Consolidador (FK) (FK) La Pierna de Retribucin de la Pierna Tarifa Millas de la Pierna
Ponga A Babor Dimensin (La vista para 4 papeles)
La Dimensin Comercial de Entidad (Los puntos de vista para 7 papeles)
Figura 11.3 el dibujo tcnico del Expedidor.
El transportador extranjero, el consolidador extranjero, el expedidor, el consolidador domstico, el transportador domesticado, y el consignatario son todos los papeles jugados por una dimensin comercial maestra de entidad que contiene todas las posibles fiestas comerciales asociadas con un viaje. El nmero de conocimiento de embarque es una dimensin degenerada. Suponemos que las retribuciones y las tarifas son aplicables para la pierna individual del viaje. Los dibujos tcnicos navieros de transporte como ste caractersticamente tienen un num-be grande de dimensiones. Cuando todas las fiestas para el viaje se han agregado, el diseo puede hincharse para 15 o puede emparejar 20 dimensiones. Los Servicios de Viaje Si trabajamos para un viaje repara a la compaa, podemos visualizar complementar el dibujo tcnico de actividad de vuelo del cliente con Tablas de hecho para rastrear estadas asociadas del hotel y uso del auto de alquiler. Estos dibujos tcnicos compartiran varios dimen-sions comn, como la fecha, el cliente, y el nmero del itinerario, junto con boleto y nmero del segmento, tan aplicable, permitir hotel se queda y rentas de carros para ser leaved correctamente en un viaje de la aerolnea. Pues el hotel se queda, el grano de la mesa de hecho es la estada entera, como ilustrado en Figura 11.4. El grano de una mesa similar de hecho de renta de carros sera el episodio de alquiler entero. Por supuesto, si construysemos una mesa de hecho para una cadena del hotel en vez de una compaa de servicios de viaje, el dibujo tcnico sera bastante ms robusto porque sabramos mucho ms acerca de las caractersticas de prop-erty del hotel, el uso de servicios, y los asociados cargos detallados del invitado.
La Dimensin de Fecha (Los puntos de vista para 3 papeles) la Dimensin del Hotel El Viaje Repara Hecho de Estada del Hotel La fecha de Fecha de la Llave de Llegada (FK) de Fecha de la Llave de Partida (FK) de Llave del Cliente de la Llave de Reservacin (FK) (FK) La llave del hotel (FK) El nmero de Nmero del Segmento de Nmero del Boleto de Nmero del Itinerario Sales Channel Key (DD) (DD) (DD) (FK) de Dlar de la Comida de Cargo del Dlar del Cuarto de Noches Carga a la Cuenta Cargo Telefnico de Impuesto de Cargo Miscelneo de Cargo del Dlar
La Dimensin del Cliente La Ventas Canalizan Dimensin
Creo que 11.4 Viaje repare dibujo tcnico de estada del hotel.
Combinando En Trozos Pequeos Dimensiones en un Superdimension
Dijimos previamente que si uno muchos para muchos la relacin existe entre dos grupos de atributos de dimensin, en ese entonces deberan ser modelado como dimensiones separadas con llaves extranjeras separadas en la mesa de hecho. Algunas veces, sin embargo, encontraremos una situacin donde estas dimensiones pueden estar combinadas en una sola superdimensin en vez de tratarlos como dos dimensiones separadas con llaves de dos separatas de extranjero en la mesa de hecho. La Clase de Servicio La Figura 11.1 el dibujo tcnico en borrador incluy la clase de servicio dimensin a la que se hizo volar. El mugido Fol nuestro primer punto de inspeccin del diseo con el mundo de los negocios, nos enteramos de que los usuarios comerciales quieren analizar la clase de servicio comprado, as como tambin la clase a la que se hizo volar. Desafortunadamente, somos incapaces de fuente fidedigna determinar la clase de ser-vice en verdad usado de la base original de tarifa porque el cliente puede hacer un programa mejorado de ltimo momento. Adems, los usuarios comerciales quieren fcilmente filtrar y escriben una crnica de actividad basada en ya sea un programa mejorado o descenso ocurrido. Nuestra reaccin inicial es incluir una segunda dimensin de caracterizacin de papeles y llave extranjera en la mesa de hecho soportar acceso para ambos la clase comprada y a la que se hizo volar de servicio, junto con una tercera llave extranjera para el indicador de programa mejorado. En esta situacin, cmo alguna vez, slo tres filas en cada mesa de dimensin de clase para indicar primero, comercial, y las clases del vagn de pasajeros. Asimismo, la dimensin del indicador de programa mejorado tambin tendra simplemente tres filas en ella, correspondiente a programa mejorado, se desmejoran, o ningn cambio de clase. Desde que las cuentas de la fila son tan pequeas, elegimos en lugar de eso combinar las dimensiones en una sola clase de dimensin de servicio, tan ilustradas en Figura 11.5.
La clase de Comprado Clasifique La Llave de La Clase La Clase a Hecho Volar Cambio Servicio Comprada la Que Se El Grupo de Indicador Hizo Volar Clase
1 El vagn de pasajeros El vagn de El Vagn De Pasajeros de Ningn Cambio de Clase Vagn de Pasajeros Comercial En Vagn De Actualice Pasajeros 3 4 El vagn de pasajeros Primero Negocio El vagn Que Se Entrena Primero Actualice de El Comercial Vagn de Pendiente abajo Pasajeros Comercial En Negocio Primer En Negocio Ningn Cambio de Clase Actualice pasajeros 2 El vagn de pasajeros Negocio
pasajeros 5 6 Negocio Negocio Negocio Primero
El vagn de El Primer Vagn Pendiente abajo pasajeros de Pasajeros 8 Primero Negocio Comercial A Pendiente abajo First 9 Primero Primero Primer A First Ningn Cambio de Clase Creo 11.5 que las filas De Muestra de la clase combinada dimensionan.
Primero
El producto cartesiano de las dimensiones separadas de clase slo resulta en una mesa de dimensin (tres clasifican filas compradas, tres clasifican filas a las que se hizo volar) de nueve filas. Tambin tenemos la oportunidad en esta superdimensin para describir la relacin entre las clases compradas y a las que se hizo volar, como el grupo de clase y clase indicador de cambio. En ciertos aspectos, podemos pensar acerca de ste clase combinada de superdimensin de servicio como un tipo de dimensin de trastos viejos, cul introdujimos en Captulo 5.
El Origen y el Destino Asimismo, podemos considerar el pro y el contra de combinar el origen y las dimensiones del aeropuerto de des-tination. En esta situacin los volmenes de datos son ms signif-icant, as es que el origen de caracterizacin de papeles
separado y las dimensiones del destino parecen ms prcticos. Sin embargo, los usuarios pueden necesitar atributos adicionales que dependen de la combinacin de origen y destino. Adems de acceder al charac-teristics de cada aeropuerto, los usuarios comerciales tambin quieren analizar los datos de actividad de vuelo por la distancia entre los aeropuertos del par de ciudad, as como tambin el tipo de ciudad hacen pareja (como domstico o transatlntico). Empareje la pregunta aparentemente simple estimando la actividad total entre San Francisco (SFO) y Denver (la GUARIDA), sin tener en cuenta ya sea los vuelos se originaron en SFO o GUARIDA, seran chal-lenging con dimensiones de origen separado y del destino. Seguro, los expertos de lenguaje normalizado de consulta pueden poder contestar la pregunta programticamente, pero qu acerca de lo menos apoderado? Adems, aun si podemos derivar la respuesta correcta, nos falta una etiqueta estndar para esa ruta del par de ciudad. Algunas aplicaciones pueden etiquetar eso SFO-DEN, mientras que los otros pudiesen optar por DEN-SFO, la ciencia ficcin San Fran Denver, Den, etctera. En vez de empotrar etiquetas inconsistentes en cdigo aplicativo, los deberamos meter en una mesa de dimensin a fin de que las etiquetas comunes, estndar pueden ser usadas a todo lo largo de la organizacin. Sera una lstima ir hasta el extremo de crear un almacn de datos y entonces dejara cdigo aplicativo implementar etiquetas inconsistentes de informacin. Los patrocinadores comerciales del almacn de datos no tolerarn eso por mucho tiempo.
El Par de Ciud ad Tecl ee

1
El Par Orig de en La Ciudad Aero Ciudad Nombr puert de e o Origen
Destin Destino o Ciudad Aerop uerto
La distan La Banda de El Tipo cia Distancia del Par (Las de Millas Ciudad )
Menos de 200 millas Domstico
BOS-JFK Olores Boston, corpora Massachuset les desagra dables ocasion ados por sudor el ts
JFK
Nueva York, 191 Nueva York
BOS-JFK JFK
Nueva York, Olores
Boston,
191
Menos de 200 millas Domstico
Nueva York corporales Massachuset desagrada ts bles ocasionad os por el sudor 3 BOS-LG Olores Boston, W corpora Massachuset les desagra dables ocasion ados por sudor 4 BOS-LG LGW W Londres, UK Olores Boston, 3267 3,000 millas para 3,500 Transatlnti co el ts LGW Londres, UK 3267 3,000 millas para 3,500 Transatlnti co
corporales Massachuset desagrada ts bles
ocasionad os por el sudor 5 BOS-NRT Olores Boston, corpora Massachuset les desagra dables ocasion ados por sudor el ts NRT Tokio, Japn 6737 Ms millas que 6,000 Transpacfic o
Creo 11.6 filas De Muestra de la dimensin del par de ciudad (la ruta).
Para satisfacer la necesidad para acceder a atributos adicionales del par de ciudad, tenemos dos opciones. Uno debe meramente aadirle otra dimensin a la mesa de hecho para los descriptores del par de ciudad, incluyendo el nombre del par de ciudad, el tipo del par de ciudad, y la distancia. La otra alternativa, como se muestra en Figura 11.6, es combinar el origen y los atributos del aeropuerto de desti-nation adems de incluir los atributos suplementarios del par de ciudad. En este caso, el nmero de filas en la mesa combinada de dimensin crecer significativamente. Tericamente, la dimensin combinada podra tener tantas filas como el producto cartesiano del origen y los aeropuertos de destino. For-tunately, en la vida autntica el nmero de filas es muy ms pequeo que este lmite terico. Ms a propsito, estamos dispuestos a estar viviendo con este acuerdo intermedio porque la dimensin combinada del par de ciudad refleja la forma que el negocio piensa acerca de los datos. Nos pudimos uso esta misma mesa como una obra teatral de papel para una dimensin del par de ciudad de viaje. Como mencionamos, si los condes reales de la fila prohibiesen una dimensin combinada, en ese entonces podramos continuar usando el origen separado y dimensiones del destino pero incluyendo una tercera dimensin en la mesa de hecho a soportar el attrib-utes del par de ciudad en vez de confiar en la aplicacin de acceso para la lgica del par de ciudad de la combinacin. Adems de los volmenes abrumadores de datos, la otra motivacin para Tablas de dimensin de sepa-rate de manutencin ocurre si otros procesos comerciales requieren las
dimensiones separadas, aunque uno pudiese sostener la opinin que las dimensiones separadas meramente deben conformarse a la superdimensin combinada.
En la mayora de los casos, las dimensiones de caracterizaciones de papeles deberan ser tratadas como separado dimen-sions lgico creado por medio de los puntos de vista en una sola mesa fsica, como hemos visto ms temprano con dimensiones de fecha. Adentro las situaciones espordicas a las que puede tener sentido combinan las dimensiones separadas en una superdimensin, notablemente cuando los volmenes de datos son sumamente pequeas o hay una necesidad para atributos adicionales que dependen de los papeles subyacentes combinados para el contexto y significado.
Ms Consideraciones de Fecha y de Tiempo Del earliest los captulos en este libro que tenemos, discuti la importancia de hav-ing una dimensin poco concisa de fecha, ya sea est en el da individual, la semana, o la granularidad de mes, eso contiene atributos descriptivos a eso de la fecha y las etiquetas privadas para los perodos fiscales y los das de fiesta de trabajo. En esta seccin final introduciremos varias consideraciones adicionales al ocuparnos de la fecha y las dimensiones de tiempo.
Los Calendarios Especficos En Pas Si los datos almacenan necesidades de la empresa multinacional de saques, le debemos generalizar la dimensin estndar de fecha para maniobrar calendarios multinacionales en un nmero indefinido de pases. La dimensin primaria de fecha contiene atributos genricos a eso de la fecha, sin tener en cuenta el pas. Si su negocio multinacional se extiende a lo largo de calendarios gregorianos, hebreos, islmicos, y chinos, en ese entonces incluiramos cuatro sets de das, los meses, y los aos en esta dimensin primaria. Las dimensiones especficas en pas de fecha suplementan la mesa primaria de fecha. La llave para la dimensin suplementaria es la llave primaria de fecha, junto con el nombre del pas. La mesa incluira atributos especficos en pas de fecha, como los nombres de da de fiesta o de estacin, tan ilustrado en Figura 11.7. Este acercamiento es similar al manejo de calendarios fiscales y mltiples de contabilidad, tan descritos en Captulo 7. Podemos adjuntar esta mesa a la dimensin principal del calendario o a la mesa de hecho directamente. Si nosotros proveemos una interfaz que requiere que el usuario especificara un nombre del pas, en ese entonces los atributos del suplemento especfico en pas pueden ser mirados tan lgicamente anexados para la mesa primaria de fecha, dejndole mirar el calendario a travs de los ojos de un solo pas a la vez. Los calendarios especficos en pas pueden ser desordenados para incorporar su derecho. Las cosas se emparejan ms desordenado si necesitamos ocuparnos de los locales das de fiesta que ocurren en los das diferentes en partes diferentes de un pas. Hecho La Dimensin Fecha La fecha de la Llave fecha (PK) El Da de Semana El Nmero de Da Nmero de Semana poca en Nmero de El Arbotante Especfico En Pas de Fecha El pas de la Llave del Pas de la Llave de fecha (PK) (FK) la Bandera de Da de Fiesta de Nombre Civil El Nombre Corts de
La llave de fecha (FK) Ms Hechos Extranjeros de Llaves
de
en de de
Mes de poca en la poca El Nmero de Da en Calendar Month Day Number en Calendar Year Day Number en el Mes Fiscal El Nmero de Da en el Da Fiscal de la Horma de Ao en el Da de la Horma del Indicador de Semana en Indicador de Mes Calendar Week Ending Date El Nmero de Semana Calendario en el Ao Mes De Calendario El nmero de mes de calendario en Cantn del Calendario de Year-Month del Calendario de Ao (YYYY-MM) El Calendario la Ao Civil Cuarto de En Ao de Semestre del Calendario La Semana Fiscal El Nmero Fiscal de Semana en el Ao El Mes Fiscal El Nmero Fiscal de Mes en el Ao El Mes Fiscal de Ao La Cuarta Parte Fiscal El Ao Fiscal Medio Fiscal Cuarto de En Ao
Da de Fiesta la Bandera de Da de Fiesta Religioso el Nombre Religioso de Estacin del Indicador de Da Laboral de Nombre de Da de Fiesta
Fiscal de Ao El fechador de lenguaje normalizado de consulta y ms
Figura 11.7 el arbotante especfico en pas del calendario.
El tiempo de Da como una Dimensin o el Hecho Fuertemente alentamos a los diseadores a separarnos de tiempo de da el dimen-sion de fecha para evitar una explosin en la cuenta de la fila de dimensin de fecha. En tiempo atrs ejemplos hemos ilustrado la hora del da como una mesa de dimensin hecha y derecha con una fila por el discreto lapso de tiempo (por ejemplo, cada segundo o minuto dentro de un perodo de 24 horas). sta es la ruta preferida si necesitamos soportar el movimiento hacia arriba de peri-ods de tiempo en agrupamientos ms resumidos para reportar y el anlisis, como Los intervalos de 15 minutos, las horas, o / la modulacin de fase AM. Tambin podran reflejar agrupamientos de tiempo especficos en negocio, como el perodo de prisa de maana de da laborable para la actividad de vuelo. Si no hay necesidad para arroparse en la cama o filtro sobre el tiempo de grupos de da, en ese entonces tenemos la opcin para tratar tiempo como un hecho numrico simple en lugar de eso. En esta situacin, la hora del da sera expresada como un nmero de minutos o el nmero de segundos desde la medianoche, como se muestra en Figura 11.8.
Salga En Citas y Tiempo en Series Mltiples Husos Horarios Al funcionar en pases mltiples o aun simplemente husos horarios mltiples, somos confrontados con un dilema concirnindole fechas de transaccin y por. Captamos nosotros la fecha y el tiempo referente a la medianoche local en cada huso horario, o expresamos el lapso de tiempo referente a un estndar, como la fecha /tiempo corporativa del centro de operaciones o la Hora del Meridiano de Greenwich (la hora media de Greenwich)? Para completamente cancelar require-ments de usuarios, la respuesta correcta es probablemente ambos. La hora oficial nos deja ver la naturaleza simultnea de transacciones a travs del negocio, mientras que la hora local nos deja comprender oportunidad del momento de transaccin referente a la hora del da. En contra de la creencia popular, hay ms que 24 husos horarios (correspondiente a las 24 horas del da) en el mundo. Por ejemplo, hay un solo huso horario en India,
offset de hora media de Greenwich a las 5.5 o 6.5 horas a merced del tiempo de ao. La situacin se pone aun ms desagradable cuando usted considera el com-plexities de alternacin hacia y desde la hora de verano. Como tal, es unrea-sonable para pensar eso meramente proveyendo un offset en una mesa de hecho puede mantener
El Hecho de Actividad de Vuelo

La Dimensin de Fecha
La fecha de partida la Llave del Aviador de la Llave Frequent (FK) (FK) Ms Tiempo Extranjero de Partida de Dimensiones de Llaves Degenerate de Da Ms Hechos Figura 11.8 la mesa de Hecho con tiempo de da como un hecho.
Frecuente Dimensin del Aviador
El tiempo de da como un hecho
El Hecho de Actividad de Vuelo La dimensin de fecha (jugando 2 papeles) La llave de Fecha de partida (FK) La llave de Fecha de Partida de hora media de Greenwich (FK) Ms Tiempo Extranjero de Partida de Dimensiones de Llaves Degenerate de Da El tiempo de Partida de hora media de Greenwich de Da Ms Hechos Figura 11.9 la fecha /tiempo Localizada e igualada a travs de los husos horarios.
La comparacin a travs de los husos horarios requiere 2 fechas y por de da
El equivalized pasa de moda y cronometra. Asimismo, el offset no puede residir en una mesa de dimensin de tiempo o de babor en aire. El acercamiento recomendable para expresar las fechas y por en husos horarios mltiples deben incluir seprese la fecha y el tiempo de dimensiones de da (o el tiempo de hechos de da, como acaba de intercambiar opiniones) correspondiente a las fechas locales y equivalized, tan mostrado en Figura 11.9. Nos elaboraremos ms adelante en la fecha mltiple y cronometraremos Tablas de dimensin para capturar ambos el absoluto reloj estndar y local en las fechas de la pared y por cuando le discutimos un detallista multinacional de Web en Captulo 14.
Resumen En este captulo fijamos nuestra atencin en el concepto de viajes o las rutas. El expandido estudio de casos enfoc la atencin en una aerolnea ejemplo frecuente del aviador, y brevemente tratamos superficialmente argumentos similares sacados del embarque e industrias de servicios de viaje. Examinamos la situacin en la cual tenemos Tablas mltiples de hecho en las granularidades mltiples con hechos especficos en grano mltiples. Nosotros tambin los dis maldijimos la posibilidad de combinar dimensiones en una mesa unidimensional en los casos donde los libros de la cuenta de la fila son sumamente pequeos o cundo hay atributos adicionales que dependen de las dimensiones combinadas. Otra vez, las dimensiones de com-bining deberan ser miradas como la excepcin en vez de la regla. Empacamos este captulo intercambiando opiniones varias fecha y cronometramos tcnicas de dimensin, incluyendo arbotantes especficos en pas del calendario, el tratamiento de tiempo como un hecho versus una dimensin separada, y el manejo de fechas absolutas de rela-tive y y por.
Educacin El carbono HAPTE R12
tungsteno
El paso de la e en el mundo de una institucin educativa en este captulo. Primero miraremos la tubera del estudiante del solicitante como una foto de atesoramiento. Cuando introdujimos el atesoramiento hecho veteado en foto mesa en Captulo 5, usamos una tubera de cumplimiento de orden para ilustrar el concepto. En este captulo, en vez de observar le manda muvase estados diversos directos antes de la terminacin, la foto de atesoramiento se usa para monitorear a los solicitantes estudiantiles prospectivos como se mueven hitos estndar directos de admisiones. El otro concepto primario discutido en este captulo es la mesa de hecho de factless. Exploraremos varias ilustraciones de estudio de casos sacadas de la educacin fomentar elaborado en estas Tablas especiales de hecho, y discutiremos el anlisis de acontecimientos que no ocurrieron.
el rastreo del solicitante de la admisin como una foto de atesoramiento la mesa de hecho Factless para inscripcin estudiantil y los datos de la gerencia de facilidades el manejo de acontecimientos inexistentes, incluyendo acontecimientos de promocin de la industria por menor
243
El Universitario Estudio de Casos En este captulo que pretenderemos que trabajamos para una universidad, una universidad, u otro tipo de institucin educativa. Tradicionalmente, ha habido menos foco en rev-enue y la ganancia en esta arena, pero con los costos que se incrementan alguna vez y competi tion se asoci con enseanza superior, universidades y las universidades son muy interesadas en atraer la atencin y retener a los estudiantes de altas calidad. De hecho, hay un inters fuerte en entender y mantener una relacin bien ms all de la graduacin. Hay tambin una necesidad dominante para comprender qu nuestro Cu-tomers estudiantil sea aprovisionarse de trminos de cursos cada trmino. Finalmente, le echaremos un vistazo a maximizar el uso de facilidades de utilizacin intensiva de capital de la universidad.
Acumulando Foto para Las admisiones Rastreando En Captulo 5 tratamos la tubera de cumplimiento de orden como una foto de atesoramiento. Tambin describimos el uso de una foto de atesoramiento para rastrear un artculo especfico, excepcionalmente identificados por una novela por entregas o el nmero del lote, como se mueve a travs de la tubera manufacturera y experimental. Requirmonos un momento para acordarnos de que las caractersticas de distin-guishing de una mesa de hecho de la foto de atesoramiento: una sola fila representa la historia completa de algo. tal hecho que la mesa es ms correcta para procesos en seco vividos, como las rdenes y cuentas. las fechas mltiples representan los hitos estndar de la panorama de cada fila. Los sets indefinidos de hechos acumulan las medidas interesantes. cada fila es vuelta a visitar y cambiada cada vez que algo ocurre. ambas llaves extranjeras y hechos medidos pueden cambiar durante lo vuelva a visitar. Podemos visualizar estas mismas caractersticas aplicadas a la tubera estudiantil prospectiva de admisiones. Pues esos que trabajan en otras industrias, hay similitudes obvias para rastrear a personas en busca de empleo como se mueven a
travs del alquiler proceso, y rastrear prospectos de ventas como se convierten en clientes. En el caso de solicitante rastreando, los estudiantes prospectivos progresan a travs de un estndar colocado de obstculos de admisiones o hitos. Se interes en quiz rastrear actividades a eso de las fechas de la llave, como el recibo de puntuaciones preliminares de prueba de admisiones, la informacin pedida (por Web o de otra manera), la informacin enviada, entrevistar visita transmitida del campus, en el sitio, aplicacin recibida, copia recibida, probar puntuaciones recibidas, recomendaciones la revisin admitida por la mayora, primera del paso por admisiones, retrospectivas para la ayuda financiera, la decisin final de admisiones, aceptado
Con lugar, y se enrola. En cualquier punto en el tiempo, las personas en las admisiones y el rea de la gerencia de enrolamiento estn interesados cuntos solicitantes estn en cada palco escnico a punto de suceder. El proceso se parece mucho a un embudo, dnde muchos solicitantes entran en la tubera, excepto mucho menos cantidad de progreso a travs para la fase final. Al personal de admisin tambin le gustara analizar la piscina del solicitante por un varus-ety de caractersticas. El grano de la foto de atesoramiento para rastrear a lifecycle del solicitante es una fila por estudiante prospectivo. Esta granularidad representa el nivel mnimo de detalle captado cuando el prospecto entra en la tubera. A medida que ms la informacin es coleccionada mientras el prospecto progresa hacia aplicacin, la aceptacin, y la admisin, continuamos volviendo a visitar y actualizando el estatus del prospecto en la mesa de hecho fila, como ilustrado en Figura 12.1.
La Dimensin de Decisin de Admisiones La categora de Decisin de Admisiones de Descripcin de Decisin de Admisiones de la Llave de Decisin de admisiones (PK)
La Dimensin del Solicitante El nombre del Solicitante de la Llave del solicitante (PK) La direccin del solicitante Atribuye Puntuacin de Matemticas del Solicitante de la Escuela Secundaria de la Escuela Secundaria del Solicitante GPA Applicant SAT Puntuacin del Solicitante SAT Verbal El Nmero de Crditos Adelantados de Colocacin Gnero La Escuela de Preliminar de Etnicidad de Fecha de Nacimiento El Estudiante Avanzado Preliminar de la Universidad y ms El Hecho de Atesoramiento de la Tubera del Solicitante La informacin preliminar de la Llave de Fecha de Informacin de la Llave de Fecha del Recibo de Puntuacin de Prueba Requested (FK) (FK) Envi Llave de Fecha (FK) La entrevista Transmiti Llave de Fecha (FK) las Puntuaciones de Prueba de la Llave de Fecha de la Copia de la Llave de Fecha de la Aplicacin de la Llave de
Fecha de Visita del Campus Submitted Received (FK) (FK) (FK) En el Sitio la Llave Admitida por la Mayora (FK) de Fecha Las recomendaciones las Admisiones Admitidas por la Mayora de la Llave de Fecha (FK) la Primera Llave de Fecha de Revisin del Paso (FK) Reviewed para Llave de Fecha de Decisin del Solicitante de la Llave de Fecha de Decisin Final de Admisiones de la Llave de Fecha de Ayuda Financiera Received (FK) (FK) (FK) Llave de Fecha (FK) Con Lugar La llave enrolada (FK) del Solicitante de la Llave de Decisin de Admisiones de la Llave de Fecha (FK) (FK) La Informacin Preliminar de Cantidad del Recibo de Puntuacin de Prueba Pidi Informacin de Cantidad Cantidad Expedida La Informacin la Entrevista Expedida A Requested de Atraso Transmiti Cantidad en Aplicacin de Cantidad de Visita del Campus del Sitio Copia Propuesta de Cantidad Cantidad Admitida por la Mayora Pruebe Recomendaciones Admitidas por la Mayora Scores de Cantidad Aplicacin Aplicativa Quantity Admitida por la Mayora de Cantidad Complete Cantidad Primera Admissions Lag Completa A Submitted de Revisin del Paso Reviewed para la Decisin Final A Submitted Financial Aid Quantity Admissions Final Decision Quantity Application la Cantidad de Atraso Accepted La Cantidad de Disminucin El Atraso Aceptado En Decisin Final de / Disminucin Admiti Cantidad La Cantidad Enrolada
Figura 12.1 la tubera Estudiantil del solicitante como una foto de atesoramiento.
Como otras fotos de atesoramiento que hemos discutido, hay las fechas mltiples en la mesa de hecho correspondiente a los hitos estndar de proceso. Queremos analizar el progreso del prospecto por estas fechas para determinar el paso de move-ment por canales privados, y tambin queremos divisar cuellos de botella. ste es espe-cially importante si vemos un atraso significativo involucrando a un candidato que se interes en atraer la atencin. Cada uno de estas fechas son tratadas como un dimen-sion de caracterizacin de papeles, usando llaves vicarias para manipular las fechas desconocidas inevitables cuando primero cargamos la fila. La dimensin del solicitante contiene muchos atributos interesantes acerca de nuestros estudiantes prospectivos. Se los interes en analistas admisiones cortar en rodajas y jugar a los dados estas caractersticas del solicitante por la geografa, credenciales entrantes (el promedio del punto de grado, las admisiones de la universidad las puntuaciones experimentales, los crditos adelantados de colocacin, y la escuela secundaria), gnero, fecha de nacimiento, etnicidad, y preliminar se especializan. Analizar estas caractersticas en etapas diversas de la tubera ayudar per-sonnel de admisiones a ajustar sus estrategias para alentar a ms (o menos) estudiantes a proceder hacia el siguiente marcador de milla.
Como vimos previamente, fotos que acumulan son apropiadas para procesos de breve duracin, como la tubera del solicitante, eso tiene un principio definido y cesa, as como hitos intermedios estndar. Este tipo de mesa de hecho nos deja ver un estatus actualizado y disposicin finalmente final de cada solicitante prospectivo. Podramos incluir un hecho para la probabilidad estimada que el prospecto se convertir en un estudiante. Sumando todas estas probabilidades, veramos una prediccin instantnea del enrolamiento del ao subsiguiente. Otro ejemplo basado en educaciones de una foto de atesoramiento enfoca la atencin en actividades de propuesta de investigacin. Algn usuario que los cuerpos de electores pueden ser interesados en view-ing el lifecycle de una propuesta de concesin de investigacin como eso progresa a travs de la tubera de concesin de propuesta preliminar para conceder aprobacin y otorgar recibo. Esto soportara anlisis del nmero de propuestas sobresalientes en cada etapa de la
tubera por la facultad, departamento, rea de tema de investigacin, o fuente de financiacin de investigacin. Asimismo, podramos ver tasas de xito por las dimensiones diversas. Tener esta informacin en un confidente comn como el almacn de datos permita que eso ser palanqueado ms fcilmente por una poblacin universitaria ms amplia. Las Tablas de Hecho de Factless Hasta ahora hemos diseado Tablas de hecho que han tenido una estructura muy caracterstica. Cada mesa de hecho tpicamente tiene tres para aproximadamente 15 para 20 columnas cruciales, fol mugi a la una para potencialmente varias docena numrico, continuamente apreci, los hechos preferentemente aditivos. Los hechos pueden ser considerados como medidas tomadas en la interseccin de los valores de la llave de dimensin. De esta perspectiva, los hechos son la justificacin para la mesa de hecho, y los valores cruciales son simplemente estructura adminis trative para identificar los hechos.
Hay, sin embargo, un nmero de procesos comerciales cuyo hecho pospone es sim-ilar para esos que hemos estado diseando con una distincin principal: No hay hechos medidos! Llamamos estas Tablas de hecho de factless. En los siguientes ejemplos discutiremos ambos acontecimiento rastreando y las Tablas de hecho de factless de cobertura. Nosotros en breve intro duced la mesa de cobertura de factless en Captulo 2 al discutir venda al por menor la cobertura de promo-tion, as como tambin en Captulo 5 para describir cobertura del territorio del agente comercial.
Los Acontecimientos Estudiantiles de Inscripcin Hay muchas situaciones en las cuales los acontecimientos necesitan grabarse como el simulta-us juntndose de un nmero de entidades dimensionales. Por ejemplo, podemos rastrear inscripciones estudiantiles por el trmino. El grano de la mesa de hecho sera una fila para cada curso registrado por estudiante y el trmino. Como ilustrada en Fig Ure 12.2, la mesa de hecho tiene la siguiente dimensionalidad: Trmino, estudiante avanzado estudiantil, estudiantil y logro, curso, y facultad. En esta panorama nos ocupamos de datos de hecho en el nivel de trmino en vez de al da calendario ms tpico, la semana, o la granularidad de mes. El trmino es el nivel mnimo disponible para los acontecimientos de inscripcin. La dimensin de trmino todava debera conformarse a la dimensin de fecha del calendario. En otras palabras, cada fecha en nuestra dimensin diaria del calendario debera identificar el trmino (por ejemplo, Fall AY2002), el ao acadmico (por ejemplo, AY2002), y la estacin de trmino (por ejemplo, Winter). La columna etiqueta y los valores deben ser idnticos para los atributos comunes hasta ambos las dimensiones del calendario de fecha y de trmino.
La Dimensin de Ao de Trmino El trmino /estacin de Ao Acadmico de Descripcin de Trmino de la Llave de trmino (PK) La Dimensin de Curso El formato de Curso de la Escuela de Curso de Nombre de Curso de la Llave de curso (PK) Las Horas de Crdito de Curso La Dimensin de Facultad La llave de facultad (PK) La facultad el Nombre de Facultad Employee Idaho (la Llave Natural) Los Atributos de la Direccin de Facultad El Tipo de Facultad Los Aos de Facultad de Fecha del Salario del Original de Facultad del Indicador de Tenencia de Facultad de Escuela de Facultad de Servicio El Hecho Estudiantil de Acontecimiento de Inscripcin La llave del Estudiante de la Llave de trmino (FK) (FK) Declar Tono Mayor (FK) La llave de Curso de la Llave de Logro de crdito (FK) (FK) Facultad (FK) La inscripcin Count (siempre = 1)
La Dimensin Estudiantil La llave estudiantil (PK) Los atributos estudiantiles del Estudiante de Idaho (la Llave Natural) Declar Dimensin Principal Declar Tono Mayor (PK) Declar Indicador Major Description Declared Major School Interdisciplinary La Dimensin de Logro de Crdito La descripcin del Nivel de Clase de la Llave de Logro de crdito (PK)
Figura 12.2 acontecimientos Estudiantiles de inscripcin como una mesa de hecho de factless.
La dimensin estudiantil es una versin expandida de la dimensin del solicitante que discutimos en la ltima panorama. Todava queremos retener toda la informacin que acumulamos del proceso aplicativo (por ejemplo, la geografa, las credenciales, y el preliminar se especializan) pero suplemento eso con en informacin del campus, como el estatus de tiempo completo de medio tiempo, la residencia, la participacin en estudiante avanzado de campo y pista, declarado, y la clase derriban estatus (por ejemplo, el estudiante de segundo ao). Como discutimos en Captulo 6, imaginamos tratar algunos de estos atributos como una minidimensin (s) porque las facciones se interes en a todo lo largo de la universidad rastreo se cambia a ellos con el paso del tiempo, especialmente en lo que se refiere al nivel del estudiante avanzado declarado, de clase, y el logro de graduacin. Las personas en gerencia y academia estn con entusiasmo interesadas en progreso acadmico y tasas de retencin por la clase, escuela, depart-ment, y estudiante avanzado. Una mesa de hecho es un lugar razonable para representar el set robusto de muchos para muchas relaciones entre estas dimensiones. Registra la colisin de dimensiones en un punto con el tiempo y el espacio. Esta mesa podra ser puesta en duda contestar un nmero de preguntas interesantes estimando inscripcin para lo offer-ings acadmico de la universidad, como cules estudiantes registraron cules recorre? Cmo muchos estudiantes avanzados declarados que disea toman un curso de finanzas principal apagadas? Cuntos estudiantes se han registrado para los cursos de un dado miembro de la facultad durante los ltimos tres aos? Cuntos estudiantes se han registrado para ms que un curso de un dado miembro de la facultad? La nica peculiaridad en este ejemplo es que no tenemos un hecho numrico vinculado esta informacin de inscripcin. Como tal, analy-Se de esta informacin se basar mayormente en cuentas.
Los acontecimientos a menudo son modelados como una mesa de hecho conteniendo una serie de llaves, cada representando una dimensin participante en ese momento. Las Tablas de acontecimiento a menudo no tienen los hechos numricos obvios se asociaron con ellas y por lo tanto son llamados Tablas de hecho de factless.
El lenguaje normalizado de consulta para representar a los condes en esto los factless el hecho es asimtrico por la ausencia de cualquier hechos. Al contar el nmero de inscripciones para un miembro de fac-ulty, cualquier llave puede ser utilizada como la discusin para la funcin de la CUENTA. Por ejemplo: SELECCIONE FACULTAD, CONDE (TERM_KEY) ... AGRPESE POR LA FACULTAD Esto le da la cuenta simple del nmero de inscripciones estudiantiles por la facultad, sujeto para cualquier restricciones que pueden existir en la clusula WHERE. Una rareza de lenguaje normalizado de consulta es que usted puede contar cualquier llave y todava puede tener la misma respuesta porque usted cuenta el nmero de llaves que vuelan por la averiguacin, no sus valores bien definidos. Necesitaramos usar una CUENTA BIEN DEFINIDA si quisisemos contar las instancias nicas de una llave en vez del nmero de llaves encontradas. La confusin inevitable rodeando la declaracin de lenguaje normalizado de consulta, mientras no un problema semntico serio, causa que algunos diseadores creen un hecho implcito artificial,
Quiz la cuenta designada (a distincin de tonto) de inscripcin, ese es siempre popu lated por el valor 1. Mientras este hecho no le aade ninguna informacin a la mesa de hecho, hace el lenguaje normalizado de consulta ms legible, como: SELECCIONE FACULTAD, SUM (REGISTRATION_COUNT) ... AGRPESE POR LA FACULTAD En este punto la mesa es ya no estrictamente factless, pero las mayoras estaran de acuerdo que el 1 no es nada ms que un artefacto. El lenguaje normalizado de consulta estar un poco ms limpio y ms expresivo con el artefacto de inscripcin. Quiz las herramientas de averiguacin tendr un tiempo ms fcil haciendo la averiguacin de algunos gestos simples del usuario. Ms importante, si construimos una mesa resumida del agregado por encima de esta mesa de hecho, necesitaremos que una columna autntica se arrope en la cama para cuentas significativas de inscripcin del agregado. Si un hecho mensurable sale a la superficie durante el diseo, puede sumarse al dibujo tcnico, suponiendo que est consistente con el grano de inscripciones estudiantiles por el trmino. Por ejemplo, si tenemos la capacidad de rastrear renta de instruccin, horas devengadas de crdito, y califique puntuaciones, las podramos aadir a esta mesa de hecho, pero entonces es ya no una mesa de hecho de factless. La adicin de estos hechos definitivamente permitira ms que interesndole analiza. Por ejemplo, cul es la renta generada por el curso o la facultad? Cul es el grado promedio por la clase por la facultad?
La Cobertura de Utilizacin de Facilidades El segundo tipo de mesa de hecho de factless es la mesa de cobertura. Dibujaremos en un sce-nario tratando con gerencia de facilidad para servir de una ilustracin. Las universidades invierten una tremenda cantidad de capital en sus facilidades y planta fsica. Sera de ayuda comprender cul las facilidades servan qu propsito durante cada hora del da durante cada uno el trmino. Por ejemplo, cules facilidades fue la mayora usada pesadamente? Cul era la tasa promedia de ocupacin de las facilidades como una funcin de tiempo de da? El uso decae significativamente en
Fri-Day cuando nadie quiere ensear (o asiste) clases? Otra vez, la mesa de hecho de factless acude al rescate. En este caso incluiramos una fila en la mesa de hecho para cada facilidad por cada da de dur-ing de bloques de tiempo de cada hora estndar de la semana durante un trmino sin tener en cuenta ya sea la facilidad es usada o no. Hemos ilustrado el dibujo tcnico en Figura 12.3. La dimensin de facilidad incluira que todos los tipos de atributos descriptivos acerca de la facilidad, como el edificio, el tipo de facilidad (por ejemplo, el aula, el laboratorio, o la oficina), elevan al cuadrado metraje, capacidad, y buenas costumbres (por ejemplo, el pizarrn blanco o el proyector incorporado). La dimensin de estatus de utilizacin obviamente incluira un descriptor del texto con valores de Available o Utilized. Entretanto, las organizaciones mltiples pueden estar involucradas en utilizacin de facilidades. Algo semejante sera el caso si un organismo poseyese la facilidad durante un bloque de tiempo, considerando lo mismo o una organizacin diferente fue asignada como el usuario de facilidad.
La Dimensin de Ao de Trmino El Da de Dimensin de Semana El Tiempo de Dimensin de Hora de Da El tiempo de Descripcin de Time-Of-Day de la Llave de Hora de Da (PK) El tiempo de Indicador de / modulacin de fase de Da AM El Tiempo de Parte de Da de Da La Dimensin de Organizacin (Los puntos de vista para 2 papeles) El Hecho de Cobertura de Utilizacin de Facilidad El da de la Llave de Ao de trmino (FK) de Llave de Semana (FK) El tiempo de Llave de Facilidad de la Llave de Hora de Da (FK) (FK) La llave de Organizacin del dueo (FK) Asign Estatus de Utilizacin de la Llave de Organizacin Llave Utilization (FK) (FK) Count (siempre = 1)
La Dimensin de Facilidad La llave de facilidad (PK) La Facilidad de Nombre del Edificio de Facilidad Construyendo Tipo de Facilidad de Nmero del Cuarto de Facilidad de la Direccin El Piso de Facilidad El Metraje del Cuadrado de Facilidad La Capacidad de Facilidad El Indicador Blanco del Pizarrn El indicador del Monitor de la PC y ms
Resuelva utilizacin de 12.3 Facilidades como una mesa de hecho de factless de cobertura. La Dimensin de Estatus de Utilizacin La descripcin de Estatus de Utilizacin de la Llave de Estatus de utilizacin (PK)
Los Acontecimientos Estudiantiles de Asistencia Podemos visualizar un dibujo tcnico similar para rastrear asistencia estudiantil en un curso. En este caso el grano sera una fila para cada estudiante que pasa en medio de la puerta del aula del curso cada da. Esta mesa de hecho de factless compartira un num-be de las mismas dimensiones que discutimos con relacin a los acontecimientos de inscripcin. La diferencia primaria sera que la granularidad est al lado de compaero de cita del calendario en este dibujo tcnico en vez de meramente el trmino. Este modelo dimensional, tan ilustrado en Figura 12.4, nos dejara contestar tales preguntas como el cual recorre fue la mayor parte de pesadamente asistido a? Cul cursos soportaron la asistencia mnima attri tion sobre el trmino? Cul estudiantes asistieron cules recorre? Cul el miembro de facultad le ense a la mayor parte de estudiantes?
La Dimensin de Curso de Dimensin de Facilidad de Dimensin de Fecha El Hecho Estudiantil de Acontecimiento de Asistencia La llave de Curso de la Llave de Facultad de la Llave de Facilidad de la Llave del Estudiante de la Llave de fecha (FK) (FK) (FK) (FK) (FK) La Asistencia Count (0 o 1)
La Dimensin Estudiantil La Dimensin de Facultad
Figura 12.4 la mesa Estudiantil de hecho de asistencia.
Las filas explcitas para Lo Que No Ocurri Quiz las personas estn interesadas en estudiantes monitores que estaban registrados para un curso pero no salieron a la vista arriba. En este ejemplo podemos visualizar aadirle las filas explcitas a la mesa de hecho para los acontecimientos de asistencia que no ocurrieron. Sumar filas es viable en esta panorama porque los acontecimientos de ausencia tienen la misma dimensionalidad exacta como los acontecimientos de asistencia. Asimismo, la mesa de hecho no crecer en una tasa alarmante, suponer que (o quiz esperando) los sujetos que no llega son una parte pequea porcentual de los estudiantes totales inscritos para un curso. En esta situacin ya no tratamos de una mesa de hecho de factless porque ahora el hecho de asistencia igualara ya sea 1 o 0. Mientras este acercamiento es razonable en esta panorama, crear filas para acontecimientos que no ocurrieron es ridculo en muchas situaciones. Por ejemplo, si recordamos para nuestro estudio de casos de transporte, ciertamente no queremos construir mesa de hecho rema para cada vuelo desocupado por un aviador asiduo en un da dado.
Otras Opciones de Relaciones para Qu No ocurri En muchos casos la mesa primaria de hecho de transaccin, como las ventas en una tienda de comestibles, est muy escasamente poblada. Slo una fraccin de la total cartera de productos vende en cada tienda cada da en la mayora de ambientes por menor. Habra abrumando en lo alto se asoci con el almacenaje las filas explcitas para productos que no vendieron. La mesa de hecho de ventas de transaccin es ya muy grande; Lo ltimo que queremos hacer es gastar ms dinero en los recursos y el espacio del disco para almacenar un racimo de pone en el cero. Como recordamos de Captulo 2, podemos usar una mesa de hecho de factless de edad de cubierta de promocin para ayudar a contestar que la pregunta de qu estaba siendo promovido sino no vendi. Una fila est colocada en la mesa de cobertura para cada producto en cada tienda que est sobre la promocin en cada lapso de tiempo. Esta mesa sera muy ms pequea que aadirle las filas explcitas a la mesa existente de hecho de transaccin porque slo contiene los artculos sobre la promocin; Esos que no
siendo promovido sera excluido. Adems, quiz podramos substituir una granularidad semanal en lugar de un grano diario si las promociones corren sobre una base semanal. Para contestar la pregunta suponiendo cul fue sobre la promocin pero no vendi, primero le consultaramos la mesa de cobertura para los productos sobre la promocin en un tiempo dado en esa tienda. Entonces le consultaramos la mesa de hecho de ventas para determinar qu hizo venda; Lo differ-ence determinado entre estas dos listas de productos es nuestra respuesta.
En un ambiente de la base de datos de relaciones, tambin tenemos la opcin de acostumbrar lo NO EXISTE construccin en el lenguaje normalizado de consulta para identificar filas que no existen en una base de datos, como los hechos inexistentes o dimensionan atributos. Mientras este acercamiento allevi ates la necesidad para por adelantado la planificacin y el diseo trabajan para tampoco incluir filas explcitas o las Tablas de cobertura de construccin, no es como dolor gratis como aparece inicialmente. Debemos preguntar muy especficamente lo que no existe dndole marco a lo NO EXISTE dentro de una mayor averiguacin. Por ejemplo, para contestar la pregunta acerca de ventas inexistentes para productos promovidos, primero debemos determinar todos los productos vendidos durante un dado extendido lmite de tiempo y entonces debemos publicar una subaveriguacin dentro de lo NO EXISTE que la construccin para determinar todos los productos vendi sobre la promocin durante un ms pequeo lmite de tiempo. El peligro en usar este lenguaje normalizado de consulta correlacion acercamiento de subaveriguacin es que perderemos productos que no vendieron del todo durante el extendido lmite de tiempo. Tambin, la averiguacin debe funcionar lentamente por la complejidad. Finalmente, el acceso de datos que labra pueden prohibir el uso de esta construccin dentro de su interfaz. Usar la mesa de cobertura de promocin de factless en Figura 12.5, aqu es el lenguaje normalizado de consulta para encontrar todos los productos que no vendieron sobre una promocin particular ( Promo-Tion activo ) adelante el 15 de enero de 2002 que de otra manera se vendieron en la San Antonio Principal Conexin de Salida en alguna ocasin durante el enero del 2002. Si usted puede comprender este lenguaje normalizado de consulta, en ese entonces usted est calificado para soportar esta aplicacin!
SELECCIONE _ DESCRIPCIN P1 PRODUCT_DESCRIPTION DE SALE_FACT F1, el PRODUCTO P1, S1 DE LA TIENDA, FECHA D1, PROMOCIN R1 DONDE F1. PROD_KEY = P1. PROD_KEY El operador booleano AND de operador booleano AND de operador booleano AND F1. STORE_KEY = S1. STORE_KEY F1. DATE_KEY = D1. DATE_KEY F1. PROMO_KEY = R1. PROMO_KEY Operador booleano AND S1. STORE_LOCATION MES de operador booleano AND de la ' Conexin de Salida San Antonio Main ' D1. ' el enero, 2002 '
Y NO EXISTE (SELECCIONE a R2. PROMO_KEY DE SALE_FACT F2, la PROMOCIN R2, FECHA D2 DONDE el operador booleano AND de operador booleano AND de operador booleano AND F2. PROMO_KEY = R2. PROMO_KEY F2. PROD_KEY = F1. PROD_KEY F2. STORE_KEY = F1. STORE_KEY F2. DATE_KEY = D2. DATE_KEY _ el TIPO de operador booleano AND R2 PROMOTION_TYPE operador booleano AND de ' Promocin de voz activa ' D2. FULL_DATE 'el el 15 de enero de 2002 ')
La Dimensin de Fecha Los atributos de Fecha de la Llave de fecha (PK) Almacene Dimensin Almacene Atributos De la Tienda Cruciales (PK) El Hecho de Cobertura de Promocin La llave de Promocin de la Llave de la Tienda de la Llave del Producto de la Llave de fecha (FK) (FK) (FK) (FK) La promocin Count (siempre = 1) La Dimensin del Producto Los atributos del Producto de la Llave del producto (PK) La Dimensin de Promocin Los atributos de Promocin de la Llave de promocin (PK)
Figura 12.5 la cobertura de Promocin como una mesa de hecho de factless.
El Manejo Multidimensional de Qu No ocurri Las bases de datos analticas de procesamiento en lnea multidimensionales (OLAP) hacen uno aventaja trabajo prestado de ayudar a usuarios a entender lo que no ocurri. Cuando el cubo de datos se construye, la multidimensional base de datos maniobra el sparsity de los datos de transaccin al minimizar el gasto de fbrica de almacenar explcito pone en el cero. Como tal, al menos para cubos de hecho que no son demasiado escasos, el acontecimiento y datos de anticlmax estn disponibles para anlisis del usuario al adelgazar algunos del com-plexities que acabamos de discutir en el mundo de relaciones.
Otras reas de Inters Analtico Ahora que hemos tomado una tangente para discutir el anlisis de qu no ocurri, regresemos al mundo de enseanza superior para traer este captulo a una conclusin ordenada. Muchos de los procesos analticos descritos tiempo atrs en este libro, como la adquisicin y recursos humanos, son obviamente aplicables al ambiente de univer-sity dado el deseo a mejor monitorear y manejar costos. Cuando enfocamos la atencin en la renta lateral de la ecuacin, la investigacin consiente y con-tributions de alumnos graduados son fuentes cruciales, adems de la renta de instruccin. La mayor parte de anlisis de concesin de investigacin es una variacin de anlisis financiero, como discutimos en Captulo 7, pero en un nivel ms bajo de detalle, mucho como un sublibro mayor. El grano inclua dimensiones adicionales a fomentar describen la concesin de investigacin, como la fuente corporativa o gubernamental y financiadora, la duracin de tema de investigacin, de concesin, y el investigador de facultad. Hay una necesidad fuerte para
Mejor comprenda y maneje el gasto presupuestado y real y asociado con cada proyecto de investigacin. El objetivo es optimizar el gasto tan ese un excedente o la situacin de dficit es evitada, mientras los fondos son destacados donde sern ms productivos. Asimismo, comprender gastar investigaciones rod arriba por dimensiones diversas hay que asegurar control institucional correcto de tales monies. La mejor comprensin los alumnos graduados de la universidad se parece mucho a mejor understand-ing una base del cliente, como describimos en Captulo 6 relacionada gestor de relaciones con el cliente. Obviamente, hay muchas caractersticas interesantes que seran de ayuda manteniendo una relacin mutuamente propicia con nuestros alumnos graduados, como el empleo geogrfico, grfico en demo,, los intereses, y la informacin conductista, adems de los datos que coleccionamos acerca de ellos como estudiantes (por ejemplo, las credenciales entrantes, las afiliaciones, escuela, estudiante avanzado, longitud de tiempo a graduarse, y los honores). El acceso mejorado para un alcance amplio de atributos acerca de la poblacin de alumnos graduados dejara la universidad mejor apuntarle a los mensajes y ubicar recursos. Adems de contribuciones de alumnos graduados, podemos apalancar la informacin para el potencial reclutando, colocacin de empleo, y oportunidades de investigacin. Con este fin, podemos visualizar que una gestor de relaciones con el cliente en gran escala sistema operacional rastree todo el toque de la universidad apunta con sus alumnos graduados, trabajando en conjuncin con la fundacin analtica del almacn.
Resumen En este captulo que canalizamos a dos conceptos primarios. Primero, consideramos la foto de atesoramiento usada para rastrear la tubera aplicativa (o inversamente, la tubera de actividad de concesin de investigacin). Si bien la foto de atesoramiento es usada mucho menos frecuentemente que la transaccin ms comn y las Tablas peridicas de hecho de la foto, es muy til en situaciones donde queremos rastrear el estatus actual de un proceso de breve duracin con hitos estndar generalmente aceptados de progreso. En segundo lugar, exploramos varios ejemplos de la mesa de hecho de factless.
Estas Tablas de hecho captan la relacin entre dimensiones en el caso de un acontecimiento o la cobertura pero son nicas en lo referente a que ninguna medida es coleccionada para servir de hechos reales. Tambin discutimos el manejo de situaciones donde queremos rastrear acontecimientos que no ocurrieron.
Asistencia Mdica Para La Salud El carbono HAPTE R13
hidrgeno
Los presentes de cautela del ealth que varios datos interesantes almacenan disean situaciones. En este captulo que nos imaginaremos primero que trabajamos para una abrumadora asistencia mdica para la salud consor tium, entonces que trabajamos para una organizacin facturadora para proveedores de cautela y hospitales, y finalmente que trabajemos para una clnica grande con registros de tratamiento de millones de complejos de paciente. Cada uno de estas situaciones sugerirn tcnicas del diseo importantes aplicables para la asistencia mdica para la salud y otras industrias.
aprecie el crculo dentro de la asistencia mdica para la salud, centrada en los registros pacientes de tratamiento acumulando mesa de hecho de la foto para maniobrar rubros contables mdicos de la cuenta ms caracterizacin de papeles de dimensin tan aplicado para mltiplo pasa de moda y proveedores Multivalued dimensiona, como un nmero indefinido de diagnostica junto con las fechas de efectividad y oprimiendo factores para soportar dotaciones
el hecho extendido se sediment para soportar anlisis de rentabilidad el manejo de acontecimientos mdicos complicados la dimensin de hecho para organizar medidas sumamente escasas, heterogneas
255
El Crculo de Valor de Asistencia Mdica para la Salud Un consorcio grande tpico de asistencia mdica para la salud es una red de proveedores, clnicas, hospitales, farmacias, fabricantes farmacuticos, laboratorios, empleadores, compaas de seguros, y organismos gubernamentales. A diferencia de la cadena de valor describimos en Captulo 3, un consorcio de asistencia mdica para la salud se parece a ms de un crculo de valor, tan ilustrado en Figura 13.1. Esta figura no es un diagrama del dibujo tcnico! Es un cuadro de cmo todos estos los organismos diferentes necesitan compartir los mismos datos crticos: El registro paciente de tratamiento. Hay dos tipos principales de registros pacientes de tratamiento. El tratamiento facturando registro concuerda con un rubro contable en una cuenta paciente de la oficina de un proveedor, una clnica, un hospital, o un laboratorio. El tratamiento ficha mdica, por otra parte, es ms global e incluye no slo los tratamientos que dan como resultado cargos pero tambin todo el laboratorio experimenta, conclusiones, y dur-ing de notas del proveedor el tratamiento. Los asuntos consistieron en estas dos clases de registros es realmente diferente, y los miraremos en secciones separadas.
Nuestro consorcio grande de asistencia mdica para la salud debe poder compartir tratamiento facturando registros suavemente de organizacin para la organizacin. Los registros de facturacin de todos los diferentes tipos de proveedores deben tener una coleccin completa de dimen-sions comn para ser procesados por las compaas de seguros y los pagadores mdicos de la cuenta. Como los individuos se mueven de posicin para la posicin, el empleador para el empleador, y la compaa de seguros para programa de asistencia mdica para la salud de gobierno, un pic-ture coherente de necesidades de historia de ese individuo a ser creable en cualquier momento. Y finalmente, en la lnea de escaramuza de prctica de entrega de asistencia mdica para la salud, las fichas mdicas de una necesidad del paciente a estar disponibles con poco tiempo de aviso para legtimo mdico usar antes de cualquier de los proveedores primarios.
Clnicas A Largo Plazo

Las Facilidades de Cautela
Mdico
Oficinas
Hospitales
El Gobierno Agencias
Seguro Compaas
El paciente Tratamiento
Empleadores Farmacias
Farmacutico Fabricantes
Laboratorios
Figura 13.1 el crculo Tpico de valor de asistencia mdica para la salud.
El crculo de valor de asistencia mdica para la salud difiere de la cadena lineal clsica de valor porque no hay ordenamiento obvio puntual. Sin embargo, los asuntos de conformar las dimensiones comunes permanecen exactamente iguales. El consorcio de asistencia mdica para la salud podr funcionar si y slo si puede implementar un set de dimen-sions conformado. Un representante colocado de dimensiones que se conform por el consorcio de asistencia mdica para la salud incluya: la fecha del calendario el paciente la fiesta responsable (el padre, el guardin, el empleado) empleador el plan de salud pagador (primario, secundario proveedor (todas las formas de expertos en salud que administran tratamientos) tratamiento (la prueba de mtodo facturable, del laboratorio, el examen) la droga diagnstico resultado posicin (la oficina, la clnica, la facilidad del paciente no hospitalizado, el hospital)
Una fila facturadora probablemente necesitara todas estas dimensiones excepto por los apagados vengan dimensin. Una fila mdica no siempre identificara al empleador, plan de salud, o dimensiones del pagador. Y los reclamos de seguro yendo en procesin necesitaran emparejar ms dimensiones referente a demandantes, accidentes, abogados, y los tipos de transaccin necesitados para los reclamos yendo en procesin. Suprimiremos el aspecto de seguro de almacenes de datos de asistencia mdica para la salud porque nos ocuparemos de esas clases de temas en Captulo 15. En el negocio de asistencia mdica para la salud, algunos de estas dimensiones son arduas para aprender de memoria forma, mientras que los otros son ms fciles que miran a primera vista. Las dimensiones pacientes y responsables de fiesta son lo ms duro, al menos en los Estados Unidos, por la falta de un nmero nacional
fidedigno de identidad y porque las personas es contratado separadamente en las oficinas de doctores y hospitales y situaciones de empleo. Los problemas con las dimensiones pacientes y responsables de fiesta son muy parecidos a los asuntos que discutimos en Captulo 6 referente al consoli-dation de fuentes mltiples para la informacin del cliente. El mismo cliente haciendo buena pareja, householding, software de purga de consorcio, y la oferta de pases proveedores de servicios los servicios similares para la industria de asistencia mdica para la salud. Para averiguar ms aproximadamente estos com-panies, vaya en busca de purga de nombre del householding o de consorcio en un motor de bsqueda de la Internet como Google (www.google.com).
El diagnstico y dimensiones de tratamiento estn considerablemente ms estructurados y previsibles que uno podra esperar porque la industria de seguro y gobierno han promulgado su contenido. Diagnostica usualmente sigue la Clasificacin Internacional de Enfermedades, Revisin 9: La modificacin clnica, los Volmenes 1 y 2 (ICD-9-CM) estndar. El EEUU Department de Salud y vicios Human Ser (HHS) mantiene este estndar tan lejano como los Estados Unidos estn afectados. El estndar ICD-9-CM, Volumen 3, define tratamiento y cdigos administrativos. El Health Care Financing Administration Common Procedure Codificando a Sistema (HCPCS) estndar, tambin actualizado y distribuido por HHS; Y la Terminologa dural a Proce Actual, la Edicin 4 (CPT-4), tan actualizado y distribuido por la Asociacin Norteamericana de Mdicos, cubierta los servicios relacionados con la salud y otros artculos, inclusivos: el mdico repara los servicios fsicos y ocupacionales de terapia los mtodos radiolgicos el laboratorio clnico experimenta otros mtodos diagnsticos mdicos los servicios audicin y de vista los servicios de transporte (incluyendo ambulancia) los suministros mdicos los dispositivos ortticos y protsicos equipo mdico durable Los dentistas pueden usar el Cdigo en Nomenclatura y Mtodos Dentales, tan actualizados y distribuidos por la Asociacin Dental Americana, para los servicios dentales. Cuando todas las dimensiones en nuestra lista han sido conformadas, entonces cualquier organiza tion con privilegios apropiados de acceso puede entrenarse a travs de las Tablas separadas de hecho, vinculando la informacin correspondiendo a los encabezados de la fila de cada fila. El uso de dimensiones conformadas garantiza que este proceso coincidente est bien definido. Describimos este proceso en Captulo 3 en un movimiento del producto del texto en
la contra, pero los principios son exactamente iguales cuando le son aplicados para el crculo de valor de asistencia mdica para la salud.
La Cuenta de Asistencia Mdica para la Salud Imaginmonos que trabajamos para una organizacin facturadora para personas que provee asistencia mdica para la salud y los hospitales. Recibimos las transacciones primarias de la facturacin de lo
Los proveedores y los hospitales, le preparan y le envan las cuentas a todos los pagadores responsables, y rastrean el progreso de los pagos hechos. Nuestro almacn de datos que pone en cartelera asistencia mdica para la salud debe responsabilizarse por un nmero de objec-tives comercial. Queremos analizar las cuentas y cantidades del dlar de todas las cuentas por cada dimensin disponible para nosotros, incluyendo por paciente, proveedor, diagnstico, tratamiento, fecha, y cualquier combinaciones de todos estos. Queremos ver cmo han sido estas cuentas pagado y qu el porcentaje de las cuentas no han sido coleccionadas. Queremos ver cunto tiempo requiere quedar pagado, y queremos ver el estatus actual de todos los efectos devueltos, actualizados cada 24 horas. Y por supuesto, las averiguaciones necesitan ser simples, y el tiempo de respuesta debe ser instantneo! Como discutimos en Captulo 5, cada vez que consideramos una fuente de datos para inclu-sion en el almacn de datos, tenemos tres elecciones fundamentales de grano para la mesa de hecho. Recuerde que el grano del hecho que la mesa es el defini-tion fundamental de qu constituye una fila de la mesa de hecho. En otras palabras, cul es lo measure-ment que registramos? El grano de transaccin es lo ms fundamental. En el ejemplo de la cuenta de asistencia mdica para la salud, el grano de transaccin incluira cada transaccin de aporte de los proveedores y los hospitales, as como tambin cada transaccin de pago resultando de la cuenta siendo enviado. Aunque el mundo puede estar reconstruido de transacciones de indi-vidual, este grano no puede ser el mejor grano con el que comenzar para responsabilizarse por nuestro negocio reportando objetivos porque muchas de las averiguaciones requeriran renovar hacia el futuro las transacciones desde principio del tratamiento del paciente. El grano peridico de la foto es el grano de eleccin para largos procesos de series temporales que corre como banco lleva las cuentas y plizas de seguros. Sin embargo, la foto peridica no hace un buen trabajo de captar el comportamiento de un proceso rpidamente en movimiento, de breve duracin como las rdenes o las cuentas mdicas. La mayor parte de la actividad interesante rodeando una cuenta mdica tiene lugar rpidamente en uno o dos meses. Tambin, si la foto peridica est disponible slo en el fin de mes, no podemos ver el estatus actual de los efectos
devueltos. Escogeremos el grano de la foto de atesoramiento para nuestra cuenta de asistencia mdica para la salud. Una fila de sin-gle en nuestro hecho que la mesa representar un solo rubro contable en una cuenta de asistencia mdica para la salud. Adems, esta sola fila representar la historia acumulada de ese rubro contable desde el momento de creacin de la fila hasta el da actual. Cuando cualquier cosa acerca del rubro contable cambia, volvemos a visitar la fila nica de atesoramiento y modificamos la fila apropiadamente. Desde el punto de vista del organiza-tion facturador, asumiremos ese la panorama estndar de una cuenta incluye: la fecha de tratamiento el seguro primario cobrando fecha el seguro secundario cobrando fecha
la fiesta responsable cobrando fecha ltimo la fecha de pago primaria de seguro por ltimo la fecha de pago secundaria de seguro por ltimo la fecha de pago responsable de fiesta Escogemos estas fechas para ser una descripcin adecuada de una cuenta de normalidad. La foto An accu mulating no trata para describir situaciones inusuales completamente. Si los usuarios comerciales ocasionalmente necesitan ver todos los detalles de una en particular situacin confusa del pago de facturas, en ese entonces una transaccin del compaero vete mesa de hecho se necesitara. El propsito del grano de la foto de atesoramiento es colocar cada cuenta de asistencia mdica para la salud dentro de un armazn uniforme as es que los objetivos comerciales que describimos ms temprano puede quedar satisfecho fcilmente. Ahora que hacemos una idea evidente de qu hecho tan individual poner sobre una mesa fila representa (por ejemplo, la historia acumulada de un rubro contable en una cuenta de asistencia mdica para la salud), podemos completar la lista de dimensiones por cuidadosamente listando todo lo que sabemos ser verdaderos en el contexto de esta fila. En nuestra organizacin facturadora hipottica, sabemos el organiza-tion de fiesta responsable, del empleador, del paciente, del proveedor, del proveedor, tratamiento realizado, posicin de tratamiento, diagnstico, organizacin primaria de seguro, organizacin secundaria de seguro, y nmero maestro de la cuenta Idaho. Estos se convierten en nuestras dimensiones, como se muestra en Figura 13.2.
La Dimensin de Fecha (Los puntos de vista para 7 papeles) La Asistencia Mdica Para La Salud Facturando Hecho de Rubro Contable La llave de Fecha de tratamiento (FK) El seguro de seguro primario Billing Date Key Secondary (FK) Facturando Fiesta de la Llave de Fecha Responsible (FK) Facturando Llave de Fecha (FK) La ltima Fecha de Pago de Fiesta de la Horma de la Llave de Fecha de Pago de Seguro de la Horma Primary Insurance Payment Date Key Secondary Responsible (FK) (FK) la Llave de Fiesta de la Llave Responsible (FK) (FK) La llave del Proveedor de la Llave del Paciente de la Llave del empleador (FK) (FK) (FK) La llave de la Posicin de Tratamiento de la Llave de Tratamiento de Organizacin del proveedor (FK) (FK) (FK) El diagnstico Teclea (multipreciado) La organizacin primaria de Seguro de la Llave de Organizacin de Seguro Secondary Llave Master Bill (FK) (FK) Idaho (DD) La Cantidad Facturada La cantidad primaria (calculado) de Total de Cantidad de Fiesta de Cantidad de Seguro de Cantidad de Seguro Paid Secondary Paid Responsible Paid Paid Envi a Cantidad de Colecciones Escrita Fuera de Cantidad Continuar siendo Pag Nmero de Cantidad (calculado) de Unidades de Tratamiento La Duracin de Tratamiento Los Das para Primer Primary Insurance Payment Days hasta los Primeros Das de Pago Secundarios de Seguro para el Primer Pago Responsable de Fiesta La Dimensin Responsable del Empleador de Dimensin de Fiesta la Dimensin Paciente del Proveedor de Dimensin La Dimensin de Organizacin del Proveedor La dimensin de Organizacin de Seguro de Dimensin de Diagnstico de Dimensin de la Posicin de Tratamiento de Dimensin de tratamiento (vea Higo 13.3) (Los puntos de vista para 2 papeles)
Figura 13.2 cobrando.
Acumulando mesa de hecho de la foto para la cautela de salud
Los hechos interesantes que elegimos acumular sobre la historia del rubro contable en la cuenta de asistencia mdica para la salud incluyen la cantidad facturada, el seguro primario pag cantidad, el seguro secundario pag cantidad, el partido responsable pag cantidad, el total pag cantidad (calculado), la cantidad enviada a colecciones, cantidad amortizada, cantidad quedando para estar pagado (calculado), numerar de unidades de tratamiento (depend-ing sobre el tipo de tratamiento), duracin de tratamiento, nmero de das de cobrar para el primer pago primario de seguro, el nmero de das de cobrar para el primer pago secundario de seguro, y el nmero de das de cobrar para lo primerEl pago responsable de fiesta. Supondremos que una fila es creada en esta mesa de hecho cuando el transAc-tions de actividad es primero recibido de los proveedores y hospitales y las cuentas iniciales es enviado. En una cuenta dada, quiz la primaria compaa de seguros es enviada la factura, pero el seguro secundario y la fiesta responsable no son facturados, pendientes una respuesta de la primaria compaa de seguros. Pues un perodo de tiempo despus de que la fila sea primera entr en la base de datos, las ltimas cinco fechas no son aplicables. La llave vicaria de fecha en la mesa de hecho no debe ser nula, pero el descrip-tion lleno de fecha en la fila correspondiente de la mesa de dimensin de fecha ciertamente puede ser nulo. En los prximos das y las semanas despus de la creacin de la fila, los pagos son recibidos, y las cuentas son enviadas a la fiesta de la compaa de seguros secundaria y de responsi-ble. Cada vez que estos acontecimientos tienen lugar, la misma fila de la mesa de hecho es revis-ited, y los llaves correctas y hechos estn destructivamente actualizados. Esta actualizacin destructiva plantea algunos retos para el administrador de la base de datos. Las anchuras de la fila en bases de datos como el Orculo crecern cada vez una actualizacin ocurre porque los hechos numricos pueden variarse de un nmero pequeo para un mayor nmero. Esto puede causar escisiones del bloque y fragmentacin si el espacio suficiente no est disponible en el nivel del bloque de discos para acomodar este crecimiento. Si la mayor parte de este atesoramiento rema estabilcese y deje de cambiar en un plazo de 90 das (por ejemplo), en ese entonces una reorganizacin fsica de la base de datos en aquel entonces puede recobrar almacenamiento en disco y puede mejorar funcin. Si la mesa de hecho est subdividida en la llave de fecha de treat-ment, en ese entonces el fsico agrupamiento de estrellas (la particin de discos) probablemente estar bien conservado a todo lo largo de estos cambios porque
suponemos que la fecha de tratamiento no es normalmente vuelta a visitar y cambiada.
Los Papeles Tocaron por la Dimensin de Fecha Acumulando Tablas de hecho de la foto siempre requiere fechadores mltiples. Nuestro ejemplo, cul es tpico, tienen siete llaves extranjeras sealando el dimen-sion de fecha. ste es un buen lugar para reiterar varios puntos importantes: las llaves extranjeras en la mesa de hecho no pueden ser fechadores reales porque tienen que manipular el No caso Aplicable . Las llaves extranjeras deberan ser enteros simples haciendo las funciones de llaves vicarias.
las llaves vicarias asignaron en la fecha dimensin debera ser asignado consecutivamente en la orden de fecha. sta es la nica dimensin donde las llaves vicarias tienen cualquier relacin para la semntica subyacente de la dimensin. Hacemos esto tan tan fsica particin de discos de un hecho que la mesa puede estar consumada por utilizador de las llaves extranjeras basadas en fechas. En nuestro ejemplo que recomendamos que la llave de fecha de tratamiento sea utilizada como la base para physi-cally dividiendo en partes la mesa de hecho. subrogue llaves correspondiente a las condiciones especiales como No Applica ble, corrupto, o No Ha Ocurrido Pero debera ser asignado al extremo superior del alcance numrico a fin de que estas filas estn fsicamente subdivididas juntos en la particin caliente con los datos ms recientes. Hacemos esto si estas filas son unos que se esperan para cambiar. No adjuntamos las siete llaves extranjeras basadas en fechas a una sola instancia de la mesa de dimensin de fecha. Tal juntura exigira mucho que todas las siete fechas fueron la misma fecha. En lugar de eso, creamos siete puntos de vista en la sola mesa de dimensin de fecha de underly-ing, y unimos la mesa de hecho separadamente para estos siete puntos de vista, tal como si fuesen siete la fecha del inconformista la dimensin Tablas. Esto da rienda suelta a que las siete fechas para ser independiente. Nos referimos a estos siete puntos de vista como los papeles desempeados por la fecha dimensionan mesa. las siete definiciones de vista usando la mesa de dimensin de fecha cosmet-ically redeberan designar los nombres de la columna de cada vista para ser distinguible a fin de que la averiguacin labre directamente accediendo a los paisajes presentar los nombres de la columna a travs de la interfaz de usuario en uno muy ese tienen sentido para el usuario final. Aunque el comportamiento de caracterizacin de papeles de la dimensin de fecha es muy tic de characteris de Tablas de hecho de la foto de atesoramiento, otras dimensiones a menudo juegan contra papeles en las formas similares, como la dimensin del pagador en Figura 13.2. Ms tarde en este captulo que veremos cmo la dimensin del mdico necesita tener varios papeles en com-plex mtodos quirrgicos segn que el mdico es el mdico responsable primario, trabajando en una capacidad consultiva, o trabajando en una capacidad auxiliar.
La Dimensin Multipreciada de Diagnstico Normalmente nosotros escogemos las dimensiones rodeando una fila de la mesa de hecho preguntando, qu sabemos ser verdaderos en el contexto de la medida? Casi siempre queremos decir, lo que cobra un solo valor en el contexto de la medida? Si algo tiene un montn de valores en el contexto de la medida, casi siempre descalificamos esa dimensin porque la manera de muchos preciados que la dimensin ofensiva pertenece en un grano ms bajo de medida.
Sin embargo, hay algunas situaciones en las cuales lo de muchos preciados es sin afectacin e inevitable, y nosotros queremos incluir tal dimensin en nuestro diseo, como el caso cuando asociamos a clientes mltiples con una cuenta en Captulo 9. La dimensin de diagnstico en nuestra asistencia mdica para la salud facturando mesa de hecho es otro buen ejemplo. Al momento de tratamiento, el paciente tiene uno o ms diagnostican, que es bien conocido. Adems, hay buen incentivo para conservar estos diagnostica junto con la fila facturadora. Si hubo siempre un mximum de tres diagnostica, por ejemplo, podramos estar tentados de crear tres dimensiones de diagnstico, casi tan si fuesen papeles. Sin embargo, diagnostica no se comporte gustan los papeles. Desafortunadamente, hay a menudo ms que tres diagnostican, especialmente para pacientes entrados en aos que son hospital-ized. Organizaciones que pagan realmente cuenta mdica algunas veces encuentran a los pacientes con ms que 50 diagnostican! Tambin, lo diagnostica no quepa dentro de papeles bien definidos aparte de posiblemente admitiendo diagnstico y exonerando diagnstico. Las dimensiones de caracterizaciones de papeles de las que hablamos en la seccin precedente son catego-rized bastante ms naturalmente y disjuntamente. Finalmente, la aguja fonogrfica de ranuras mltiples de diseo parte rumbo aplicaciones muy ineficientes porque la averiguacin no sabe ranura a priori cul dimensional para constreir para un diagnstico particular. Maniobramos la naturaleza indefinida de mltiplo diagnostica con el diseo mostrado en Figura 13.3. Reemplazamos el diagnstico llave extranjera en la mesa de hecho con una llave del grupo de diagnstico. Esta llave del grupo de diagnstico est conectada por uno muchos para muchos la juntura para un cuadro puente del grupo de diagnstico, lo cual contiene una fila separada para cada diagnstico en un grupo particular.
La Asistencia Mdica Para La Salud Facturando Hecho de Rubro Contable La llave de Fecha de tratamiento (FK) El seguro de seguro primario Billing Date Key Secondary (FK) Facturando Fiesta de la Llave de Fecha Responsible (FK) Facturando Llave de Fecha (FK) La ltima Fecha de Pago de Seguro de la Horma Primary Insurance Payment Date Key Secondary (FK) la Llave de Fiesta de la Llave Responsible (FK) (FK) La llave del Proveedor de la Llave del Paciente de la Llave del empleador (FK) (FK) (FK) El grupo de Diagnstico de la Llave de la Posicin de Tratamiento de la Llave de Tratamiento de Organizacin del proveedor (FK) (FK) (FK) (FK) La organizacin primaria de Seguro de la Llave de Organizacin de Seguro Secondary Llave Master Bill (FK) (FK) Idaho (DD) Hechos
El Puente del Grupo de Diagnstico La llave de Diagnstico de la Llave del Grupo de diagnstico (FK) (FK) Oprimiendo Factor
La Dimensin de Diagnstico El diagnstico el Cdigo de la Llave ICD-9 (PK) Abatane Descripcin de Diagnstico El Tipo de Diagnstico La Categora de Diagnstico
Figura 13.3 el Diseo para una dimensin multipreciada de diagnstico.
Si un paciente tiene tres diagnostican, entonces ese paciente es asignado que un grupo de diagnstico con tres diagnostica. Le asignamos un factor numrico que oprime a cada diagnstico en el grupo algo semejante que la suma de todos los factores que oprime en el grupo est exactamente 1.00. Entonces podemos acostumbrar los factores que oprime para ubicar cualquier de los hechos numricos de addi-tive a travs de individuo diagnostican. De este modo podemos sumar todas las cantidades facturadas por el diagnstico, y el gran total ser la cantidad facturada total grandiosa correcta. Esta clase de informe sera llamada un informe correctamente oprimido. Vemos que los factores que oprime son simplemente una forma para ubicar los hechos aditivos numricos a travs de lo diagnostica. Algunos sugeriran que cambiamos el grano de la mesa de hecho para ser rubro contable por el diagnstico en vez de slo aplicarle delineador tem. En este caso los tomaramos los factores que oprime y fsicamente los multiplicaramos en contra de los hechos numricos originales. Esto termina raras veces, para tres razones. Primero, el tamao de la mesa de hecho estara multiplicado por el nmero comn de diag-nose. En segundo lugar, en algunas Tablas de hecho tenemos ms que lo que uno multiapreci dimen-sion. El nmero de filas se sala de control en esta situacin, y comenzaramos a cuestionar el significado fsico de una fila individual. Finalmente, podemos querer ver los nmeros no dispuestos, y es difcil de reconstruir estos si las dotaciones han estado combinadas fsicamente con los hechos numricos. Si escogemos no aplicar los factores que oprime en una averiguacin dada, todava podemos resumir cantidades facturadas por el diagnstico, pero en este caso obtenemos lo que es llamado un informe de impacto. Una pregunta tan Qu implica el total cantidad facturada a travs de todos los tratamientos posibles de cualquier modo el diagnstico de XYZ? Sera un ejemplo de un informe de impacto. En Figura 13.3, una vista de lenguaje normalizado de consulta pudo estar definida combinando el hecho la mesa y el cuadro puente del grupo de diagnstico tan tan estas dos Tablas, cuando se combin, aparecera para herramientas de acceso de datos como una mesa estndar de hecho con un diagnstico normal llave extranjera. Dos puntos de vista pudieron estar definidos, un acostumbrando los factores que oprime y uno no acostumbrando los factores que oprime.
Finalmente, si lo muchos para muchos toma parte en Cifra 13.3 problemas de causas para su herramienta de mod-eling que insiste en llave extranjera correcta para las relaciones de la llave primaria, el diseo equivalente de Figura 13.4 puede ser usado. En este caso una mesa adicional cuya llave primaria es grupo de diagnstico est inserto entre la mesa de hecho y el puente
La Asistencia Mdica Para La Salud Cobrando El Hecho de Rubro Contable el diagnstico extranjero de Llaves los Hechos del Grupo Master Bill Idaho (DD) (FK) El Grupo de Diagnstico Dimensin La llave del Grupo de diagnstico (PK)
El Puente del Grupo de Diagnstico La llave de Diagnstico de la Llave del Grupo de diagnstico (FK) (FK) Oprimiendo Factor
La Dimensin de Diagnstico El diagnstico el Cdigo de la Llave ICD-9 (PK) Abatane Descripcin de Diagnstico El Tipo de Diagnstico La Categora de Diagnstico
Creo que 13.4 el grupo de Diagnstico dimensionan para crear una relacin clave primaria.
Mesa. Ahora ambos el hecho posponen y el cuadro puente tenga convencional muchos para una junturas en todas las direcciones. No hay informacin nueva en esta mesa adicional. En la vida real, un organismo que paga cuenta decidira cmo administrar los grupos de diagnstico. Si un grupo nico de diagnstico se le creara cada tratamiento de paciente no hospitalizado, el nmero de filas podra volverse astronmico e inexplotable. Probablemente el mejor acercamiento es tener un portafolio estndar de grupos de diagnstico que son usados repetidamente. Esto pide que cada set de diag-nose sea visto arriba en la mesa maestra del grupo de diagnstico. Si el grupo existente es encontrado, es usado. Si no es encontrado, en ese entonces un grupo nuevo de diagnstico es creado. En una situacin de estada del hospital, sin embargo, el grupo de diagnstico probablemente debera ser nico para el paciente porque va a evolucionar con el paso del tiempo como un tipo 2 lentamente cambiando dimensin (SCD). En este caso suplementaramos el cuadro puente con dos fechadores para capturar comience y el fin pasa de moda. Mientras los fechadores gemelos complican la gerencia de actualizacin del cuadro puente del grupo de diagnstico, valen de mucho poner en duda y cambian rastreo. Tambin nos dejan realizar averiguaciones de perodos de tiempo, como identificar todos los pacientes que el sented un diagnstico dado en cualquier momento entre dos fechas. Para resumir este debate de dimensiones multipreciadas, podemos listar los asuntos rodeando un diseo multipreciado de dimensin: en el contexto de la medida de la mesa de hecho, la dimensin multipreciada cobra una parte pequea pero nmero variable de valores bien definidos. los informes correctamente ubicados pueden ser creados slo si se accedi a oprimir factores. oprimir factores puede omitirse, pero entonces slo los informes de impacto pueden ser generados usando la dimensin multipreciada. en situaciones de volumen alto como cuentas mdicas y cuentas del banco, un sistema de reconocer y reutilizar grupos debera ser usado. en los casos donde la relacin representada en el cuadro puente cambia con el paso del tiempo, embellecemos el cuadro puente con comience y el fin pasa de
moda.
Extendiendo Una Mesa Facturadora de Hecho para la Rentabilidad de Funcin Resuelva 13.5 funciones un set extendido de hechos que podran sumarse al dibujo tcnico bsico de la facturacin de Figura 13.2. Estos incluyen el costo de artculos de consumo, el costo del proveedor, el costo asistente, el costo del equipo, el costo de la posicin, y ganancia neta antes de los gastos generales y administrativos (G y Uno), lo cual es un hecho calculado. Si estos hechos de addi-tional pueden sumarse al dibujo tcnico facturador, el poder de la mesa de hecho aumenta enormemente. Eso ahora se convierte en una vista de ganancias y prdidas hecha y derecha (P y L) del negocio de asistencia mdica para la salud.
La Asistencia Mdica Para La Salud Facturando Hecho de Rubro Contable Existiendo 17 Llaves Extranjeras Amaestre a Bill Idaho (DD) Existing 13 Proveedor de Costo de Artculos de Consumo de Hechos la Posicin Costada Asistente Costada de Costo del Equipo el Costo La ganancia neta delante de G y Uno (calculado) Resuelvo 13.5 Facturando rubro contable mesa de hecho extendida en el mismo grano con costos basados en actividades.
Estos costos no son de la apfisis facturadora y normalmente no seran col-lected al mismo tiempo que los datos facturadores. Cada uno de estos costos potencialmente provienen de un sistema separado de la fuente. Para meter esta informacin en la mesa facturadora de hecho, lo separadamente datos del sourced tendran que ser ubicados hasta el rubro contable facturador. Pues los costos basados en actividades como los que hemos puesto en la lista, puede valer la pena hacer esta dotacin. Todas las dotaciones son con-troversial y para una extensin arbitraria, pero si el contrato puede ser alcanzado en el set de dotaciones, la P y la base de datos L que resulta es increblemente poderosa. Ahora el organismo de asistencia mdica para la salud puede analizar rentabilidad por todas las dimensiones!
Las Dimensiones Pues las Estadas Facturadas del Hospital La primera parte de este captulo describi un diseo asimilativo y flexible para tratamientos facturados de asistencia mdica para la salud que abrigaran a ambos enfermo internado y cuentas del paciente no hospitalizado. Si un organismo tuviese el deseo de enfocar exclusivamente la atencin en estadas del hospital, sera razonable pellizcar la estructura dimensional de Figura 13.2 para proveer ms informacin especfica en hospital. Resuelva 13.6 funciones un set revisado de
dimen-sions especializado pues el hospital se queda, con las dimensiones nuevas se sedimenta en letra negrita. En Figura 13.6 mostramos dos papeles para proveedor: Admitiendo al proveedor de proveedor y de attend-ing. Mostramos a proveedor las organizaciones para ambos papeles porque los proveedores pueden representar organizaciones diferentes en un hospital sedimentndose. Tambin tenemos tres dimensiones multipreciadas de diagnstico en cada fila facturada de tratamiento. Lo admitir diagnstico est resuelto al principio de la estada del hospital y debera ser lo mismo para cada fila de tratamiento que es del mismo sostn del hospital. El diagnstico actual describe al estado de conocimiento del paciente al momento del tratamiento. El diagnstico de descarga no es sabido hasta que al paciente se le d de baja y sea aplicado retroactivamente para que todas las filas que han sido en las que se entr como parte de la estada del hospital.
El Hecho de la Facturacin de Estada del Hospital La llave de Fecha de tratamiento (FK) El seguro de seguro primario Billing Date Key Secondary (FK) Facturando Fiesta de la Llave de Fecha Responsible (FK) Facturando Llave de Fecha (FK) La ltima Fecha de Pago de Fiesta de la Horma de la Llave de Fecha de Pago de Seguro de la Horma Primary Insurance Payment Date Key Secondary Responsible (FK) (FK) la Llave de Fiesta de la Llave Responsible (FK) (FK) La llave del Paciente de la Llave del empleador (FK) (FK) Admitiendo Llave del Proveedor de la Llave del Proveedor Attending (FK) (FK) Admitiendo Llave de Tratamiento de Organizacin del Proveedor de Organizacin del Proveedor Attending (FK) (FK) (FK) La llave de la Posicin de tratamiento (FK) Admitir Diagnstico Teclea (multipreciada) Llave Actual (FK) de Organizacin de Seguro de Llaves de Diagnstico de Descarga de Llaves de Diagnstico Primary Insurance Organization Key Secondary Hospital Stay (FK) (multipreciado) (multipreciado) Idaho (DD) Hechos Figura 13.6 Acumulando foto para estadas del hospital cobrando.
Complique Acontecimientos de Asistencia Mdica para la Salud En un hospital sedimentndose, podemos querer modelar ciertos acontecimientos muy complicados, como mtodos quirrgicos principales. En una operacin del transplante de corazn, los equipos enteros de especialistas y los asistentes son congregados para este un acontecimiento. Un transplante diferente del corazn puede involucrar a un equipo con un maquillaje diferente. Podemos modelar estos acontecimientos complicados con el diseo mostrado en Figura 13.7. Combinamos las tcnicas de dimensiones de caracterizaciones de
papeles y dimen-sions multipreciado. Suponemos que un mtodo quirrgico involucra a un solo mdico responsable y nmeros variables de mdicos de cabecera, ayudando profession-als, los mtodos, y el equipo determina el tipo sanguneo. Tambin suponemos que el paciente tiene un diagnstico multipreciado antes de que la ciruga y una separata multiapreciaron diagno-si despus de la ciruga. As nosotros sexto hemos multiapreciado las dimensiones, indicamos por la letra negrita en Fig Ure 13.7. El mdico responsable, el mdico de cabecera, y ayudar a profes sional que las dimensiones son todos los papeles jugaron por una dimensin global del proveedor. La preciruga y la postciruga multiapreciaron las dimensiones de diagnstico son papeles jugados por una sola dimensin de diagnstico.
El Hecho Quirrgico de Transaccin de Acontecimientos El tiempo de Tratamiento de la Llave de Fecha de tratamiento (FK) de Llave del Paciente de la Llave de Da (FK) (FK) La llave responsable (FK) del Mdico El mdico de cabecera Teclea (multipreciado) Ayudando Llave de la Posicin de Claves de Profesionales (FK) (multipreciado) Llaves del mtodo (multipreciado) Equipment Teclea (multipreciado) El diagnstico de Postciruga de Llaves de Diagnstico de preciruga (multipreciado) Teclea (multipreciado) Resultado El Total Factur Cantidad Demuela Cantidad Pagada (el atesoramiento sobrescriba) Consummables Cost El Proveedor Cost Costo Costado Asistente de la Posicin de Costo del Equipo La ganancia neta delante de G y Uno (calculado) Creo 13.7 hecho Quirrgico de transaccin de acontecimientos que la mesa prolong para mostrar ganancias y prdidas.
Desde que el grano de la mesa de hecho es el mtodo quirrgico mismo, es natural suministrar un set asimilativo de hechos. Mostramos el set extendido de hechos que dejaran un anlisis de la P completa y L hacerse en mtodos quirrgicos, suponiendo que los costos diversos pueden ser asignados a cada acontecimiento quirrgico. Salimos fuera los factores que oprime en todas las dimensiones multipreciadas en este diseo. Si intentsemos proveer oprimir factores para el dimen-sions multipreciado, implcitamente soportaramos todas las combinaciones complicadas de oprimir valores, una cierta cantidad de la cual sera absurdo. No parece que vale el problema para afirmar que la porcin correctamente ubicada del total factur cantidad de la ciruga conjuntamente asignado para cada asistente posible y cada pedazo posible de equipo tiene mucho significado. Nuestra tcnica de colocar los factores que oprime independientemente en cada dimensin es slo de la proB-lem. Una preocupacin ms prctica es que la mayora de organismos no estaran dispuestos a asignar docenas o centenares de oprimir factores.
Fuera los factores que oprime, no obstante podemos crear muchos informes tiles de impacto. Por ejemplo, cul es el valor total de todas las cirugas realizado una bomba corazn-pulmn tan usada? Tambin podemos preguntar cules mdicos, que fessionals auxiliares, y cul une las piezas de equipo estaba involucrado en clases diversas de ciruga. Y finalmente, si le hemos asignado los costos a cada ciruga en una forma racional, podemos preguntar cul mecanografa de ciruga es provechoso o poco provechoso y por qu.
Fichas Mdicas Las fichas mdicas generales son desafiantes para el almacn de datos por su variabilidad extrema. Los registros en una toma paciente del archivo muchas formas diferentes, extendindose desde formato estndar que los datos numricos captaron en lnea, para los resultados de prueba del laboratorio nico en su gnero, emitir comentarios del texto entr por un experto en salud, a grficas y fotos. Dada esta variabilidad extrema, nosotros no tratamos de hacer en forma simultnea averiguaciones e informes analizar cada datos determinan el tipo sanguneo. Sin embargo, todava nos gustara proveer un armazn estndar, simple para todos los registros para un paciente dado. Somos vueltos por la sospecha que si el grano podra ser definido como una entrada sin precedente individual para un paciente, deberamos poder capturar la mayor parte de una ficha mdica en una sola mesa de hecho. En tal mesa de hecho podramos estar tentados de proveer un campo de hecho para cada tipo de medida. Algunos campos seran numricos, y algunos campos seran banderas (o las claves extranjeras para echar a la basura dimensiones consistente en grupos de banderas, tan describieron en Captulo 5). Sin embargo, la pura variedad de entradas sin precedente mdicas posibles nos derrota. Pronto sacaramos en limpio un hecho ridculamente ancho el alboroto de la mesa con demasiados campos de hecho, la mayor parte de que seran nulos o el cero para cualquier entrada mdica especfica. Adems, este estilo de la ranura fija de diseo es muy inflexible porque los tipos nuevos de medida podran agregarse slo por fsicamente alterar la mesa de hecho con la adicin de un campo nuevo.
La Dimensin de Hecho para los Hechos Escasos Tratamos la variabilidad extrema de la entrada mdica del registro con una dimensin especial que llamamos una dimensin de hecho. En Figura 13.8 el tipo de entrada es un dimen-sion de hecho que describe lo que la fila quiere decir o, en otras palabras, lo que el hecho representa. La dimensin de tipo de entrada tambin decide cul de las cuatro clases de hecho los campos (la cantidad, la bandera, el comentario, y el Grupo Unido de Expertos en Fotografa el archivo el nombre)
valen para que la entrada especfica y cmo interprete cada campo. Por ejemplo, la columna genrica de cantidad sirve para cada entrada numrica. La unidad de medida para una entrada numrica dada se encuentra en la fila adjunta de dimensin de tipo de entrada, junto con cualquier restricciones del additivity. Si la entrada es una bandera (por ejemplo, YesNo o HighMedium / Muge), los tipos de valores de la bandera se encuentran en la dimensin de tipo de entrada. Si la entrada es un texto gratis el comentario o un objeto multimedia como la imagen del grfico de Grupo Unido de Expertos en Fotografa o la foto, la dimensin de tipo de entrada alerta que el applica-tion peticionario mire en este hecho campos de la mesa.
La Mesa Mdica de Hecho de Entradas del Registro La llave del Paciente de la Llave de Fecha de entrada (FK) (FK) La llave responsable (FK) del Proveedor de la Llave del Proveedor Attending (FK) Ayudando Llave de la Posicin de Claves de Profesionales (FK) (Multivalued) La llave del equipo (FK) El comentario de Llaves de diagnstico (FK) (Multivalued, cronometre diferir) El tipo de entrada (FK) la Cantidad de Prueba Panel Idaho (DD) Bandera El nombre de archivo de Grupo Unido de Expertos en Fotografa
La llave extranjera para emitir texto de prueba del mtodo /laboratorio La dimensin de hecho para identificar cules hechos estn poblados en esta fila y lo que quieren decir El valor medido de prueba del mtodo /laboratorio El set definido de valores categricos de prueba del mtodo /laboratorio El puntero a la grfica o la foto de mtodo /laboratorio prueba
Figura 13.8 la mesa de Transaccin con hechos sin precedente mdicos escasos, heterogneos y una dimensin de hecho.
Este acercamiento es elegante porque es excelentemente flexible. Podemos sumar que mea-surement nuevo determina el tipo sanguneo simplemente sumando filas nuevas en la dimensin de hecho, no por ah alterando la estructura de la mesa de hecho. Tambin eliminamos los nulls en el diseo clsico de la mesa de hecho de posi-tional porque una fila existe slo si la medida existe. Sin embargo, hay algo de trueques significativos. Usando un hecho la dimensin puede generar montones de hecho nuevo filas de la mesa. Si un acontecimiento resultase en 10 mea-surements numrico, nosotros ahora hacemos 10 filas en la mesa de hecho en vez de un soltero remar en el diseo clsico. Pues las situaciones sumamente escasas, como / el laboratorio clnico o la manufactura experimenta ambientes, ste es un acuerdo intermedio razonable. Cmo cultiva alguna vez, como la densidad de los hechos, nosotros el fin eyectar con fuerza filas de hecho de ms. En este punto ya no tenemos hechos escasos y deberamos regresar al acercamiento clsico de la mesa de hecho. Adems, debemos ser conscientes de que este acercamiento tpicamente complique aplicaciones de acceso de datos. Combinar dos nmeros que han estado ocupados como parte de un solo acontecimiento es ms difcil porque ahora debemos ir a traer dos filas de la mesa de hecho. Al lenguaje normalizado de consulta le gusta realizar funciones de aritmtica dentro de una fila, no a travs de las filas. Adems, debemos cuidarnos de no mezclar cantidades incompatibles en un clculo porque todas las medidas numricas residen en una sola columna de cantidad. Las otras dimensiones en Figura 13.8 deberan ser medianamente obvias. El proveedor paciente, responsable, el proveedor acompaante, la posicin, el equipo, y las dimensiones de diagnstico fueron todos presentes en formas diversas en nuestros anteriores diseos. El panel experimental Idaho es una dimensin degenerada estndar porque probablemente es simplemente una llave de nota natural de sim-ple que vincula entradas mdicas mltiples del registro que fue.
Los comentarios gratis del texto no deberan guardarse en una mesa de hecho en seguida porque desperdician espacia y raras veces participa de averiguaciones. Probablemente, el com-ments del texto gratis ocurre slo en algunos registros. Ms bien, la mesa de hecho debera tener una llave extranjera que seala una dimensin de comentario, como se muestra en Figura 13.8. El uso de un nombre de archivo de Grupo Unido de Expertos en Fotografa a referirse a una imagen, en vez de empotrar la imagen como una masa informe directamente en la base de datos, est algo de una decisin arbitraria. La ventaja de usar un nombre de archivo de Grupo Unido de Expertos en Fotografa es esa otra creacin de imagen, mirando, y los programas editores pueden acceder a la imagen libremente. La desventaja es que una separada base de datos de archivos grficos debe ser mantenida en la sincrona con la mesa de hecho.
La Vuelta Atrs con el Tiempo Como los datos almacenan a los practicantes, nosotros hemos desarrollado tcnicas poderosas para exactamente captando el flujo histrico de datos de nuestras empresas. Nuestras medidas numricas entran en Tablas de hecho, y rodeamos estas Tablas de hecho de descripciones contemporneas de lo que sabemos son ciertas al momento de las medidas. Estas descripciones contemporneas estn empacadas como Tablas de dimensin en nuestros dibujos tcnicos dimensionales. En nuestro almacn de datos de asistencia mdica para la salud, permitimos que las descripciones de paciente, el proveedor, y el pagador evolucionen cada vez que estas entidades cambian sus descripciones. Desde que estos cambios ocurren imprevisiblemente y espordicamente, hemos llamado estas dimensiones (SCDs) lentamente cambiantes. En Captulo 4 desarrollamos tcnicas especficas para ir en procesin sobrescribe (mecanografe
1 SCDs), los cambios ciertos en las entidades en puntos con el tiempo (el tipo 2 SCDs), y Los cambios en las etiquetas que pegamos para entidades (categorice a 3 SCDs). Estos mtodos son Una parte importante de nuestro extracto transforma mtodos de carga (ETL) con cada Actualice.
Sin embargo, qu hacemos cuando recibimos datos que llegan tarde que debera haber estado hace cargado en las semanas del almacn de datos o los meses? Algunos de nuestros cedures no funcionarn. Hay dos casos interesantes que necesitan discutirse separadamente.
El Hecho Que Llega Tarde Rema Usando nuestra panorama paciente de tratamiento, supone que recibamos hoy una fila de treat-ment que tiene varios meses de edad. En la mayora de almacenes operacionales de datos estamos dispuestos a introducir esta fila que llega tarde en su posicin histrica correcta, aun sin embargo nuestros resmenes pues el anterior mes ahora cambiar. Cmo debemos escoger alguna vez, las viejas filas contemporneas de dimensin que aplique para esto
El tratamiento cuidadosamente. Si hemos fechado la dimensin hace avanzar con el remo en nuestro tipo 2 SCDs, en ese entonces nuestro procesamiento consiste en los siguientes pasos: 1. Para cada dimensin, encuentre la fila correspondiente de dimensin cuyo fechador es el ltimo fechador menos que o igual hasta la fecha del tratamiento. 2. Utilizar las claves vicarias funda en lo cada de las filas de dimensin de paso 1, reemplaza las llaves naturales de la fila que llega tarde de hecho con las llaves vicarias. 3. Introduzca la fila que llega tarde de hecho en la particin fsica correcta de la base de datos conteniendo las otras filas de hecho del tiempo del tratamiento que llega tarde. Hay algunos puntos sutiles aqu. Primero, suponemos que todo nuestras filas de dimensin contienen fechadores gemelos que indican el intervalo de tiempo cuando esa descripcin detallada partic ular fue vlida. Necesitamos tener el cuidado de hacer una cadena intacta de poco traslapo comenzar y el fin pasa de moda para cada paciente, proveedor, y pagador porque debemos encontrar que las filas correctas de dimensin para el hecho nuevo reman a punto de estar insertas. Un segundo punto sutil se remonta a nuestra suposicin que tenemos un almacn de datos de opera-tional que lega para insertar estas filas que llegan tarde en los viejos meses. Si su almacn de datos tiene que empatar para los libros, en ese entonces usted no puede cambiar un viejo total mensual, aun si ese viejo total fue incorrecto. Ahora usted tiene una situacin tramposa en la cual la dimensin de fecha en el registro de tratamiento es para una fecha que reserva, cul puede ser hoy, pero el otro paciente, otra proveedora, y dimensiones del pagador no obstante deberan referirse a las viejas descripciones en la manera en que describimos ms temprano. Si usted est en esta situacin, usted debera tener un debate con su gerente del departamento financiero para asegurarse de que l o ella poco aguanta qu usted est desempendose. Un acuerdo intermedio interesante es llevar dos dimensiones de fecha en registros de tratamiento. Uno se refiere a la fecha real de tratamiento, y el otro se refiere a la fecha que reserva. Ahora podemos reinvertir los registros de tratamiento ya sea operacionalmente o por los libros. El tercer punto sutil es el requisito para introducir la fila que llega tarde de
tratamiento en la particin fsica correcta de la base de datos conteniendo sus hermanos de contem-porary y sus hermanas. De este modo, cuando usted se mueve una particin fsica de una forma de almacenamiento a otro o cundo usted realiza un respaldo o restaura operacin, usted afectar todo lo que el tratamiento hace avanzar con el remo desde un intervalo particular de tiempo. En la mayora de los casos esto es lo que usted quiere hacer. Usted puede garantizar que todas las filas de hecho en un perodo de tiempo ocupan la misma particin fsica si usted declara la fsica particin de discos de la mesa de hecho para basarse en la dimensin de fecha, donde la fecha vicaria que las llaves son asignadas en una orden previsible de secuencia.
La Dimensin Que Llega Tarde Rema Una dimensin que llega tarde de la que la fila presenta un set enteramente diferente publica eso, en ciertos aspectos, est ms complicado que una fila que llega tarde de hecho. Supongo que la fila paciente de dimensin del fulano de tal contiene un atributo marital de la bandera que siempre contuvo el valor el Soltero. Tenemos un nmero de filas pacientes para fulano de tal porque sta es una dimensin lentamente cambiante y otros atributos como la direccin de John y el estatus de empleo ha cambiado durante el ao pasado o dos. Hoy a nosotros nos es notificado que el fulano de tal estaba casado el 15 de julio de 1999 y ha estado casado desde entonces. Aadirle esta informacin nueva a que los datos almacenan requiere los siguientes pasos: introduzca una fila fresca, con un substituto nuevo teclea, para fulano de tal en que la dimensin paciente con el atributo de estado civil coloc Casado con y el effec-tive al que la fecha se sediment el 15 de julio de 1999. escudrie adelante en la mesa paciente de dimensin desde julio 15, 1999, encontrando algunas otras filas para fulano de tal, y destructivamente sobrescribe el campo de estado civil para Married. encuentro que todo hecho rema involucrndolo al fulano de tal del 15 de julio de 1999 hasta la primera parte despus cambio para l en la dimensin luego del 15 de julio de 1999 y destructivamente cambio la llave extranjera paciente en esas filas de hecho para la llave vicaria nueva creada a comps 1.
ste es un cambio medianamente confuso, pero usted debera poder automatizar estos pasos en un buen ambiente programable ETL. Tenemos algunos asuntos sutiles en este caso, tambin. Primero, necesitamos revisar para ver si algn otro cambio tuvo lugar para fulano de tal el 15 de julio de 1999. Si es as, en ese entonces slo necesita realizar paso 2. No necesitamos una fila nueva de dimensin en esta causa especial. En segundo lugar, desde que estamos usando un par de fechadores en cada fila de dimensin del producto, necesitamos encontrar mientras ms cercano antes del 15 de julio fila del paciente para fulano de tal y cambiarnos a su fecha de fin el 15 de
julio de 1999, y tambin necesitamos encontrar lo ms cercano con posterioridad al 15 de julio fila del paciente para fulano de tal y sedimentarnos la fecha de fin por el
julio 15, 1999 entrada para lo comienza la fecha de esa siguiente fila. Lo tengo?
Finalmente, vemos de este ejemplo por qu las llaves del substituto para todas las dimensiones deducen excepcin la fecha o el tiempo no puede ser ordenado de cualquier modo. Usted nunca sabe cundo usted va a tener que asignar una llave vicaria para una fila que llega tarde. Y desde llaves vicarias est simplemente asignado en la orden numrica sin cualquier lgica o struc-ture, usted fcilmente puede tener una llave vicaria de valor alto representando una fila de dimen-sion que es muy vieja.
Si Dios quiere, estos el hecho que llega tarde y las filas de dimensin son inusuales en la mayor parte de nuestros almacenes de datos. Si nada ms, son molestos porque cambian las cuentas y totales por anterior historia. Sin embargo, hemos tomado un compromiso como guardianes del almacn de datos para presentar la historia de nuestra empresa como accu-rately tan posible, as es que le deberamos dar la bienvenida a las viejas filas porque son mak ing nuestras bases de datos ms completas. Algunas industrias, como la asistencia mdica para la salud, tienen enormes nmeros de filas que llegan tarde. En tales casos, estas tcnicas, en vez de ser se especializ las tcnicas para el caso inusual, pueden ser el modo de escala dominante de ir en procesin.
Resumen La asistencia mdica para la salud no slo es un rea aplicativo importante en su propio derecho, pero tambin provee al diseador del almacn de datos de un nmero de ejemplos evidentes del diseo que pueden ser usados en muchas otras situaciones. En este captulo que hemos visto: El crculo de valor, donde un gran nmero de organismos necesita mirar los mismos datos de adentro paralelamente sin cualquier sentido fuerte de ordenacin en secuencia de tiempo. Cmo construir alguna vez, los asuntos de una arquitectura del autobs del almacn de datos del crculo de valor con dimensiones conformadas y los hechos conformados son exactamente igual como las cadenas de valor ms convencionales. La cantidad muy pequea de la foto de atesoramiento de mesa de hecho se aplic a una lnea mdica de la cuenta tem. Esta cantidad muy pequea fue apropiado por la duracin relativamente breve de una cuenta mdica comparado algo as como una cuenta corriente, donde la foto peridica es ms correcta. Los papeles tocaron por la dimensin de fecha en el grano de la foto de atesoramiento, as como tambin los papeles jugaron por el proveedor y dimensiones del pagador en otras Tablas de hecho de este captulo. Los papeles son implementados como separados, especficamente denominados puntos de vista en una sola dimensin maestra subyacente.
Multivalued dimensiona, especialmente la dimensin de diagnstico. En muchos casos podemos asociarnos un factor que oprime con cada uno de los valores en una entrada multipreciada de dimensin a fin de dejar dotaciones calcularse sobre los hechos numricos en la mesa de hecho. Llamaramos esta clase de informe un cor-rectly informe oprimido. Sin embargo, en algunos casos donde tenemos pocos deseos de hacer cesin oprimiendo factores, la dimensin multipreciada todava nos deja producir informes de impacto. Un set extendido de hechos basados en costos que nos dejan implementar una P y el dibujo tcnico L. Sumar estos hechos basados en costos es muy atrayente, pero es una buena cantidad de trabajo. Lo mejor cuesta agrandar un diseo son costos basados en actividades porque estos no problematizan tambin para asociar con filas individuales de hecho como nuestros rubros contables mdicos de la cuenta.
Complique acontecimientos modelados como la sola mesa de hecho reme conteniendo varias dimensiones multipreciadas. En estos casos a menudo no construimos oprimir factores en todas las dimensiones multipreciadas porque la interaccin entre los factores que oprime se vuelve absurda. Las dimensiones de hecho acostumbraron organizar measure-ments sumamente escaso, heterogneo en un armazn solo, uniforme. Nuestro ejemplo plausiblemente cubri fichas mdicas generales consistente en las medidas numricas estndar, El laboratorio nico en su gnero resulta, categricas medidas textuales, el texto gratis hace comentarios, y los datos de imagen.
Comercio Electrnico El carbono HAPTE R14
tungsteno
Los negocios intensivos en la epidermlisis bullosa tienen acceso a una clase nueva de fuente de datos que literalmente registra los gestos de cada visita del sitio Web. Le llamamos el clickstream. En su forma ms elemental, el clickstream es cada acontecimiento de la pgina registrado por cada uno de los servidores de Web de la compaa. El clickstream contiene un nmero de dimen-sions nuevo como pgina, la sesin, y referrer que es desconocido en nuestros centros de compras de datos de conven-tional. El clickstream es un caudal de informacin, fcilmente siendo el conjunto de datos del texto ms grande y de nmero que alguna vez hemos considerado para un almacn de datos. Aunque el clickstream es el desarrollo ms nuevo excitante en loza de datos alojando, al mismo momento que puede ser lo ms difcil y ms exasperando. Se conecta al resto de almacn? Pueden ser sus dimensiones y hechos conformados en un almacn de datos lleva en autobs arquitectura? La historia llena de la fuente de datos del clickstream y su implementacin por com-panies, como esos consistieron en el comercio electrnico, es informado en el libro completo sobre este tema, La Data Webhouse Toolkit, por Ralph Kimball y Richard Merz (Wiley, 2000). Este captulo es una excursin del relmpago de las ideas centrales sacadas de La Data Webhouse Toolkit. Comenzamos por describir la
fuente cruda de datos del clickstream. Mostramos cmo disear un centro de compras de datos alrededor de los datos del clickstream. Finalmente, integramos este centro de compras de datos en una mayor matriz de ms centros de compras convencionales de datos para un detallista grande de Web y sostenemos la opinin que la rentabilidad del canal de ventas de Web puede ser medida si usted ubica los costos correctos de regreso a las ventas de indi-vidual del detallista.
277
Subsidiaria 14 discute los siguientes conceptos: resuma manual de instruccin sobre interacciones del servidor de cliente de Web las caractersticas nicas de datos del clickstream, incluyendo los retos de identificar a las visitas, su origen, y su sesin completa las dimensiones especficas a Clickstream, como la pgina, el acontecimiento, la sesin, y las dimensiones de referencia las Tablas de hecho Clickstream para la sesin completa, el acontecimiento de la pgina del individuo, y un resumen agregado integrando el centro de compras de datos del clickstream en el resto de almacn de datos de la empresa el centro de compras de datos de rentabilidad de Web
El Manual De Instruccin de Interacciones del Servidor de Cliente de Web Comprender las interacciones entre un cliente de Web (el navegador) y un servidor de Web (el sitio Web) es esencial para comprender la fuente y significado de los datos en el clickstream. En Figura 14.1 mostramos un navegador, llamados el Navegador de la Visita. Miraremos a qu ocurre en una interaccin tpica del per-spective de un usuario del navegador. El navegador y el sitio Web se interactan el uno al otro a travs de la Internet usando protocolo de comunicacin de Internet el Protocolo de Traslado de Hipertexto (el HTTP). Primero, la visita da un clic sobre un botn o un enlace de hipertexto conteniendo un localizador de recursos uniforme (el URL) para acceder a un sitio Web particular, mostrado como la accin de anfiteatro negro 1 en Figura 14.1. Cuando esta peticin de HTTP alcanza el sitio Web, el monaguillo devuelve el artculo pedido (accin 2). En nuestra ilustracin, esto va a traer un docu-ment en formato de Lenguaje de Etiquetacin de Hipertexto (el HTML) websitepage.html. Una vez que el documento es enteramente recuperado, web-sitepage.html de tomografas del navegador de la visita y avisos varias referencias para otros documentos de Web que debe satisfacer antes de su trabajo es completado; El navegador debe recuperar
otro com-ponents de este documento en las peticiones separadas. Note ese la nica accin humana tomada aqu debe dar un clic sobre el enlace original. Todo lo dems de las acciones que entienden en este ejemplo son interacciones computadoras a computadora provocadas por el clic y administrado, en la mayora de los casos, por instrucciones acarreado en el documento HTML inicialmente del que se hizo un download, websitepage.html. Para apresurar la marcha de sensibilidad de la pgina de Web, la mayora de navegadores ejecutarn estas acciones de mucha consecuencia adentro paralelamente, tpicamente con hasta 4 o ms peticiones de HTTP siendo reparados concurrentemente. Los descubrimientos del navegador de la visita una carta de recomendacin para una imagen un logotipo quiz que, de su URL, es localizado en Website.com, el mismo lugar que recuper el documento HTML inicial. El navegador publica una segunda peticin para el servidor (accin 3), y el monaguillo responde devolviendo la imagen especificada.
El Navegador de la Visita
El HTML Pages
Website.com
El clic Link
Usuario Perfil
Imgenes
Websitepage.html Imagen 3 Banner-ad.com Lee Cookie
El Anuncio del Estandarte Publicidades
Link escondido
Cookie File Website.com

Banner-ad.com
Lee
Cookie Profiler.com
El Detalle Demogrfico
Profiler.com
Resuelva 14.1 Interacciones entre el servidor de Web (el sitio Web) del cliente (el navegador) y de Web.
El navegador contina para la siguiente referencia en websitepage.html y encuentra una instruccin para rescatar otra imagen de Banner Ad.com. El navegador hace esta peticin (accin 4), y el monaguillo en Banner Ad.com interpreta una peticin para la imagen en una forma especial. En vez de parte trasera inmediatamente que enva una imagen, los asuntos de primera parte del servidor del anuncio de estandarte una peticin de la galleta para el navegador de la visita pidiendo el contenido de cualquier galleta que podra haber sido colocada previamente en la PC de la visita por Banner Ad.com. El estandarte respecto a sitio Web recupera esta galleta, examina su contenido, y usa el contenido como una llave para decidir cul estandarte debera recibir respecto a la visita. Esta decisin se basa en los intereses del peasco de visus o en anuncios previos la visita haban sido enviados por este servidor particular del anuncio. Una vez que el estandarte respecto a servidor hace una determinacin del anuncio ptimo, le devuelve la imagen seleccionada a la visita. El estandarte respecto a servidor entonces pone en bitcora cul
Respecto a eso ha colocado junto con la fecha y los datos del clickstream de peticin de la visita. Si no tuviese el estandarte respecto a servidor encontrado su galleta, hubiese enviado una galleta persistente nueva al navegador de la visita para utilizacin futura, hubiese enviado un anuncio espordico del estandarte, y hubiese empezado una historia en su base de datos de interacciones con el navegador de la visita. La peticin de HTTP del navegador de la visita para el estandarte respecto a servidor sigui con eso un crucial trozo de informacin conocido como el referrer. El referrer es el URL del agente responsable para colocar el enlace en la pgina. En nuestro ejemplo el referrer es Website.com/websitepage.html. El referrer no es el navegador del usuario sino ms bien es el contexto de HTML en el cual el enlace para Banner Ad.com estaba incrustado. Porque Banner Ad.com ahora sabe quin fue el referrer, puede depositar a favor de Website.com para haber colocado una publicidad en una ventana del navegador. sta es una sola impresin. El anunciante puede ser pasado la factura de esta impresin, con la renta siendo compartido por el referrer (Website.com) y el servidor publicitario (Banner-Ad.com). Si el sitio Web comparte informacin del leo de Web con el sitio respectivo, ser de valor compartir atributos de la pgina tambin. En otras palabras, no slo haga que queremos el URL de la pgina respectiva, pero tambin queramos saber lo que el propsito de la pgina fue. Fue eso una pgina de navegacin, la pgina de un socio, o una pgina general de bsqueda? Mientras el monaguillo del anuncio se ocupa primordialmente de colocar contenido apropiado, los tratos del prolimador con suministrar informacin demogrfica acerca de Web sitan a las visitas. En nuestro documento HTML original, websitepage.html tuvo un campo escondido que con-tained una peticin para recuperar un documento especfico de Profiler.com (accin 5). Cuando esta peticin alcanz el servidor de perfilador, Profiler.com inmediatamente trat de encontrar su galleta en el navegador de la visita. Esta galleta contena una identificacin de usuario colocada previamente por el perfilador que se usa para identificar a la visita y saques como una llave para la informacin personal contenida en la base de datos del perfilador. El prolimador o le podra devolver sus datos del perfil al navegador de la visita ser devuelto para el sitio Web inicial o enviarle una notificacin de tiempo real al referrer, Website.com, por un camino alternativo alertando a
Website.com que la visita es actualmente puesta en bitcora encima de Website.com y mirando una pgina especfica (accin 6). Esta informacin tambin podra ser devuelta al documento HTML para ser devuelta al referrer como parte de una cuerda de averiguacin la prxima vez que una peticin de HTTP es enviada a Website.com. Aunque la Figura 14.1 funciones tres los sitios diferentes consistieron en sirviendo las tiendas de campaa de contra de un documento, son posible, ciertamente probable, ese estas funciones estarn combinadas en menos servidores. Es probablemente que hacer publicidad y perfilar estar hecho dentro de la misma empresa, as es que una sola peticin (y la galleta) saciara para recuperar informacin personal que hara ms precisamente le apuntan a los anuncios que son devueltos. Sin embargo, es igualmente posible que una pgina de Web pudiese contener ref-erences para los servicios diferentes del anuncio /perfil, con tal que la renta para el referrer de fuentes mltiples.
Por Qu el Clickstream No Es Simplemente Otra Fuente de Datos El clickstream no es simplemente otra fuente de datos que es extrada, limpiada, e inundada el mercado a bajos precios en el almacn de datos. El clickstream es realmente un collec-tion que evoluciona de fuentes de datos. Hay ms que una Web de docena que el archivo del leo del servidor formatea para datos apresadores del clickstream. Estos formatos del archivo del leo tienen datos optativos com-ponents que, si fueron consumidos, pueden ser demasiado de ayuda identificando a las visitas, las sesiones, y el significado detrs de las apariencias de comportamiento. Estamos en la infancia de este juego del clickstream, y es una apuesta segura tan nueva poniendo en bitcora capacidades y tala forestal nueva que los formatos se harn disponibles de forma regular. El lenguaje extensible (XML) del Apunte tiene el potencial para hacer la estructura de nuestras pginas de Web mucho ms expresivo, que debe afectar la fuente de datos del clickstream. Por la naturaleza distribuida de Internet, los datos clickstream son a menudo cobrados simultneamente por servidores fsicos diferentes, an cuando la visita piensa que l o ella le interacta un solo sitio Web. Aun si el logaritmo archiva ser col-lected por estos servidores separados es compatible, un problema muy interesante surge sincronizando los archivos del leo ex post facto. Recuerde que un servidor ocupado de Web puede estar tramitando centenares de acontecimientos de la pgina por segundo. Es difcil que los relojes en servidores separados estarn en sincrona para un centavo de un segundo. La Data Webhouse Toolkit explora acercamientos tcnicos diversos para solucionar este problema de sincronizacin. Tambin obtenemos datos del clickstream de fiestas diferentes. Adems de los nuestros pone en bitcora archivos, podemos obtener datos del clickstream de socios respectivos o de proveedores de servicio de Internet (ISPs). Tambin podemos obtener datos del clickstream de servicios del observador de Web que hemos alquilado para colocar un control especial en ciertas pginas de Web que los avisan de una visita abriendo la pgina. Otra forma importante de datos del clickstream es la especificacin de bsqueda dada a un motor de bsqueda que entonces dirige la visita para el sitio Web.
Finalmente, si somos un ISP proveerle el acceso de Web a directamente asoci a los clientes, tenemos una perspectiva nica porque vemos cada clic de nuestras visitas familiares de cap-tive que pueden permitir mucho ms anlisis poderoso e invasivo de las sesiones de la visita de fin. La forma ms anticida de datos del clickstream de un sitio Web normal est sin nacionalidad. Es decir, el leo muestra un acontecimiento espordico de recuperacin de la pgina pero no le provee una corbata clara a otros acontecimientos de la pgina a otro sitio en bruto. Sin alguna otra clase de ayuda de contexto, es difcil o imposible de fuente fidedigna identificar una sesin completa de la visita. La otra frustracin grande con datos bsicos del clickstream es el anonimato de la sesin. A menos que la visita acuerde revelar su identidad de algn modo, a menudo no podemos estar seguros quin l o ella es o si alguna vez hemos visto a la visita antes.
En ciertas situaciones aun no podemos poder distinguir los clics de dos visitas que hacen una lectura ligera nuestro sitio Web simultneamente.
Los Retos de Rastrear con Clickstream Data Los datos Clickstream contienen muchas ambigedades. Identificando orgenes de la visita, sesiones de la visita, e identidades de la visita es algo de un arte interpretativo. El navegador esconde en reserva y los monaguillos del apoderado hacen estas identificaciones aun ms desafiantes.
Identificando el Origen de la Visita Si somos con suerte, nuestro sitio es la pgina anfitriona predeterminada para el navegador de la visita. Cada vez que la visita abre su navegador, nuestra pgina principal del sitio Web es la primera cosa que l o ella ve. Esto es bonito improbable a menos que somos el Webmaster para un sitio porta o una intrarred a casa pgina, pero muchos sitios tienen botones que, cuando son hechos clic, instigan a la visita a colocar a su URL como la pgina principal del sitio Web del navegador. Desafortunadamente, no hay forma fcil para determinar de un leo ya sea o no nuestro sitio est colocado como la pgina principal del sitio Web de un navegador. Una visita puede ser dirigida a nuestro sitio de una bsqueda en un portal como Provinciano ! o Alta Vista. Tales referencias pueden venir cualquier del ndice del portal o la tabla de contenidos, para cul usted pudo haber pagado una retribucin de colocacin, o de una palabra o la bsqueda de la tienda de campaa de contra. Para muchos sitios Webes, la fuente ms comn de visitas es de una seal de lectura del navegador. En la orden para esto ocurrir, la visita tendr que tener previamente bookmarked el sitio, y esto ocurrir slo despus de que el inters del sitio y niveles de confianza cruzan el umbral de la seal de lectura de la visita. Desafortunadamente, cuando una visita usa una seal de lectura, el campo del referrer est vaco, tal como si la visita haba introducido el URL a mano.
Finalmente, el sitio puede ser alcanzado como resultado de un clic efectivo un clic deliberado en un enlace del texto o grfico de otro sitio. sta puede ser una referencia pagada tan por un anuncio del estandarte o una referencia libre de un individuo o el sitio cooperador. En el caso de los clics efectivos, el sitio respectivo casi siempre ser identificable en datos del leo referrer del sitio Web. Captando esta informacin crucial del clickstream es importante para verificar la eficacia de comercializar programas. Tambin provee datos cruciales para la auditora factura usted puede recibir de cargos que anuncian clic efectivo.
Identificando la Sesin La mayora de datos cntricos en la Web almacenan aplicaciones requerirn que cada sesin de la visita (la visita) tenga su etiqueta nica de identidad, similar para una tienda de comestibles
El boleto de punto de venta Idaho. Llamamos esto el sesin Idaho. Las filas de cada visita individual ponen en marcha en una sesin, ya sea derivativo del clickstream o de una interaccin aplicativa, deben contener esta etiqueta. Mantenga en mente, sin embargo, que la aplicacin operacional genere esta sesin Idaho, no el servidor de Web. El protocolo bsico para la Red Mundial, HTTP, est sin nacionalidad es decir, le falta el concepto de una sesin. No hay entrada en el sistema del factor que se une al extrnseco en la mucosa digestiva o las acciones de salida del sistema construyeron en el HTTP, as es que la identidad de sesin debe ser establecida en alguna otra forma. Hay varias formas para hacer esto: 1. En muchos casos, el individuo le atina a comprender una sesin puede ser consoli-date cotejando entradas ntimas en tiempo del leo del mismo anfitrin (el Protocolo Internet, o el protocolo entre redes, la direccin). Si el leo contiene un nmero de entradas con el mismo Idaho anfitrin en un corto tiempo (por ejemplo, una hora), uno razonablemente puede suponer que las entradas son para la misma sesin. As de El mtodo fracasa para visitas de ISPs grandes porque las visitas diferentes pueden reutilizar direcciones IPs dinmicamente asignadas durante un breve lapso de tiempo. Adems, las direcciones IPs diferentes pueden ser usadas dentro de la misma sesin para la misma visita. Esta va de entrada tambin presenta problemas al tratar de navegadores que estn detrs de algunas cortinas de fuego. A pesar de estos proB-lems, muchos productos comerciales de anlisis del leo usan este mtodo de sesin rastreando, lo cual no requiere galletas o caractersticas especiales del servidor de Web. 2. Otro, mucho ms mtodo satisfactorio es dejar al navegador de Internet colocar una galleta nivelada en la sesin dentro del navegador de Internet de la visita. Esta galleta durar con tal de que el navegador est abierto y, en general, no estar disponible en sesiones del navegador de subSe-quent. El valor de la galleta puede servir de una sesin temporal Idaho no slo para el navegador sino que tambin para cualquier aplicacin que pide la galleta de sesin del navegador. Esta peticin debe venir del mismo servidor de Web (en verdad, el mismo dominio) que coloc la galleta en primer lugar. Usar un valor transitorio de la galleta como una sesin temporal Idaho para ambos el clickstream y el poner en bitcora aplicaciones deja un acercamiento franco asociar los datos de ambos estas fuentes durante leo de
postsesin yendo en procesin. Sin embargo, usar una galleta transitoria tiene la desventaja que usted no puede decir cuando la visita regresa al sitio posteriormente en una sesin nueva. 3. Los conectores seguros del HTTP acodan (el Espaol Como Segunda Lengua) ofertas una oportunidad para rastrear una sesin de la visita porque puede incluir una accin de entrada en el sistema por la visita y el cambio de llaves de cdigo. Lo negativo para usar este mtodo es eso a rastrear la sesin, el cambio entero de informacin necesita estar en Espaol Como Segunda Lengua areo alto, y la visita puede ser alejada por anuncios precautorios prendarios que pueden aparecer de pronto cuando ciertos navegadores son usados. Adems, cada servidor anfitrin debe tener su certificado prendario nico. 4. Si la generacin de la pgina es dinmica, usted puede intentar mantener al estado de la visita colocando una sesin Idaho en un campo escondido de cada pgina devuelta a la visita.
Esta sesin que Idaho puede ser devuelto al servidor de Web como una cuerda de averiguacin anexada a un subsiguiente URL. Este mtodo de rastreo de sesin requiere que una gran cantidad de control sobre los mtodos de la generacin de pgina del sitio Web asegure que el hilo de sesin Idaho no est quebrado. Si la visita da un clic sobre los enlaces que no soportan esta sesin Idaho reciprocan, una sola sesin dar la apariencia de ser sesiones mltiples. Este acercamiento tambin fracasa si los vendedores mltiples suministran contenido en una sola sesin. 5. Finalmente, el sitio Web puede establecer una galleta persistente en la PC de la visita que se suprimi por el navegador cuando la sesin cesa. Por supuesto, es posible que la visita tendr su navegador se sediment para rehusar galletas o por completo puede expulsar que su archivo de la galleta manualmente, as no hay garanta incondicional una galleta tan persistente pareja sobrevivir. Aunque a cualquier galleta dada le puede ser ledo slo por el sitio Web tan causado ella para ser creado, los grupos de cer-tain de sitios Webes pueden acordar almacenar una etiqueta comn de Idaho que dejara a estos sitios combinar sus nociones separadas de una sesin de la visita en un reemplazo. En resumen, el mtodo ms poderoso de sesin el rastreo de registros del leo del servidor de Web es incrustar una galleta persistente en el navegador de la visita. Otro menos mtodos de pow-erful incluyen a colocar una galleta poco persistente nivelada en la sesin o casi asociar entradas ntimas en tiempo del leo del mismo anfitrin. El mtodo ms reciente requiere que un algoritmo robusto en el postprocesador del leo asegure resultados satisfactorios, en parte decidiendo cuando no tomar en serio los resultados.
Identificando A la Visita Identificar a una visita especfica que pone en bitcora encima de nuestro sitio presenta una cierta cantidad de los problemas ms desafiantes afrontando un diseador del sitio, Webmaster, o gerente de datos almacenando para las siguientes razones: Las visitas de Web tienen el deseo de ser annimas. Pueden no tener razn para confiar en nosotros, lo
La Internet, o su PC con identificacin personal o crdito carda informacin.
Si pedimos la identidad de una visita, l o ella es propenso a mentir acerca de ella. Se cree que cuando preguntase su nombre en una forma de la Internet, los hombres introducirn un seudnimo 50 por ciento del tiempo y las mujeres usarn un seudnimo
80 por ciento del tiempo.
No podemos estar seguros cul familia el miembro visita nuestro sitio. Si obtenemos una identidad por asociacin, por ejemplo, de una izquierda persistente de la galleta durante una visita previa, la identificacin es slo para la computadora, no para la visita de spe-cific. Cualquier miembro familiar o cualquier empleado de compaa pudo haber usado esa computadora particular en ese momento con el tiempo.
No podemos suponer que un individuo est siempre en la misma computadora. Las galletas provistas en servidor identifican una computadora, no un individuo. Si alguien accede al mismo sitio Web de una computadora de la oficina, una PC anfitriona, y un com-put de la computadora porttil, una galleta diferente del sitio Web son probablemente opcin de venta en cada uno trabaja a mquina.
Los Servidores del Apoderado Cuando un navegador hace una peticin de HTTP, que la peticin no es siempre para la que se sirvi del servidor especific en un URL. Muchos ISPs aprovechan servidores del apoderado para reducir trfico de la Internet. Los servidores del apoderado se usan para esconder en reserva contenido frecuentemente pedido en una posicin entre su fuente pretendida y una visita de fin. Tal prox-ies es utilizada comnmente por ISPs grandes como enlace de la AOL y Tierra, y en algunos casos, una peticin de HTTP aun no puede dejar PC de la visita. Puede ser satisfecha del escondite local del navegador de objetos recientemente a los que se accedi. Los servidores del apoderado pueden introducir tres problemas, tan ilustrados en Figura 14.2. Primero, un apoderado puede entregar contenido pasado de tiempo. Aunque la Web que las pginas pueden incluir etiquetas que distingue a apoderado servidores ya sea o no el contenido puede ser escondido en reserva y cuando contenido caduca, estas etiquetas a menudo se omiten por Webmasters o ignoradas por servidores del apoderado. En segundo lugar, los apoderados pueden satisfacer una peticin contenta sin correctamente notificando al monaguillo originario que la peticin ha sido para la que se sirvi por el apoderado. Cuando un apoderado maneja una peticin, la convencin manda que debera reenviar un mensaje que seala que una respuesta del apoderado ha sido hecha para el servidor pretendido, pero esto no es confiable. Como consecuencia, nuestro Webhouse puede perder acontecimientos cruciales que son diferentes requeridos para hacer sentido de los acontecimientos que comprenden una sesin del sitio del navegador /Web. En tercer lugar, si la visita ha venido sin embargo un apoderado, el sitio de Web no sabr quin hecho la peticin
de la pgina a menos que una persona est presente. Es importante, por consiguiente, para hacer uso liberal de fechas de vencimiento y ninguna etiqueta del apoderado en el HTML contenido de su sitio Web. Esta ayuda de voluntad asegure que obtenemos tantos datos tan posible para nuestro almacn. El tipo de apoderado a quien nos referimos en este debate es llamado un apoderado acometedor. Est fuera de nuestro control porque le pertenece a una compaa que enlaza en red o un ISP. Otro tipo de servidor del apoderado, llam a un apoderado inverso, puede estar colocado en parte delantera de los servidores de Web de nuestra empresa para ayudarles peticiones del offload para contenido frecuentemente al que se accedi. Esta clase de apoderado est enteramente dentro de nuestro control y usualmente no le presenta impedimento a coleccin de datos Webhouse. Debera poder sorber capa la misma clase de informacin del leo tan tan producido por un servidor de Web y discutido en la siguiente seccin.
La peticin Respuesta
La Internet
ISP
La interaccin normal de HTTP (el poco apoderado) El Servidor de Web
El leo de Web capturado aqu!
La peticin Respuesta ISP
El servidor del Apoderado del ISP Reconocimiento
La Internet
La interaccin delantera de HTTP del Apoderado El Servidor de Web
La peticin Respuesta
La Internet
ISP
El Servidor de Web
Ponga al revs Interaccin de HTTP del Apoderado
Resuelva 14.2 arquitecturas del Apoderado. Apoderado Servidores
Los Escondites del Navegador Los escondites del navegador tambin introducen incertidumbres en nuestros intentos a rastrear todos los acontecimientos que ocurren durante una sesin de la visita. La mayora de navegadores almacenan una copia de
Los objetos recientemente recuperados como las pginas de HTML y las imgenes en un escondite local del objeto en el sistema de archivo de la PC. Si la visita regresa a una pgina ya en su escondite local (por ejemplo, dando un clic sobre el botn De Atrs) del navegador, ningn registro de este acontecimiento ser enviado al servidor, y el acontecimiento no se grabar. Esto quiere decir que nunca podemos tener la seguridad de que tengamos un mapa lleno de las acciones de la visita. Al igual que con apoderados, podemos tratar de forzarle el navegador para siempre obtener objetos a partir de un servidor en vez de escondite incluyendo apropiado Ninguna etiqueta Cache de HTML, pero no podemos elegir hacer esto por la funcin u otras razones relatadas en contenido. Una incertidumbre similar puede ser introducida cuando una visita abre ventanas mltiples del navegador para el mismo sitio Web. La visita puede tener mltiples puntos de vista de pginas diferentes del sitio disponible en su pantalla de la PC, pero no hay de cualquier forma para el servidor de para Web para saber esto.
Las dimensiones especficas para el Clickstream Antes de que diseemos centros de compras especficos de datos del clickstream, efectuemos cobros juntos tantas dimensiones como podemos pensar de eso puede tener relevancia en un clickstream envi ronment. Cualquier solo dibujo tcnico dimensional no usar todas las dimensiones de inmediato, pero da ganas de un portafolio de dimensiones esperando a ser usado. La lista completa de dimensiones para un detallista de Web podra incluir: salga en citas el tiempo de da parte vendedor transaccin estatus tipo trasportador la posicin de facilidades
producto cliente los medios de comunicacin causal
la poltica de servicio la organizacin interna empleado mande a llamar acontecimiento sesin referencia Todas las dimensiones en la lista, excepto por lo ltimo cuatro, son datos familiares tienen cuidado con que la casa dimensiona, la mayora de la cual hemos acostumbrado ya en anteriores captulos de este libro. Lo ltimo cuatro, sin embargo, es las dimensiones nicas del clickstream y garantiza alguna atencin cuidadosa. Tambin proveeremos preliminar dimensionando esti-mate para darle un sentido de su magnitud.
Page Dimension La dimensin de la pgina describe el contexto de la pgina para un acontecimiento de la pgina de Web, como se muestra en Mesa 14.1. El grano de esta dimensin es la pgina individual. Nuestra definicin de pgina debe ser lo suficientemente flexible para manejar la evolucin de pginas de Web de la entrega actual de la pgina, en su mayor parte esttica para entrega de la pgina altamente dinmica en la cual la pgina exacta que el cliente ve es nico a ese instante con el tiempo. Asumiremos aun en el caso de la pgina dinmica que hay una funcin bien definida que caracteriza la pgina, y usaremos as de describir la pgina. No crearemos una fila de la pgina para cada instancia de una pgina dinmica porque eso producira una dimensin con un nmero astronmico de filas, pero las filas no diferiran en formas interesantes. Lo que queremos es una fila en esta dimensin para cada tipo interesante, distinguible de pgina. Las pginas estticas probablemente obtienen su fila, pero las pginas dinmicas seran agrupadas por el tipo y funcin similar. Cuando la definicin de una pgina esttica cambia porque el Webmaster la altera, la fila en la dimensin de la pgina o puede ser sobre-escrita o puede ser tratada como una dimensin lentamente cambiante. Esta decisin es cuestin de poltica
para el datos Webhouse, y depende en si los viejos y descripciones nuevas de la pgina difieren materialmente y si la vieja definicin debera ser mantenida por propsitos de anlisis de his-torical. Los diseadores del sitio Web y los desarrolladores Webhouse necesitan colaborar para asignarle los atributos y cdigos descriptivos a cada pgina servida por el servidor de Web, ya sea la pgina es dinmica o esttica. Idealmente, los desarrolladores de la pgina de Web suministran atributos y cdigos descriptivos con cada pgina que crean y empotran estos
Mesa 14.1 el Diseo Recomendable para la Page Dimension AT TR YO B UTE SAM P LE VALU ES Page Key Surrogate aprecia, 1-N La Esttica de la Fuente de la Pgina, Dinmico, Desconocido, Corrompido, Inaplicable El Portal de Funcin de la Pgina, la Bsqueda, la Descripcin del Producto, la Informacin Corporativa La Plantilla de la Pgina Escasa, Densa La unidad de control de inventarios del Producto de Tipo del artculo, el Nmero de Nmero Internacional Estndar del Libro del Libro, el Tipo Telco Rate Los grficos Determinan el Tipo Sanguneo Formato de intercambio de grficos, JPG, Divulgacin Progresiva, Tamao declarado a Pre, Combinacin El Tipo de Animacin Similar para el Tipo del Sonido de Tipo de Grficos Similar para Graphics Type Page File Name File Name
Los cdigos y los atributos en los campos optativos de la Web ponen en bitcora archivos. Esta grada crucial est en la fundacin de la implementacin de esta dimensin de la pgina. La dimensin de la pgina es pequea. Si la anchura nominal de una sola fila es 100 bytes y nosotros tenemos un sitio Web grande con 100,000 pginas, en ese entonces el tamao de datos del unindexed es 100 la x 100,000 = 10 el megabyte. Si la indexacin suma un factor de 3, en ese entonces el tamao total de esta dimensin es sobre 40 MB.
La Dimensin de Acontecimiento
La dimensin de acontecimiento describe lo que sucedi en una pgina particular en un punto de par-ticular con el tiempo. Los acontecimientos interesantes principales son pgina del claro, refrescan pgina, dan un clic sobre enlace, y datos de interlineacin. Como las pginas dinmicas basaron en XML convertido en ms com-mon, la dimensin de acontecimiento se pondr mucho ms interesarle porque el seman-tic de la pgina ser bastante ms obvio para el servidor de Web. Cada campo en un documento XML puede estar etiquetado con una etiqueta definida por visita. Querremos para cap-ture esta informacin en esta dimensin de acontecimiento, como se muestra en Mesa 14.2 Mesa 14.2 el Diseo Recomendable para la Dimensin de Acontecimiento AT TR YO B UTE La Llave de Acontecimiento SAM P LE VALU ES Subrogue valores, 1-N
El Tipo de Acontecimiento Abra Pgina, Refresca Pgina, Clic Datos del Enlace, de Interlineacin, Desconocido, Inaplicable El acontecimiento Content eventualmente conducidos de Las etiquetas XML Los campos dependientes en la aplicacin
La dimensin de acontecimiento es diminuta. Si la anchura nominal de una sola fila es 40 bytes y nosotros tenemos 1,000 acontecimientos bien definidos, en ese entonces el tamao indexado de datos es 40 x 1,000 = 0.04 megabyte. Si la indexacin suma un factor de 3, en ese entonces el tamao total de esta dimensin est slo aproximadamente
0.16 el megabyte.
La Dimensin de Sesin La dimensin de sesin, ilustrada en Mesa 14.3, provee uno o ms niveles de diagnstico para la sesin de la visita como un todo. Por ejemplo, el contexto local de la sesin es pedir informacin del producto, pero el contexto global de sesin ordene un producto. El xito que el estatus diagnosticara ya sea la misin fueron completados. El contexto local puede ser decidable de simplemente la identidad de la pgina actual, pero el contexto global de sesin probablemente puede ser juzgado slo tramitando la sesin completa de la visita en el tiempo del extracto de datos. El atributo de estatus del cliente es un lugar conveniente para designar al cliente por los perodos de tiempo, con etiquetas que no son claras inmediatamente tampoco de la pgina o de la sesin inmediata. Los estatus tiles incluyen cliente de reli-able de valor elevado, cliente nuevo, a punto de cancelar, o en el default. Todos estos estatus pueden estar derivativos de centros de compras auxiliares de datos en el datos Webhouse, pero por plac-ing estas etiquetas profundas dentro del clickstream, podemos estudiar el comportamiento de ciertos tipos de clientes directamente. No metemos estas etiquetas en la dimensin de Cu-tomer porque pueden cambiar durante los cortsimos perodos de tiempo. Si hubiese un gran nmero de estos estatus, en ese entonces consideraramos crear una dimensin separada de estatus del cliente en vez de empotrar esta informacin en la dimensin de sesin. Esta dimensin es sumamente importante porque provee una forma para agrupar Se-sions para anlisis penetrante. Por ejemplo, esta dimensin se usara para preguntar: cuntos clientes le consultaron nuestra informacin del producto antes de hacer el pedido?
cuntos clientes miraron nuestra informacin del producto y nunca hicieron el pedido? cuntos clientes empezaron el proceso ordenador pero no terminaron?
Y dnde se detuvieron?
La dimensin de sesin es diminuta. Si la anchura nominal de una sola fila es 80 bytes y nosotros tenemos 10,000 combinaciones identificadas de sesin, en ese entonces el tamao indexado de datos es 80 x 10,000 = 0.8 megabyte. Si la indexacin suma un factor de 3, en ese entonces el tamao total de esta dimensin es sobre 3 MB.
Mesa 14.3 el Diseo Recomendable para la Dimensin de Sesin AT TR YO B UTE La Llave de Sesin El Tipo de Sesin Inaplicable SAM P LE VALU ES Subrogue valores, 1-N Clasificado, sin Clasificar, Corrupto,
Content local El informacin peticionaria del producto El Contexto de Sesin ordenar un producto La Secuencia de Accin accin durante la sesin El Estatus de xito El Estatus del Cliente Predeterminado
contexto
derivado
en pgina,
como
El contexto derivado en trayectoria, como
La etiqueta sumaria para la secuencia global de
Si la misin global de sesin fue lograda El Valor Alto, Fidedigno, Adentro
La Dimensin de Referencia Mostrado de adentro Mesa 14.4, la dimensin de referencia describe cmo el cliente arrib a la pgina actual. Los leos del servidor de Web usualmente proveen esta informacin. El URL de la pgina previa es identificado, y en algunos casos, infor-mation adicional es presente. Si el referrer fuese un motor de bsqueda, entonces usualmente la cuerda de bsqueda es especificada. No vale la pena poner la especificacin cruda de bsqueda en nuestra base de datos porque las especificaciones de bsqueda estn tan complicadas e idio syncratic que un analista tilmente no las podra poner en duda. Suponemos que alguna clase de especificacin simplificada y liberada est colocada en el campo de especificacin.
Mesa 14.4 el Diseo Recomendable para la Dimensin de Referencia AT TR YO B UTE La Llave de Referencia SAM P LE VALU ES Subrogue valores, 1-N
El Tipo de Referencia El Sitio del Intra, el Sitio Remoto, el Motor de Bsqueda, Corrompido, Inaplicable Referente al URL Referente A Sitio Referente Al Dominio Busque Tipo Fsforo Complicado Especificacin simple, dudoso de otra manera Ww Ww Site.com La Lgica de Fsforo Simple del Texto, del
La especulacin real usada; til si el texto
Blanco Donde la bsqueda encontr su fsforo, por ejemplo, Meta Tags, Texto del Cuerpo Humano, Ttulo
La dimensin de referencia puede ser medianamente grande. Si la anchura promedia de una sola fila es 100 bytes y si tenemos 1 millones de filas de referencia, en ese entonces el tamao indexado de datos es 100 x 1,000,000 = 100 megabyte. Si la indexacin suma un factor de 3, en ese entonces el tamao total de esta dimensin es sobre 400 MB. sta es una dimensin dura para estimar sin datos reales porque la variabilidad en el tamao viene de la longitud de lo refieren URL del anillo y la especificacin de bsqueda, lo cual no puede ser presente. Ahora que tenemos un portafolio de dimensiones tiles del clickstream, primero podemos construir el centro de compras primario de datos del clickstream en seguida fuera de los archivos del leo del servidor. En ese entonces integraremos este centro de compras de datos en la familia de otros centros de compras de datos en nuestro detallista de Web.
Clickstream Fact Table para Sesiones Completas El primer hecho que la mesa en nuestro centro de compras de datos del clickstream se basar solamente en los datos del clickstream se deriv de nuestros leos del sitio Web. Con un ojo hacia prevenirle la primera mesa de hecho creciente astronmicamente, escogemos el grano para ser una fila para cada uno sesin completada del cliente. Este grano es significativamente ms alto que los leos subyacentes del servidor de Web, cul registra cada acontecimiento microscpico de la pgina. Sin embargo, quiz le tenemos una grabacin grande del sitio ms que 100 len de milipulgada acontecimientos crudos de la pgina al da, y queremos comenzar con un nmero ms dcil de filas para tener mucho dinero cada da. Suponemos que por el bien de la discusin el 100 divieso de acontecimientos de la pgina de milln hasta 5 millones Se-sions completo de la visita. Esto podra levantarse si una audiencia promedia de la visita toc cinco pginas, y hubo un promedio de cuatro acontecimientos bsicos registrados por pgina, incluyendo peticiones para el formato de intercambio de grficos y las imgenes del grfico de Grupo Unido de Expertos en Fotografa. Las dimensiones que son apropiadas para esta primera mesa de hecho son la fecha del calendario, cronometran de da, cliente, pgina, sesin, y referrer. Finalmente, sumamos un set de hechos medidos para esta sesin que incluye los segundos de
sesin, manda a llamar visitada, las rdenes colocadas, cantidad de pedido, y dlar de orden tienen importancia. Al diseo completado le son mostrados en Figura 14.3. Hay un nmero de aspectos interesantes para el diseo mostrado en Figura 14.3. Usted puede preguntarse por qu la fecha y el tiempo de dimensiones de da juegan dos papeles diferentes, identificados por semnticamente los independientes puntos de vista, en este dibujo tcnico, como introdujimos en Captulo 11. Porque se interes en medida las veces precisas de sesiones, debemos asegurarnos de que choquemos con dos require-ments conflictivo. Primero, queremos asegurarnos de que podemos sincronizar que toda sesin fecha y por a travs de los husos horarios mltiples internacionalmente. Quiz tenemos otra fecha y timbres de tiempo de otros servidores de Web o de sistemas de poco trama a otro sitio en nuestro almacn de datos. Para lograr sincronizacin cierta de acontecimientos a travs de servidores mltiples y los procesos, debemos registrar que toda sesin fecha y
Cronometra uniformemente en un solo huso horario como la Hora del Meridiano de Greenwich (la hora media de Greenwich). Interpretamos la fecha de sesin y combinaciones de tiempo como el comienzo de la sesin. Desde tiene lo mora tiempo de la sesin como un hecho numrico, podemos distinguir cuando la sesin ces si esto es de inters. El otro requisito por el que nos responsabilizaremos con este diseo debe registrar la fecha y el tiempo de la sesin referente al reloj de pared de la visita. La mejor forma para representar esta informacin est con un segundo par de fecha del calendario y tiempo de da llaves extranjeras. Tericamente, podramos representar el huso horario del cliente en la mesa de dimensin del cliente, pero las restricciones para determinar el tiempo correcto del reloj de pared estaran horrorosamente complicadas. La diferencia de tiempo entre dos ciudades puede cambiar por ah tanto como 2 horas a las veces de dif-ferent del ao a merced de cundo estas ciudades sigue y fuera del tiempo diurno de ahorros (como Londres y Sydney). Esto no es el negocio de la aplicacin de usuario final para resultar; Es el negocio de la base de datos almacenar esta informacin a fin de que puede ser puesto tirante en contra en una forma simple y directa. La inclusin de la dimensin de la pgina en Figura 14.3 puede parecer sorprendente dado que el grano del diseo es la sesin del cliente. Sin embargo, en una sesin dada, una pgina interesante es la pgina de entrada. Interpretamos la dimensin de la pgina en este diseo como la pgina con la cual la sesin empez. En otras palabras, cmo brinc el cliente encima de nuestro autobs ahora mismo? Acoplados con la dimensin del referrer, nosotros ahora tenemos una habilidad interesante para analizar cmo y por qu el cliente accedi a nuestro sitio Web. Un diseo ms elaborado tambin sumaba una dimensin de la pgina de la salida.
La Dimensin de Fecha (Los puntos de vista para 2 papeles) Los atributos de Fecha de la Llave de fecha (PK) La Dimensin del Cliente Los atributos del Cliente de la Llave del cliente (PK)
La Dimensin de la Pgina de Entrada La entrada Page Key Page (PK) Attributes
La Dimensin de Sesin Los atributos de Sesin de la Llave de sesin (PK) Referrer Dimension Referrer Key Referrer (PK) Attributes
El Hecho de Acontecimiento de la Pgina del Clickstream El tiempo universal universal de la Llave de Fecha (FK) de Da Llave de Fecha de la Llave Local (FK) (FK) La hora local de Llave del Cliente de la Llave de Da (FK) (FK) La sesin de la Llave de la Llave de Sesin de entrada Page Key Referrer Key Causal (FK) (FK) (FK) (FK) Seconds Pages Visited Las rdenes Colocadas Cantidad De Pedido La Cantidad del Dlar de Orden
El Tiempo de Dimensin de Da (Los puntos de vista para 2 papeles)
El tiempo de Tiempo de la Llave de Da (PK) de Atributos de Da
La Dimensin Causal Los atributos Causales Cruciales causales (PK) Figura 14.3 el dibujo tcnico Clickstream en el grano de sesin.
Podemos estar tentados de aadirle la dimensin causal a este diseo, pero si la dimensin causal estuviera dirigida a enfocar la atencin en productos individuales, sera inapropiada agrandar este diseo. El sntoma que la dimensin causal no engrana con este diseo es la naturaleza multipreciada de los factores causales para una sesin completa dada. Si nosotros corremos el anuncio hace campaa o el especial negocia para varios productos, cmo representamos esta situacin multipreciada si la sesin del cliente requiere varios productos? El lugar correcto para una dimensin causal orientada en producto estar en la mesa ms de grano fino que construimos en el siguiente ejemplo de la mesa de hecho. Inversamente, un mercado ms ampliamente enfocado dimensin causal que describi condiciones de mercado afectando todos los productos sera apropiado para una mesa veteada en sesin de hecho. La sesin secunda el hecho es el nmero total de segundos que el cliente gast en el sitio durante esta sesin. Habr muchos casos donde no podemos distinguir cuando el cliente sali. Quiz el cliente introdujo un URL nuevo. Los leos convencionales del servidor de Web no detectarn esto (aunque si los datos est siendo coleccionado por un ISP que puede ver cada clic a travs de sesiones, entonces este asunto particular se desvanece). O quiz el cliente se levant fuera de la silla y no regres por una hora. O quiz el cliente acaba de cerrar el navegador sin hacer ms clics. En todos estos casos que nuestras necesidades del software del extracto para asignar un nmero pequeo y nominal de segundos para esta parte de la sesin a fin de que el anlisis no se distorsiona de forma poco realista. La mesa de hecho mostrada en Figura 14.3 tiene 13 campos. Desde todos los extranjeros campos de clave es substituto teclea, ninguno de ellos necesita estar representado en ms de 4 bytes. De modo semejante, todos los hechos medidos son ya sea enteros o enteros modificados a escala. Otra vez,
Los dominios de 4 bytes son razonables para los propsitos de estimacin. As nuestra mesa de hecho est cerca 52 bytes anchos. Si coleccionamos 5 millones de filas nuevas de hecho cada da para nuestro hypothet El ical el ejemplo del sitio Web abrumador, en ese entonces sumamos 260 megabyte de datos (delante de ndice Ing) para la mesa de hecho cada da. Sobre el curso de un ao, esto tendra importancia para 260 la x de megabyte 365 = 94.9 el gygabyte de datos del unindexed. Esto es grande, pero no ridculamente as. Tres aos de datos, conjuntamente con indexar en lo alto, quiz consumiran 600 el gygabyte de espacio del disco. Dado el paso de Web comercializando y la tecnologa de Web, eso Parece razonable para hacer planes de mantener slo 3 aos de datos.
Reparo en que la dimensin pospone, con la excepcin posible de la dimensin del cliente, es pequeo en contraste con la mesa principal de hecho. Una mesa del cliente con creces de 50 millones de filas indexada podra ocupar 200 gygabyte de almacenamiento, aproximadamente de un tercera parte el tamao de la mesa de hecho. Todas las otras Tablas de dimensin son insignificantes en contraste. A propsito construimos esta primera mesa de hecho en nuestro centro de compras de datos del clickstream para enfocar la atencin en sesiones completas de la visita y mantener bajo control el tamao del centro de compras de datos. La siguiente mesa que diseamos est en baja para la granularidad prctica mnima que podemos soportar en el datos Webhouse: El acontecimiento individual de la pgina.
Clickstream Fact Table para Los Acontecimientos Individuales de la Pgina En esta segunda mesa de hecho definiremos la granularidad para ser el acontecimiento de la pgina del individuo en cada sesin del cliente. Con pginas simples, estticas de HTML, podemos poder registrar slo un acontecimiento interesante por la vista de la pgina, a saber, la vista de la pgina misma. Como la planilla de sitios Webes dinmicamente cre las pginas basadas a XML con la habilidad para establecer un dilogo en curso a travs de la pgina, el nmero y los tipos de acontecimientos crecern. Es probable que esta mesa de hecho se volver astronmica en el tamao. Resistiremos el deseo a agregar la mesa hasta una granularidad ms brbara porque tal paso inevitablemente implica eliminar dimensiones. En verdad, la primera mesa de hecho que construimos para este centro de compras de datos representa simplemente tal agregacin. Es una mesa importante de hecho, pero el analista no puede hacer preguntas acerca de pginas de la visita de comportamiento o de indi-vidual. Cuando los datos orientados en pgina individuales se sedimentan se pone demasiado grande, en ese entonces para conservar la habilidad para analizar detall comportamiento, ya sea el perodo de tiempo de los datos debe ser muestreo restringido o estadstico que las tcnicas deben usarse para reducir tamao de datos. Aunque la capacidad de almacenamiento en disco se ha doblado aun ms rpido (cada 12 meses, supuestamente) que tramitar poder, nuestro propen-sity para coleccionar resmas de datos parece duplicar en un paso aun ms acelerado. Habiendo escogido el grano, podemos escoger las dimensiones apropiadas. Nuestra lista de dimensiones incluye la fecha del calendario, el tiempo de Idaho de da, del cliente, de la pgina, de acontecimiento, de Se-sion, de sesin, producto, causal, y referrer. Al diseo completado le son mostrados en Figura 14.4.
La Dimensin de Fecha (Los puntos de vista para 2 papeles) la Dimensin del Cliente La Dimensin de Sesin
La Dimensin del Producto Los atributos del Producto de la Llave del producto (PK)
La Dimensin Causal El Hecho de Acontecimiento de la Pgina del Clickstream El tiempo universal universal de la Llave de Fecha (FK) de Da Llave de Fecha de la Llave Local (FK) (FK) La hora local de Llave del Cliente de la Llave de Da (FK) (FK) La llave de la Llave del Producto de la Llave de Sesin de la Llave de Acontecimiento Page Key Session Idaho Referrer Key Causal (FK) (FK) (FK) (DD) (FK) (FK) (FK) Page Secunda Cantidad de Pedido La Cantidad del Dlar de Orden
Page Dimension
La Dimensin de Acontecimiento Los atributos de Acontecimiento de la Llave de acontecimiento (PK)
Referrer Dimension
Figura 14.4 el dibujo tcnico Clickstream en el grano de acontecimiento de pgina.
El diseo en Figura 14.4 se parece ms bien mucho a nuestro primer diseo. Esto similar-ity entre Tablas de hecho es tpico de modelos dimensionales. Uno de los encantos de modelado dimensional es la similitud aburrida de los diseos. Sin embargo, esto est donde tienen su poder. Cuando los diseos tienen una estructura previsible, todo el software de arriba abajo por los datos almacena que la cadena, de extraccin, para base de datos poniendo en duda, para el usuario final labra, puede explotar esta similitud para gran advan-tage. La averiguacin y las herramientas ponentes, por ejemplo, puede poder adaptarse a una familia entera de diseos dimensionales sin cualquier reprogramando. Los dos papeles desempeados por la fecha del calendario y el tiempo de dimensiones de da tienen la misma interpretacin as como en el primer diseo; Un papel es el tiempo sincronizado y universal, probablemente expresado en la hora media de Greenwich, y el otro papel es el tiempo local del reloj de pared tan medido por el cliente. En esta mesa de hecho que las combinaciones de fecha /tiempo se refieren al acontecimiento individual de la pgina que est siendo descrita por la fila construimos. La dimensin de la pgina se refiere a la pgina individual cuyos acontecimientos somos record-ing. sta es la diferencia principal en grano entre esta mesa de hecho y el primero que construimos. En esta mesa de hecho podremos ver todas las pginas a las que se accedi por los clientes.
La dimensin de acontecimiento describe lo que sucedi en la pgina, como describimos ms temprano en este captulo. La dimensin de sesin describe el resultado de la sesin. Un campo del compaero, la sesin Idaho, es una dimensin degenerada que no tiene una juntura para una mesa de dimensin. La sesin Idaho es simplemente un identificador nico sin contenido semntico que viene a agrupar los acontecimientos de la pgina de cada sesin del cliente en una forma de no be-biguous. No necesitamos una sesin Idaho dimensin degenerada en nuestra primera mesa de hecho porque cada fila en esa mesa ya representase una sesin completa. Recomendamos que la dimensin de sesin est en un nivel ms alto de granularidad que la sesin Idaho porque la
dimensin de sesin est dirigida a describir clases y cat-egories de sesiones, no las caractersticas de cada sesin individual. Mostramos una dimensin del producto en este diseo debajo de la suposicin que este sitio Web es posedo por un detallista de Web. Un sitio financiero de servicios probablemente tendra una dimensin similar. Un sitio consultivo de servicios tendra una dimensin de servicio. Un sitio de subasta tendra una dimensin sujeta o categorial describiendo la naturaleza de los artculos rematndose. Un sitio noticioso tendra una dimensin sujeta, aunque con contenido diferente que un sitio de subasta. Acompaamos la dimensin del producto con una dimensin causal a fin de que podamos adjuntar las interpretaciones tiles del mercado a los cambios en demanda que podemos ver para ciertos productos.
Para cada acontecimiento de la pgina registramos el nmero de segundos que creemos elapso antes del siguiente acontecimiento de la pgina. Llamamos por telfono que esta pgina secunda para contrastarla con segundos de sesin que usamos en la primera mesa de hecho. ste es un ejemplo simple de ponerle atencin a hechos conformados. Si llamsemos ambos estas medidas simplemente segundos, en ese entonces correramos el riesgo de tener estos segundos aadidos o combinamos inap-propriately. Desde que estos segundos no son precisamente equivalentes, los nombramos diferentemente como advertencia. En este caso particular esperaramos que el sec-onds de la pgina para una sesin en esta segunda mesa de hecho ascienda a los segundos de sesin en la primera mesa de hecho. Nuestros hechos finales son cantidad de pedido y cantidad del dlar de orden. Estos campos sern cero o nulo para muchas de las filas en esta mesa de hecho simplemente porque el acontecimiento especfico de la pgina no es el acontecimiento que coloca la orden. No obstante, es altamente atractivo proveer estos campos porque vinculan renta de Web de mucha importancia directamente para el comportamiento. Si la cantidad de pedido y dlar tienen importancia fuese slo capacitado en la ganancia a travs del sistema de entrada de orden de produccin a otro sitio en la casa de Web de datos, sera ineficiente realizar el anlisis renta a comportamiento a travs de Tablas grandes mltiples. En muchos sistemas de gestin de base de datos lo exbe-tence de estas clases de campos nulos es maniobrado eficazmente y puede subir espacio de cero del aliado de litro en la mesa de hecho. Rpidamente podemos estimar el tamao de esta mesa de hecho. Si usamos el anterior ejemplo de 100 milln acontecimientos crudos del leo de Web cada da, probablemente terminamos con aproximadamente 20 millones de acontecimientos significativos de la pgina al da tras descarta las peticiones para las imgenes de formato de intercambio de grficos y de Grupo Unido de Expertos en Fotografa. Cada fila en la mesa de hecho de acontecimiento de pgina tiene 15 campos, cul estimamos ocupa 15 x 4 bytes = 60 bytes. As los datos totales de la mesa de hecho a agregarse cada da son 20 millones x 60 bytes = acerca de 1.2 gygabyte al da. Esto tendra importancia para 365 la x 1.2 gygabyte GB 438 al ao, antes indexando. Otra vez, mientras ste es un gran nmero, est dentro de alcance de tecnologa de hoy.
Como nos mudamos a ms entrega dinmica de la pgina con mejores etiquetas semnticas en cada uno de las acciones (gracias a XML), indudablemente aumentaremos el volumen de datos disponibles. Quiz mantenemos la granularidad de la mesa presente en aproximadamente una vista de la pgina por fila en vez de haciendo una fila para cada gesto del cliente de dis-Crete. Es muy temprano a esta hora hacer un predic-tion definitivo de si descenderemos hasta el gesto individual a ras de una tercera y mesa de hecho aun ms granular. Aun si nuestro almacenamiento y nuestras tecnologas de averiguacin se mantienen al da con el volumen aumentado de datos, necesitamos esperar a ver si hay suficiente contenido de anlisis en los datos de comportamiento del nivel mnimo para hacerlo importante. Si Dios quiere, usted puede ver cmo prolongar las tcnicas de este captulo para manejar este caso.
Las Tablas de Hecho del Clickstream del Agregado Ambos las Tablas de hecho que hemos construido hasta ahora en nuestro centro de compras de datos del clickstream son grandes. Hay muchos negocio duda que nos gustara preguntar eso se vera forzado a resumir millones de filas de estas Tablas. Por ejemplo, si queremos rastrear el total hace una visita y renta de grupos socioeconmicos principales de clientes accediendo a nuestro sitio Web en un mes por la base de mes, ciertamente podemos hacer ste con ya sea la mesa de hecho. En la mesa veteada en sesin de hecho aprenderamos de memoria tensin la dimensin de fecha del calendario hasta el apropiado perodo de tiempo (digamos, enero, febrero, y marzo del ao en curso). Entonces crearamos encabezados de la fila del campo de tipo de caractersticas demogrficas en la dimensin del cliente y el campo de mes en la dimensin del calendario (para separadamente designar los tres meses en la apagada opcin de venta). Finalmente, sumaramos sobre los dlares totales de orden y contaramos el nmero de sesiones. Esto todo trabaja simplemente la multa. Sin embargo, tiene probabilidad de ser lento sin ayuda de una mesa del agregado. Si esta clase de averiguacin es frecuente, el administrador de base de datos ser promovido para construir una mesa del agregado tan mostrada en Figura 14.5. Podemos construir esta mesa directamente de nuestra primera mesa de hecho, quin es aquel cuyo grano es la sesin de indi-vidual. Para construir esta mesa del agregado, agrupamos por pgina de mes, de tipo demogrfico, de entrada, y resultado de sesin. Contamos el nmero de sesiones y sumamos todos los otros hechos aditivos. Esto resulta en una mesa de hecho drsticamente ms pequea, casi ciertamente menos de 1 por ciento de la mesa veteada en sesin original de hecho. Esta reduccin en el tamao traduce directamente para un incremento correspondiente en perfor-mance para la mayora de averiguaciones. En otras palabras, esperaramos que averiguaciones han sido dirigidas a esta mesa del agregado corran al menos 100 veces ms rpido. Aunque no pudo haber sido obvio, seguimos una disciplina cuidadosa en build-ing la mesa del agregado. Esta mesa de hecho del agregado est relacionada a un set de dimensiones encogidas directamente relacionadas con que las dimensiones originales en el hecho veteado en sesin posponen. La mesa de mes es un subconjunto conformado de la mesa de da calendario. La mesa demogrfica es un
subconjunto conformado de la mesa del cliente. Suponemos que la pgina y las Tablas de sesin estn inalteradas, aunque un diseo cuidadoso de la lgica de agregacin podra sugerir un acortamiento conformado de estas Tablas tambin.
La Dimensin de Mes La Dimensin de la Pgina de Entrada Las Caractersticas de Sesin El Hecho del Agregado Llave Mes (FK) universal Demographic Nmero de la Llave de Resultado de Sesin de la Llave Entry Page Key (FK) (FK) (FK) de Segundos de Sesin de Sesiones Los Pajes Visitaron rdenes Colocada Cantidad de Pedido La Cantidad del Dlar de Orden
La Dimensin Demogrfica La Dimensin de Resultado de Sesin
Resuelvo 14.5 dibujo tcnico del clickstream Agregado resumido por las caractersticas de sesin.
Integrando al Clickstream Data Mart en el Almacn de Datos de la Empresa En este pasaje miramos el diseo global de una serie de centros de compras de datos implementados para un detallista de la computadora basada en la Web. Los centros de compras de datos le concuerdan con todo el negocio los procesos necesitados por este detallista para correr su negocio. Podramos ilustrar este diseo mostrando cada dibujo tcnico como hemos hecho en los ejemplos precedentes, pero la sinergia entre los diseos sera difcil de ver claramente. En lugar de eso, usamos la matriz del autobs del almacn de datos, cul introdujimos en Captulo 3. El mtodo matricial lista los centros de compras de datos abajo del lado izquierdo de la matriz y las dimensiones usadas por los centros de compras de datos a travs de la parte superior de la matriz. Las celdas de la matriz contienen a Xs si el centro de compras particular de datos usa una dimensin particular. Reparo en que la matriz describe centros de compras de datos, no Tablas individuales de hecho. Tpicamente, un centro de compras de datos consiste en una suite de cerca Tablas asociadas de hecho toda descripcin un proceso comercial particular. Una buena manera para echar a andar el diseo de una serie de centros de compras de datos es definir centros de compras de datos de primeros niveles que son, lo ms posible, relacionados para singularizar fuentes de datos. Una vez varios de estos centros de compras de datos de primeros niveles ha sido implementado, en ese entonces los centros de compras consolidados que se secundan a ras de datos, como la rentabilidad, pueden construirse eso requieren que los datos de los de primeros niveles centros de compras estn combinados. As las entradas en una fila dada de la matriz representan la existencia de una dimensin alguno donde en la de cerca suite asociada de Tablas definiendo un centro de compras particular de datos. Resuelva 14.6 funciones la matriz completada del autobs para un detallista de Web. La matriz tiene un nmero de asestar caractersticas. Hay un lote de Xs. Una X en una columna matricial dada est, en efecto, una invitacin para la reunin para conformar esa dimensin. Los usos promedios del centro de compras de datos seis para ocho dimensiones. Algunos de las dimensiones, como la fecha /tiempo, la transaccin, el estatus /tipo, la organizacin, y el empleado, aparecen casi cada centro de compras de datos. El producto y dimensiones del cliente dominan toda la parte central de la matriz, donde estn pegados a los centros de compras de datos que describen al cliente orientaron actividades. En lo alto de la matriz, los
proveedores y las partes dominan los procesos de adquirir las partes que hacen productos y construirlos de encargo para el cliente. Al pie de la matriz tenemos infraestructura clsica y costamos centros de compras de datos del conductor que no estn atados directamente para el comportamiento del cliente. Vemos el centro de compras de datos del clickstream de la visita de Web sentndose en ngulo recto entre los centros de compras de datos orientados hacia el cliente. Comparte la fecha /tiempo, la transaccin, producto, cliente, de los medios de comunicacin, causal, y la pliza de servicio dimensiona con varios otros centros de compras de datos cerca. En este sentido debera notarse que el centro de compras de datos de la corriente de clic de la visita de Web est bien integrado en la tela de la casa global de loza de datos para este detallista. Las aplicaciones atando el clickstream de la visita de Web sern fciles de integrarse a travs de todos estos centros de compras de datos compartiendo stas dimen-sions conformado porque las averiguaciones separadas para cada centro de compras de datos podrn ser com-bined a travs de filas individuales del informe.
La Compra del Proveedor Hace el Pedido Las Entregas del Proveedor La Parte Hace Inventario El Producto Assembly Bill de Asamblea del Producto de Materiales para las Promociones del Producto de Orden Las Comunicaciones Publicitarias del Cliente de Averiguaciones del Cliente Tejen Facturacin del Cliente de Embarques del Producto de Transacciones de Ventas del Producto del Clickstream de la Visita La Poltica de Servicio de Apoyo del Producto de Regresos del Producto de Pagos del Cliente Hace el Pedido Las Respuestas de Poltica de Servicio Las Operaciones de Facilidades de Recursos Humanos de Trabajo del Empleado Tejen Operaciones del Sitio Creo que 14.6 Datos almacenen matriz del autobs para un detallista de Web.
El centro de compras de datos del clickstream de la visita de Web contiene las cuatro dimensiones del clickstream especiales no encontradas en los otros centros de compras de datos. Estas dimensiones no plantean un problema para aplicaciones. En lugar de eso, la habilidad del centro de compras de datos del clickstream de la visita de Web a cruzar entre el mundo de Web y el mundo de cemento y ladrillo es exactamente la ventaja que andamos buscando. Podemos constreir y podemos agruparnos sobre los atributos de las cuatro dimensiones de Web y podemos explorar el efecto por otra parte procesos comerciales. Por ejemplo, podemos ver qu clases de experiencias de Web producen a los clientes que compran algunos tipos de plizas de servicio y entonces conjuran ciertos niveles de demandas de servicio.
El Centro De Compras de Datos de Rentabilidad de Comercio Electrnico Despus de que el equipo de datos Webhouse exitosamente suba el centro de compras inicial de datos del clickstream y amarre este centro de compras de datos a la transaccin de ventas y cliente
Los centros de compras de datos de comunicacin, el equipo pueden estar listos a abordar la mayor parte de centro de compras de datos de chal-lenging de todo: El centro de compras de datos de rentabilidad de Web. Podemos construir el centro de compras de datos de rentabilidad de Web como una extensin del centro de compras de datos de transaccin de ventas. Fundamentalmente, vamos a ubicar que toda la actividad cuesta y que la infraestructura cuesta hasta cada transaccin de ventas. Podramos, como un intento nativo en Alter, para construir el centro de compras de datos de rentabilidad de Web encima del clickstream, pero esto implicara un aun ms controversial proceso de imputacin en el cual ubicamos costos hasta cada sesin. Era difcil de asignarle los costos de actividad y de infraestructura a una sesin que no tuvo participacin obvia del producto y condujo a ninguna venta inmediata. Un beneficio grande de extender la mesa de hecho de transaccin de ventas es que tendremos una vista de rentabilidad sobre todos nuestros canales de ventas, no simplemente la Web. En cierto modo, esto debera ser obvio, porque se sabe que tenemos que sortear los costos y asignarles a los canales diversos de cualquier manera. Por esta razn, llamaremos la mesa principal de hecho en nuestro centro de compras nuevo de datos simplemente rentabilidad. As el grano de la mesa de hecho de rentabilidad es cada producto individual convencido de un boleto de venta para un cliente en un punto con el tiempo. Esto suena familiar, verdad? Este grano frisa idntico para el grano del primer modelo dimensional diseamos. La diferencia primaria es que el Captulo 2 el dibujo tcnico fue limitado a la tienda de abarrotes tienda de cemento y ladrillo. En este pasaje el modelo incluir mtrica de profitabil-ity a travs de todos los canales, incluyendo almacena ventas, telesales, y ventas de Web. Hicimos un reconocimiento de un centro de compras de datos de rentabilidad extensamente en Captulo 5. Enumeramos una larga lista de hechos de ganancias y prdidas (P y L) de ingreso bruto para utilidad de contribucin. Cifra 14.7 ilustra estos mismos hechos en un contexto algo ms amplio. Como vimos en Captulo 5, la mesa de hecho es organizada como una declaracin de la P simple y L. El primer hecho es nuestra cantidad ahora familiar vendida. El resto de hechos son
valores del dlar, a partir del ingreso bruto, cul es el valor del artculo como si fuera vendido en el precio de lista o del catlogo. Damos razn de que concesiones y promociones logren ingreso neto, lo cual es el precio neto cierto que el cliente paga las veces la cantidad comprada. El resto de P y L posponen consiste en una serie de sustracciones, donde nosotros calcu-late progresivamente para ms versiones de gran alcance de ganancia. Empezamos por tracting que el producto confeccionando cost (si lo confeccionamos) o que, equivalentemente, el coste de adquisicin del producto (si lo compramos a un proveedor). Entonces sustraemos el costo de almacenamiento del producto. En este punto muchas empresas se refieren a este resultado parcial como la ganancia bruta. Uno puede dividir esta ganancia bruta por el ingreso bruto para tener la proporcin de margen bruto.
La Dimensin de Fecha (Los puntos de vista para 2 papeles) La Dimensin del Cliente La Dimensin del Producto El Hecho de Rentabilidad El tiempo universal universal de la Llave de Fecha (FK) de Da Llave de Fecha de la Llave Local (FK) (FK) La hora local de Llave del Cliente de la Llave de Da (FK) (FK) La cantidad de Nmero del Boleto de la Llave de Promocin de la Llave del Producto de la Llave del canal (DD) (FK) (FK) (FK) Se Vendi El Ingreso Bruto Confeccionando Rebaja de Ventas de Promocin de Mercadeo de la Mesada La Manufactura Neta de Renta Cost Costo de Almacenamiento La Carga Vulgar de la Ganancia Cost Costo Especial de Trato Otros Gastos Fijos Cuestan Ganancia Neta
La Dimensin del Canal La Dimensin de Promocin
Figura 14.7 el dibujo tcnico de rentabilidad de Comercio Electrnico.
Obviamente, las columnas llamaron ingreso neto y Ganancia Bruta se calcula directamente de los campos inmediatamente precedindolas en la P y la mesa L. Sin embargo, deberamos almacenar explcitamente estos campos en la base de datos? La respuesta depende en si usted le provee el acceso a esta mesa de hecho a travs de una vista o deja a los usuarios o las aplicaciones acceder a la mesa fsica de hecho directamente. La estructura de la P y la mesa L est suficientemente complicada que, como los datos almacenan al proveedor, usted no quiere arriesgarse a tener medidas importantes como ingreso neto y ganancia de la gruesa computada incorrectamente. Si usted provee todo acceso a travs de los puntos de vista, usted fcilmente puede suministrar las columnas computadas sin fsicamente almacenndolas. Sin embargo, si sus usuarios tienen permiso de acceder a la mesa fsica subyacente, en ese entonces usted debera incluir ingreso neto, ganancia bruta, y ganancia neta como campos fsicos. Debajo de la ganancia bruta continuamos sustrayendo costos diversos. Tpicamente, el equipo del almacn debe fuente o estima cada uno de estos costos separadamente. Recuerde que las entradas reales en cualquier fila dada de la mesa de hecho son las fracciones de estos costos totales ubicados a lo largo de para la fila individual de hecho el grano. A menudo hay presin significativa en el equipo del almacn para terminar el centro de compras de datos de prof-itability. Para poner sta de cualquier otro modo, all es tremenda presin para la fuente todos estos costos. Pero cmo el bien son los costos en lo diversos estando bajo de
Los conjuntos de datos? Algunas veces un costo est slo disponible como un promedio nacional, computado por un el ao entero. Cualquier plan de dotacin es ir para asignar un tipo de valor pro forma que no le tiene textura autntica para l. Otros costos estarn arruinados abajo uno bet-ter pequeo, quiz para la cuarta parte del calendario y por regin geogrfica (si ste es rele-vant). Finalmente, algunos costos pueden ser verdaderamente basados en actividades y pueden variar en una forma altamente dinmica, receptiva, y realista con el paso del tiempo. Los costos del sistema del sitio Web son un conductor importante de costo en negocios orientados en comercio electrnicos. Aunque los costos del sitio Web son la infraestructura clsica cuesta y por eso es difcil de ubicar directamente para el producto y actividad del cliente, ste es un paso crucial en desarrollar una la declaracin de la P orientada en Web y L. Los planes diversos de alloca-tion son posibles, inclusivos asignndole los costos del sitio Web a lneas diversas del producto por el nmero de pginas asignadas a cada producto, ubicando los costos por pginas visitadas, o ubicando los costos por las compras basadas en la Web reales. Antes de dejar este diseo, vale la pena repetirse esa Cifra 14.7 la mesa de hecho de prof-itability dentro de un armazn dimensional sustancioso es inmensamente ful de poder. Podemos ver la anomala de todos los componentes de renta, podemos costar, y podemos beneficiarnos para cada rebanada concebible y cadas dados soportados por las dimensiones. Podemos preguntar, Qu Tan provechoso es cada uno de nuestros canales (por ejemplo, las ventas de Web, telesales, y ventas de la tienda) y por qu? O Qu Tan provechosas son todas nuestras segmentaciones posibles del cliente y por qu? Por supuesto, el acercamiento dimensional simtrico nos deja combinar restricciones de tantas dimensiones como podemos. Esto nos da versiones compuestas de rentabilidad analizan, tan, Quines estn los clientes provechosos en cada canal y por qu? O Cul promociones marchan bien en Internet pero no surten efecto bien en otros canales y por qu?
Resumen El ejemplo del detallista de Web que usamos en este captulo es ilustrativo de
cualquier negocio con una presencia significativa de Web. Adems de construir el centro de compras de datos del clickstream, el reto central debe integrar los datos del clickstream eficazmente en el resto de negocio. En este captulo los conceptos cruciales incluidos: El reto de identificar el origen de la visita de Web. En algunos casos podemos vernos atrs a travs de la informacin de referencia en el leo de Web, pero en muchos otros casos esta informacin no es suministrada. El reto de identificar una sesin completa. Las sesiones de HTTP estn sin nacionalidad.
El uso de galletas es el mejor mecanismo para definir una sesin, enrumbando adentro Tenga en cuenta que no podemos explicar todos los espacios de tiempo entre las peticiones de la pgina.
El reto de identificar la visita de Web. Aun con una galleta, no podemos estar seguros quin el individuo est en el otro extremo.
Cmo tratar con servidores del apoderado. Un monaguillo del apoderado intercepta las peticiones de la pgina de la visita. Podemos inhibir el uso de servidores del apoderado, o en algunos casos que podemos coleccionar los leos. El diseo de la dimensin de la pgina. El paso crucial debe obligar al diseador de la pgina de Web a asignarle los atributos y cdigos contentos a cada pgina y entonces empotrar estos cdigos y atributos en los leos del servidor de Web. El diseo de la dimensin de sesin. El paso crucial es usar el registro de la sesin completa, conjuntamente con algunos criterios simples, para proveer un diagnstico de sesin que puede usarse para buscar sesiones de tipos diferentes. El diseo de una mesa de hecho del clickstream para sesiones completas. Esta mesa de hecho es un acuerdo intermedio interesante entre un resumen de alto nivel de actividad del sitio Web y el detalle abrumador provisto por una mesa de hecho para cada acontecimiento de la pgina. El diseo de una mesa de hecho del clickstream para cada acontecimiento de la pgina. Este nivel ltimo de detalle es el registro ms preciso y completo de behav-ior del cliente. Los problemas de tamao con esta mesa pueden ser tratados segn muestreo. El diseo de Tablas de hecho del clickstream del agregado. Las Tablas de hecho muy ms pequeas (y ms rpido) tilmente pueden resumir comportamiento de la visita, como correlacionar caractersticas demogrficas con sesiones productivas. Cmo integrar el centro de compras de datos del clickstream en el resto de casa de loza de datos. Usando el mtodo del diseo de la matriz del autobs, vemos cules dimensiones deben ser conformadas a travs de todos los centros de compras de datos, y vemos que el centro de compras de datos de la corriente de clic tiene un traslapo significativo con los otros centros de compras de datos. Cmo sumar medidas de rentabilidad para el centro de compras de datos de ventas del producto a fin de que la contribucin de canal de Internet puede estar apartada y analizada.
Seguro El carbono HAPTE R15
tungsteno
La e juntar conceptos de casi todos los captulos previos para construir un almacn de datos para una propiedad y la compaa de seguro contra accidentes en este final estudio de casos. Si usted es de la industria de seguro y saltado sobre en seguida para este captulo para un apuro rpido, por favor acepte nuestra disculpa, pero este material depende pesadamente de ideas de los anteriores captulos. Usted necesitar devolverse al comienzo del libro para hacer este captulo hacer cualquier sentido. Como ha sido nuestro mtodo estndar, este cabildo es lanzado con informacin de regreso molida para un caso comercial. Mientras los requisitos se desarrollan, redactaremos que la matriz del autobs del almacn de datos, mucha lo haramos en un esfuerzo de anlisis de require-ments de la vida real. Entonces disearemos una serie de modelos dimensionales cubriendo con una capa las tcnicas de fondo instruidos hasta ahora en cierto modo similar para la capa superpuesta de diapositivas areas.
Divida en captulos 15 revisiones los siguientes conceptos:
el acercamiento conducido en requisitos para diseo dimensional Las implicaciones de la cadena de valor
los datos almacenan matriz del autobs la transaccin complementaria, la foto peridica, y acumularse le toman instantneas a los dibujos tcnicos El proceso del diseo de cuatro pasos para los modelos dimensionales la caracterizacin de papeles de dimensin el manejo de atributos de dimensin lentamente cambiantes Minidimensions para ocuparse de abrumador, ms rpidamente atributos de dimensin cambiante
305
Multivalued dimensione atributos degenere dimensiones para nmeros operacionales de control la auditora dimensiona para rastrear linaje de datos los productos heterogneos con atributos y hechos que difieren por la clase de negocio los hechos y dimensiones conformadas el hecho consolidado pospone que la mtrica del cartel de negocio separado va en procesin las Tablas de hecho Factless los errores comunes a evitar al disear modelos dimensionales
El Estudio De Casos de Seguro
Imaginmonos que trabajamos para un asegurador de $5 billn de caracterstica y de la vctima que ofrece automvil, propietarios de casa, y el seguro de propiedad personal. Aprendemos de memoria ducto entrevistas extensivas con representantes y la alta gerencia de los reclamos, fildeamos operaciones, actuarial, las finanzas, y comercializando departamentos. Basados sobre estas entrevistas, nos enteramos de que la industria de seguro est en un estado de flujo. Los jugadores nuevos, poco tradicionales entran palanqueando chan-nels alternativo, como la Internet. Mientras tanto, la industria consolida debido a la globalizacin, desreglamentacin, y retos de demutualizacin. Los mercados cambian, junto con las necesidades del cliente. Los numerosos entrevistados nos dicen que la informacin se est volviendo un activo aun estratgico ms importante. Sin tener en cuenta los grupos funcionales, hay un deseo ardiente para usar informacin ms effec-tively para identificar oportunidades ms rpidamente y responder ms apropiadamente. Las buenas noticias son que los sistemas internos y los procesos ya capturan la masa de los datos requeridos. La mayora de compaas de seguros generan un montn de nitty-gritty datos operacionales. Las malas noticias es que los datos no son integrados. A travs de los aos, los linderos polticos y de procesamientos de datos
han alentado lo con-struction de barreras altas alrededor de estas islas aisladas de datos. Hay fuentes dispares mltiples para informacin acerca de los productos de la compaa, clientes, y canales de distribucin. En el legado sistemas operacionales, el mismo asegurado puede ser identificado varias veces en automvil separado, puede dirigirse hacia el blanco, y las aplicaciones de propiedad personal. Tradicionalmente, este acercamiento segmentado para datos fue aceptable porque el func-tioned diferente de giros de negocios mayormente autnomamente. Hubo inters pequeo en compartir datos a travs de unidades para cruz vendiendo y la colaboracin en el pasado. Ahora tratamos mejor apalancar una enorme cantidad de datos inconsistentes pero algo redundantes. Adems de los asuntos inherentes rodeando integracin de datos, a los usuarios comerciales les falta la habilidad para acceder a los datos con holgura cuando necesitaron. En un intento para dirigirle la palabra esto
Defecto, varias organizaciones dentro de la compaa de seguros congregado sus recursos y asesores contratados para solucionar sus necesidades de datos de corto plazo individuales. En muchos casos los mismos datos fueron extrados del mismo sys-tems de la fuente para ser a los que se accedi por organizaciones separadas sin cualquier estrategia global estratgica de la entrega de informacin. Desafortunadamente, nadie tuvo el valor proactivamente dar a saber alta gerencia de las consecuencias negativas de este acercamiento. No se tard pues la gerencia para reconocer las ramificaciones negativas asoci con almacenes separados de datos porque el sented de resultados de funcin en las sesiones ejecutivas difiri a merced de la fuente analtica. Man-agement tuvo por entendido que esta ruta independiente no fue viable como una por largo tiempo solucin por la falta de integracin, volmenes abrumadores de datos redundantes, y la dificultad en acceder e interpretar los resultados. Dado la importancia de informacin en este mundo nuevo valiente de seguro, la gerencia fue moti vated para ocuparse de las implicaciones costadas rodeando la urbanizacin, las ineficiencias portuarias en sorbo, y analticas de estos supuestos almacenes de datos que meramente proliferaron las islas operacionales de datos. Un nuevo Jefe de Informacin (el informtico en jefe) fue contratado para conducir el cargo de informacin. La alta gerencia alquil al Congreso de Organizaciones Industriales con la responsabilidad y la autoridad para estudiar en sus partes los silos histricos de datos para logre nir-vana de informacin. Acusaron al informtico en jefe de la responsabilidad fideicomisaria manejar y apalancar los activos de informacin de la organizacin ms eficazmente. El informtico en jefe desarroll una vista global tan casado con una estrategia de la empresa que ocuparse de cantidades macizas de datos, con una respuesta para la necesidad inmediata se conviertan en una organizacin enriquecedora en la informacin. Mientras tanto, un equipo del almacn de datos de la empresa se le cre comenzar a disear e implementando la vista. La alta gerencia ha sido sermonear acerca de una transformacin para un foco ms cntrico en cliente en lugar del acercamiento cntrico en producto tradicional en un esfuerzo a ganar ventaja competitiva. El informtico en jefe se subi de un salto a ese partido triunfador como un catalizador para el cambio y ya ha tenido un impacto. El mensaje ha alcanzado a las personas en las trincheras. Empean intento
para compartir datos en vez de squirrel-ing l fuera para un solo propsito. Hay un deseo ardiente para que todo el mundo tengan una comprensin comn del estado del negocio. Estn clamando para deshacerse de los bolsillos aislados de datos mientras asegurando que tienen acceso al detalle y los datos sumarios en ambos la empresa y que los niveles de clases de negocio.
La Cadena de Valor de Seguro La cadena primaria de valor de una compaa de seguros es aparentemente pequea y simple. Los procesos de corazn son publicar polticas, coleccionar pagos del premio, y reclamos de proceso. La organizacin es interesada en mejor comprensin lo
La mtrica engendrada por cada uno de estos procesos. Los usuarios quieren analizar transacciones detalladas referente a la formulacin de polticas, as como tambin las transacciones generadas por los reclamos yendo en procesin. Quieren medir ganancia con el paso del tiempo por la cobertura, el tipo cubierto (es decir, cul las clases de casas y autos) del artculo, geogrfico, demogrfico, y las caractersticas de canal de distribucin de ventas. Por supuesto, el deseo para monitorear ganancia significa que ambos ingresos y costos pueden ser identificados y rastreados. Mientras los usuarios estn interesados en el per-spective de la empresa, tambin quieren analizar la naturaleza heterognea de giros de negocios de la compaa de seguros. Obviamente, una compaa de seguros trae entre manos muchos otros procesos externos, como la inversin de pagos del premio, as como tambin un montn de actividades internamente enfocadas, como recursos humanos, financia, y purchas-ing. Por ahora, enfocaremos la atencin en el negocio de fondo relacionado con polticas y los reclamos. La cadena de valor de seguro comienza con una coleccin variada de transacciones de poltica. Basado sobre nuestra comprensin actual de los requisitos y datos subyacentes, optamos por manejar todas las transacciones teniendo un impacto sobre una poltica como un solo proceso de negocio (y la mesa de hecho). Si esta perspectiva es demasiado simplista para acomodar la mtrica, la dimensionalidad, o analytics requiri, tenemos la opcin para desdoblar las actividades de transaccin en Tablas separadas (por ejemplo, ponga aparte Tablas de hecho para abrir comillas, evaluando, y firmar al pie de un escrito) de hecho. Como discutimos en Captulo 3, hay trueques entre crear Tablas separadas de hecho pues cada grupo natural de transaccin mecanografa versus aglomerar las transacciones en una sola mesa de hecho. Mientras estamos sobre el tema de polticas, hay tambin una necesidad para mejor comprender la renta del premio asociada con cada poltica sobre una base mensual. ste ser aporte crucial en el cuadro global de la ganancia. En el caso de seguro, el negocio es muy intensivo en la transaccin, pero las transacciones mismas no representan pedazos de light-tle de renta, como lo hizo el caso con venta al por menor o la ventas manufacturera. Nosotros que se se puede no meramente sumamos transacciones de seguro para determinar la cantidad de renta. El cuadro est ms all
complicado en seguro porque los clientes pagan antes para los servicios. Encontramos este mismo modelo de pago anticipado en organizaciones que ofrecen suscripciones de la revista o extendieron contratos de la garanta. Los pagos del premio deben ser difundidos a travs de mltiple los perodos de declaracin porque la organizacin gana la renta con el paso del tiempo como provee cobertura de seguros. La relacin complicada entre transacciones individuales y las medidas bsicas de renta a menudo imposibilita contestar preguntas de renta gateando a travs de las transacciones individuales. No slo est algo semejante gateando consumidor de tiempo, pero la lgica le hizo falta interpretar el efecto de tipos diferentes de transaccin en rev-enue tambin puede estar horrorosamente complicado. El conflicto natural entre la vista detallada de transaccin y la perspectiva mensual de la foto casi siempre pide que construimos ambas clases de Tablas de hecho en el almacn. En este caso, la foto del premio no es meramente un resumen de las transacciones de poltica; Es realmente una cosa separada que viene de una fuente separada.
Las DIMENSIONES COMUNES
El NEGOCIO VA EN PROCESIN Las Transacciones de Poltica La Foto del Premio de Poltica Creo que 15.1 el borrador Inicial llevan en autobs matriz.
Redacte Matriz del Autobs de Seguro Basado sobre las conclusiones de entrevista, junto con una comprensin de los sistemas cruciales de la fuente, el equipo comienza a redactar una matriz del autobs del almacn de datos con los procesos de negocio de fondo como filas y dimensiones de fondo como columnas. En este punto estamos enfocados a los procesos basados en polticas. Metemos dos filas en la matriz, uno correspondiente a las transacciones de poltica y otro para la foto del premio mensualmente helada en Pl.
Como ilustradas en Figura 15.1, las dimensiones de fondo incluyen la fecha, el asegurado, el empleado, la cobertura, cubri tem, y la poltica. Al redactar la matriz, no tratamos de incluir todas las dimensiones porque la matriz podra terminar con 100 columnas o ms. En lugar de eso, intentamos enfocar la atencin en las dimensiones comunes de fondo que se reutiliz en ms de un dibujo tcnico.
Las Transacciones de Poltica Ahora fijemos nuestra atencin en la primera fila de la matriz enfocando la atencin en las transacciones para crear y alterar una poltica. Suponemos que la poltica es el encabezado para un set de coberturas vendidas para el asegurado. Las coberturas pueden ser con-sidered los productos vendidos por la compaa de seguros. Las coberturas del propietario de casa incluyen fuego, inundacin, robo, y responsabilidad personal. Las coberturas del automvil incluyen globales, el dao de colisin, el automovilista no asegurado, y la responsabilidad personal. En una propiedad y compaa de seguro contra accidentes, las coberturas tpicamente se aplican a un artculo cubierto especfico, como un coche o casa particular. Ambos la cobertura y artculo cubierto son identificados cuidadosamente en la poltica. Un detalle cubierto tem usualmente tendr varias coberturas listadas en la poltica. Asumimos que uno helado en Pl puede contener artculos cubiertos mltiples. Simplemente para conservar cosas razonablemente simple, un agente vende la pliza para el asegurado en este caso. Antes de que la poltica puede ser creada, un actuario que le pone precio a impiden mina a la tasa de prima que le sern cargado a la cuenta donado las coberturas especficas, cubrieron artculos, y aptitudes del asegurado. Un asegurador, quin
La responsabilidad de colmo de tomas para hacer negocio con el asegurado, hace la aprobacin final. El sistema operacional de transaccin de poltica capta los siguientes tipos de transacciones: cree poltica, altere poltica, canclele poltica (con razn) cree cobertura en artculo cubierto, altere cobertura, canclele cobertura
(Con razn)
la cobertura de tasa, la disminucin para evaluar cobertura (con razn subscriba poltica, rehsese a subscribir poltica (con razn) El grano de la mesa de hecho de transaccin de poltica sera una fila para cada transaccin de poltica de indi-vidual. Cada transaccin atmica debera ser embellecido con tanto contexto tan posible para crear una descripcin dimensional completa de la transaccin. Las dimensiones asociadas con el proceso de negocio de transaccin de poltica incluye la fecha de transaccin, la fecha de efectividad, asegurado, el empleado, cobertura, cubri artculo, nmero de pliza, y tipo de transaccin de poltica. La Dimensin Detalla y Tcnicas Ahora fomentemos los discos las dimensiones en este dibujo tcnico al aprovechar esta oportunidad para reforzar conceptos de anteriores captulos. La Caracterizacin De Papeles de Dimensin Hay dos fechas asociadas con cada transaccin de poltica. La fecha de transaccin de poltica es la fecha cuando la transaccin fue introducida en el sistema operacional, mientras que la transaccin de poltica que la fecha de efectividad es cuando la transaccin legalmente se lleva a efecto. Estas dos dimensiones independientes pueden ser implementadas usando una sola mesa fsica de fecha. Mltiple las Tablas lgicamente discretas son entonces presentadas a la usuaria a travs de los puntos de vista con nombres nicos de la columna, tan descritos originalmente en Captulo 5.
El asegurado es el cliente en este dibujo tcnico. El asegurado puede ser personas de mltiplo, como una persona y su esposo, o el asegurado puede estar una entidad comercial. El asegurado que la dimensin a menudo capacita como una dimensin grande, como es el caso con nuestro asegurador de $5 billn que est dispuesto a ofrecer a millones de asegurados. Lentamente Cambiando Dimensiones Las compaas de seguros tpicamente son muy interesadas en rastrear cambios para dimen-sions con el paso del tiempo. Le aplicaremos las tres tcnicas bsicas para manipulador lentamente cambiando atributos de dimensin que introdujimos en Captulo 4 a la dimensin de asegurado.
Con el tipo 1 acercamiento, simplemente sobrescribimos el valor precedente de atributo de dimensin. ste es el acercamiento ms simple para ocuparse de atributo cambia porque los atributos siempre representan los descriptores ms actuales. Por ejemplo, quiz el negocio acuerda manejar cambios para la fecha de nacimiento del asegurado como un tipo que 1 cambio bas en la suposicin que cualquier cambios para este atributo es pretendido como correcciones. De esta manera, toda historia de la mesa de hecho para este asegurado parece siempre haber sido asociada con el valor de fecha de nacimiento actualizado. Desde el ZIP del asegurado el cdigo es aporte crucial para el asegurador algoritmos de fijacin de precios y de riesgo, los usuarios son muy interesados en rastrear cambios de cdigo postal, as es que optamos por usar un tipo 2 el acercamiento para este atributo. Tipo 2 es lo ms comn lentamente cambiando acercamiento de dimensin (SCD) cuando hay un requisito para el rastreo preciso de cambio con el paso del tiempo. En este caso, cuando el cdigo postal cambia, creamos una fila nueva de dimensin del asegurado con unos nuevos atributos vicarios y cruciales y actualizados y geogrficos. No regresamos y volvemos a visitar la mesa de hecho. La mesa histrica de hecho rema, antes del cambio de cdigo postal, todava refleje la vieja llave vicaria. Siguiendo adelante, usamos la llave vicaria nueva del asegurado a fin de que las filas nuevas de la mesa de hecho se incorporen al perfil de postcambio. Mientras esta tcnica es sumamente graciosa y poderosa, coloca ms cargas en la aplicacin de escenificacin de datos. Tambin, el nmero de filas en la mesa de dimensin cultiva con cada tipo 2 vuelto SCD. Dado ese hay ya bien sobre 1 millones de filas en nuestra mesa de dimensin de asegurado, podemos optar por usar una minidimensin para rastrear que el cdigo postal cambia, cul repasaremos en poco tiempo. Finalmente, supongamos que cada asegurado est clasificado como perteneciente a un segmento de par-ticular. Quiz histricamente etiquetamos a nuestros asegurados no residenciales tan tampoco comercial o entidades de gobierno. Siguiendo adelante, los usuarios comerciales quieren clasificaciones del cliente ms detalladas. Por ejemplo, el asegurado nuevo se segmenta puede diferenciar entre el abrumador mercado multinacional, intermedio, y los clientes pequeos del anuncio publicitario de negocio, adems de organizaciones sin fines de lucro y agencias del gobierno. Por un perodo de tiempo, los usuarios quieren que la habilidad analice resultados por ya sea las clasificaciones histricas o nuevas de seg-ment. En este
caso nos pudimos uso un tipo 3 el acercamiento para rastrear el cambio por un perodo de tiempo. Le aadimos una columna a la mesa de dimensin, design Tipo histrico del Segmento del Asegurado, para retener las viejas clasificaciones. Los valores nuevos de clasificacin poblaran el atributo de segmento que ha sido una instalacin fija permanente en la dimensin del asegurado. Este acercamiento, mientras no sumamente comn, nos deja ver funcin por ya sea los mapas actuales o histricos del segmento. ste es til cuando hay sido uno en masa cambio, como la reorganizacin de clasificacin del cliente. Obviamente, el tipo 3 que la tcnica se pone excesivamente complicada si necesitamos rastrear ms que un ver-sion del mapa histrico o si necesitamos rastrear antes y despus de los cambios para los atributos mltiples de dimensin.
Minidimensions para Large o Rpidamente Cambiando Dimensiones Como establecimos referencias ms temprano, la dimensin del asegurado califica como una dimensin grande con ms de lo que 1 millones de filas. Los cubiertos tem dimensionan probablemente tambin cadas en esta categora porque la mayora de asegurados aseguran ms que un artculo especfico. En ambos casos, es a menudo importante rastrear contenido aprecia accu-rately para un subconjunto de atributos. Por ejemplo, necesitamos una descripcin precisa de algn asegurado y los atributos cubiertos del artculo a la hora que la poltica fuese creada, as como tambin al momento de cualquier ajuste o cualquier reclamo. Vimos en Captulo 6 que la manera prctica para rastrear cambiar atribuye en dimensiones grandes debi desdoblar lo apretadamente monitoreado, ms rpidamente convertir atributos en uno o ms minidimensiones directamente asociadas al hecho pospone con una llave vicaria separada. El uso de minidimensiones tiene un impacto sobre la eficiencia de brow-ing de atributo porque los usuarios tpicamente quieren hacer una lectura ligera y constreir sobre estos atributos cambiables, as como tambin sobre actualizar. Si todas las combinaciones posibles del el atributo los valores en la minidimensin han sido creados ya, manejar un cambio de minidimensin simplemente significa colocar una llave diferente en la mesa de hecho fila de un cierto punto en el tiempo adelante. Nada ms necesita estar cambiado o sumado para la base de datos. Los Atributos Multipreciados de Dimensin Discutimos atributos multipreciados de dimensin en Captulo 9 cuando nosotros los clientes de mltiplo associ ated con una cuenta y no obstante en Captulo 13 cuando un encuentro paciente requiri mltiplo diagnostica. Ciertamente podramos duplicar a los clientes mltiples por diseo de la cuenta para cada poltica, pero en este caso podramos estudiar que consideraremos an otra situacin multipreciada de modelado: El barco de relacin entre clientes comerciales y sus clasificaciones de la industria. Cada cliente comercial puede ser asociado con uno o ms cdigos estndar de clasificacin de la industria (el Sistema Estndar de Calificacin Industrial). Un cliente grande, diversificado y comercial pudo estar representado por una docena o
ms Sistema Estndar de Calificacin Industrial codifica. Mucho como hizo con Captulo 13 el grupo de diagnstico, construimos un cuadro puente del grupo de Sistema Estndar de Calificacin Industrial para vincular todo lo que el Sistema Estndar de Calificacin Industrial codifica dentro de un grupo de Sistema Estndar de Calificacin Industrial. Este cuadro puente de Sistema Estndar de Calificacin Industrial se incorpora a la dimensin del cliente como un arbotante. Nos deja reportar mtrica de la mesa de hecho por cualquier atributo en la mesa de Sistema Estndar de Calificacin Industrial, ya sea correctamente oprimidos o como un informe de impacto. Para manejar el caso donde ningn cdigo vlido de Sistema Estndar de Calificacin Industrial es asociado con un cliente dado, nosotros simplemente creamos una fila especial de dimensin de Sistema Estndar de Calificacin Industrial que representa la Incgnita. Sigamos adelante hacia la dimensin de cobertura. Las grandes compaas de seguros tendrn docenas o emparejarn centenares de productos de cobertura separados disponibles para costar un tipo dado de artculo cubierto. Si la cobertura tiene deducibles o lmites especficos, generalmente tratamos estos parmetros numricos como los hechos en vez de
Creando una cobertura bien definida para cada valor posible diferente. Por ejemplo, un lmite bsico en la proteccin de fuego de propietario de casa es la valuacin fiscal de la casa. Desde que la valuacin fiscal puede ser pensamiento de como una cantidad continuamente numrica preciada que est medido cada vez que consideramos una poltica diferente y aun podemos diferir para una poltica dada con el paso del tiempo, nosotros los lmites de gusto como los hechos legtimos. Lo cubierto tem es la casa, el coche, u otro artculo asegurado especfico. La dimensin del artculo de cov-ered contiene una fila para cada artculo cubierto real. Como nosotros men-tioned tiempo atrs, la dimensin cubierta del artculo. En general, no gusta captar las descripciones variables del reconocimiento mdico propsitos cubiertos como los hechos porque ms es textual y no es numrico o continuamente preciado. En la mayora de los casos una medida textual es una descripcin de algo sacado de una lista discreta de alternativas. El diseador debera hacer lo imposible por poner medidas textuales en Tablas de dimensin porque pueden estar correlacionados ms eficazmente con los otros atributos textuales en una dimensin y pueden requerir mucho menos espacio, especialmente si la columna propuesta del texto de la mesa de hecho es un campo ancho, de ancho fijo que est a menudo vaco. Los hechos textuales pueden ser contados y embarazosos adelante, pero si son texto gratis imprevisible, las actividades dimensionales usuales de constreir y agruparse sobre estos valores del texto sern de poco valor. Un hecho del texto cierto no es una cosa muy buena para tener en una mesa de hecho. El empleado es el individuo responsable para crear la transaccin. Pues crea poltica y crea transacciones de cobertura, el empleado responsable son el agente. Para evaluar transacciones, el empleado es el evaluador. Asimismo, el asegurador es el empleado involucrado en subscribir transacciones.
Degenere Dimensin El nmero de pliza ser tratado como una dimensin degenerada si hemos extrado toda la informacin del encabezado asociada con la poltica en las otras dimensiones. Obviamente queremos evitar crear una mesa de hecho de transaccin de poltica con simplemente varias llaves mientras empotrar todos los detalles descriptivos (incluyendo al asegurado, fechas, y coberturas) en una poltica
dimensiona. En algunos casos pueden haber uno o dos atributos tan quietos pertenecen a la poltica y no para otra dimensin. Por ejemplo, si el asegurador establece un grado global de riesgo para la poltica, basada sobre la totalidad de las coberturas y los artculos cubiertos, entonces este grado de riesgo probablemente corresponde a una dimensin de poltica. Por supuesto, en esta panorama ya no tenemos una dimensin degenerada. La dimensin de tipo de transaccin de poltica es una dimensin pequea consistente en la transaccin determina el tipo sanguneo listado ms temprano conjuntamente con todo el descrip-tions posible de razn para las transacciones aplicables. Usualmente, una dimensin de tipo de transaccin contiene menos de 100 entradas, aunque no siempre.
La Dimensin de Auditora Siempre tenemos la opcin para aadirle la informacin del keylike a la fila de hecho de transaccin, como una llave de auditora que se acopla para una fila de dimensin creada por el proceso del extracto. Como describimos en Captulo 8, cada fila de dimensin de auditora puede describir el linaje de datos del hecho fila, incluyendo el tiempo del extracto, la mesa de la fuente, y la versin del software del extracto. Podemos ahora presentar el dibujo tcnico de transaccin de poltica, tan ilustrados en Fig Ure 15.2. La mesa resultante de hecho ilustra varias caractersticas de una mesa clsica de hecho del grano de transaccin. Ante todo, el hecho que la mesa se compone casi enteramente de teclea. Los dibujos tcnicos nivelados en la transaccin nos dejan analizar comportamiento en el detalle extremo. Como bajamos hasta aminorar granularidad con datos atmicos, la mesa de hecho naturalmente echa ms dimensionalidad. En este caso el hecho que la mesa tenga un solo hecho numrico, llam cantidad de transaccin de poltica. La interpretacin de la columna de cantidad depende del tipo de transaccin, tan identificada en la dimensin de tipo de transaccin. Porque hay clases diferentes de transacciones en la misma mesa de hecho, nosotros usu-ally no podemos etiquetar el hecho con cualquier cosa ms especfica. Si el sistema de proceso de transacciones introduce tipos adicionales de transacciones, representan un cambio para los datos contentos pero no necesitan una modificacin del dibujo tcnico. Los Productos Heterogneos Mientras hay soporte firme para una perspectiva ancha en la empresa en nuestra compaa de insur-ance, los usuarios comerciales no quieren perder de vista sus cosas especficas de clases de negocio. Las compaas de seguros tpicamente estn involucradas en mltiplo pero muy los diferentes giros de negocios. Por ejemplo, los parmetros detallados de coberturas de dueos de hogar difieren significativamente de coberturas del automvil. Y estos que ambos difieren sustancialmente de cobertura de propiedad personal, cobertura general de adeudo, y otros tipos de seguro. Aunque todas las coberturas pueden ser codificadas en las estructuras genricas hemos usado en lo que va de este captulo, faltante de com-panies de seguro para rastrear numerosos atributos especficos (y quiz los
hechos) que slo tienen sentido para una cobertura particular y artculo cubierto. Le podemos generalizar el dibujo tcnico inicial desarrollado en Figura 15.2 usando la tcnica heterognea de productos que discutimos en Captulo 9.
La dimensin de Cobertura de Dimensin del Empleado de Dimensin del Asegurado de Dimensin de fecha (los puntos de vista para 2 papeles) El Hecho de Transaccin de Poltica La poltica la Llave del Asegurado de la Llave de Fecha de Efectividad de Poltica Transaction Date Key (FK) (FK) (FK) La llave de Cobertura de la Llave del empleado (FK) (FK) Cubri tem Llave (FK) El nmero de pliza de la Llave de Auditora de Transaccin de Poltica de la Llave de Tipo de Transaccin de poltica (DD) (FK) (FK) La Cantidad De Transaccin de Poltica
La Dimensin Cubierta de Auditora de Transaccin de Poltica de Dimensin de Tipo de Transaccin de Poltica de Dimensin del Artculo
Figura 15.2 el dibujo tcnico de transaccin de Policy-Creation.
En Figura 15.3 mostramos un dibujo tcnico a manipular los atributos especficos que describen autos y sus coberturas. Para cada clase de negocio (o el tipo de cobertura), creamos Tablas aduaneras de dimensin para ambos el artculo cubierto y la cobertura. Cuando una aplicacin de acceso necesita los atributos especficos de un solo tipo de cobertura, use las Tablas aduaneras correctas de dimensin. Eche de ver que en este dibujo tcnico transaccional no necesita una mesa aduanera de hecho. Slo introducimos Tablas aduaneras de dimensin a manejar los atributos especiales del automvil. Ninguna llave nueva necesita ser generadas; Lgicamente, todo lo que estamos haciendo es extender existir filas de dimensin.
Foto Que Acumula Poltica Alternativa (o Complementary) Finalmente, antes de que dejamos transacciones de poltica, queremos mencionar brevemente el uso de una foto de atesoramiento para captar el efecto acumulativo de las transacciones. En este caso el grano del hecho que la mesa probablemente sera una fila para cada cobertura / cubierta tem sobre una poltica. Podemos visualizar incluir las siguientes fechas cntricas en la poltica en la mesa de hecho: Citado, evaluado, avalado, efectivo, renovado, y el vencimiento. Muchas de las otras dimensiones que discutimos tambin seran aplicables para este dibujo tcnico, con excepcin de la dimensin de tipo de transaccin. A la foto de atesoramiento probablemente le estableceran un hecho expandido. Como discutimos en Captulo 5, una foto de atesoramiento es efectiva para coleccionar informacin acerca de los hitos cruciales del proceso de transaccin de poltica. Representa el lifespan acumulativo de una poltica, artculos cubiertos, y coberturas; Sin embargo, no capta informacin acerca de cada uno y cada transaccin tan ocurrida. Los acontecimientos transaccionales inusuales o los inesperados mentidores apagados del proceso estndar podran ser ocultos con un per-spective de atesoramiento. Por otra parte, este tipo de foto, sourced de las transacciones, provee un cuadro claro de las duraciones o las veces de atraso entre los acontecimientos cruciales de proceso.
La Cobertura del Automvil Dimensin La descripcin de Cobertura de la Llave de cobertura (PK) La Cobertura del Parabrisa de Deducible del Automvil de Descripcin de Clase de Negocio Incluy A Rental Car Coverage Included El Hecho de Transaccin de Poltica La poltica la Llave del Asegurado de la Llave de Fecha de Efectividad de Poltica Transaction Date Key (FK) (FK) (FK) La llave de Cobertura de la Llave del empleado (FK) (FK) Cubri tem Llave (FK) El nmero de pliza de la Llave de Auditora de Transaccin de Poltica de la Llave de Tipo de Transaccin de poltica (DD) (FK) (FK) La Cantidad De Transaccin de Poltica El Automvil Cubierto La Dimensin del Artculo La llave cubierta (PK) del Artculo Cubri tem Marca del Vehculo del Fabricante del Vehculo de Descripcin El Ao del Vehculo La Clasificacin del Vehculo El Tamao del Motor El Nmero de Capacidad del Pasajero El indicador de la Bolsa de Aire del conductor
Creo 15.3 dibujo tcnico de transaccin de Poltica con Tablas aduaneras de dimensin del automvil.
La Poltica la Foto Peridica El dibujo tcnico de transaccin de poltica vale de mucho contestar una gran variedad de ques-tions. Sin embargo, la ventisca de transacciones dificulta rpidamente impedir lo mo el estatus o el valor financiero de una poltica en un punto dado con el tiempo. Aun si todo el detalle necesario recae sobre los datos de transaccin, una perspectiva de la foto requerira renovar hacia el futuro las transacciones desde principio de historia. No slo es esto casi imprctico sobre una sola poltica, pero es ridculo pensar acerca de puntos de vista de la lnea sobresaliente sumarios gener ating de mtrica crucial de funcin de este modo. La respuesta para este dilema debe crear una segunda mesa de hecho que opera como un compaero para la mesa de transaccin de poltica. En este caso el proceso comercial es la foto mensual del premio de poltica. La granularidad de la mesa de hecho es una fila por la cobertura y el artculo cubierto sobre una poltica cada mes. Las dimensiones conformadas
Por supuesto, cuando abordamos este segundo proceso comercial dentro de nuestra compaa de insur-ance, nos esforzamos por reutilizar tantas dimensiones como las marcas sospechan en la granularidad peridica de la foto. Si Dios quiere, usted se ha convertido en un entusiasta conformado de dimensin a esta hora. Como indicamos en Captulo 3, las dimensiones conformadas utilizaron en Tablas separadas de hecho ya sea debe ser idntico o deben represente un subconjunto de la versin ms granular de la dimensin. El asegurado, abrigado tem, y las dimensiones de cobertura eran idnticas. Reemplazamos la dimensin diaria de fecha con una mesa conformada de dimensin de mes. No necesitamos rastrear a todos los empleados que estaban en cierta forma involucrados en transacciones de poltica sobre una base mensual, aunque puede ser til retener al agente involucrado, cuanto ms que las operaciones del campo son tan enfocadas sobre el anlisis de rendimiento de renta en curso. La dimensin de tipo de transaccin no sera usada porque no tiene aplicacin en la granularidad peridica de la foto. En lugar de eso, introducimos una dimensin de
estatus a fin de que los usuarios le puedan discernir rpidamente al estado actual de una cobertura o una poltica, como las cancelaciones o polticas nuevas este mes y con el paso del tiempo. Los hechos conformados Mientras estamos sobre el tema de conformidad, tambin necesitamos usar hechos conformados. Si los mismos hechos aparecen en Tablas mltiples de hecho, como algunos hechos que son com-mon para esta mesa de hecho de la foto as como tambin la mesa consolidada de hecho legamos dis-cuss ms tarde en este captulo, en ese entonces deben tener etiquetas y definiciones coherentes. Si los hechos no son idnticos, en ese entonces necesitan recibir nombres diferentes.
La Mtrica de Pago por Adelantado La administracin de empresas quiere saber cunto estuvo escrita la renta del premio (o vendi) cada mes, as como cunto la renta fue ganado. En este caso no podemos derivar mtrica de renta meramente resumiendo las transacciones detalladas de poltica. Mientras un asegurado puede pactar y puede pagar por coberturas especficas en artculos cubiertos especficos por un perodo de tiempo, la renta no es ganada hasta que el servicio sea provisto. En el caso de la compaa de seguros, la renta de una poltica es ganada cada mes con tal de que el cliente no le cancela lo helado. Un clculo correcto de uno mtrico como la prima devengada significara completamente reproduciendo todas las reglas comerciales del sistema de reconocimiento de ingresos operacional dentro del almacn de datos aplicacin de acceso. Tpicamente, las reglas para convertir una cantidad de transaccin en su impacto mensual de renta son muy complejo, espe-cially con programas mejorados de cobertura y los descensos. Afortunadamente, estos la mtrica pueden ser sourced de un sistema de reconocimiento de ingresos operacional separado. Como vemos en la foto peridica en Figura 15.4, incluimos dos mtrica de renta del premio en la mesa de hecho a manejar las definiciones diferentes de escrito versus la renta devengada. Simplistically, si una pliza anual para una cobertura dada y al artculo cubierto les fue escrito el 1 de enero para un costo de $600, en ese entonces el premio escrito por enero sera $600, mientras que la prima devengada sea $50 ($600 entre 12 meses). En febrero, el premio escrito es cero, mientras que la prima devengada es $50 quieto. Si la poltica es cancelada el 31 de marzo, la prima devengada por marzo es $50, mientras que el premio escrito es un $450 negativo. Obviamente, en este punto la sarta de renta devengada se trata de una parada de derrumbamiento. Los argumentos comerciales de pagos por adelantado tpicamente requieren que la combinacin de una mesa veteada en transaccin de hecho y una mesa de hecho mensualmente veteada en foto para contesten preguntas de frecuencia de transaccin y oportunidad del momento, as como tambin las preguntas de ingreso devengado en un mes dado. Casi nunca le podemos aadir bastantes hechos a un dibujo tcnico de la foto deshacernos de la necesidad para un dibujo tcnico de transaccin, o viceversa.
La Dimensin de Cobertura de Dimensin del Asegurado de Dimensin de Fin de Mes El Hecho de la Foto del Premio de Poltica La llave del Asegurado de la Llave de Fecha de la Foto de Fin de mes (FK) (FK) La llave de cobertura (FK) Cubri tem Llave Crucial (FK) del Agente (FK) El nmero de pliza de la Llave de Estatus de poltica (DD) (FK) La Cantidad Escrita de Renta del Premio La Cantidad Devengada de Renta del Premio
La Dimensin Cubierta del Artculo La Dimensin del Agente La Dimensin de Estatus de Poltica
Creo que 15.4 la pliza Peridica le toman instantneas al dibujo tcnico.
Los Productos Heterogneos Otra Vez Somos otra vez puestos en la necesidad para mirar datos de la foto por ms atributos de clases de negocio spe cific. En este caso tambin necesitamos enfrentarnos con hechos de la foto que difieren por la clase de negocio. Porque los hechos aduaneros para cada lnea son incompatibles con cada otro, para cualquier fila dada de la foto, la mayor parte de la mesa de hecho se llenara de nulls. En esta panorama, la respuesta es para sep-arate la mesa mensual de hecho de la foto fsicamente por la clase de negocio. Terminamos con el solo dibujo tcnico mensual de la foto de fondo y una serie de fotos mensuales aduaneras, uno para cada clase de negocio o el tipo de cobertura. Cada uno de las Tablas de hecho de la foto de costumbre son una copia de un segmento de la mesa de hecho de fondo para simplemente esas llaves de cobertura y las llaves cubiertas del artculo perteneciente a una particular clase de negocio. Incluimos los hechos de fondo como una conveniencia tan ese analice dentro de un tipo de cobertura pueden usar ambos los hechos de fondo y aduaneros sin hav-ing para acceder a dos Tablas grandes de hecho. Alternativamente, podramos maniobrar el set extendido de hecho aadindole una llave especial de la juntura a cada fila de la mesa de hecho, tan descritas en Captulo 9.
Las Dimensiones Multipreciadas Otra Vez El seguro de automvil nos provee de otra oportunidad discutir dimensiones multipreciadas. A menudo los conductores de la persona asegurada de mltiplo son asociados con un poli-cyholder. Podemos construir un cuadro puente, tan ilustrados en Figura 15.5, para captar la relacin entre los conductores asegurados y el asegurado. En este caso la compaa de seguros puede hacer clculos el factor que oprime que ms real-istically bas en la parte del premio total de cada programa de gestin cost. Tambin podemos hacer cesin comience y los compaeros de cita de fin para el puente ponen sobre una mesa filas para captar cambios de relacin con el paso del tiempo, segn se requiera.
El Hecho de la Foto del Premio de Poltica La llave del Asegurado de la Llave de Fecha de la Foto de Fin de mes (FK) (FK) Ms Llaves Extranjeras La Cantidad Escrita de Renta del Premio La Cantidad Devengada de Renta del Premio Asegurado Por Asegurado El Puente del Conductor La llave del asegurado (FK) Asegur Factor de la Llave del Conductor Weighting (FK)
La Dimensin Asegurada del Conductor La llave asegurada (PK) del Conductor Garantiz Nombre del Conductor Los Atributos Asegurados de la Direccin del Conductor ... la Fecha Asegurada del Conductor de Nacimiento La Ocupacin Asegurada del Conductor Los Atributos Asegurados de Historia de Accidente del Conductor ...
Creo que 15.5 conductores mltiples Manipuladores se asociasen con una poltica.
Ms Historial de Estudio de Casos de Seguro Desafortunadamente, el negocio de seguros tiene un lado de abajo. Aprendemos de los viewees que hay ms a la vida que los pagos colectores del premio. Los costos en esta industria predominantemente resultan de reclamos o prdidas. Despus de que una poltica con sus coberturas asociadas y artculos cubiertos est vigente, en ese entonces un reclamo puede ser hecho en contra de una cobertura especfica y artculo cubierto. Un demandante, quienes pueden ser el asegurado o quiz una fiesta nueva no previamente sabida para la compaa de seguros, hace el reclamo. El demandante provee una descripcin de la prdida en el reclamo. La naturaleza del reclamo obviamente depende de la cobertura y artculo cubierto. Cuando la compaa de seguros abre un reclamo nuevo, una reserva es usualmente estab lished a esta hora. La reserva es una estimacin preliminar del adeudo eventual del com-pany de seguro para el reclamo. Como la ms informacin se vuelve sabida, esta reserva puede estar ajustada. Antes de que la compaa de seguros paga cualquier reclamo, hay usualmente una fase investigadora donde la compaa de seguros manda fuera a un perito tasador para examinar el cov-ered tem y entrevistar al demandante, el asegurado, u otros individuos consistieron en. La fase investigadora produce un caudal de transacciones. En los reclamos de com-plex, los expertos exteriores diversos pueden estar obligados a emitir opinin sobre el reclamo o la extensin del dao. En la mayora de los casos, despus de la fase investigadora, la compaa de seguros publica un nmero de pagos. Muchos de estos pagos van a los terceros como peascos de doctor, los abogados, o los telefonistas automotores de la tienda del cuerpo humano. Algunos pagos pueden ir directamente al demandante. Una grande compaa de seguros puede tener ms que 1,000 individuos que estn autorizados para publicar pagos en contra abre reclamos. Por esta razn, es importante para identificar al empleado responsable para cada pago hecho en contra de un reclamo manifiesto. La compaa de seguros puede tomar posesin del artculo cubierto tras replac-ing l para el asegurado o demandante. En muchos tales casos que hay un valor del salvamento para el artculo, lo cual est realizado eventualmente por la compaa de
seguros. Los pagos de sal-vage recibidos son un crdito en contra del reclamo llevando las cuentas. Eventualmente, los pagos son completados, y el reclamo est cerrado. Si nada en particular ocurre, ste es el fin de la corriente de transaccin generada por el reclamo. Sin embargo, en los casos complicados, los ms reclamos se hacen en ms tarde por o las acciones legales del demandante pueden obtener a la fuerza un reclamo para estar reabiertas. En este caso el usu-ally de la reserva es vuelto a arrancar tambin. Una medida importante para una compaa de seguros es cada cunto y debajo de lo que los reclamos de circunstancias son reabiertos y las reservas son vueltas a arrancar. Hacia la cola cese de tramitar un reclamo complicado, la compaa de seguros puede creer que el ms dinero refluir para la compaa de seguros cundo
Las acciones legales pendientes o las contradenuncias se resuelven eventualmente. La compaa de seguros puede elegir vender las derechas para todas tales ms recuperaciones para special-ists que est preparado para esperar fuera de la decisin de las acciones legales o las reconvenciones. Aunque tales ventas tienen lugar a precio reducido, dejan a la compaa de seguros ponerse efectiva inmediatamente y cerrar sus libros sobre el reclamo. Esta opcin es sabida como la subrogacin y genera su transaccin especial. Adems de analizar las transacciones detalladas, la compaa de seguros tambin quiere entender lo que ocurre durante la vida de un reclamo. Por ejemplo, el intervalo entre la fecha por fijar de reclamo y la primera fecha de pago es una medida de impor-tant de eficiencia que tramita reclamos.
La Matriz Actualizada del Autobs de Seguro Con una mejor comprensin del lado de reclamos de la casa, volveremos a visitar la matriz en borrador de Figura 15.1. Basados sobre los requisitos nuevos tenemos uncov-ered, le aadimos otra fila a la matriz para acomodar transacciones de reclamos, como se muestra en Figura 15.6. Muchas de las dimensiones identificadas tiempo atrs en el proj-ect estarn reutilizadas; Le aadimos las columnas nuevas a la matriz para el reclamo, el demandante, y el tercero. Los equipos de proyecto algunas veces luchan contra el nivel de detalle captado en una matriz del autobs. En la fase planificadora de un architected los datos almacenan proyecto, hace sentido para ser fiel ms bien procesos comerciales de alto nivel (o las fuentes). Las Tablas mltiples de hecho pueden resultar de cada uno de estas filas comerciales de proceso. Como ahondamos en la fase de implementacin, algunas veces llevamos un subconjunto de la matriz a un nivel ms bajo de detalle reflejando todo el hecho pospone resultando del proceso como filas matriciales separadas. En este punto la matriz puede ser realzada en diferentes formas. Podemos sumar columnas para reflejar la granularidad y la mtrica se asoci con cada mesa de hecho. Asimismo, podemos indicar que el uso de ms sum-marized conform dimensiones, especialmente cuando documentando un dibujo tcnico agregado. Hemos ilustrado esta matriz ms bajo del autobs de implementacin en Figura 15.7.
Las Transacciones de Poltica La Foto del Premio de Poltica Reclama Transacciones Creo que 15.6 el seguro Actualizado llevan en autobs matriz.
El Proceso Comercial Granularidad
La Hechos
Mesa
de
Hecho
Las Transacciones Corporativas de Poltica 1 fila para cada transaccin de poltica La Cantidad De Transaccin de Poltica Trxn Eff
Las Transacciones de Poltica Las Transacciones Automticas de Poltica 1 fila por la transaccin automtica de poltica La Cantidad De Transaccin de Poltica Trxn Eff Automvil Automvil
Las Transacciones Hogareas de Poltica Los Premios Corporativos de Poltica

Los Premios de Poltica del Automvil de la Foto del Premio de Poltica
1 fila por la transaccin hogarea de poltica 1 fila para cada poltica, cubierta tem, y la cobertura cada mes 1 fila por la poltica automtica, automvil cubierto La Cantidad De Transaccin de Poltica La Cantidad Escrita de Renta del Premio, la Cantidad Devengada de Renta del Premio La Cantidad Escrita de Renta del Premio, Trxn Eff Dirjase Hacia El Blanco a Casa
Agente
tem, y la cobertura automtica cada mes La Cantidad Devengada de Renta del Premio Automvil El Agente Automtico
Los Premios Anfitriones de Poltica 1 fila por la poltica hogarea, a casa Cantidad Escrita cubierta de Renta del Premio, tem, y la cobertura hogarea cada mes Earned Premium Revenue Amount El Agente de la Casa de la Casa
321 Seguro Figura 15.7 la matriz del autobs de Implementacin detallando Tablas de hecho para cada proceso comercial.
Reclama Transacciones Reclame Transacciones
Reclame Acumular Foto
El Acontecimiento de Accidente 1 fila para cada transaccin de reclamo
1 fila por artculo cubierto y la cobertura sobre un reclamo
1 fila por fiesta de prdida y la afiliacin en un reclamo automtico La Cantidad De Transaccin de Reclamo La Cantidad Original de la Reserva, la Cantidad Evaluada de Dao, Reserve Adjustment Amount, Cantidad Actual de la Reserva, Cantidad Abierta de la Reserva, Cantidad de Reclamo Paid, Pago Received, Salvamento Received, Nmero de Transacciones
La Cuenta Dada a Entender de Accidente Trxn Eff
Automvil
Automvil
Agente
Automvil
Reclama Transacciones Como aprendimos ms temprano, el sistema que tramita reclamos operacionales genera un montn de transacciones, incluyendo los siguientes tipos de transaccin: abra reclamo, reabra reclamo, cierre reclamo la reserva determinada, la reserva vuelta a arrancar, cerca la reserva la estimacin determinada de salvamento, recibe pago de salvamento la entrevista de perito tasador de inspeccin, del perito tasador abra accin legal, cierre accin legal verifique el pago, reciba pago subrogue reclamo Descubrimos cundo actualizando la Figura 15.6 la matriz del autobs que estos usos del dibujo tcnico un nmero de dimensiones desarroll para el mundo de poltica. Otra vez tenemos dos fechas de caracterizaciones de papeles asociadas con las transacciones de reclamos. Las etiquetas nicas de col-umn deberan distinguir la transaccin de reclamos y las fechas de efectividad de esas se asociaron con transacciones de poltica. El empleado es el empleado involucrado en el acontecimiento transaccional. Como mencionado en el caso comercial, esto es en particular interesante para transacciones de la autorizacin de pago. La dimensin de tipo de transaccin de reclamos incluira los tipos de transaccin y agrupamientos simplemente listados. Como se muestra en Figura 15.8, hay varias dimensiones nuevas en el hecho de transaccin de reclamos mesa. La dimensin de reclamo contiene una descripcin codificada del reclamo. Generalmente, debe hacer mapas para la cobertura y artculo cubierto para ser vlido y tener sentido. El demandante es la fiesta haciendo al reclamo, typ-ically un individuo. El tercero es un testigo, experto, o el portador. El demandante y dimensiones de terceros usualmente son dimensiones sucias por la dificultad de fuente fidedigna identificando y rastrendolas a travs de los reclamos diferentes, aunque all ciertamente sera valor al hacer eso. Los portadores potenciales inescrupulosos pueden hacer un esfuerzo extraordinario para no identificarse ellos mismos en uno muy ese facilitara amarrarles a otros reclamos en el sistema del com-pany de seguro.
Las tcnicas del producto heterogneas discutidas tiempo atrs en este captulo son tambin aplicables a datos de reclamos. La nica diferencia es que probablemente queremos extender la mesa de dimensin de reclamo, adems del artculo cubierto y edad de cubierta las Tablas de dimensin, porque parece plausible que pudiesen haber atributos especiales de reclamos que dependen del tipo de cobertura.
La dimensin de Cobertura de Dimensin del Empleado de Dimensin del Asegurado de Dimensin de fecha (los puntos de vista para 2 papeles) Reclama Hecho de Transaccin El reclamo Transaction Date Key (FK) Llave del Asegurado de la Llave de Fecha de Efectividad de Reclamo (FK) (FK) La llave de Cobertura de la Llave del empleado (FK) (FK) Cubri tem Llave Crucial (FK) del Demandante (FK) Reclamo Llave de Fiesta (FK) 3 La llave de Tipo de Transaccin de reclamo (FK) la Llave de Reclamo (FK) Nmero de pliza (DD) La Cantidad De Transaccin de Reclamo
La Dimensin Cubierta del Artculo La Dimensin del Demandante Reclamo Dimensin de Fiesta 3 la Dimensin de Tipo de Transaccin de Reclamo la Dimensin de Reclamo
Resuelva dibujo tcnico de transaccin de 15.8 Reclamos.
Reclama Acumular Foto Como hemos visto en el pasado, aun con un dibujo tcnico nivelado en la transaccin robusto, hay una clase entera de preguntas comerciales urgentes que no pueden ser contestadas utilizadoras slo detalle de transaccin. Es difcil de derivar reclamo para fechar medidas de funcin atravesndole a travs de cada transaccin detallada desde principio de la historia del reclamo y aplicndole las transacciones apropiadamente. Sobre una base peridica, quiz en el final de cada da, podemos renovar hacia el futuro todas las transacciones para actualizar una foto de reclamos de atesoramiento incrementalmente. La granularidad es una fila para cada combinacin nica de poltica, cobertura, cov-ered tem, y reclamo. La fila es creada una vez cuando el reclamo es abierto y entonces est actualizado a todo lo largo de la vida de un reclamo hasta que est finalmente cerrada. Muchas de las dimensiones son reusables, dimensiones conformadas, tan ilustradas en Figura 15.9. Incluimos ms fechas en esta mesa de hecho a rastrear los hitos cruciales en la vida de un reclamo. Las fechas nos dejan observar los intervalos fcilmente. Tambin hemos sumado una dimensin de estatus para rpidamente identificar todos reclamos manifiestos, cerrados, o reabiertos, por ejemplo. Las dimensiones especficas en la transaccin como empleado, demandante, tercera parte festejan, y reclaman tipo de transaccin se suprime, considerando la lista de medidas aditivas, numricas ha sido expandido. En los casos dnde un reclamo no es tan de breve duracin, tan con discapacidad a largo plazo o la cautela reclama eso tenga un intervalo de vida de multiao, podemos representar la foto como una foto mensual peridica en vez de una variedad de atesoramiento. El grano de la foto peridica sera una fila para cada reclamo en funciones cada mes. Los hechos representaran hechos numricos, aditivos tan ocurridos durante el mes, como cantidad reclamada, cantidad pagada, y cambiaran en reserva. En algunas situaciones nos encontramos construyendo todos
los tres tipos de Tablas de hecho para el mismo proceso comercial.
La Dimensin de Cobertura de Dimensin del Agente de Dimensin del Asegurado Reclama Acumular Hecho de la Foto El reclamo Open Date Key (FK) Reclame Reclamo de la Llave de Fecha de Terminacin de Valoracin (FK) Llave 1 (FK) de Fecha de Pago Reclame Reclamo Ms Reciente Payment Date Key (FK) La Mayora de Reclamo Reciente de la Llave de Fecha de Transaccin (FK) Cerca Llave de Fecha (FK) La llave de Cobertura de la Llave del Agente de la Llave del asegurado (FK) (FK) (FK) Cubri tem Llave Crucial (FK) de Reclamo de la Llave de Estatus de Reclamo de la Llave del Demandante (FK) (FK) (FK) La cantidad de la Reserva del Original de nmero de pliza (DD) Evalu Cantidad de la Reserva del Claro de Cantidad de la Reserva de la Corriente de Cantidad de Ajuste de Reserva de Cantidad de Dao Afirmo Que la Cantidad Le Pag A Payment Received Salvage Received Number de Transacciones La fecha por fijar de reclamo para el Atraso de Valoracin la Fecha por Fijar de Reclamo para el Atraso 1 de Pago la Fecha por Fijar de Reclamo para el Atraso Cercano
La Dimensin Cubierta del Demandante de Dimensin del Artculo la Dimensin de Estatus de Reclamo la Dimensin de Reclamo
Creo dibujo tcnico de la foto de atesoramiento de 15.9 Reclamos.
La Poltica /reclamos Consolid Foto Con las cuatro Tablas de hecho diseadas hasta ahora (adems de las extensiones heterogneas), entregamos una perspectiva robusta de la poltica y que transAc-tions de reclamos, adems de fotos de ambos procesos. Sin embargo, acurdese de que los usuarios expresaron un inters fuerte en la mtrica de la ganancia. Mientras el premio y el reclamo la mtrica financiera se deriv por separadamente poniendo en duda dos Tablas de hecho y entonces combinando el set de resultado, optamos por ir del siguiente paso en el espritu de facilidad de uso y la funcin. Podemos construir otra mesa de hecho para juntar la renta del premio y la mtrica de prdida de reclamo, como se muestra en Figura 15.10. Esta mesa tiene un set reducido de dimensiones correspondiente a su granularidad ligeramente mensual summa rized. Como usted recuerda de Captulo 7, nos referimos a esto como una mesa consolidada de hecho porque combina datos de procesos comerciales mltiples. Es mejor desarrollar Tablas consolidadas de hecho despus de que la mtrica de base ha sido redimida en los modelos dimensionales separados.
La Dimensin de Cobertura de Dimensin del Asegurado de Dimensin de Fin de Mes El Hecho Consolidado de Poltica /reclamos La llave del Asegurado de la Llave de Fecha de la Foto de Fin de mes (FK) (FK) La llave de cobertura (FK) Cubri tem Llave Crucial (FK) del Agente (FK) La llave de Estatus de poltica (FK) el Nmero de Pliza de la Llave de Estatus de Reclamo (DD) (FK) La Cantidad Escrita de Renta del Premio Gan Cantidad de Indemnizacin Pagada de Cantidad de Renta del Premio La Cantidad del Recibo de Reclamo
La Dimensin Cubierta del Artculo La Dimensin de Estatus de Poltica de Dimensin del Agente la Dimensin de Estatus de Reclamo
Figura 15.10 la poltica /reclamos consolidaron dibujo tcnico.
Los Acontecimientos de Accidente de Factless Cuando discutimos Tablas de hecho de factless en Dividen en Captulos 12, nos referimos a ellos como la colisin de llaves en un punto en espacio y el tiempo. En el caso de un asegurador del automvil, podemos registrar colisiones literales usando una mesa de hecho de factless. En esta situacin el hecho que la mesa registra lo muchos para muchas correlaciones entre la prdida festeja y artculos de prdida o, para ponerle a ella menos eufemsticamente, todas las correlaciones entre las personas y los vehculos involucrados en un accidente. Varias dimensiones nuevas aparecen en la mesa de hecho de factless mostrada en Figura 15.11. La fiesta de prdida describe a otros individuos que estaban involucrados en el accidente, posiblemente como pasajeros, es testiga, o en otra capacidad. Si la fiesta de prdida no fuese asociada con un vehculo en el accidente, en ese entonces la llave del vehculo de prdida se incorporara a un Ningn Vehculo entrada en esa dimensin. La afiliacin de prdida explica el papel de la fiesta de prdida (y el vehculo de prdida, si aplicable) para el reclamo. Otra vez, como hicimos en Captulo 12, incluimos un hecho que es siempre preciado a las 1 para facilitar contar y la agregacin. Estos factless que la mesa de hecho puede representar complican acci-dent involucrando a muchos individuos y vehculos porque el nmero de fiestas complejas con papeles diversos est indefinido. Cuando hay ms que un demandante o el partido de prdida se asoci con un accidente, nosotros optativamente podemos tratar estas dimensiones como grupo del demandante que consume dimensiones multipreciadas y cuadros puentes del grupo de fiesta de prdida. Esto tiene la ventaja que el grano de mesa del hecho es conservado como un registro por el reclamo de accidente. Cualquier dibujo tcnico que la variacin podra responder preguntas tan Cuntos reclamos corporales de la lesin representamos nosotros han-dle que donde Socios del abecedario Legal el demandante y tienda del cuerpo humano de EZ-DENT B-GONE realizaron la reparacin?
La Dimensin de Cobertura de Dimensin del Asegurado de Dimensin de Fecha Cubri tem Dimensin El Hecho de Acontecimiento de Accidente La llave de Cobertura de la Llave del Asegurado de la Llave de Fecha de accidente (FK) (FK) Cubri tem Llave Crucial (FK) de Reclamo de la Llave del Demandante (FK) (FK) El nmero de pliza de la Llave de Afiliacin de Prdida de la Llave del Vehculo de Prdida de la Llave de Fiesta de prdida (DD) (FK) (FK) (FK) El accidente Count (siempre 1)
La Dimensin del Demandante Reclame Dimensin del Vehculo de Prdida de Dimensin de Fiesta de Prdida de Dimensin La Dimensin de Afiliacin de Prdida
Figura 15.11 la mesa de hecho Factless para los acontecimientos de accidente.
El Modelado Dimensional Comn Los Errores a Evitar
Como cerramos este captulo final sobre las tcnicas dimensionales de modelado, pensamos que sera de ayuda establecer linderos ms all de los cuales los diseadores no deberan ir. Hasta ahora en este libro que tenemos presentaron conceptos por positivamente manifestando que usted debera usar A de tcnica en X de situacin. Ahora, en vez de focus-ing sobre las conmociones, revolvemos nuestra atencin para no para dos explicando en detalle tcnicas modeladoras dimen sional que deberan ser evitadas. Como hicimos con Captulo 1 es lista de hoyas cubiertas, hemos escorado lo no para dos en la orden inversa de importancia. Est al tanto, sin embargo, tan parejo los errores menos importantes enlatan seriamente compro mise que sus datos almacenan. Error 10: Los atributos del texto del lugar destinados para constreir y a agruparse en una mesa de hecho. El proceso de crear un modelo dimensional es siempre un tipo de triage. Las medidas numricas efectuaron la entrega de una fuente comercial operacional de proceso corresponda a la mesa de hecho. Los atributos textuales descriptivos del contexto de las medidas se van en Tablas de dimensin. Finalmente, hacemos un campo por la decisin del campo acerca de los cdigos residuales y los artculos pseudonumeric, colocndolos en la mesa de hecho si son ms como medidas Y en la mesa de dimensin si fueran ms como descripciones fsicas de algo. Usted no debera perder nimo y debera dejar texto verdadero, campos de comentario expecially, en la mesa de hecho. Necesitamos sacar estos atributos del texto de la principal pista de aterrizaje de su almacn de datos y en Tablas de dimensin. Error 9: El modo de palabra completa del lmite los atributos descriptivos en dimensiones a salvar
Espacie. Usted podra pensar que usted es un diseador bueno, conservador por ah Manteniendo el tamao de sus dimensiones bajo control. Sin embargo, en virtualmente
Cada datos almacenan, las Tablas de dimensin son geomtricamente ms pequeas que las Tablas de hecho. Tener una mesa de dimensin del producto 100-MB es insignificante si la mesa de hecho es 100 veces tan abrumadoras! Su trabajo como el diseador de un almacn de datos fciles de usar deba suministrar tanto contexto descriptivo poco conciso en cada dimensin como usted puede. Haga seguro cada cdigo es aumentado con texto descriptivo legible. Mejor an, usted probablemente puede quitar los cdigos enteramente. Recuerde que los atributos textuales en las Tablas de dimensin le proveen la interfaz de usuario a datos haciendo una lectura ligera, constriendo, o filtrando, as como tambin el contenido para la fila y los encabezados de la columna en sus informes finales. Error 8: Desdoble jerarquas y niveles de jerarqua en dimensiones mltiples.
Una jerarqua es una serie propagada en cascada de muchos para una las relaciones. Por ejemplo, Muchos productos pueden reinvertir para una sola marca; Y muchas marcas pueden rodar Hasta una sola categora. Si su dimensin es expresada en el nivel mnimo De granularidad (por ejemplo, el producto), en ese entonces todos los niveles ms altos del hier Archy puede ser expresado como los valores nicos en el producto remen. Los usuarios debajo Las jerarquas del puesto. Su trabajo es presentar las jerarquas en lo ms natural Y la manera eficiente. Una jerarqua corresponde juntos a un solo reventn fsico La mesa de dimensin. Resista el deseo a copo de nieve una jerarqua generando uno El set de progresivamente Tablas ms pequeas de subdimensin. En este caso usted sera Confundiendo datos de la trastienda escenificando con presentacin delantera de datos del cuarto! Finalmente, si ms de lo que un movimiento hacia arriba existe simultneamente para una dimensin, adentro La mayora de casos a los que es perfectamente razonable incluyen jerarquas mltiples en lo La misma dimensin, con tal de que la dimensin haya estado definida en lo mnimo El grano posible (y las jerarquas estn excepcionalmente etiquetadas).
Error 7: Ignore la necesidad para rastrear cambios de atributo de dimensin. En contra de la creencia popular, los usuarios comerciales a menudo quieren comprender el impacto de cambios para un subconjunto de atributos de las Tablas de dimensin. Es difcil que sus usuarios se reacomodarn para Tablas de dimensin con atributos que siempre reflejan el estado actual de mundo. Tenemos tres tcnicas para rastreador lentamente conmoviendo cambios de atributo; No confe en tipo 1 exclusivamente. Asimismo, si un grupo de atributos cambia rpidamente, no se demore dividiendo una dimensin para tener prevista una minidimensin ms voltil. Usted no siempre puede comprender la volatilidad de sus datos cuando usted primero disea las dimensiones. Supongo que su dimensin del producto contiene un set de atributos designados parame-ters estndar. Al
principio del proceso del diseo a usted se le asegura que estos parmetros de stan-dard se compongan para la vida del producto. Sin embargo, despus de desenrollar su almacn de datos, usted descubre que este cambio de atributos varias veces al ao para cada producto. Ms pronto, en vez de ms tarde, usted probablemente debera separar su dimensin del producto en dos dimensiones. La dimensin nueva de parmetro del estndar del producto mantendr su dimensin del producto original lejos de floreciente desastrosamente si usted intentase modelarla tan lentamente cambiante.
Error 6: Solucione todos los problemas de funcin de averiguacin sumando loza ms dura. Los agregados, o las derivativas Tablas sumarias, estn la mayor parte de forma eficiente en base a costos para mejorar funcin de averiguacin. La mayora de vendedores de la herramienta de averiguacin tienen apoyo explcito para el uso de agregados, cul depende de construcciones dimensionales explcitas de modelado. Sumar hardware caro debera hacerse como parte de un programa simtrico que incluye construir agregados, crear indices, escoger software eficiente en la averiguacin de sistema de gestin de base de datos, aumentar tamao autntico de memoria, aumentar velocidad de la UPC, y finalmente, sumar paralelismo en el nivel del hardware. Error 5: Use operacional o la punzada teclea para adjuntar las Tablas de dimensin a una mesa de hecho. Los datos legos almacenan a los diseadores son algunas veces demasiado de mentalidad literal al disear las llaves primarias de las Tablas de dimensin que se conectan a las llaves de for-eign de la mesa de hecho. Es contraproductivo declarar una suite entera De dimensin los atributos como la dimensin ponen sobre una mesa llave y entonces los utilizan como la base de la juntura fsica para la mesa de hecho. Esto incluye la costumbre aciaga de declarar la llave de dimensin para ser la llave operacional, junto con una fecha de efectividad. Todos los tipos de problemas feos surgirn eventualmente. Usted debera reemplazar la llave fsica bonita con una llave simple del substituto de entero que est numerada secuencialmente de 1 hasta N, donde la N es el nmero total de filas en la mesa de dimensin. Error 4: Descudese de declarar y entonces acceder con el grano de la mesa de hecho.
Todos los diseos dimensionales deberan comenzar con el proceso comercial que la informacin Los erates las medidas numricas de funcin. En segundo lugar, especifique lo exacto La granularidad de esa informacin. El hecho edificador pospone en lo ms atmico, granular El nivel graciosamente resistir el ataque ad hoc. En tercer lugar, rodee estos mea Los surements con dimensiones que son ciertas para ese grano. Permaneciendo cierto lo El grano es un paso crucial en el diseo de un modelo dimensional de datos. Uno sutil Pero el error serio en un diseo dimensional debe aadirle los hechos tiles a un hecho Mesa, como las filas que describen los totales por un extendido perodo de tiempo o uno grande El rea geogrfico. Aunque estos hechos adicionales son bien conocidos al momento de La medida individual y parecera hacer algo de aplicaciones Ms simple, causan descalabro porque todas las sumas totales automticas a travs Las dimensiones sobre-cuentan estos hechos del nivel ms alto, produciendo resultados incorrectos.
Cada cantidad muy pequea diferente de medida exige su mesa de hecho.
Error 3: Disee el modelo dimensional basado en un informe especfico. Un modelo dimensional no tiene nada que ver con un informe pretendido! Ms bien, es un modelo de un proceso de medida. Las medidas numricas forman la base de Tablas de hecho. Las dimensiones que son apropiadas para una mesa dada de hecho son el contexto de reconocimiento mdico que describe las circunstancias de las medidas. Vemos que un modelo dimensional se basa slidamente sobre la fsica de un proceso de mea-surement y es realmente independiente cmo elige un usuario definir
Un informe. Un equipo de proyecto una vez se confes con nosotros que haban construido varios centenares de hecho que las Tablas para entregar ordenan datos administrativos para sus usuarios. Result que cada hecho que la mesa se haba construido para ocuparse de una peticin especfica de informe. Los mismos datos estaban siendo extrados muchos, muchas veces para poblar todas estas Tablas de hecho. Como es lgico, el equipo pona el mximo empeo en actualizar las bases de datos dentro de la ventana nocturna de la cantidad de cosas. En vez de disear un cenagal de dibujos tcnicos cntricos en informe, deberan haber enfocado la atencin en la medida proceso (es). Los requisitos de los usuarios pudieron haber sido tratados con un dibujo tcnico bien diseado para los datos atmicos junto con un puado (no los centenares) de agregaciones que realzan funcin. Error 2: Espere que usuarios pongan en duda los datos atmicos nivelados mnimos en un formato de normal-ized. Los datos del nivel mnimo son siempre lo ms dimensional y debera ser la fundacin de su diseo dimensional. Los datos que han sido agregados de cualquier modo han sido privado des algunos de sus dimensiones. Usted no puede hacer un centro de compras de datos de datos agregados y puede esperar que sus usuarios y sus herramientas como una sola pieza profundicen para los terceres datos normales de la forma para lo Los detalles atmicos. Los modelos normalizados pueden ser de ayuda para escenificar los datos, pero nunca deberan servir para presentarle los datos a usuarios comerciales. Error 1: Fracase en conformar hechos y dimensiones de a travs ponen aparte Tablas de hecho.
Esto final no para hacer debera replantearse como dos separen errores porque Son ambos tan peligroso para un ambiente atinado del almacn de datos, Pero nos hemos quedado sin nmeros de error para asignar, as es que los hemos aglomerado En uno.
Sera una lstima llegar as de lejano y entonces construir toberas aisladas de datos. Nos referimos a esto como arrebatar derrota de las mandbulas de victoria. Si usted tiene un hecho medido numrico, como la renta, en dos o ms sourced de centros de compras de datos de sistemas subyacentes diferentes, en ese entonces usted necesita tardar cautela especial en asegurar que las definiciones tcnicas de estos hechos equivalen exactamente. Si las definiciones no equivalen exactamente, en ese entonces ambos no deberan ser referidas
Para como la renta. Esto se llama conformar los hechos.
Finalmente, la sola tcnica ms importante del diseo en el arsenal dimensional de modelado es conformar sus dimensiones. Si dos o ms Tablas de hecho tienen la misma dimensin, en ese entonces usted debe ser fantico acerca de hacer Estas dimensiones subconjuntos idnticos o cuidadosamente escogidos el uno del otro. Cuando usted conforma sus dimensiones a travs de Tablas de hecho, usted podr entrenarse a travs de fuentes separadas de datos porque las restricciones y los encabezados de la fila quieren decir lo mismo y fsforo en el nivel de datos. Las dimensiones conformadas son el secreto que la salsa necesit para construir almacenes distribuidos de datos, aadirle las fuentes nuevas inesperadas de datos a un almacn existente, y hacer tecnologas incompatibles mltiples funcionar juntos armoniosamente.
Resumen En este final estudio de casos diseamos una serie de seguro modelos dimensionales representando la culminacin de muchos conceptos importantes desarrollado a travs fuera de este libro. Esperanzadamente, ahora usted se siente a gusto y confidente usando el vocabulario y herramientas de un modelador dimensional. Con modelado dimensional dominado con maestra, fijamos nuestra atencin en todas las otras actividades que ocurren durante el lifecycle de un proyecto atinado del almacn de datos en el siguiente captulo. Antes de que usted vaya hacia adelante y es dimensional, es til tener esta perspectiva integral y comprensin, aun si a su foco de trabajo se le limita modelar.
Construyendo el Almacn de Datos
l engrana cambio ms bien dramticamente en este captulo. En vez de enfocar la atencin en tcnicas dimensionales de modelado, fijamos nuestra atencin en todo lo dems que ocurre durante el curso de un diseo del almacn de datos e implementacin proyecto. Caminaremos a travs de la vida de un proyecto del almacn de datos de principio a travs del mantenimiento en curso, identificando supera oficinas de leyes a cada paso, as como las vulnerabilidades potenciales. Ms cobertura global del lifecycle de la casa de loza de datos est disponible en La Data Warehouse Lifecycle Toolkit, por Ralph Kimball, Laura Reeves, Margy Ross, y Warren Thornthwaite (Wiley, 1998). Este captulo es un curso intensivo sacado del texto completo, lo cual pesa adentro en unas fuertes pginas 750 +. Algunos pueden percibir que el contenido de este captulo es aplicable slo para los administradores de proyecto de la casa de loza de datos. Ciertamente no consideramos que ste sea el caso. Imple-menting que un almacn de datos requiere apretadamente integr actividades. Creemos que todo el mundo en el equipo de proyecto, incluyendo el analista de empresas, el arquitecto, el diseador de la base
de datos, el sabio de datos, y el analtico desarrollador aplicativo, las necesidades una comprensin de alto nivel del lifecycle completo de un almacn de datos. Como el resto de libro, hemos escrito este captulo a fin de que sea accesible para una audiencia ancha.
Divida en captulos 16 cubiertas los siguientes conceptos:
la visin general dimensional comercial del lifecycle los datos almacenan planificacin de proyecto y gerencia y comunicacin en curso las tcticas para coleccionar requisitos comerciales, incluir priorizacin
331
el proceso para desarrollar la arquitectura tcnica y entonces seleccionar productos los talleres dimensionales del diseo las consideraciones fsicas del diseo, la indexacin y agregacin inclusiva las recomendaciones de escenificacin de datos el diseo aplicativo analtico y el desarrollo las recomendaciones para la implementacin, el mantenimiento en curso, y el crecimiento futuro los errores comunes a evitar al construir y manejar un almacn de datos
El Mapa De Rutas Dimensional Comercial del Lifecycle Al conducir hacia un lugar nunca hemos debido antes, la mayor parte de nosotros confiamos en un mapa de rutas. De modo semejante, un mapa de rutas es sumamente til si estamos a punto de embarcarnos en el viaje poco familiar de datos almacenando. Los autores de La Data Warehouse Lifecycle Toolkit echaron mano de decenios de experiencia para desarrollar el acercamiento comercial de dimen-sional lifecycle. Escogimos el nombre porque reforz varios de nuestras afirmaciones cruciales para datos atinados almacenando. Ante todo, los datos tienen cuidado con casa que los proyectos deben enfocar sobre las necesidades del negocio. En segundo lugar, el sented de datos para los usuarios comerciales debe ser dimensional. Si Dios quiere, esto es de esperar para cualquier lectores en este punto! Finalmente, mientras el almacenar datos es un proceso en curso, cada proyecto de implementacin debera tener un ciclo finito con un comienzo especfico y debera cesar. Usamos el diagrama en Figura 16.1 para narrar de forma resumida las actividades principales del lifecycle dimensional comercial. El diagrama ilustra secuencia de tarea, depen-dency, y concurrencia. Sirve de un mapa de rutas para ayudar a los equipos a hacer lo correcto en el momento oportuno. El diagrama no refleja una lnea cronolgica absoluta. Mientras las cajas son igualmente anchas, hay una vasta diferencia en el tiempo y el esfuerzo requerido para cada uno la actividad principal.
Proyctese
La planificacin
La Definicin Comercial de Requisitos El Diseo Tcnico de Arquitectura
Dimensional El modelado La Seleccin del Producto y la Instalacin
Fsico El diseo
El Diseo de Escenificacin de Datos y el Desarrollo
Implementacin
El Mantenimiento y el Crecimiento
La Especificacin Aplicativa Analtica El Desarrollo Aplicativo Analtico
Administracin Del Proyecto Resuelva 16.1 Heces el diagrama dimensional del lifecycle.
El Mapa De Rutas Major Points de Inters Antes de que buceemos en cosas especficas, requirmonos un momento para orientarnos nosotros mismos para el mapa de rutas. Los datos almacenan lifecycle comienza con planificacin de proyecto, como uno esperara. Durante este mdulo evaluamos la presteza de la organizacin para una iniciativa del almacn de datos, establecen la justificacin y alcance preliminar, obtienen recursos, y emprenden el proyecto. La administracin del proyecto en curso sirve de una fundacin para conservar el resto del lifecycle en pista. La segunda tarea principal en Figura 16.1 enfoca la atencin en defini-tion comercial de requisitos. Note la flecha de doble va entre la planificacin de proyecto y la definicin comercial de requisitos porque hay mucha interaccin entre estas dos actividades. Alineando el almacn de datos con requisitos comerciales es absolutamente crucial. Las tecnologas mejores en su campo no rescatarn un almacn de datos que se rehusa a enfocar la atencin en el negocio. Los datos almacenan a los diseadores deben comprender las necesidades del negocio y las deben traducir a consideraciones del diseo. Los usuarios de Busi-Ness y sus requisitos tienen un impacto en casi cada decisin del diseo y de implementacin hecho durante el curso de un proyecto del almacn. En Figura mapa de 16.1 vas, esto se refleja por las tres huellas paralelas que entienden. La pista sobresaliente de Figura 16.1 se ocupa de tecnologa. El diseo tcnico de arquitectura establece el armazn global para soportar la integracin de tecnologas mltiples. Usando las capacidades identificadas en el diseo de arquitectura como una lista de compras, entonces evaluamos y seleccionamos productos especficos. Echo de ver que la seleccin del producto no es la primera caja en el mapa de rutas. Uno de los errores ms frecuentes hizo por equipos legos es seleccionar productos sin una comprensin evidente de lo que estn tratando de lograr. Esto es semejante para agarrar uno ham-mer ya sea usted necesita golpear una ua o apretarse un tornillo. La pista intermedia dimanando de definicin comercial de requisitos enfoca la atencin en datos. Empezamos por traducir los requisitos a un modelo dimensional, como hemos estado practicando. El modelo dimensional es entonces transformado en una estructura fsica. Enfocamos la atencin en funcin afinando estrategias,
como aggre-gation, la indexacin, y la particin de discos, durante las actividades del diseo de reconocimiento mdico. No menos importante, los procesos de carga de transformacin de extracto de escenificacin de datos (ETL) son diseados y desarrollados. Como mencionamos ms temprano, las bofetadas igualmente dimensionadas no representan esfuerzos igualmente clasificados segn el tamao; Esto cae de su peso cuando pensamos acerca de la carga de trabajo diferencial entre datos y diseo fsico escenificando actividades. El set de cierre de tareas engendradas por la definicin comercial de requisitos es el diseo y desarrollo de aplicaciones analticas. Los datos almacenan proyecto no est terminado cuando entregamos datos. Las aplicaciones analticas, en la forma de plantillas accionadas por parmetros y analizan, satisfarn un porcentaje abrumador de las necesidades analticas de usuarios comerciales.
Juntamos la tecnologa, datos, y huellas aplicativas analticas, junto con una buena dosis de educacin y el soporte, para uno deploy-ment bien orquestado. Desde all, el mantenimiento en curso se necesita para asegurar que los datos almacenan y su comunidad del usuario permanece saludable y equilibrada para apalancar la inversin. Finalmente, manejamos crecimiento futuro del almacn de datos iniciando subsiguientes proyectos, cada regresando al comienzo del lifecycle una vez ms. Ahora que tenemos una comprensin de alto nivel del struc-ture global del mapa de rutas, ahondaremos en cada uno de las bofetadas de Figura 16.1 para ms detalles.
La Planificacin De Proyecto y la Gerencia Como es lgico, lanzamos el almacn de datos con una serie de actividades de planificacin de proyecto. Algunas veces nos referimos a estos como las tareas del malvavisco porque son suaves, pegajosos, y pueden arruinar las obras de un proyecto del almacn de datos seriamente.
Evaluando Presteza Delante del vapor lleno en movimiento adelante con datos significativos los gastos del almacn, es medido requerirse un momento para evaluar la presteza de la organizacin para proceder. Basados sobre nuestra experiencia acumulativa de centenares de almacenes de datos, nosotros hemos identificado cinco factores que diferencian proyectos que fueron predominantemente suaves veleros versus esos que conllevaron una constante lucha. Estos factores son indicadores anticipados de datos almacenan xito. Usted no necesita que marcas altas sobre cada factor se muevan hacia adelante, pero cualquier dficits representan riesgos o vulnera-bilities. Describiremos las caractersticas en la orden flagrante de importancia. El factor ms crtico para el almacenar atinado de datos es tener a un patrocinador comercial fuerte. Los patrocinadores comerciales deberan tener una vista para el impacto potencial de un almacn de datos sobre la organizacin. Deberan ser
apasionados y personalmente convencidos de valor del proyecto mientras el positivista al mismo tiempo. ptimamente, el patrocinador comercial tiene una trayectoria de xito con otras iniciativas internas. l o ella debera ser un lder polticamente astuto que puede convencer sus miradas fijas para soportar el almacn. Algunas veces hay demanda fuerte para un almacn de datos originndose de un solo patrocinador. Aun si esta persona y su oportunidad abarcan las caractersticas de la casa de loza que andamos buscando, todava podemos encontrar problema en esta panorama porque los patrocinadores solitarios tienden a moverse adelante, ya sea internamente o externamente. sta es la causa ms comn para el estancamiento del almacn de datos. Algunos equipos son puestos en demasiado demanda viniendo de todas las esquinas del organiza-tion. Suponiendo que usted (o su gerencia) no trata de abordar todo el
Exija de un golpe, sta es una gran forma para iniciar. Finalmente, el patrocinador comercial puede ser desaparecido en combate, pero esto no detiene la organizacin de tecnologa de la informacin de moverse hacia adelante, casi garantizar un almacn de datos salida en falso. sta es la panorama ms riesgosa; El proyecto despacio debera derribar hasta que el patrocinador comercial correcto haya sido identificado (o quiz reclutado) y ha sonorizado uno commit-ment para el proyecto. El segundo factor de presteza tiene un motiva-tion firme, apremiante y comercial para construir un almacn de datos. Este factor a menudo va aparejado con patrocinio. Un proyecto del almacn de datos meramente no puede entregar uno agradable para tener capacidad; Necesita solucionar problemas comerciales crticos para acumular los recursos requeridos para una lancha atinada y un lifespan sano. La motivacin apremiante tpicamente crea un sentido de urgencia, ya sea la motivacin es de fuentes externas (por ejemplo, los factores competitivos) o internas (por ejemplo, la incapacidad para analizar adquisiciones del grupo de seguidores de funcin de organizacin cruzada). El tercer factor al evaluar presteza es viabilidad. Hay varios aspectos de viabilidad, como la viabilidad tcnica del recurso o, pero feasibil-ity de datos es lo ms crucial. Coleccionamos nosotros los datos autnticos en sistemas de la fuente realmente operacionales para soportar los requisitos comerciales? La viabilidad de datos es uno con-cern principal porque no hay apuro de corto plazo si ya no coleccionamos datos limpios que se razonan hbilmente de la fuente en la granularidad correcta. Los siguientes factores no son showstoppers de proyecto sino todava influencian a su probabil ity para el xito. El cuarto factor enfoca la atencin en la relacin entre el busi-ness y ella las organizaciones. En su compaa, comprende el organismo de tecnologa de la informacin y respeta el negocio? Inversamente, comprende el negocio y respeta la organizacin de tecnologa de la informacin? La incapacidad a honestamente contestar que s para estas preguntas no quiere decir que usted no pueda proceder. Ms bien, significa que usted necesita vigilantemente mantener el negocio y a L representantes marchando para el mismo tambor. De muchas formas los datos almacenan iniciativa puede ser un oppor-tunity para reparar la cerca entre estas organizaciones, suponiendo que ambos efectan la entrega. El aspecto final de presteza es la cultura analtica actual dentro de su com-pany.
Hacen los analistas de empresas decisiones basadas en hechos y figuras, o son sus decisiones basadas sobre la intuicin, la prueba anecdtica, y las reacciones instintivas? El businesspeople ya sumergido en nmeros probablemente ser ms receptivo para un almacn de datos. Sin embargo, usted puede tener xito con ya sea panorama con tal de que usted se prepare para la carga aumentada de desviar la disposicin mental cultural (con la ayuda del patrocinador comercial), as como tambin la necesidad para el desarrollo aplicativo analtico adicional, la educacin, y puede soportar recursos. Si su proyecto no est listo a proceder, tpicamente debido a un dficit comercial del patrocinador, sugerimos dos acercamientos para robustecer su presteza. La primera parte
Debe transmitir un anlisis de requisitos comercial de alto nivel y una priorizacin. Hablaremos ms acerca de este proceso en la siguiente seccin principal, as es que la estada afinada. La otra alternativa es crear una prueba de concepto. Las pruebas de concepto son comprobaciones rpidas y sucias de las capacidades potenciales de un almacn de datos. Son una herramienta de ventas en vez de una prueba tcnica de diseo. Los equipos usan este tech-nique porque los usuarios comerciales supuestamente no pueden describir qu quieren con fuera de ver algo reaccionar a. Mientras la prueba de concepto puede establecer una comprensin comn, no sugerimos que sea la primera herramienta arrancada de su caja de herramientas. Las pruebas de concepto a menudo requieren ms esfuerzo que rpido y sucio entrae. Tpicamente, son mantenidas unidas con cinta del ducto pero tienen inclinacin a morph en un sistema de produccin sin el requisito revise. Desafa a manejar expectativas del usuario apropiadamente. Esos que les gusta jugar con herramientas gravitan a esta tcnica, pero usted debera ser consciente de que podran haber ms mtodos efectivos y eficientes para alcanzar el mismo objetivo.
Scoping
Una vez que usted se encuentra a gusto con presteza de la organizacin, es hora de poner los linderos alrededor de un proyecto de la inicial. Scoping requiere el aporte unido de ambos la organizacin de tecnologa de la informacin y la administracin de empresas. El alcance de su proyecto de la casa de loza de datos debera ser ambos significativo en trminos de su valor para el organiza-tion y dcil. Cuando usted primero comienza, usted debera enfocar la atencin en datos de un solo proceso comercial. Salve los proyectos de proceso ms desafiantes, cruzado para una posterior fase. Algunas veces los alcances son conducidos por una fecha de terminacin del blanco, como el fin del ao fiscal. Usted puede manejar el alcance para una fecha de vencimiento eficazmente, pero hacer eso puede presentar riesgos adicionales. Aun con un determinado lmite de tiempo, usted necesita mantener su foco en scoping un proyecto que es ambos com-pelling y hacible. Algunas veces los equipos de proyecto sienten que el horario de la entrega sea lanzado en cemento armado antes de la planificacin de proyecto es incluso iniciado. El proceso de priorizacin, cul describiremos durante la definicin comercial de requisitos,
podremos estar acostumbrados a convencer ELLA y administracin de empresas que los ajustes son requeridos. Finalmente, acurdese de evitar la ley de demasiado cuando scoping demasiado firme de uno commit-ment a tambin resumir de una lnea cronolgica involucrando sistemas de la fuente de ms y demasiados usuarios en demasiadas posiciones con tambin requisitos analticos diversos.
Justificacin Un montn de tabicones de acrnimos la justificacin van en procesin, pero no les dejan intimidarle. La justificacin requiere una estimacin de los beneficios y los costos se asociaron con un almacn de datos; Si Dios quiere, las ganancias adelantadas aproximadamente pesan ms que los costos. Usualmente es responsable de derivar los gastos. Usted necesita determinar costos aproximados para el software y hardware requerido. Los almacenes de datos tienen tendencia a expandirse rpidamente, as est seguro las estimaciones le permiten una cierta cantidad
El cuarto para el crecimiento de corto plazo. A diferencia del desarrollo operacional del sistema, dnde el recurso que las estipulaciones siguen de cerca fuera de despus de la produccin, las necesidades del soporte del almacn en curso no declinarn sensiblemente con el paso del tiempo. Confiamos en el negocio para determinar que los beneficios financieros de unos datos tienen cuidado con casa. Los almacenes tpicamente son justificados basados sobre oportunidades de renta aumentada o de la ganancia en vez de meramente enfocando la atencin en reduccin de gasto. Dndole una sola versin de la verdad o flexible va de entrada a la informacin no es suficiente justificacin financiera. Usted necesita despegar los estratos para determinar el impacto cuantificable de hacer mejorado de decisiones puso posible por estos mordiscos en buen estado. Si usted lucha contra justificacin del almacn, ste es probablemente un sntoma que usted es canalizado al patrocinador comercial equivocado o problema. Dotacin de personal Los datos almacenan proyectos requieren la integracin de un equipo funcional en la cruz con recursos de ambos el negocio y eso las comunidades. Es comn que la misma persona llene ms que un papel, especialmente como el costo de entrada para el almacenar datos ha cado. La asignacin de denominados recursos para los papeles depende de la magnitud del proyecto y el alcance, as como tambin la disponibilidad del individuo, la capacidad, y la experiencia. Del lado comercial de la casa, usted necesitar que representantes colmen los papeles de fol-low: El patrocinador comercial. El patrocinador comercial es el cliente postremo del almacn, as como tambin su defensor ms fuerte. El patrocinio algunas veces se plasma en un comit planificador ejecutivo, especialmente para las iniciativas de la empresa cruzada. El conductor comercial. Si usted trabaja en una organizacin abrumadora, el patrocinador puede estar demasiado lejos removido o inaccesible para el equipo de proyecto. En este caso el patrocinador algunas veces comisiona sus responsabilidades del almacn menos estratgicas a Un administrador intermedio en la organizacin. Este conductor debera poseer las
mismas caractersticas como el patrocinador. La pista comercial. La pista comercial de proyecto es una persona muy respectada que est altamente involucrada en el proyecto, probablemente comunicndose con el envejecente de hombre de proyecto diariamente. La misma persona haciendo las funciones del conductor comercial o el experto de materia algunas veces colma este papel. Los usuarios comerciales. ptimamente, los usuarios comerciales son los aficionados entusiastas de los datos almacenan. Usted necesita involucrarlos temprano y a menudo, a partir del alcance de proyecto y los requisitos comerciales. Desde all, usted debe encontrar formas creativas para mantener su inters y su participacin a todo lo largo del lifecycle. Recuerde, la participacin del usuario es crtica para accep-tance del almacn de datos. Sin usuarios comerciales, el almacn de datos es un ejercicio tcnico
En la futilidad.
Varias otras posiciones son provistas de personal de ya sea el negocio o eso organizaciones. Estos sobrepasadores pueden ser recursos tcnicos que comprenden los recursos comerciales o comerciales que comprenden tecnologa. Los papeles del sobrepasador incluyen lo siguiente: El analista comercial del sistema. Esta persona es responsable de determinar las necesidades de busi-ness y traducirlas en datos arquitectnicos,, y los requisitos aplicativos analticos. El experto comercial de materia. Esta persona es a menudo el empuje actual para recurso para anlisis ad hoc. l o ella comprende lo que la manera de datos, cmo es usado, y donde las inconsecuencias de datos acechan. Sus entendimientos profundos analticos y de datos son sumamente tiles, especialmente durante los procesos modeladores y analticos y aplicativos. El desarrollador aplicativo analtico. Los desarrolladores aplicativos analticos son respon sible para disear y desarrollar el arrancador colocado de plantillas analticas, as como con tal que el soporte aplicativo en curso. Los datos almacenan al educador. El educador (s) debe estar seguro de sus datos, aplicaciones, y conocimiento de la herramienta de acceso porque el mundo de los negocios no diferencia entre estos productos a entregarse del almacn. Los siguientes papeles tpicamente son provistos de personal de la organizacin de tecnologa de la informacin (o una firma consultora externa). Si usted est trabajando con asesores debido a las restricciones de recurso o de experticia, usted debera retener propiedad interna del proyecto. Insista en entrenamiento y el traslado extensivo de habilidad /conocimiento a fin de que usted pueda funcionar ms independientemente sobre el siguiente proyecto. Finalmente, usted claramente debe entender si usted compra experiencia significativa en vez de proveer de personal aumento (quiz con asesores que meramente saben cmo fascinar a OLAP). Administrador de proyecto. La administradora de proyecto es una posicin crtica. l o ella debera ser muy cmodo con y respetado por ejecutivos, as como tambin analistas de tech-nical. La comunicacin del administrador de proyecto y las habilidades de manage-ment de proyecto deben ser estelares. El arquitecto tcnico. El arquitecto es responsable de la en conjunto arquitectura tcnica y prendaria. l o ella desarrolla el plan que vincula la funcionabilidad
tcnica requerida y las criadas asistentas evalan productos con base en la arquitectura global. Los especialistas tcnicos del soporte. Los especialistas tcnicos tienden a ser casi encyclo pedic acerca de un espectro relativamente estrecho de tecnologa. El modelador de datos. El modelador de datos probablemente viene de un historial transaccional de mod-eling de datos con nfasis pesado sobre la normalizacin. l o ella
Deberan aceptar conceptos dimensionales de modelado y deberan ser empathetic para lo
Los requisitos del negocio en vez de enfocado estrictamente sobre ahorrar el espacio o reduciendo la carga de trabajo de escenificacin. El administrador de la base de datos. Como el modelador de datos, el administrador de la base de datos debe estar dispuesto a dejar a un lado algn tru-isms tradicional de la gerencia de la base de datos, como tener slo un ndice en una mesa de relaciones. El coordinador Metadata. Esta persona asegura que todos los metadatos son coleccionados, manejados, y diseminados. Como un papel del perro guardin, el coordinador es responsable de recordarle a otros de sus metadatos deberes cntricos. El aeromozo de datos. El aeromozo de datos es responsable de acuerdo de la empresa en las dimensiones conformadas del almacn y los hechos. Claramente, ste es un papel desafiante politi cally. Diseador que escenifica datos. El diseador que escenifica es responsable de disear los datos que la escenificacin ETL procesa. l o ella tpicamente est involucrado en la marca versus la decisin de compra suponiendo escenificando software. Desarrollador que escenifica datos. Basado sobre la direccin del diseador que escenifica, el desarrollador que escenifica da y automatiza los procesos de escenificacin usando ya sea una herramienta de escenificacin o las rutinas manualmente programadas. Los datos almacenan soporte. Por ltimo, pero no menos, el almacn de datos requiere trastienda en curso y recursos delanteros del soporte del cuarto. Ms a menudo este papel es asignado a individuos que han estado involucrados en el proyecto en una anterior capacidad. Desarrollndose y Manteniendo el Plan de Proyecto Desarrollando los datos el plan de proyecto del almacn requiere identificacin de todas las tareas necesarias para implementar el almacn de datos. Los recursos estn disponibles en el mercado a ayudarle a compilar una lista de tarea de proyecto. Por ejemplo, el CD-ROM que viene con El Datos Warehouse Lifecycle Toolkit incluye uno casi
La tarea de 200 artculos escorando.
Cualquier buen administrador de proyecto sabe que los miembros cruciales del
equipo, como el diseador que escenifica datos, deberan desarrollar las estimaciones de esfuerzo para sus tareas. El gerente de proj-ect no puede dictar la cantidad de tiempo permitido y puede esperar conformidad. El plan de proyecto debera identificar un punto de inspeccin de aceptacin del usuario despus de cada hito principal y el producto a entregarse para asegurar que el proyecto queda en pie pista y que el negocio est todava ntimamente involucrado. Los datos almacenan proyecto comunicacin de la tipa de demandas. Durante la fase planificadora proj ect, sugerimos que el administrador de proyecto establece una matriz de communi-cation, como Mesa 16.1 ilustra, para ayudar a poner cierto que la estrategia de comunicacin es ejecutada.
Mesa 16.1 el Plan de Comunicacin del Almacn de Datos de Ejemplo EL CO N STITUF R EQ U E NLa O de la FLA K EY M ESSAG E N CY CY RUM ES Los patrocinadoresBimensualmen Frontal La decisin de asunto, comerciales te Resumiendo La gerencia de expectacin, La financiacin Negocio Mensualmente Sitio Web La participacin requerida, La comunidad La gerencia de expectacin, Las fechas crticas El equipo deSemanal Estatus El progreso, asunto proyecto Reuniones La identificacin y Decisin ESO los colegas Bimensualmen Existiendo La gerencia de te ESO expectacin, Reunin deLas necesidades del profesores recurso
Los datos que el almacn proyecta son vulnerables para el asqueroso de alcance mayormente debido a nuestro deseo ardiente para satisfacer requisitos de usuarios. Necesitamos estar ms vigilantes acerca de la acumulacin de cambios menores que tiran bolas de nieve. Mientras ninguna sola peticin es demasiado ardua, tomada en total, pueden representar un cambio significativo para el alcance del proyecto. Tenemos varias opciones cundo enfrentado con cambios. Primero, podemos aumentar el alcance sumando tiempo, recursos, o dinero para accom-modate el cambio. De otra manera, el esfuerzo total puede permanecer inalterado si los usuarios renuncian a algo que haba estado en alcance para acomodar el cambio. Finalmente, slo podemos decir que no sin realmente decir que no por manipular el cambio como una peticin de realce. La cosa ms importante a recordar acerca de
cambios de alcance es que no deberan hacerse en un vaco de tecnologa de la informacin. La respuesta correcta depende de la situacin. Ahora es la hora de apalancar a su asociacin con el negocio para lograr una respuesta con la cual todo el mundo puede vivir.
Las llaves para datos almacenan planificacin de proyecto y gerencia incluya: 1. Teniendo a un patrocinador comercial slido 2. Balanceando a gran altura valor y doability para definir el alcance 3. Trabajando con el mejor equipo posible para desarrollar un plan detallado de proyecto 4. Siendo un excelente administrador de proyecto por ah motivador, ingenindose, y comunicndose arriba, abajo, y a travs de la organizacin
La Definicin Comercial de Requisitos Abrazar a los usuarios comerciales para comprender sus requisitos y acumular su compra adentro es de primera necesidad para el almacenamiento atinado de datos. Este sec-tion se enfoca adelante de regreso para las tcnicas de fundamentos para lograr simplemente eso.
El Planeamiento Previo de Requisitos Antes de sentarse con el mundo de los negocios para recoger requisitos, sugerimos que usted se coloca para una sesin productiva por ah considerando lo siguiente:
Escoja el Foro Recogemos requisitos encontrndose con representantes comerciales del usuario mientras entretejiendo audiencias de datos con gurs del sistema de la fuente y los expertos de materia. Este acercamiento de raz cnica de un diente dual nos da entendimiento profundo en las necesidades del negocio en conjuncin con las realidades de los datos. Sin embargo, no le podemos preguntar a gerentes comerciales acerca de la granularidad o la dimensionalidad de sus datos crticos. Necesitamos hablar con ellos acerca de lo que hacen, por qu lo hacen, cmo hacen decisiones, y cmo esperan hacer decisiones en el futuro. Como la terapia de orga-nizational, estamos tratando de detectar los asuntos y las oportunidades. Hay dos tcnicas primarias para recoger requisitos las entrevistas o las sesiones facilitadas. Ambos tienen sus ventajas y sus desventajas. Las entrevistas promueven partes de participacin individual. Son tambin ms fciles de programar. Las sesiones facilitadas pueden reducir el tiempo transcurrido para recoger requisitos, aunque requieren ms compromiso de tiempo de cada participante. Basadas sobre nuestra experiencia, las encuestas no son una herramienta razonable para recoger requisitos porque son planas y de dos dimensiones. Los demandados autoseleccionados slo contestan las preguntas que hemos preguntado por adelantado. No hay opcin para indagar ms profundamente, tan cundo estamos cara a cara. Adems, no olvide ese un resultado secundario de recoger requisitos debe crear una unin entre usuarios y la iniciativa de almacenamiento. Esto no es justo no yendo para ocurrir con encuestas. Generalmente usamos un acercamiento hbrido con entrevistas para recoger los detalles ensangrentados y en ese entonces la facilitacin para traer el grupo a consenso. Mientras describiremos este acercamiento hbrido en ms detalle, mucho del debate se aplica a facili-tation puro tambin. La eleccin del foro depende de las
habilidades del equipo, la cultura del organiza-tion, y qu usted ya tiene, subordin sus usuarios para. ste es un caso en cul el tamao definitivamente no equipa todo.
Identifique y Prepare El Equipo de Requisitos Sin tener en cuenta el acercamiento, usted necesita identificar y preparar los miembros del equipo de proyecto que estn involucrados. Si usted est haciendo entrevistas, usted necesita identificar un entrevistador de pista cuya responsabilidad primaria es preguntar las grandes preguntas indefinidas. Entretanto, el escribiente de entrevista toma notas copiosas. Mientras una cinta
La grabadora puede proveer cobertura ms completa de cada entrevista, no utilizamos uno porque cambia la dinmica de la reunin. Nuestra preferencia es tener una persona de sec-ond en el cuarto con otro cerebro y otros sets de ojos y las orejas en vez de confiar en una mquina vertiginosa. A menudo invitamos uno o dos miembros adicionales (a merced del nmero de entrevistados) de proj-ect como observadores a fin de que puedan or el aporte de los usuarios directamente. Antes de que usted se sienta con usuarios, usted necesita asegurarse de que usted est cercano a las sesiones con la disposicin mental correcta. Usted no debera suponer que usted ya sepa todo. Si hecho correctamente, usted definitivamente aprender durante estas entrevistas de require-ments. Por otra parte, usted debera hacer alguna tarea investigando fuentes disponibles, como el informe anual, el sitio Web, y el organigrama interno. Desde la llave para tener las respuestas correctas es preguntar las preguntas correctas, nosotros reC-ommend que los cuestionarios sean formulados antes de reuniones del usuario. El ques-tionnaire no debera ser mirado como un escrito. Es una herramienta para organizar sus pensamientos y servir de un dispositivo de retirada en caso que su mente se quede en blanco durante la sesin de entrevista.
Seleccione, Horario, y Negocio Prepare Representantes Si sta es su primera correra en el almacenamiento de datos (o su primer intento para rescatar toberas de datos), usted debera hablar para businesspeople que representa la anchura horizontal a travs de la organizacin. Esta cobertura es crtica para formular el calco heliogrfico de la matriz del autobs del almacn de datos. Usted necesita tener uno understand-ing tempranero de los datos comunes y el vocabulario a travs del negocio de fondo funciona para construir un ambiente extensible. Dentro de la comunidad del usuario del blanco, usted debera cubrir el verti-cally de organizacin. Los datos que el proyecto del almacn mancomuna naturalmente gravitan hacia los analistas de superpoderes en el negocio. Mientras su entendimiento profundo es de valor, usted no puede ignorar a los ejecutivos con
antigedad y la direccin de nivel medio. De otra manera, usted es vulner-able para estar excesivamente enfocado a lo tctico aqu y ora pero pierde vista de la direccin estratgica futura de la organizacin. Programar a las diligenciadoras puede ser la tarea de requisitos ms onerosa. Sea especialmente amable con su administrador (o el administrador de su jefe es usted trata de programar sesiones con cuerpo directivo). Preferimos encontrarnos con ejecutivos en el de ellos, mientras que podemos encontrar un homogneo conjunto de dos para tres personas pues esos decrecen en el organigrama. Tenemos previstas 1 hora a reuniones individuales y horas 11D2 para los grupitos. El planificador necesita tener previstas la hora del 1D2 entre reuniones interrogatorio y otras necesidades. Entrevistar es sumamente oneroso porque usted debe ser completamente
Enfocado para la duracin de la sesin. Consecuentemente, slo programamos tres para cuatro sesiones en un da porque nuestra materia gris se vuelve pastosa despus de eso. En lo que se refiere a preparar a los entrevistados, el acercamiento ptimo es aprender de memoria ducto una lancha de proyecto encontrndose con los usuarios. El patrocinador comercial juega un papel crtico, enfatizando su compromiso y la importancia de la participacin de todo el mundo. La lancha encontrndose disemina un mensaje coherente acerca del proyecto. Tambin genera un sentido de la propiedad del negocio del proyecto. Si la lancha encontrndose es una pesadilla logstica, la patrocinadora debera distribuir un memorndum de la lancha cubriendo los mismos temas. Asimismo, el equipo de entrevista debe preparar a los entrevistados resaltando los temas para ser cubierto de la sesin prxima a llegar. No incluimos una copia del cuestionario, lo cual no est dirigido a la diseminacin pblica. Nosotros les pedimos a los entrevistados que traigan copias de sus informes cruciales y analizamos.
Coleccionando los Requisitos Comerciales Es hora de sentarse abajo cara a cara para coleccionar los requisitos comerciales. El proceso usualmente proviene de una introduccin a travs del interrogatorio estructurado para un final resumen de noticias, como intercambiaremos opiniones.
Lance La responsabilidad para introducir la entrevista debera ser establecida antes de reunirse en una sala de juntas. La persona de inicio designada debera escribir un guin para los puntos primarios para ser transportada en los primeros minutos de la pareja de casados cuando usted establece el tono de la entrevista intersectndose. Usted debera enfocar la atencin en el proyecto y entreviste objetivos pero no vague en alrededor el hardware, el software, y otro lenguaje tcnico. La introduccin debera transportar un mensaje crujiente, cntrico en negocio.
El Flujo de Entrevista De el objetivo de una entrevista es obligar a los usuarios comerciales a hablar lo que hacen y por qu lo hacen. Un lugar simple, poco amenazador a comenzar debe indagar acerca de sus responsabilidades de trabajo y su ataque organizativo. sta es una pelota de lanzamiento elevado de la pelota a la que intervie-wees puede reaccionar fcilmente. Desde all, tpicamente indagamos acerca de su mtrica crucial de per-formance. Determinando cmo rastrean progreso y que xito traduce directamente al modelo dimensional. Nos cuentan a nosotros sobre sus procesos cruciales de busi-ness y sus hechos sin nosotros preguntando esas preguntas directamente. Si nos encontramos con una persona que tiene ms experiencia de datos de participacin activa, indirectamente exploramos mejor comprender la dimensionalidad del negocio, junto con el jerrquico movimiento hacia arriba. Otra vez, vamos su mundo en vez de ask-ing a ellos al concurso en nuestra tierra enzacatada. Tales preguntas tan Cmo usted hace la distincin
Entre productos (o los agentes, los proveedores, o las facilidades)? O Cmo usted naturalmente clasifica en categoras productos? La ayuda identifican atributos cruciales de dimensin y jerarquas. Si el entrevistado es ms analtico, indagamos acerca de los tipos de analiza que l o ella actualmente acta. Comprender la naturaleza de estos analiza y ya sea son ad hoc o estndar provee introduce en la computadora en los requisitos de la herramienta de acceso de datos, as como tambin el proceso aplicativo del diseo de la plantilla. Que se espera completamente, el entrevistado ha trado a lo largo de copias de sus informes y hojas contables cruciales. En vez de esconderlos en reserva en una carpeta, es de ayuda comprender cmo el entrevistado destina el anlisis hoy, as como las oportunidades para la mejora. En contra del consejo de algunos expertos de la industria, usted no puede disear un ambiente analtico extensible meramente obligando a los usuarios a estar de acuerdo en la parte superior cinco informes o averiguaciones. Las preguntas de los usuarios deben cambiar. Consecuentemente, debemos resistir la tentacin a estrechar nuestro foco del diseo para una supuesta parte superior cinco. Si nos encontramos con ejecutivos, usualmente no ahondamos en los detalles descritos anteriormente. En lugar de eso, les preguntamos acerca de su vista para mejor informacin que envejece palanca en la organizacin. Quiz el equipo de proyecto visualiza un ambiente completamente ad hoc, mientras que la administracin de empresas sea ms interesada en la entrega de anlisis estndar. Necesitamos hacer seguro a los encuentros del producto a entregarse del almacn de datos el negocio exigir mucho y expectativas. Le preguntamos a cada entrevistado acerca del impacto de acceso mejorado a la informacin. Probablemente ya hemos recibido preliminar financiador para el proyecto, pero nunca duele para captar ms beneficios potenciales, cuantificables.
Las reglas bsicas para efectivo entrevistar incluyen: recuerde su papel de entrevista; Escuche y absorba como una esponja. luche por un flujo conversacional; No bucee demasiado rpidamente (o el tirn
fuera de una copia de elementos de datos de poten-tial). verifique terminologa de comunicacin y de captura precisamente porque la mayora de terminologa de uso de organiza-tions poco consistentemente. establezca una base de mirada fija con el entrevistado; Use su vocabulario.
El Resumen De Noticias Como la entrevista es llegar a una conclusin, le preguntamos a cada entrevistado acerca de sus criterios de xito para el proyecto. Por supuesto, cada criterio debera ser mea-surable. Fcil para acostumbrar y ayunar trmino medio algo diferente para todo el mundo, as usted debera obligar a los entrevistados a articular cosas especficas, como sus expectativas referente a la cantidad de entrenamiento requerido para correr un informe predeterminado.
En este punto en la entrevista hacemos un ancho descargo de responsabilidad. Los entrevistados deben tener por entendido que solamente porque discutimos una capacidad en la reunin no garantiza que ser incluida en la primera fase del proyecto. Le damos a entrevistados las gracias por sus entendimientos profundos brillantes y les dejamos saber qu es hap-pening despus y lo que su participacin ser. Tambin nos aprovechamos de esta oportunidad para manejar expectativas.
Transmitiendo Entrevistas Cntricas En Datos Mientras somos en los que se enfoc la atencin comprender los requisitos del negocio, es de ayuda intercalar sesiones con los gurs de datos del sistema de la fuente o los expertos de materia para evaluar la viabilidad de soportar las necesidades comerciales. Estas entrevistas enfocadas en datos son realmente diferentes a los que descritas anteriormente. La meta es evaluar que los datos de fondo necesarios existen delante de constituciones de momento en pos de los requisitos. Una auditora de datos ms completa ocurrir durante el proceso dimensional de modelado. Estamos tratando de aprender bastante en este punto a manejar las expectativas de la organizacin apropiadamente.
Postcollection Documentation y Seguimiento Inmediatamente despus de la entrevista, el equipo de entrevista debera interrogar. Usted quiere asegurar que usted est en la misma pgina acerca de cul es aprendido, as como tambin preparndose para cualquier sorpresas o cualesquiera inconsecuencias. Es tambin de ayuda revisar sus notas rpidamente para rellenar cualquier boquetes mientras la entrevista es todava fresca en su memoria. Asimismo, usted debera examinar los informes recogidos para ganar fur-ther fuera de la Internet entendimiento profundo en la dimensionalidad que se mantuvo en el almacn de datos. En este punto es hora de documentar lo que usted oy. Mientras la documentacin es todo el mundo la actividad menos favorita, es crtico para la validacin del usuario y los materiales de referencia del equipo de proyecto. Hay dos niveles de documentacin que tpicamente resultan del proceso de requisitos. La primera parte
debe redactar cada entrevista individual. Esta actividad puede ser muy que consume mucho tiempo porque la crtica no debera ser meramente una sarta de copia de conciencia sino debera hacer sentido para alguien que no estaba en la entrevista. El segundo nivel de documenta-tion es un documento consolidado de conclusiones. Organizamos el documento por primero identificando los procesos comerciales cruciales. Como mencionamos ms temprano, abordamos las fases iniciales de un almacn de datos sobre un proceso por la base de proceso. Consecuentemente, es lgico organizar los requisitos del negocio en los mismos cubos que legan, a su vez, lo harn esfuerzos de implementacin. Nota de que todas las entrevistas son revisadas para captar las conclusiones asociados con cada uno de los procesos comerciales de fondo.
Al redactar el documento de conclusiones, tpicamente comenzamos con un resumen ejecutivo, seguido por una visin general de proyecto eso discute el proceso usado y los participantes involucrados. La masa del informe gira alrededor de nuestro find-ings de requisitos. Para cada principal proceso comercial discutido, describimos por qu quieren los usuarios comerciales analizar el proceso resulta, qu capacidades que desean, sus limitaciones actuales, y el potencial se beneficia o impacto. Incluimos una lista de preguntas de sam-ple que podran ser contestadas una vez la mtrica de proceso est disponible en el almacn de datos. El comentario acerca de la viabilidad de abordar los datos generados por cada proceso est tambin documentado. Algunas veces juntamos los procesos en una matriz para transportar el oppor-tunities a travs de la organizacin. En este caso no nos referimos a una matriz del autobs de la casa de loza de datos. Las filas de la matriz de oportunidad todava identifican los procesos comerciales. Sin embargo, en la matriz de oportunidad, en vez de identify-ing dimensiones comunes como las columnas, en lugar de eso identificamos los grupos de organiza-tional o funciones. Sorprendentemente, la matriz ser muy densa porque muchos grupos necesitan acceso para la misma mtrica comercial de perfor-mance de proceso de fondo.
La Priorizacin y el Consenso El documento de conclusiones de requisitos sirve de la base para presentaciones de regreso a representantes mayores de la gerencia, como para otros que participaron. Inevitablemente nos hemos descobijado ms de lo que podemos ser abordados en una sola iteracin, as es que necesitamos darle prioridad a nuestros esfuerzos. Como intercambiamos opiniones con alcance de proyecto, usted no debera hacer esta decisin en un vaco. Usted necesita apalancar a (o cra) su asociacin con el mundo de los negocios para lograr prioridades con las cuales todo el mundo puede vivir. La presentacin de resumen de noticias de requisitos es situada como una revisin de conclusiones y una priorizacin intersectndose. Los participantes incluyen
rep-resentatives relativamente comercial de alto nivel, as como tambin el gerente del almacn de datos y otra gerencia involucrada de tecnologa de la informacin. La sesin comienza con una visin general de cada proceso comercial identificado. Usted quiere que todo el mundo en el cuarto tenga una comprensin comn del alcance de oportunidades, as como tambin cul es a la que se quiso decir cuando decimos anlisis de book-ings de ventas, por ejemplo. Una vez que las conclusiones han sido revisadas, es hora de establecer prioridades. La tcnica de discurso rimbombante de cuadrngulo de cuatro celdas, ilustrada en Figura 16.2, es una herramienta efectiva para alcanzar consen-sus sobre un plan de desarrollo del almacn de datos que enfoca la atencin en las oportunidades directamente iniciales. El eje vertical del cuadrante se refiere al valor o impacto potencial para el negocio. El eje de las abscisas transporta viabilidad. Cada uno del descubrimiento
A Comercial Proceso B Comercial Proceso de
de
Carbono Comercial de Proceso D Comercial Proceso A gran altura de
Negocio Impacte
Bajo
Viabilidad
Bajo Figura 16.2 el anlisis del cuadrante de Priorizacin. A gran altura
Las composiciones comerciales de proceso estn colocados en un cuadrante basado en el acuerdo complejo de los representantes sobre el impacto y la viabilidad. Los proyectos que garantizan atencin inmediata estn ubicados en la esquina superior derecha porque son proyectos de alto impacto, as como tambin altamente factible. Los proyectos en la ms abajo celda izquierda deberan ser evitados como la plaga son misiones imposibles eso haga poco para el negocio. Asimismo, los proyectos en la ms abajo celda correcta no justifican atencin de corto plazo, aunque los equipos de proyecto algunas veces gravitan aqu porque estos jects no son hacibles pero no muy crucial. En otras palabras, nadie se fijar si el proyecto no va bien. Finalmente, los proyectos en la celda izquierda superior representan oportunidades de mean-ingful. Estos proyectos tienen abrumadora potencial comercial devolucin de lo adeudado pero son actualmente infeasible. Mientras los datos almacenan el proyecto al que el equipo est enfocado se proyecta adentro la celda correcta superior sombreada, otros equipos de tecnologa de la informacin deberan ocuparse de las limitaciones rasgadas por perro sin raza de viabilidad de esos en la celda izquierda superior.
La Pista de Tecnologa del Lifecycle La definicin comercial de requisitos es seguidos inmediatamente por tres huellas actuales en la contra enfocado sobre la tecnologa, datos, y aplicaciones analticas, respec-tively. En las siguiente varias secciones que pondremos en la mira en la pista de tecnologa, que incluya disea de la seleccin y arquitectura tcnica de productos que traen la arquitectura para la realidad.
El Diseo Tcnico de Arquitectura Mucho como un calco heliogrfico para una casa nueva, la arquitectura tcnica es la copia heliogrfica para los servicios tcnicos del almacn y los elementos. El plan de arquitectura sirve de un armazn de organizacin para soportar la integracin de tech-nologies. Como la vivienda disea, la arquitectura tcnica consiste en una serie de modelos que ahondan en mayor detalle estimando cada uno del compo-nents principal. En ambas situaciones, la arquitectura nos deja percibir problemas en escrito (como tener el lavaplatos demasiado lejos del fregadero) y minimizar sorpresas de midpro-ject. Soporta la coordinacin de esfuerzos paralelos al acelerar desarrollo a travs del aprovechamiento de componentes modulares. La arquitectura identifica los componentes inmediatamente requeridos versus esos que sern incorporados ms tarde (como la cubierta y el porche ocultado). Ms importante, los saques de arquitectura como una herramienta de comunicacin. Los calcos heliogrficos anfitriones de construc-tion le permiten al arquitecto, el contratista general, los subcontratistas, y el propietario de casa comunicar de un documento comn. El fontanero sabe que el electricista tiene poder en el lugar para el vertedero de basuras. Asimismo, los datos almacenan comunicacin tcnica de soportes de arquitectura estimando un set consistente de requisitos tcnicos dentro del equipo, hacia arriba para manage-ment, y hacia afuera para los vendedores. En Captulo 1 discutimos varios componentes principales del architec-ture tcnico, los servicios inclusivos de escenificacin de datos, los datos acceden a los servicios, y los metadatos. En la siguiente seccin fijamos nuestra atencin en el proceso de crear el diseo tcnico de arquitectura.
El Proceso de Ocho Pasos para Crear la Arquitectura Tcnica Los datos almacenan va de entrada de equipos el proceso tcnico del diseo de arquitectura de fines opuestos del espectro. Algunos equipos simplemente no comprenden los beneficios de una arquitectura y consideran que el tema y las tareas estn demasiado nebulosos. Son tan enfocados en datos almacena entrega que a las percepciones de arquitecturas les gustan que una distraccin y un impedimento progresen, as es que optan para bordear diseo de arquitectura. En lugar de eso, ensamblan los componentes tcnicos requeridos para la primera iteracin con guita
de achicamiento y goma de mascar, pero la integracin e interfaces quedan gravadas como agreguemos ms datos, ms usuarios, o ms funcionabilidad. Eventualmente, estos equipos a menudo terminan reconstruir porque la estructura del nonarchitectured no podra resistir los estreses. En el otro extremo, algunos equipos quieren invertir diseo de dos aos la arquitectura al olvidarse de que el propsito primario de un almacn de datos es solucionar problemas comerciales, no dirigirle la palabra cualquier reto tcnico plausible (y no tan plausible).
Ningn fin del espectro de arquitectura es saludable; La respuesta ms apropiada miente en alguna parte de la mitad. Hemos identificado un proceso de ocho pasos para ayudarle a navegar estas aguas arquitectnicas del diseo. Recuerde, cada almacn de datos tiene una arquitectura tcnica. La pregunta est si la tuya es planificada y explcita o meramente implcita.
Establezca Una Fuerza de Trabajo de Arquitectura Basado sobre nuestra experiencia, es ms til tener a una pequea fuerza de trabajo del dos al tres que las personas canalizan al diseo de arquitectura. Tpicamente, es el arquitecto tcnico, trabajando en conjuncin con el diseador que escenifica datos y el desarrollador analtico de applica-tion, para asegurar la trastienda y representacin delantera del cuarto en la fuerza de trabajo. Este grupo necesita establecer su carta constitucional y lnea cronolgica de productos a entregarse. Tambin necesita educar al resto de equipo (y quiz los otros en el orga-nization de tecnologa de la informacin) acerca de la importancia de una arquitectura.
Coleccione Requisitos Relatados En Arquitectura Como usted recuerda de Figura 16.1, definir la arquitectura tcnica no es la primera caja en el diagrama del lifecycle. La arquitectura se le crea soportar necesidades de negocio de valor alto; No est supuesta a ser una excusa para comprar lo ltimo, mximos productos. Consecuentemente, el aporte crucial en el proceso del diseo debera provenir de las conclusiones comerciales de definicin de requisitos. Sin embargo, escuchamos los requisitos del negocio con un filtro ligeramente diferente para conducir el diseo de archi-I-tecture. Nuestro foco primario debe revelar las implicaciones arquitectnicas asociadas con las necesidades crticas del negocio. Tambin escuchamos de cerca cualquier tim-ing, disponibilidad, y cualesquiera necesidades de funcin. Adems de apalancar el proceso comercial de definicin de requisitos, tambin transmitimos entrevistas adicionales dentro de la organizacin de tecnologa de la informacin. stas son sesiones puramente enfocadas en tecnologa para comprender estndares actuales, planificaron direcciones tcnicas, y linderos no
negociables. Adems, podemos revelar lecciones aprendidas de anteriores proyectos de la entrega de informacin, as como tambin la voluntad de la organizacin a acomodar cambio operacional en nombre del almacn, como identificar transacciones actualizadas en el sistema de la fuente.
Los Requisitos de Arquitectura del Documento Una vez que apalancamos la definicin comercial de requisitos proceso y con-ducted que la suplementaria tecnologa de la informacin entrevista, necesitamos documentar nuestras conclusiones. En este punto optamos por usar un formato tabular simplista. Simplemente listamos cada requisito comercial que tiene un impacto sobre la arquitectura, junto con una lista del lavandero de
Las implicaciones arquitectnicas. Por ejemplo, si hay una necesidad para entregar informacin global de funcin de ventas sobre una base nocturna siguiendo la adquisicin reciente de varias compaas, las implicaciones tcnicas podran incluir 24/7 en todo el mundo habilidad de ganancia, datos reflejando para cargas, metadatos robustos para soportar acceso global, ancho de banda de la red de ade-quate, y suficiente caballo de fuerza de escenificacin para manejar la integracin complicada de datos operacionales.
Desarrolle Un Modelo Arquitectnico de Alto Nivel Despus de que los requisitos de arquitectura hayan sido documentados, empezamos modelos de formu-lating a soportar las necesidades identificadas. En este punto la fuerza de trabajo de arquitectura a menudo se apropia a la fuerza de s mismo en una sala de juntas por varios das de persona de mucha importancia pensando. El equipo agrupa los requisitos de arquitectura en compo-nents principal, como datos escenificando, el acceso de datos, los metadatos, y la infraestructura. Desde all el equipo redacta y acendra el modelo arquitectnico de alto nivel. Este dibujo es similar a la pgina delantera de elevacin en calcos heliogrficos de la vivienda. Eso illus-trates lo que la arquitectura del almacn mirar de la calle, pero es peligrosamente simplista porque los detalles significativos estn incrustados en las pginas que entienden.
El Diseo y Specify los Subsistemas Ahora que comprendemos cmo coexistirn las pedazos principales, es hora de hacer un diseo detallado de los subsistemas. Para cada componente, como los servicios de escenificacin de datos, la fuerza de trabajo documentarn una lista del lavandero de capacidades requeridas. Lo ms especfico, lo mejora, porque lo que es importante para sus datos tiene cuidado con la casa no es necesariamente crtica para extraer de la cantera. Este esfuerzo a menudo requiere que investigacin preliminar mejor comprenda el mercado. Afortunadamente, no hay escasez de informacin y recursos disponibles en la Internet, as como tambin de network-ing con miradas fijas. La especificacin de subsistema da como resultado modelos grficos detallados adicionales.
Adems de documentar las capacidades de los subsistemas primarios, tambin debemos considerar nuestros requisitos prendarios, as como tambin las necesidades de infraestructura fsica y de configuracin. A menudo, podemos apalancar recursos nivelados en la empresa para ayudar con la estrategia prendaria. En algunos casos las elecciones de infraestructura, como el hardware del servidor y software de la base de datos, es predisuade extrado de la cantera. Sin embargo, si usted construye un almacn grande de datos, sobre 1 tuberculosis en el tamao, usted debera volver a visitar estas decisiones de la plataforma de infraestructura para asegurar que pueden descamarse segn se requiera. Tamao, dimensionalidad, funcin, y flexibilidad son tambin factores cruciales para considerar cundo determinando el papel de OLAP eleva al cubo en su en conjunto arquitectura tcnica.
Determine Arquitectura Las Fases de Implementacin Como la casa de sueo del propietario de casa, usted probablemente no puede implementar todos los aspectos de la arquitectura tcnica de inmediato. Algunos son capabil-ities no negociable del mandatario, mientras que los otros son agradables tiene eso puede ser diferido hasta uno ms tarde fecha. Otra vez, referimos de regreso a los requisitos comerciales a establecer pri-orities de arquitectura. Debemos proveer suficientes elementos de la arquitectura para soportar los requisitos unidos por los extremos de la iteracin inicial de proyecto. Sera ineficaz enfocar solamente la atencin en datos escenificando servicios mientras ignorando las capacidades requeridas para metadatos y los servicios de acceso.
Documente la Arquitectura Tcnica Necesitamos documentar la arquitectura tcnica, incluyendo las fases planificadas de imple-mentation, pues esos que se apropi a la fuerza de en la sala de juntas. La arquitectura tcnica documento de plan debera incluir detalle adecuado a fin de que los profesionales expertos pueden seguir con construccin del armazn, mucho carpinteros anlogos le dan marco a una casa basada en el calco heliogrfico.
Repase y Finalize Lo La Arquitectura Tcnica Eventualmente acabamos en el punto de partida con el proceso del diseo de arquitectura. Con un plan en borrador en mano, la fuerza de trabajo de arquitectura est de regreso para educar el organi-zation y manejar expectativas. El plan de arquitectura debera ser communi-cated, en variar niveles de detalle, para el equipo de proyecto, L los colegas, los patrocinadores comerciales, y el negocio lleva la delantera. Despus de la revisin, la documentacin debera estar actualizada y debera verse obligado a acostumbrar inmediatamente en el proceso de seleccin del producto.
La Seleccin del Producto y la Instalacin De muchas formas el plan de arquitectura es similar a una lista de compras. Entonces seleccionamos productos que caben dentro del armazn del plan para entregar el functional-ity necesario. Describiremos las tareas asociadas con seleccin del producto en un paso ms bien rpido porque muchos de estos conceptos de evaluacin son aplicables para cualquier seleccin de technol-ogy. Las tareas incluyen: Comprenda el proceso corporativo de compra. El primer paso antes de seleccionar productos nuevos es entender que el hardware interno y software compran apfisis de aprobacin, ya sea nos gusta ellas o no. Quiz la necesidad de gastos
Para ser aprobado por el comit mayscula (que acaba de responsabilizarse por la semana pasada y no reanudar la sesin pues 2 meses) de apropiaciones. Desarrolle una matriz de evaluacin del producto. Usando el plan de arquitectura como un punto de start-ing, desarrollamos una matriz basada en hojas contables de evaluacin que identi-fies los criterios de evaluacin, junto con oprimir factores para indicar importancia. Lo ms especfico los criterios, lo mejor. Si los criterios son demasiado ambiguos o genricos, cada vendedor dir que puede satisfacer nuestras necesidades. Los criterios comunes podran incluir funcionabilidad, arquitectura tcnica, caractersticas del diseo del software, impacto de infraestructura, y viabilidad del vendedor. El estudio de mercado de conducta. A nosotros nos deben ser informdosle compradores al seleccionar prod-ucts, lo cual significa que ms extensivo estudio de mercado mejor entienda Los jugadores y sus ofertas. Las fuentes de investigacin potenciales incluyen la Internet, publicaciones de la industria, colegas, convenciones, vendedores, y los analistas (aunque sea consciente de que las opiniones del analista no pueden ser tan objetivas como somos pista para creer). Una peticin para informacin o la solicitud de propuesta (RFP) es Una herramienta clsica de evaluacin de producto. Mientras algunos organismos no tienen alternativa acerca de su uso, evitamos esta tcnica, si es posible. Construir el instrumento y evaluar respuestas son tremendamente consumidoras de tiempo Para el equipo. Asimismo, originarse de la peticin es muy que consume mucho tiempo para el vendedor. Adems, los vendedores estn motivados para originarse de las preguntas en la luz ms positiva, as es que la evaluacin de respuesta es a menudo ms de un concurso de belleza. Al fin, el valor del gasto no puede garantizar el esfuerzo. Estreche opciones para un listn y realice evaluaciones detalladas. Despecho
La pltora de productos disponible en el mercado, usualmente slo un num pequeo Ber de vendedores puede responsabilizarse por ambos nuestra funcionabilidad y nuestros requisitos tcnicos. Por el preliminar de comparacin anota de la matriz de evaluacin, lo deberamos hacer Enfoque la atencin en una lista estrecha de vendedores acerca de quienes somos serios y disqual El ify el descanso. Una vez que nos ocupamos de un nmero limitado de vendedores, lo podemos hacer Empiece las evaluaciones detalladas. Los diligenciadores deberan ser Involucrado en este proceso si evaluamos datos accede a las herramientas. Como evalua Peascos, deberamos conducir el proceso en vez de dejar a los vendedores hacer lo La conduccin (que inevitablemente incluir un paseo en coche por cuadro de su headquar
Los ters construyendo). Compartimos informacin pertinente del plan de arquitectura as Que las sesiones enfocan la atencin en nuestras necesidades en vez de en producto brama y whis Tles. Vaya de seguro a hablar con referencias del vendedor, ambos esos previsto formalmente Y esos produjeron como respuesta de su red informal. Si es posible, las referencias Deberan representar de modo semejante clasific segn el tamao instalaciones.
El prototipo de conducta, si es necesario. Despus de realizar las evaluaciones detalladas, algunas veces un ganador libre de compromisos burbujea para la parte superior, a menudo basado en la anterior experiencia del equipo o las relaciones. En otros casos, el lder descuella debido a compromisos corporativos existentes. En uno u otro caso, cuando un candidato exclusivo
Toma forma del ganador, podemos pasar por encima del paso del prototipo (y la inversin de associ-ated en ambos tiempo y el dinero). Si ningn vendedor es el ganador ostensible, transmitimos un prototipo sin ms que dos productos. Otra vez, hgase cargo del proceso desarrollando un limitado pero realista y comercial estudio de casos. Pdales a los vendedores que demuestren su solucin usando un set de muestra pequeo de datos provistas por un formato plano del archivo. Vele por su shoul-DeR como construyen la solucin a fin de que usted comprenda lo que se requiere. Como aconsejamos ms temprano con prueba de conceptos, vaya de seguro a manejar expectativas de organiza-tional apropiadamente. Seleccione producto, instale a ttulo de prueba, y haga negociaciones. Es hora de seleccionar un producto.
En vez de inmediatamente formalizar el acuerdo, conserve su negoti El poder del ating haciendo un pblico exclusivo, no, compromiso para un solo ven Dor. En otras palabras, haga su escogencia pero no deje al vendedor saber eso Usted est completamente vendido. En lugar de eso, embrquese en un perodo de prueba donde usted tiene La oportunidad para ponerle el producto al uso autntico en su ambiente. Requiere La energa significativa para instalar un producto, quedarse se entren, y comienza a usarlo, entonces Usted debera ir andando por este camino slo con el vendedor de quien usted Completamente tenga la intencin de comprar; Una prueba no debera ser perseguida como otra llanta pateando Ejercicio. Como los empates de prueba para un final, usted tiene la oportunidad para negoti
Comi una compra que es beneficiosa para todas las fiestas implicaron.
La Pista de Datos del Lifecycle En el lifecycle el diagrama encontr en Figura 16.1, la pista intermedia siguiendo la definicin comercial de requisitos enfoca la atencin en datos. Revolvemos nuestra atencin en esa direccin a todo lo largo de las siguiente varias secciones.
El Modelado Dimensional Dado el foco de los primeros 15 captulos de este libro, no gastaremos mucho tiempo discutiendo tcnicas dimensionales de modelado aqu. sta es meramente una partida provisoria que con todo hemos discutido ms temprano. Nosotros, sin
embargo, tardaremos un momento en revisar el en conjunto proceso dimensional de modelado. Enfatizamos el proceso de cuatro pasos previamente, pero aqu discutiremos esos pasos dentro de un mayor contexto de proyecto. Inmediatamente despus de la definicin comercial de requisitos, deberamos redactar (o vuelve a visitar) la matriz del autobs del almacn de datos, tan introducidas en Captulo 3. Ya redactamos las filas matriciales al documentar y presentar los requisitos del usuario en el contexto de procesos comerciales. Escudriando las fuentes de datos de fondo por ah hablante con ESO los veteranos pueden fomentar carne fuera de las filas. Asimismo,
Generamos una lista impresionante de dimensiones potenciales y entonces marcamos las intersecciones. El paso final de priorizacin de las actividades comerciales de requisitos identific el proceso comercial especfico que ser abordado primero. As de, por supuesto, corre-sponds para una fila de la matriz. Tambin se ocupa de la primera pregunta de nuestro acercamiento dimensional de modelado de cuatro pasos: Identifique el proceso comercial. En este punto es hora de hacer un anlisis ms cabal de los datos generados por este proceso. Mientras transmitimos una auditora de alto nivel durante la definicin comercial de requisitos, necesitamos cavar en el nitty-gritty evaluar consistencia de granu-larity, histrica, valores vlidos, y disponibilidad de atributo. A menudo los expertos de materia busi ness o los analistas de poder del mundo de los negocios pueden derramar luz rpidamente sobre las inconsecuencias de datos o las idiosincrasias basadas en los retos que tienen, encontr mientras tratando de analizar los datos. Una vez que nuestra tarea de anlisis de datos es completa, transmitimos talleres del diseo para crear el dibujo tcnico dimensional. En nuestra experiencia, es ms efectivo y eficiente tener un trabajo del equipo de la parte pequea (consistiendo en grado mnimo en el analista comercial del sistema, el experto comercial de materia, el analista comercial de poder, y mod-eler de datos) a travs del diseo en vez de confiar en un modelador de solo figurando su torre de marfil para disear independientemente. El acercamiento facilitado de la tienda de trabajo del grupo parece arribar al diseo correcto ms rpidamente. Durante los anteriores estudios de casos, los pasos 2 a travs de 4 (es decir, el grano, las dimensiones, y los hechos) fueron abordados en una secuencia ordenada. En la vida autntica, no est sorprendido si el equipo del diseo vuelve a visitar la declaracin de granularidad una vez que est sumergida en dimen-sions o hechos. Mientras el progreso se hace en cada taller, los asuntos tambin son iden-tified inevitablemente. La responsabilidad para resolver el diseo publica necesidades para ser asignada. Alguien tambin debe ser responsable de poner en bitcora y documentando la coleccin completa de asuntos y sus decisiones. Obviamente, el equipo debera palanquear que la edad las conclusiones comerciales de requisitos para asegurar que el modelo puede soportar la llave necesita y duda.
Una vez que el equipo modelador es razonablemente confiado acerca de su producto de trabajo, nos comunicamos y validamos el diseo con una audiencia ms ancha, primero dentro de la tecnologa de la informacin y el equipo del almacn de datos y entonces con otros en el mundo de los negocios. Para empezar, la matriz es una herramienta de comunicacin de primera con ambas audiencias a fin de que todo el mundo gane un aprecio de la vista mayor, integrada y el plan. Desde all, enfocamos la atencin en el dibujo tcnico especfico. Podemos esperar a las reuniones cntricas en la tecnologa de la informacin potencialmente identifica sino que tambin esperanzadamente resolver asuntos de datos. Las sesiones del usuario comercial inicialmente involucrarn a un grupito de usuarios identificados a validar el diseo. Este grupo debera enfocar adelante
Los tipos de analizan y dudan que espera preguntar de los datos. Cuando estamos listos a presentarle el diseo dimensional a un mayor grupo de usuarios comerciales, es a menudo de ayuda simplificar el dibujo tcnico para esconder las llaves de la juntura y muchos para una patas de gallo que han sido conocidas para abrumar a los usuarios. Las ilustraciones simplificadas ayudan a alimentar con cuchara el diseo para poblar cul no es ya muy cmodo con salida de una herramienta modeladora. La documentacin sobre el modelo validado debera identificar la mesa y nombres de la columna, las definiciones, y ya sea las reglas de clculo para los hechos o lentamente cambiando reglas de dimensin por dimensionan atributos. Tpicamente capturada en una herramienta modeladora, esta informacin es una parte del primer aporte (o el enlace) para un catlogo de metadatos. Como las herramientas y las asociaciones maduran, la informacin fluir ms fcilmente entre el modelado, escenificacin, acceden, y las herramientas de metadatos. La documentacin del dibujo tcnico es ms all suplementada sumando el sistema especfico de la fuente, fildea, y reglas de transformacin para derivar la fuente para apuntarle a hacer mapas en conjuncin con el equipo que escenifica. Es de ayuda adoptar convenciones estndar que nombra para los elementos de datos a primera hora del proceso.
El Diseo Fsico Los modelos dimensionales desarrollados en la seccin precedente necesitan ser lated en un diseo fsico. En el modelado dimensional, los diseos lgicos y fsicos soportan un parecido muy juntos. Ciertamente no queremos que el administrador de la base de datos convierta nuestro dibujo tcnico dimensional precioso en una estructura normalizada durante el diseo fsico. El modelo fsico diferir del modelo lgico en trminos de los detalles especificados para la base de datos fsica, columna fsica inclusiva nombra (no d miedo usar nombres tardados), los tipos de datos, teclear declaraciones (si apropiado), y el permissibility de nulls. En este punto el diseo fsico tambin le hace frente a tales actividades prcticas como la funcin afinando, dividiendo en partes, y el arreglo de archivo.
En contra de la creencia pblica, sumando ms hardware no es el nico arma en nuestro arsenal para la afinacin de funcin. Crear ndices y las Tablas del agregado son mucho ms alternativas eficientes en base a costos. Brevemente revisaremos recomendaciones en ambas reas, tener por entendido que las consideraciones fsicas del diseo rpidamente descienden en cosas especficas de la plataforma, cules cambian rpidamente. Tambin, sea consciente de que la agregacin y la indexacin con la que las estrategias estn obligadas evolucionen como mejor comprendemos uso real. Sin embargo, no tome como excusa cambio inevitable para procrastinar en estos top-ics. Debemos entregar datos apropiadamente indizados y agregados con el rollout inicial para asegurar que el almacn da funcin adecuada de averiguacin.
La Estrategia de Agregacin Cada datos que el almacn debera contener prehicieron clculos y prealmacenaron Tablas de aggrega-tion. Dado nuestras reglas rigurosas acerca de evitar hecho mixto ponen sobre una mesa granu-larity, cada agregacin bien definida de la mesa de hecho debera ocupar su mesa fsica de hecho. Cuando agregamos hechos, nosotros o eliminamos dimensionalidad o associ-eat los hechos con una dimensin enrollada. Estas Tablas de dimen-sion enrollado, agregadas deberan ser versiones encogidas de las dimensiones asociadas con la mesa baja granular de hecho. De este modo, las Tablas agregadas de dimensin se conforman a las Tablas bajas de dimensin. Es imprctico pensar acerca de construir todo combina-tions potencial de agregacin. Si tenemos una mesa de hecho muy simple con simplemente cuatro dimensiones y cada dimensin tiene que tres atributos que son candidatos para la agregacin, hay
256 hecho potencial diferente del agregado Tablas. Desde posiblemente no puede construir, de la tienda, y puede administrar todos estos agregados, necesitamos considerar dos factores primarios al disear nuestra estrategia de agregacin. Primero, necesitamos pensar acerca de los patrones de acceso de los usuarios comerciales. En otras palabras, qu datos resumen frecuentemente al vuelo? La respuesta para esta pregunta puede estar derivativo de entendimientos profundos comerciales de anlisis de requisitos, as como tambin de aporte ganado monitoreando patrones reales de uso. En segundo lugar, necesitamos evaluar la distribucin estadstica de los datos. Por ejemplo, cuntas instancias nicas tenemos en cada nivel de la jerarqua, y que cul es la compresin como la maniobra de un nivel para lo siguiente? Si nuestros 50 productos se remangan en 10 marcas, slo resumimos 5 filas bajas (por trmino medio) para calcular el agregado de marca. En este caso est que no vale el esfuerzo para fsicamente el prealmacenamiento el agregado. Por otra parte, si podemos evitar filas bajas 100 muy juntas accediendo al agregado en lugar de eso, hace bastante ms sospechar. El juego de agregacin se resume a disminuir de entrada y salida. En general, el espacio del disco requerido por Tablas del agregado debera ser aproximadamente dos veces el espacio consumido por los datos de niveles de base.
La disponibilidad de un navegante del agregado es otra consideracin en nuestra estrategia de agregacin global. Sin un navegante del agregado, el nmero de dibujos tcnicos de aggre-gate que usuarios analticos manualmente deben elegir est muy limitado probablemente no ms de dos agregados por mesa baja de hecho. La funcionabilidad del navegante del agregado se sienta entre el cliente peticionario y sistema administrativo de relaciones de base de datos. El navegante intercepta la peticin de lenguaje normalizado de consulta del cliente y, dondequiera posible, la modifica a fin de que accede a los agregados que realzan ms funcin correcta. El navegante del agregado hace uso de produc-tive de las Tablas del agregado al neutralizar las aplicaciones del cliente. Los clientes no necesitan especficamente escribir su averiguacin para acceder a una base especfica versus mesa agregada de hecho, pidiendo que las averiguaciones estn reescritas cuando los agregados son
Aadido o dejado caer. El navegante maneja cambios para el portafolio del agregado entre bastidores a fin de que el cliente pueda permanecer olvidadizo, como debe ser. Finalmente, deberamos considerar el papel de cubos OLAP como parte de nuestra estrategia de agregacin porque estn especialmente bien agradados para la respuesta rpida para datos de summa-rized. Algunos productos permiten una integracin libre de irregularidades entre los datos de aggre-gated en los cubos y el dibujo tcnico detallado en una estructura de relaciones.
La Estrategia Inicial de Indexacin Los administradores de la base de datos hiper-pueden externar los sentimientos cuando se enteran de que las Tablas de dimen-sion frecuentemente tienen ms que simplemente un ndice. Las Tablas de dimensin tendrn un ndice nico en la sola columna llave primaria. Adems, nosotros reC-ommend que un ndice de B-Tree en columnas de atributo de high-cardinality destin para con-straints. Los ndices de los que se traz un mapa en pedacito deberan ser colocados en todos los atributos del cardinality mediano y bajo. Entretanto, las Tablas de hecho son los behemoths de los datos almacenan, as es que necesitamos indexarlas ms cuidadosamente. La llave primaria de la mesa de hecho es casi siempre un subconjunto de las llaves extranjeras. Tpicamente colocamos un ndice solo, concatenado en las dimensiones primarias de la mesa de hecho. Desde que muchas averiguaciones dimensionales son embarazosas en la dimensin de fecha, la fecha que la llave extranjera debera ser el trmino principal del ndice. Adems, teniendo la fecha llave en el primer lugar acelera el proceso de carga de datos donde los datos incrementales son aglomerados por la fecha. Desde que la mayora de optimizadores ahora permiten ms que un ndice ser usados al mismo tiempo adentro resolviendo una averiguacin, podemos construir la separata indexa por otra parte dimensin independiente que las llaves extranjeras en el hecho posponen. Mucho menos frecuentemente, los ndices son colocados en los hechos si sirven para restricciones de alcance o de estrechamiento con una banda de nylon.
Crear el plan de almacenamiento fsico para el almacn de datos no es diferente para que para otras bases de datos relacional. El administrador de la base de datos querr considerar el arreglo de archivo de la base de datos, inclusivo marcando con rayas para minimizar argumentacin de entrada y salida. Las Tablas grandes de hecho tpicamente estn subdivididas por la fecha, con seg-mented de datos por el mes, la cuarta parte, o el ao en particiones de almacenamiento separadas al aparecerse ante los usuarios como una sola mesa. Las ventajas de dividir en partes por la fecha son dobles. Las averiguaciones funcionarn mejor porque slo acceden al parti-tions requerido para resolver la averiguacin. Asimismo, en la mayora de los casos las cargas de datos corrern ms rpidamente porque slo necesitamos reconstruir el ndice para una particin, no para la mesa entera. Las particiones tambin pueden ser archived fcilmente. Finalmente, el administrador de la base de datos debera implementar un sistema de monitoreo de uso tan temprano como possi-ble. El monitorear usos ser importante para la funcin en curso afinando, como para soporte del usuario, capacidad planificando, y el mercadeo interno.
El Diseo de Escenificacin de Datos y el Desarrollo La actividad final en la pista de datos es el diseo y desarrollo del stag-ing o el sistema ETL. Algunas veces nos referimos a escenificacin como el iceberg del proyecto del almacn de datos. Mientras el iceberg se ve formidable del timn del barco, a menudo no ganamos un aprecio completo de su magnitud hasta que choquemos con l y descubramos a populacho que acecha debajo de la superficie del agua. Como describimos en Captulo 1, la escenificacin de datos quita los datos sin procesar de sistemas de opera-tional y la prepara para el modelo dimensional en el rea de presenta-tion de datos. Es un servicio de la trastienda, no un servicio de averiguacin, eso requiere una robusta aplicacin de sistema. Desafortunadamente, muchos equipos enfocan solamente la atencin en la E y la L del acrnimo ETL. Mucho del alzamiento pesado ocurre adentro lo transforma (T) paso, donde combinamos datos, el trato con calidad surge, identifique datos actualizados, edad hombre que el substituto teclea, construya agrega, y los errores de la agarradera. Como ha sido nuestro mantra a todo lo largo de este captulo, usted primero debe formular un plan de escenificacin. Similares para la arquitectura tcnica, diseamos el appli-cation de escenificacin usando una serie de schematics que empiezan en el nivel alto y entonces se entrenan en las cosas especficas para cada mesa. Usted necesita decidirse si estamos comprando una herramienta que escenifica datos o construyendo las capacidades en la nuestra. Nosotros generalmente el recom nos reparamos usando un producto comercialmente disponible. Mientras usted no puede esperar recuperar su inversin sobre la primera iteracin debido a la curva de aprendizaje, una herramienta proveer mayor integracin de metadatos y flexibilidad realzada, reusabilidad, y maintainability a largo plazo. La otra decisin fundamental para ser hizo preocupaciones la estructura de las tiendas de datos que resultan de o se usan para soportar las actividades de escenificacin, como nosotros dis-cuss en Captulo 1. Normalizar los datos de la fuente antes de que sea denormalized pues el modelo dimensional puede ser apropiado para un en particular barco espinoso de relacin o si la fuente es ya normalizado, pero a menudo es innecesario. Para una cierta cantidad, es insondable
pensar acerca de abordar las actividades de escenificacin sin el uso de un despecho normalizado de estructura que el espacio de almacenamiento adicional y esfuerzo requiri. En este caso los datos normalizados satisface una necesidad de la zona de comodidad en vez de un requisito absoluto.
La Escenificacin de la Mesa de Dimensin Desde que las dimensiones necesitan conformarse y estn reutilizadas a travs de modelos dimensionales, tpicamente son la responsabilidad de un autoridad ms centralizado. El autoridad de dimensin es responsable de definir, sosteniendo que, y publicar una dimensin particular para los centros de compras apropiados de datos. El acto de publicar es
En verdad un tipo de copia sncrona porque todo el que corriente abajo centros de compras debiesen tener una copia idntica de la dimensin al mismo tiempo. Mientras la autoridad de dimensin ha centralizado responsabilidad, hay autoridades probablemente mltiples en nuestra organizacin, cada uno responsable en primer lugar o dimensiones ms de fondo. Las dimensiones pueden ser procesadas concurrentemente. Sin embargo, todo lo que el dimen-sions requiri en un dibujo tcnico debe ser publicado antes de escenificar de los datos de hecho. La escenificacin de la mesa de dimensin implica los siguientes pasos. Escenificar herramientas puede entregar mucho de esta funcionabilidad. Extraiga datos dimensionales de sistema operacional de la fuente. Los datos extrados pueden ser movidos al rea de escenificacin de dimensin por ya sea devolviendo para un archivo y el utilizador Protocolo de Transferencia de Archivos (el FTP) o haciendo un traslado de la corriente. Las estadsticas de auditora del extracto deberan ser coleccionadas. Limpie valores de atributo. La accin apropiada debera ser llevada a manejar las siguientes situaciones, junto con muchos otros: El nombre y la direccin analizando gramaticalmente, inconsistentes valores descriptivos, perdidos descifran, cdigos sobrecargados con significados mltiples con el paso del tiempo, datos invlidos, y perdiendo datos. Maneje vicarias asignaciones de teclado. Desde utiliza llaves vicarias en el almacn de datos, debemos mantener una mesa maestra persistente de referencia cruzada adentro La zona de estacionamiento para cada dimensin. La mesa de referencia cruzada le sigue la pista a la llave vicaria asignada a una llave operacional en un punto con el tiempo, junto con el perfil de atributo. Si los datos maestros de referencia cruzada fuesen maniobrados como una mesa plana, los campos incluiran esos identificados en Figura 16.3. Como se muestra en Figura 16.4, interrogamos los datos dimensionales extrados de la fuente para determinar si es una fila nueva de dimensin, una actualizacin para una fila de exist-ing, o ni. Los registros nuevos de la fuente operacional son identificados fcilmente en el paso inicial porque la llave operacional de la fuente no est ubicada en la mesa maestra de referencia cruzada. En este caso la aplicacin de escenificacin hace cesin Unos llave vicaria nueva e insertos una fila nueva en la mesa maestra.
Amaestre Mesa de Referencia Cruzada de Dimensin Subrogue Llave de Dimensin Fila Operacional de Dimensin de Atributos de Dimensin de la Llave de la Fuente 1-N Fecha de Caducidad Efectiva de la Fila de Dimensin de Fecha El Indicador Ms Reciente de la Fila de Dimensin La suma de verificacin Cclica ms reciente (la prueba de redundancia cclica) de Redundancia
Al combinar datos de fuentes mltiples, habra columnas adicionales para las otras fuentes operacionales.
Resuelva 16.3 Campos para la Mesa de referencia cruzada de Dimensin del Amo que Escenifica
La Fuente Nueva Filas Asigne llaves vicarias y fecha /indicador determinada El inserto
Fuente La prueb a de redun danci a cclic a Comp are
Extraiga Ninguna prueba de redundancia cclica Ignore Cambia
Amaestre Juez de Cruz de Dimensin Cambi Filas Tipo 1o3
Tipo 2 Actualice atributo de dimensin Asigne llaves vicarias y fecha /indicador determinada Actualice anterior fila "ms reciente" Actualice
El inserto
Actualice Amaestre Juez de Cruz de Dimensin Actualice La Ms Reciente Asignacin de Teclado
Creo que 16.4 la Dimensin posponen a la gerencia crucial vicaria.
Rpidamente determinar si filas ha cambiado, confiamos en un algoritmo cclico de suma de verificacin de redun-dancy (la prueba de redundancia cclica). Si la prueba de redundancia cclica es idntica para el registro extrado y la fila ms reciente en la mesa maestra, en ese entonces ignoramos el registro extrado. No necesitamos revisar cada columna para tener la seguridad de que el fsforo de dos filas exactamente. Si la prueba de redundancia cclica para el registro extrado difiere de la ms reciente prueba de redundancia cclica en la mesa de referencia cruzada, en ese entonces necesitamos estudiar cada columna para determinar qu cambia y entonces cmo ser el cambio manejado. Si la columna cambiada es un tipo 1 atributo, en ese entonces meramente sobrescribimos el valor de atributo. Si la columna debe ser tratada con un tipo 3 respuesta, cambia se hace Solamente en la fila existente. Sin embargo, el procesamiento es un poco ms tramposo con un tipo 2 cambio. En este caso le aadimos una fila nueva a la mesa maestra de referencia cruzada con una llave vicaria nueva reflejando los valores nuevos de atributos, as como tambin la apropiada fecha de efectividad, la fecha de caducidad, e indicador ms reciente. La fecha de caducidad e indicador ms reciente en la anterior versin necesitan estar actualizados para reflexionar que el anterior alboroto est ya no vigente. Si acostumbramos Una combinacin de tcnicas SCD dentro de una sola mesa, debemos establecer reglas comerciales para decidir cul tcnica de cambio toma antecedencia. El paso final en Figura 16.4 debe actualizar la mesa crucial vicaria ms reciente de asignacin. Esta mesa consiste en dos columnas la llave operacional de la fuente y su substituto asignado ms reciente teclean. Si nosotros hemos manejado cambios usando el tipo 2 tcnica, esta mesa contendr slo la fila ms reciente. Creamos esta mesa para proveer bsquedas aceleradas cuando el substituto de la mesa de hecho de asignacin teclea.
Construya imgenes de carga de la fila de dimensin y publique dimensiones revisadas. Una vez que la mesa de dimensin refleja el extracto ms reciente (y ha sido confi-dently que la calidad asegur), es publicado para todos los centros de compras de datos que usan esa dimensin.
La Escenificacin de la Mesa de Hecho Mientras las Tablas de dimensin estn replegadas para todos los centros de compras apropiados de fecha, los datos de la mesa de hecho no son explcitamente duplicados. Con lo archi-I-tecture del autobs del almacn de datos, los linderos alrededor de una mesa de hecho se basan en el proceso de negocio de la fuente (es), no en lneas organizativas. Consecuentemente, las Tablas de hecho estn apartados en posiciones nicas sino disponible para quienes necesitan accede a. A diferencia de dimensin las Tablas que requieren una autoridad centralizada garantizar consistencia a travs de la organizacin, las Tablas de hecho pueden ser administradas sobre una base ms distribuida, assum ing que cada proTablas para usar la dimensin conformada de la autoridad de dimensin y no reproducir los mismos datos de la mesa de hecho en posiciones mltiples. A nosotros en breve de lneas apagado los pasos nos hicieron falta escenificar los datos de la mesa de hecho: 1. Extraiga datos de hecho de sistema operacional de la fuente. 2. Reciba dimensiones actualizadas de las autoridades de dimensin. Queremos asegurar que tenemos la coleccin completa de filas de dimensin que se encontr en los datos de hecho. 3. Separe los datos de hecho por la granularidad segn se requiera. Sys-tems operacional de la fuente algunas veces incluyen datos en niveles diferentes de detalle dentro del mismo archivo. Las granularidades deberan ser separadas a primera hora del proceso de escenificacin. 4. Transforme los datos de hecho segn se requiera. Las transformaciones comunes incluyen clculos aritmticos, cronometran conversiones, equivalizacin de monedas circulantes o las unidades de medida, la normalizacin de hechos (como el tratamiento de 12 cubos definidos en fecha en un solo registro operacional), y manejo de nulls. 5. Reemplace llaves operacionales de la fuente con llaves vicarias. Reemplazar
el oper-ational afina con llaves vicarias, usamos la mesa de asignacin ms reciente y vicaria y crucial creada por la autoridad de dimensin. Haciendo un paso sobre la mesa de hecho para cada dimensin, rpidamente substituimos la llave ms reciente de sur-rogate para cada llave operacional encontrada. Deberamos asegurar integridad de referen-tial en este punto en vez de en espera del proceso de carga de datos. Si La llave operacional de la mesa de hecho no localiza un fsforo en la mesa crucial vicaria de asignacin, tenemos varias opciones. El proceso pudo estar suspendido. Las dudosas filas podran ser escritas para un archivo capaz de volver a cargar de suspenso. De otra manera, automticamente podramos crear una fila de la llave nueva vicaria y de dimensin para la llave operacional sin precedente. En vez de asignar una sola llave falsa desconocida para todas las problemticas llaves operacionales encontradas, nosotros
Asigne una llave vicaria diferente para cada llave operacional poco localizada. Lo
El atributo descriptivo pues la llave as de recin vicaria asignada podra rezar algo as como la Incgnita de Descripcin para Operational Key XYZ. De esta manera, cuando la llave operacional nueva est descrita correctamente, usted a menudo puede evitar volver a visitar las llaves vicarias en la mesa de hecho. 6. Sume llaves adicionales para el contexto sabido. Algunas veces sumamos que el substituto teclea eso no est disponible en el registro operacional, como la llave de promocin de appropri-eat para las transacciones de punto de venta o las caractersticas demogrficas llave de minidimensin que identifica el perfil actual del cliente. Surro-gate teclea para no indicar a Applicable o Salir en Citas para Estar Resuelto
Sera asignado segn el caso.
7. La calidad aseguran los datos de la mesa de hecho. Por supuesto, deberamos generar ms cuentas de la fila y pie varo para compararnos con las estadsticas del extracto. 8. Construya o actualice Tablas de hecho de agregacin. El agregado pone sobre una mesa typi-cally es creado fuera de la plataforma de la base de datos de relaciones porque su construccin depende pesadamente de tipo y suma procesamiento secuencial. Sea consciente de que los cambios de sentido o los ajustes sobre el perodo previo puedan hacer estragos
Sobre los subsistemas de agregacin.
9. La carga de la masa los datos. Si las colisiones de la llave de la mesa de hecho ocurren durante la carga, otra vez tenemos varias opciones. Podemos detener el proceso, podemos escribir las filas para un archivo capaz de volver a cargar de suspenso, o aditivamente podemos actualizar la fila del blanco. 10. Alerte a los usuarios. Finalmente, infrmele al mundo de los negocios que la mesa de hecho ha sido publicada y est listo para accin.
El Lifecycle la Pista Analtica de Aplicaciones El set de cierre de actividades paralelas siguiendo el defini-tion comercial de requisitos en Figura 16.1 es la pista aplicativa analtica, donde diseamos y desarrollamos las aplicaciones que ponen la direccin en una porcin de lo require-ments analtico de los usuarios. Como un desarrollador aplicativo muy respectado una vez nos dijo, Remember, sta sea la parte divertida! Estamos
finalmente usando la inversin en la tecnologa y los datos para ayudar a usuarios a hacer mejores decisiones. Las aplicaciones proveen un mecha-nism crucial para intensificar la relacin entre el equipo de proyecto y la comunidad de busi-ness. Vienen a presentarle la cara del almacn de datos a sus usuarios comerciales, y traen de vuelta las necesidades comerciales en el equipo de desarrolladores de appli-cation. Mientras algunos pueden considerar que el almacn de datos debera ser un ambiente de averiguacin completamente ad hoc, entregar aplicaciones analticas accionadas por parmetros lega sit-isfy un porcentaje abrumador de necesidades del mundo de los negocios. No hay sentido
Haciendo a cada usuario de inicio de la nada. Construir un set de aplicaciones analticas establece un armazn analtico consistente para la organizacin en vez de dejar cada macro Excel decir una historia ligeramente diferente. Las aplicaciones analticas tambin vienen a narrar de forma resumida la experticia analtica de la organizacin, con tal que uno arranque con cables para lo menos analticamente inclinado.
La Especificacin Aplicativa Analtica Despus de la definicin comercial de requisitos, necesitamos revisar lo find-ings y la muestra cobrada reporta identificar un arrancador colocado de aproximadamente 10 para 15 aplicaciones analticas. Queremos estrechar nuestro foco inicial para la mayor parte de capacidades de crit-ical a fin de que podamos manejar expectativas y podamos asegurar en deliv-Ery de tiempo. El aporte comercial de la comunidad ser crtico para este proceso de priorizacin. Mientras 15 aplicaciones no pueden sonar como mucho, el nmero de analy-Se especfico que puede ser creado de una sola plantilla meramente cambiando variables le asombrar. Antes de que comencemos a disear las aplicaciones iniciales, es de ayuda establecer stan-dards pues las aplicaciones, como los comunes mens de despliegue vertical y la salida coherente miran y sienten. Usando los estndares, especificamos cada tem-plate aplicativo, captando suficiente informacin acerca del trazado, las variables de aporte, calcu-lations, y suspensiones tan tan ambos el desarrollador aplicativo y los diligenciadores comparten una comprensin comn. Durante la actividad aplicativa de especificacin, tambin debemos considerar la posibilidad de la organizacin de las aplicaciones. Necesitamos identificar caminos estructurados de naviga-tional para acceder a las aplicaciones, reflejando los usuarios de forma idea acerca de su negocio. Apalancando Internet y portales modificables de informacin son las estrategias dominantes para diseminar acceso aplicativo.
El Desarrollo Aplicativo Analtico
Cuando nos movemos hacia la fase de desarrollo para las aplicaciones analticas, otra vez necesitamos enfocar la atencin en estndares. Los estndares para nombrar a convenciones, calcula-tions, bibliotecas, y la codificacin deberan ser establecidas para minimizar futuro revise. La actividad aplicativa de desarrollo puede comenzar una vez que el diseo de la base de datos es completo, los datos acceden a las herramientas y los metadatos son instalados, y un subconjunto de datos de his-torical ha sido cargado. Las especificaciones aplicativas de la plantilla deberan ser vueltas a visitar para dar razn de los cambios inevitables para los datos modelo desde que la spec-ifications fuera completada. Cada herramienta en el mercado tiene trucos especficos para un producto que pueden causar que eso salte a travs de aros atrs. En vez de intentar aprender las tcnicas por medio de la prueba
Y el error, usted debera invertir dinero en educacin especfica en la herramienta apropiada o debera volver flexibles recursos mentales para el equipo de desarrollo. Mientras las aplicaciones estn siendo desarrolladas, varios beneficios auxiliares resultan. Los desarrolladores aplicativos, armado con una herramienta robusta de acceso de datos, rpidamente encontrarn acosar verbalmente problemas en el pajar de datos a pesar de la comprobacin de calidad formada por Per por la aplicacin de escenificacin. sta es una razn por qu preferimos comenzar sobre la actividad aplicativa de desarrollo antes de lo supuesto comple-tion de escenificacin. Por supuesto, necesitamos hacer tiempo en el horario para poner la direccin en algunos desperfectos identificados por las aplicaciones analticas. Los desarrolladores tambin sern los primeros de una manera realista experimentar tiempos de respuesta de averiguacin. Ahora es la hora de empezar estrategias review-ing nuestras que afinan funcin. Las actividades aplicativas de comprobacin de calidad de desarrollo no pueden ser com-pleted hasta los datos est estabilizado. Necesitamos asegurarnos de que hay tiempo adecuado en el horario ms all del truncamiento que escenifica datos finales para tener previsto un ordenado resumen de noticias de las tareas aplicativas de desarrollo.
Implementacin La tecnologa, datos, y analticas huellas aplicativas convergen en la implementacin. Desafortunadamente, esta convergencia no ocurre naturalmente sino requiere planeamiento previo sustancial. Quiz ms importantes, una implementacin atinada exigen que el coraje y la fuerza de voluntad evalen el estado de preparacin del proyecto para desplegarse honestamente. La implementacin es similar a servir una comida grande de da de fiesta para los amigos y los parientes. Puede ser difcil de predecir exactamente cunto tiempo tomar para cocinar al pavo. Por supuesto, si el termmetro del pavo no indica do-ness, el cocinero se ve forzado a retardar los entremeses para compensar el atraso. En el caso de la implementacin del almacn de datos, los datos es el plato fuerte principal, analo-gous para el pavo. Cocinar (o la escenificacin) los datos es la tarea ms imprevisible. Desafortunadamente, en datos almacenando, aun si los
datos no estn completamente cocinados, a menudo todava seguimos con implementacin porque le dijimos a los invitados del almacn que estaran servidos en un tiempo y fecha especfica. Porque tenemos pocos deseos de retardar el paso de implementacin, marchamos en sus oficinas con datos poco cocidos. No es extrao que los usuarios algunas veces se refrenan de volver por una segunda porcin. Adems de crticamente evaluar la presteza del almacn de datos efecta la entrega capaz, que tambin necesitamos para empaquetarla con educacin y soporte para la implementacin. Desde que la comunidad del usuario debe acoger el almacn para eso ser estimado suc-cessful, educacin es crtica. El programa de educacin necesita enfocar la atencin en el producto a entregarse completo del almacn: Datos, aplicaciones analticas, y los datos acceden a la herramienta (segn el caso). Si elegimos desarrollar materiales educativo inhouse, le debemos permitir al menos 1 hasta 2 das de desarrollo por cada hora de educacin.
Considero lo siguiente para un programa efectivo de educacin: comprenda a su grupo meta; No abrume. no entrene al mundo de los negocios temprano antes de la disponibilidad de datos y las aplicaciones de ana-lytic. posponga la educacin (y la implementacin) si el almacn de datos no est listo a ser soltado. gane el compromiso del patrocinador para una ninguna educacin, ningn acceso poltica.
Los datos almacenan estrategia del soporte depende de una combinacin de expectativas de manage-ment y las realidades de los productos a entregarse del almacn de datos. Portuario en sorbo est a menudo organizado en una estructura de dos hileras la primera lnea de experticia reside dentro del rea comercial, mientras que soporte centralizado provee una lnea de defensa de sec-ondary. Adems de identificar recursos del soporte y cedures, tambin necesitamos determinar la mantenimiento aplicativo y la liberacin planifican, as como tambin las estrategias de comunicacin en curso. Mucho como una liberacin del producto del software experimenta una serie de fases antes de la disponibilidad general, as deberan el almacn de datos. Lo con-sists experimental alfa de fase del equipo de proyecto de fondo realizando una prueba del sistema unidos por los extremos. Al igual que con cualquier prueba del sistema, usted debe encontrar problemas, as es que asegurarse all el tiempo adecuado en el horario para lo inevitable revise. Con la prueba beta, requerimos un set limitado de usuarios comerciales para realizar una prueba de aceptacin del usuario, espe-cially como se aplica a la calidad y relevancia comercial de los productos a entregarse del almacn. Finalmente, el almacn de datos es soltado para la disponibilidad general, si bien como un rollout controlado.
El Mantenimiento y el Crecimiento Lo hemos hecho a travs de la implementacin, conque estamos listos a devolver una patada y relajarnos. No tan rpidamente! Nuestro trabajo est distante de completo una vez que nos hemos desplegado. Necesitamos continuar invirtiendo recursos en las siguientes reas: Soporte. El soporte del usuario es crucial inmediatamente despus de la implementacin para asegurar que el mundo de los negocios se enreda. Para la primera parte varias semanas siguiendo a educacin del usuario, el equipo del soporte debera estar en marcha proactivamente con los usuarios. No podemos recostarnos en nuestros cubculos y podemos asumir eso sin novedad del mundo de los negocios es buenas noticias. Si no escuchamos de ellos, entonces es muy probable que nadie est usando el almacn de datos. Reubique (al menos por ahora) para el mundo de los negocios a fin de que los usuarios tengan acceso fcil para soportar recursos. Si los problemas con los datos o las aplicaciones estn descubiertos, sea honesto con el negocio para construir
La credibilidad al tomar accin inmediata para corregir los problemas. Otra vez, si su producto a entregarse del almacn no es de alta calidad, las demandas imprevistas del soporte para la conciliacin de datos y la aplicacin revisan puede ser apabullante. Educacin. Necesitamos proveer un programa permanente de educacin para el almacn de datos. El plan de estudio debera incluir refresco formal y cursos adelantados, as como tambin debera repetir cursos introductorios. Ms educacin informal puede ser ofrecida las desarrolladoras y las usuarias de poder para promover el intercambio de ideas. El soporte tcnico. El almacn de datos es ya no uno agradable para tener excepto las necesidades para ser tratado como un ambiente de produccin, completo con acuerdos del nivel de servicio. Por supuesto, el soporte tcnico proactivamente debera monitorear per-formance y la capacidad del sistema tiende. No queremos confiar en el busi-ness comunal para decirnos que la funcin ha degradado.
El soporte de programa. Mientras la implementacin de una fase especfica del almacn de datos serpentea abajo, los datos almacenan vidas de programa adelante. Necesitamos continuar monitoreando progreso en contra de los criterios de xito convenido. Necesitamos comercializar nuestro xito. Tambin necesitamos asegurar que las implementaciones existentes quedan en pista y continan ocupndose de las necesidades del negocio. Las revisiones del punto de inspeccin en curso son una herramienta de la llave para evaluar e identificar oportunidades para la mejora con anteriores productos a entregarse. Los almacenes de datos ms a menudo se caen de pista cuando pierden su foco sobre servir para las necesidades de informacin de los usuarios comerciales. Si hemos cumplido con nuestro trabajo correctamente, inevitablemente habr demanda para el crecimiento, ya sea para usuarios nuevos, la informacin nueva, las aplicaciones nuevas, o los realces principales Para los existentes productos a entregarse. Como aconsejamos ms temprano al discutir a scoping, los datos almacenan pareja no debera hacer decisiones acerca de estas opciones de crecimiento en un vaco. El negocio necesita estar involucrado en el proceso de prioritiza-tion. Otra vez, esto puede ser buena hora para palanquear el anlisis del cuadrante de priorizacin ilustrado en Figura 16.2. Si usted no ha hecho eso ya, es de ayuda tener un comit comercial ejecutivo de patrocinio en lugar para compartir responsabilidad para la priorizacin. Una vez que las prioridades nuevas
han sido establecidas, en ese entonces retrocedemos al principio de este captulo y hombre oficioso Otra vez! Si Dios quiere, podemos apalancar mucho del anterior trabajo, especialmente referente a las arquitecturas tcnicas de datos y.
Errores Que Almacenan Datos Comunes para Avoid Le hemos dicho a usted qu que haga completamente este captulo; Ahora pesaremos esos reC-ommendations contra una lista de qu no hacer. Terminamos Captulo 15 con una lista de errores dimensionales comunes de modelado. Aqu nosotros hemos listado errores para evitar
Al construir y manejar un almacn de datos. Los errores son descritos como una serie de caricaturas negativas. Por favor perdone cualquier huella de cinismo que usted podra detectar. Nuestra meta es para que usted aprenda de estas caricaturas basadas en equivoca hecho por datos annimos almacenan parejas. Como George Santayana dijo, se condena que Esos que no pueden recordar el pasado lo repiten. Quedemos en no repetir cualquier de estos errores. As como en Captulo 15 la lista de errores dimensionales de modelado, hemos listado estos errores en orden inverso, terminando con lo ms importante. Sin embargo, cualquier de estos podra ser tapones de funcin. Error 10: Acepte la premisa que eso responsable pues la empresa los sistemas de la fuente principales son tambin importantes y ocupados para pasar el tiempo con el equipo del almacn de datos. Ciertamente, no pueden alterar sus mtodos operacionales significativamente para pasar datos a o del almacn. Si su organismo realmente comprende y aprecia el almacn de datos, en ese entonces los sistemas operacionales de la fuente deberan estar los socios efectivos con usted en hacer un download de los datos necesitados y en tele-enviar limpi datos segn el caso ?. Error 9: Despus de que el almacn de datos haya sido desenrollado, establezca a una reunin planificadora para tratar comunicaciones con los usuarios comerciales, si el presupuesto da rienda suelta a que. Newslet-ters, entrenando sesiones, y soporte personal en curso del com-munity comercial deberan ser artculos del gating para el primer rollout de los datos almacenan. Error 8: Haga seguro el almacn de datos mantener al personal tienen oficinas agradables en la tecnologa de la informacin construyendo, lo cual es slo un breve paseo en coche de los usuarios comerciales, y establezca un nmero del soporte del almacn de datos con montones de opciones digitales. Los datos almacenan personas del soporte deberan estar fsicamente ubicadas en los departamentos comerciales, y mientras sobre la asignacin, deberan gastar todo su horas de vela dedicaron al contenido comercial de los departamentos que le sirven. Tal rela-tionship engendra a la coalicin de empresas y la credibilidad con los usuarios comerciales. Error 7: Entrene a cada usuario sobre cada caracterstica de la herramienta de acceso de datos en la primera clase de train-ing, difiera educacin de contenido de datos porque la clase usa datos falsos (los datos autnticos no estarn listos para otro par de meses), y declare xito en el com-pletion de la primera clase que
entrena porque el almacn de datos ha sido desenrollado a los usuarios comerciales. El retraso entrenndose hasta su primer centro de compras de datos est listo a volverse en vivo En datos autnticos. Mantenga el primer cortocircuito de sesin de entrenamiento, y enfoque slo la atencin en los usos simples de la herramienta de acceso. Ubique ms tiempo para el contenido de datos y aplicaciones analticas en vez de para la herramienta. Planifique sobre una serie permanente de clases de entrenamiento que empieza, as como tambin dele seguimiento a entrenar clases. Atribyase el mrito para el hito de aceptacin del usuario cuando sus usuarios estn todava usando los datos almacenan seis meses despus de que han sido entrenados. Error 6: Supongo que los usuarios comerciales naturalmente gravitarn hacia datos robustos y desarrollarn sus aplicaciones analticas homicidas. Los usuarios comerciales no son desarrolladores de appli-cation. Abrazarn el almacn de datos slo si un set de aplicaciones analticas preconstruidas los llama por seas.
Error 5: Antes de implementar el almacn de datos, hgale a una descripcin global de anlisis todos los activos posibles de datos de la empresa y dems pretendi usos de infor-mation, y evite la ilusin seductiva de desarrollo iterativo, cul es slo una excusa para no entendindola bien la primera vez. Muy pocas organizaciones y seres humanos pueden desarrollar el plan global perfecto para una informacin Almacene por adelantado. No slo son los activos de datos de una organizacin demasiado vasta y un complejo a describir completamente, pero tambin los conductores comerciales urgentes cambiarn significativamente sobre la vida del almacn de datos. Comience con una arquitectura ligera del autobs del almacn de datos de dimensiones conformadas y los hechos conformados, y entonces construya su almacn de datos iterativamente. Usted se mantendr alterndose y construyndolo por siempre. Error 4: No moleste a los ejecutivos con antigedad de su organizacin con el almacn de datos hasta que usted lo haya implementado y puede sealar un xito significativo. Los ejecutivos con antigedad deben soportar el esfuerzo del almacn de datos de partida. Si no lo hacen, su organizacin probablemente no podr usar el almacn de datos eficazmente. Obtenga su soporte antes de emprender el proyecto. Error 3: Aliente a los usuarios comerciales a darle informacin retroactiva continua hasta el final fuera del ciclo de desarrollo acerca de fuentes nuevas de datos y la mtrica crucial de funcin que les gustara acceder, y hacer seguro para incluir estos requisitos en la liberacin en proceso. Usted necesita pensar como un desarrollador del software y manejar tres etapas muy visibles de desarrollar cada centro de compras de datos: (1) la etapa comercial de reunin de requisitos, donde cada sugerencia es considerada seri-ously, (2) la etapa de implementacin, donde los cambios puede ser acomodada pero debe estar negociada y generalmente causar que el horario se resbale, y (3) la etapa del rollout, donde los rasgos de proyecto estn congelados. En el segundo y las fases terceras, usted debe evitar asqueroso insidioso de alcance (y la parada siendo algo semejante
Una persona complaciente).
Error 2: Acuerde entregar un centro de compras cntrico en cliente de datos prominentes, idealmente rentabilidad del tomer de cobres o una satisfaccin del cliente, como su primer producto a entregarse. Estas clases de centros de compras de datos son consolidados, que se secundan a ras centros de compras con dependencias serias en fuentes mltiples de datos. La rentabilidad del cliente requiere que todas las fuentes de recursos y todo las fuentes de costo, as como
tambin un plan de dotacin tracen un mapa de costos encima de la renta! Para el primer producto a entregarse, enfoque en lugar de eso la atencin en una sola fuente de datos, y haga los centros de compras de datos ms ambiciosos ms tarde. Error 1: No hable con los usuarios comerciales; Ms bien, confe en asesores o expertos internos para darle su interpretacin de requisitos del almacn de datos de los usuarios. Su trabajo es ser el editor publicista de los datos correctos. Para lograr su objec-tives de trabajo, usted debe escuchar a los usuarios comerciales, quienes tienen siempre la razn. Los substitutos insignificantes para la interaccin directa con los usuarios. Desarrolle la habilidad para or.
Los usuarios comerciales, no usted, define el acomodamiento y la usabilidad del producto a entregarse del almacn de datos. Usted tendr xito slo si usted sirve para las necesidades de los usuarios comerciales.
Resumen Este captulo provey una excursin de alta velocidad del lifecycle de un proyecto del almacn de datos. Brevemente tratamos superficialmente los procesos cruciales y las mejores costumbres de un diseo del almacn de datos y el esfuerzo de implementacin. Mientras cada proyecto es un dif-ferent mordido de lo siguiente, inevitablemente usted necesitar enfocar atencin en cada uno de las tareas principales que discutimos para asegurar una iniciativa atinada.
Presente Imperativos y
El Futuro Punto de Vista
El espite la fusin accidental del ncleo de un reactor de la Internet y el colapso de la alharaca publicitaria de la Internet, se puede decir sin temor a equivocarse que estamos todava en medio de una revolucin en computar y communi-cation. Una mayora de los ciudadanos en los Estados Unidos, Europa, y las partes de Asia estn usando computadoras directamente o son afectadas directamente por ellas de muchas maneras. La velocidad y las capacidades de nuestras computadoras continan doblndose cada 18 meses, y agresivamente cambiamos el alambre de nuestra infraestructura para soportar comunicaciones de ancho de banda alto. El paso no reducido de esta revolucin de informacin tiene implicaciones profundas para datos almacenando. Recuerde, almacenamiento de datos (o sea lo que fuere procedi al cobro inmediato del futuro) simplemente significa publicar los datos correctos. El almacenar datos es la responsabilidad central para hacer algo til con todos los datos que coleccionamos. As de quiz las buenas noticias son que todos nosotros tendremos trabajos por siempre porque el almacenar datos est en el corazn de L es responsabilidad. Excepto las malas noticias es que ese almacenamiento de datos ser un blanco en movimiento porque nuestro ambiente
de informacin evoluciona tanto rpidamente y seguramente continuar evolucionando para muchos decenios. Intentar tomar control de lo que los siguientes 10 o 20 aos pueden tener en tienda a nosotros, djenos primero yacer fuera de tanto como lo podemos hacer acerca de lo que otros expertos de la industria han dicho recientemente referente a las siguientes direcciones de tecnologa. Aunque esto puede parecer ir en contra de los prejuicios en este libro (es decir, comience con las necesidades del usuario comercial, no con tecnologa), en gran escala sospeche del mercado, lo nuevo
371
La tecnologa es ciertamente una reflexin de lo que los usuarios quieren. Mirado del per-spective del almacn de datos, el mundo entero se cra en el medio nuevo de la computadora, y un set entero de expectativas poderosas definir y conducir qu es un almacn de datos. En segundo lugar, debemos acusar recibo y debemos anticipar fuerzas polticas poderosas en el trabajo en el mundo hoy afectando lo que pensamos una computadora las es y cmo debera ser usada la macin infor. Las palabras valederas son seguridad y privacidad. El almacn de datos est absolutamente en lo grueso de seguridad y los asuntos de privacidad, y ms que todo, los datos comunidad del almacn han tardado en articular soluciones de seguridad y de privacidad. En lugar de eso, hemos tenido soluciones dadas para nosotros por los intereses del almacn de poco datos, incluyendo grupos de infraestructura en ESO as como polticos. Finalmente, intentaremos describir las tendencias culturales grandes dentro de warehous-ing de datos, incluyendo la sacudida fuera de la comunidad del vendedor, el uso de aplicaciones empacadas y subcontratamos los aplicativos pases proveedores de servicios, y las tendencias hacia y fuera de la centralizacin del almacn de datos.
La Tecnologa en Curso Avanza Comencemos con un tema divertido: La tecnologa nueva. Dijimos cosas? El aparato de la Internet. Selle con oblea funcin rala, alta, siempre adelante, tiempo real audio y de vdeo con color de 24 pedacitos. Las computadoras personales del hoy se conectaron a la lnea del suscriptor de digi-tal (el sublenguaje de base de datos) o los mdemes cablegrficos ya se acercan a estos specifi-cation. Progresivamente, las personas exigirn dispositivos porttiles con conexiones inalmbricas de banda ancha para la Internet. El aparato de la Internet se convertir en una combinacin aun ms potente de manipulacin de informacin y com-munication que lo que sea hoy. Muchos datos servicios conducidos en almacn sern redimidos a travs de este medio, y mucho datos sern coleccionados como
resultado de los gestos del usuario final hecho al usar el aparato. El aparato de la Internet applica tions incluir: Todas las formas de informacin buscan y recuperacin. Estos presentarn motores de bsqueda que hacen un trabajo mucho mejor de entender el significado, ambos en las especificaciones de bsqueda y en contenido del documento. Correo electrnico. Siempre en correo electrnico promover una inundacin de correos electrnicos diminutos consistente en solos fragmentos de frase como las personas conversan casualmente y como los padres averiguan sobre las posiciones de nios, as como tambin incontables otro infor-mal determina el tipo sanguneo de comunicacin. Este comportamiento es ya comn con el dispositivo Japanese DoCoMo.
Telefona. El aparato de la Internet ser un telfono de poder lleno, capacitado en la ganancia dondequiera en todo momento. La teleconferencia mvil. La de doble va y N-Way frontal y voz para expresar comunicaciones se convertirn en un modo significativo y valioso de usar el aparato de la Internet. Televisin. La televisin estar ampliamente disponible por el aparato de la Internet, aunque no reemplazar la TV estndar de la sala de estar. Pelculas, literatura, y juegos. El aparato de la Internet, asociado con acceso que se cablegrafia menos, ser usado progresivamente para el ocio y el entretenimiento, espe-cially en el camino. El entretenimiento, por supuesto, se transforma poco a poco en educacin. Aprendizaje por medio de la Internet. La educacin electrnica seguir dada a peticin cada vez ms para los estudiantes remotos. Radio. Las emisiones convencionales del radio de todas partes del mundo aumentarn en la popularidad. La Internet es la sucesora para radio de onda corta. Compras. Ir de compras en la Internet continuar creciendo. Los consumidores progresivamente configurarn las opciones que quieren y arreglan entrega de su construido para ordenar productos. Dell provee un estudio de casos en uno construido para ordenar, ningn eBay comercial. intermediario crecer para convertirse en lo mar-ketplace mundial para las ventas de persona a persona. Navegacin. Desde que el aparato de la Internet es porttil, siempre conectado, y el Sistema (el SPG) probablemente Posicionador Global - facultado, sern unos increas - la ingly til ayuda de navegacin, ya sea para conducir o para caminar. La traduccin de lenguaje. Los servicios de traduccin de lenguaje lento pero seguro, automticos a los que se accedi por el aparato de la Internet se volvern precisos y tiles. 4000 la x 3000 el pixel dos paginan monitorea. El formato grande, las tecnologas
de despliegue de alta resolucin es salir de los laboratorios hoy que aumentarn el rea disponible y decisin de nuestros sistemas de la PC de mesa dramticamente. La integracin de cmaras, cmaras de vdeo, personales aparatos de vdeo (PVRs), y PCs. El almacenamiento en disco y los anchos de banda del procesador estn muy cerca para estar listos en precios al consumidor para una sntesis grandiosa de photog-raphy de alta resolucin, abatanan captura de vdeo, PVRs, y videotecas. El lenguaje hablado interacta. El reconocimiento del lenguaje hablado es bastante bueno ya para el control de voz de comandos de computadora. Una capacidad relacionada ser anotaciones de voz en documentos, una tecnologa que han estado esperando entre bastidores para que bastantes para micrfonos adjunto a la presente para PCs logren masa crtica. La integracin de SPG. Los dispositivos de SPG permearn todo de nuestro automo-bile para nuestros PCs porttiles para nuestras bonitas tarjetas de crdito. Estos dispositivos no slo
Le dar informacin retroactiva de usuarios finales de acerca de donde en la superficie de la tierra que estn sino que tambin frecuentemente registrar y salvar las posiciones de acontecimientos importantes, como las llamadas telefnicas y las transacciones. La geocodificacin aumentada de mucho de nuestros datos del almacn de datos traer el almacn de datos y comunidades de SPG algo ms junto. La cartera electrnica segura, penetrante. Las incertidumbres del hoy acerca de revelar sus nmeros de la tarjeta de crdito pasarn al olvido. Todos nosotros tendremos la capacidad de fuente fidedigna autenticarnos nosotros mismos (vea el siguiente artculo) y pagar por productos y ser-vice en cualquier situacin. Fortuitamente, esto apurar la crisis econmica de la convencional oficina de correos porque las cuentas de pago por correo de primera clase sern una de las categoras ms grandes cambiando de decisin encima para la forma electrnica. La identificacin biomtrica confiable. La ventana de oportunidades para seales bonitas, como el cajero automtico (el cajero automtico) carda, ha transcurrido imperceptiblemente ya. Especialmente adentro estos das de preocupacin acerca de hacer seguro a la persona en la PC son en realidad quin l o ella dice que l o ella es, habr uso comn de dispositivos virtualmente biomtricos a prueba de tontos para identificacin personal. Hoy, en 2002, el reconocimiento de la huella digital parece ser el lder, pero el reconocimiento de retina parece ser la mejor por largo tiempo tecnologa, suponiendo que los dispositivos de reconocimiento de retina pueden construirse a bajo precio. Transductores que recaban datos personales en todas partes. Sobre los siguiente varios decenios, ser difcil de resistir el uso gradualmente aumentado de transductores que recaban datos que registrarn nuestro cada maniobra y cada gesto. Algunos de la presin vendr de transductores o cmaras prendarias en reas pblicas sensitivas. Algunos de la presin vendr de par-ents protectora necesitando rastrear la localizacin de sus nios. Los criminales quiz pueden ser puestos en libertad temprano de crcel si acuerdan llevar puesto un dispositivo rastreador en todo momento. Los enseres del hogar tiles encendern las luces y calentarn el caf cuando tropezamos de entre cama. Nuestras despensas mantendrn un inventario corredor y generarn una lista de eleccin para la siguiente visita de la tienda de comestibles. La tienda de comestibles misma le puede interactuar esta lista y puede optimizar nuestra visita. Es un Nuevo Mundo valiente. Si todo 300 personas de milln en los Estados Unidos genera un cada segundo sin precedente 24 horas por el da 365 das al ao, y suponiendo que los registros as
generados son 40 bytes anchos, ste requerira 378,432 tuberculosis De crudo almacenamiento de datos cada ao. Y ste es un diseo sin intervencin quirrgica consistente en slo texto y numera, ninguna imagen o ninguno de los mapas. Micropayments para contenido. Un efecto secundario de la cartera electrnica bien puede ser la introduccin de servicios de valores agregados a cambio de micropayments de algunos centavos o las fracciones de un centavo. Nuestra vacilacin aqu no est con el technol ogy sino con la cultura de la Internet que exige acceso libre para cada cosa. Por supuesto, los proveedores contentos tienen que ganar dinero en cierta forma, y a menos que haga publicidad, puede tener que ser micropayments.
Privacidad Prendaria y Conmovedora Que Exige Fuerzas Polticas Al momento de esta escritura estamos en las etapas anticipadas de reaccionar al chal-lenges de terrorismo internacional. Por el momento, la mayora de americanos estaran dispuestos prescinda de un poco de sus libertades ciudadanas y su privacidad a cambio de la seguridad significativamente aumentada. Si el tiempo significativo anda por antes de otro asalto terrorista principal, la demanda para una nacional tarjeta de identificacin u otras formas de autenticacin segura de todas las personas se desvanecern. Sin embargo, si otra tomas de asalto colocan pronto, parece probablemente que querremos rastrear a todo el mundo, en todas partes, al menos cuando estn usando infraestructura pblica. El tech-nologies probable de autenticacin incluye tarjetas de identificacin a prueba de falsificacin con informa-tion biomtrico incrustado, as como tambin los sistemas de reconocimiento de la cmara que pueden identificar alguien de paso a travs de una barrera prendaria. Haciendo frente a amenazas terroristas, es probable que toleraremos un cierto nivel de golpeteo de nuestros correos electrnicos as como tambin nuestras llamadas telefnicas. No es probable que impondremos restricciones nuevas significativas sobre el uso de cdigo simplemente porque la tecnologa fuerte de cdigo est ya ampliamente disponible ambos en los Estados Unidos y de pases extranjeros. La existencia de un nmero nacional de Idaho y el nimo para vincular el comportamiento de un indi-vidual con el uso de eso numera es, por supuesto, el uso familiar de una dimensin conformada sobre una escala muy grandiosa.
El Conflicto entre Beneficial Acostumbra e Insidious Abusa A menudo dejamos nuestra informacin personal estar reunido slo cuando consideramos los usos beneficiosos. Y usualmente no entendemos o anticipamos los abusos insidiosos de esa misma reunin de informacin cuando la aprobamos. Considere los siguientes ejemplos: La informacin mdica personal. Los usos beneficiosos son obvios y com-pelling. Queremos que nuestros doctores tengan informacin completa acerca
de nosotros a fin de que puedan proveer la cautela ms informada. Reconocemos que las compaas de seguros necesitan acceso para nuestras fichas mdicas a fin de que puedan compensar a las personas que provee asistencia mdica para la salud. La mayor parte de nosotros estamos de acuerdo eso agreg datos aproximadamente Sntomas, diagnostican, tratamientos, y resultados son de valor para la sociedad como un todo. Adems, vemos que la necesidad para amarrar estas fichas mdicas a medianamente detall informacin demogrfica y conductista. Es el paciente un fumador? Cuntos aos tiene el paciente? Sin embargo, los abusos insidiosos estn casi como rivet-ing como los beneficios. La mayor parte de nosotros no queremos nuestros detalles mdicos personales para
Est disponible para cualquiera aparte de nuestros doctores. Preferentemente, los reclamos de seguro
Los dependientes procesadores no deberan poder mirar nuestros nombres, pero ste es proBa-bly poco realista. Ciertamente no queremos nuestra informacin mdica personal Para ser vendido para los terceros orientados hacia el mercadeo. No queremos ser discrimi-nated en contra por nuestro estatus de salud, envejecer, o las predisposiciones genticas. El comportamiento de compra. Los usos beneficiosos de datos de comportamiento de compra dejan a nuestros detallistas favoritos darnos servicio personalizado. De hecho, cuando confiamos en un detallista, estamos realmente encantados de proveer un perfil de adecuacin listando nuestros intereses si esto enfoca las elecciones hasta un nmero dcil y nos avisa de productos nuevos en los cuales tendramos inters. Queremos que el detallista nos sabe lo suficiente como para maneja preguntas, asuntos de pago, problemas de la entrega, y el producto regresa en una forma de estrs bajo. Sin embargo, los abusos insidiosos de nuestro comportamiento de compra vuelven nosotros balsticos. No tenemos el deseo de ser ofrecidos sexualmente por cualquier tercero a travs de correo no solicitado o el correo electrnico o sobre el telfono. La seguridad y la seguridad en las facilidades pblicas. En estos tiempos, todos nosotros agradecemos un sentimiento de seguridad en aeropuertos, delante de mquinas del cajero del banco, y en estacionar garajes. Deseamos a las personas que deliberadamente corren rojas luces de trnsito dejara de poner en peligro al resto de nosotros. La mayor parte de nosotros aceptamos la presencia de cmaras y sistemas de reconocimiento de la matrcula en estos lugares pblicos como un acuerdo intermedio efectivo que aumenta nuestra seguridad y una seguridad. Lo legal
Sistema, que finalmente reflexione los valores de nuestra sociedad, slidamente ha soportado el uso de estas clases de tecnologas de vigilancia. Sin embargo, los abusos insidiosos de cmaras y sistemas que monitorean ciudadano son espeluznantes y controversiales. Tenemos la habilidad tcnica para crear una base de datos nacional de imagen de cada ciudadano e identificar la mayora de las caras que se cruzan a travs de portones prendarios del aeropuerto. Cmo va el registro acumulado de nuestros viajes a ser usado y por a quin?
Quin Posee Sus Datos Personales?
Hay una inclinacin natural para creer que cada uno de nosotros poseemos y tenemos un derecho inalienable para controlar toda nuestra informacin personal. Sin embargo, encaremos la realidad ruda. Esta vista es ingenua e imprctica en la sociedad del hoy. Las fuerzas que coleccionan y comparten informacin personal son tan penetrantes y grow-ing tan rpidamente que aun no podemos hacer listas asimilativas de los sistemas que congregan informacin, mucho menos podemos definir qu clases de coleccionismo y uso compartido son aceptables. Pienso acerca de los tres ejemplos discutidos ms temprano. Todos nosotros rutinariamente firmamos las clusulas de escape que dejan a los proveedores y compaas de seguros compartir nuestras fichas mdicas. Ha ledo usted una de estas clusulas de escape? Usualmente dejan todas las formas de registros servir para cualquier propsito para un perodo indefinido. Simplemente pruebe desaprobar la redaccin en la clusula de escape, especialmente si usted est en la sala de emergencias.
Y, honestamente, los proveedores y las compaas de seguros tienen derecho a poseer la informacin porque han cometido sus recursos y se han expuesto al adeudo sobre su patrocinio. De modo semejante, el detallista tiene derecho a saber quin es usted y lo que usted compr si usted espera cualquier forma de crdito o la relacin de la entrega con el detallista. Si usted no quiere servicio personalizado, entonces slo involcrese en transacciones efectivas annimas en tiendas de cemento y ladrillo tradicionales. Y finalmente, si usted usa aeropuertos, el cajero trabaja a mquina, o las vas, usted implcitamente acuerda aceptar el acuerdo intermedio de vigilancia. Cualquier imgenes recabadas pertenecen al gobierno o el banco, al menos hasta donde la ley actual est afectada. Un corolario extrao de ser opacado en un lugar pblico es la experiencia que todos nosotros hemos tenido de pasar en medio de una escena estando filmados por un fotgrafo amateur. Desde que un tercero inocentemente ha captado nuestra imagen, tenemos algunos derechos de own-ership en esa imagen?
Qu Es Probable para Happen? Observando A los Observadores. . . En nuestra opinin, hay dos formas principales en las cuales las leyes de privacidad y las costumbres sern desarrolladas. Ya sea nuestros legisladores guiarn la forma con legislacin innovadora y penetrante como el Health Insurance Portability y el Acto de Responsabilidad y el Acto de Proteccin de Privacidad En Lnea de los Nios ((COPPA) HIPAA) o el mercado y medios de comunicacin obtendrn a la fuerza organizaciones para adaptarse a las percibidas preocupaciones de privacidad de nuestros ciudadanos. Debera decirse que el gobierno se mueve lentamente, an cuando hace su trabajo bien. HIPAA fue representada en 1996, y COPPA fue representada en 1998. Los requisitos de estas leyes todava no han sido implementados completamente en 2002. Mucho ha estado escrito acerca de las amenazas para la privacidad y el impacto de tecnologas nuevas, pero una perspectiva pragmtica y apremiante que parece ganar uno significativo siguiente puede ser encontrado en David Brin La Sociedad Transparente: Nos obligar Technology a Choose entre la Privacidad y la
Libertad? (Los Libros Perseus, 1999). Brin sostiene la opinin que un acuerdo intermedio efectivo entre la libertad y la privacidad puede ser asestado observando a los observadores. En otras palabras, aceptamos la inevitabilidad de las aplicaciones beneficiosas de informacin personal reunindose, pero hacemos todo el proceso bastante ms visible y transparente. De este modo podemos reprimir muchos de los usos insidiosos de la informacin. Insistimos notificaciones muy visibles de informacin reunindose dondequiera que ocurre. Insistimos en honradez y consistencia tica adentro despus de las polticas indicadas. Y significativamente, insistimos en estar notificados cada vez que nuestra informacin personal es usada por alguien.
Simson Garfinkel, en Nacin de la Base de Datos (O'Reilly, 2000), est de acuerdo con muchos de los puntos incrementados en el libro de Brin y adicionalmente insisten en que los ciudadanos deberan poder acceder, desafiar, y corregir todas las instancias de su informacin personal, aun si no tienen el derecho de inhibir su uso.
Cmo Observando los Afectos de Observadores Los Datos Almacenan Arquitectura El movimiento de privacidad es una fuerza potente que puede desarrollarse rpidamente. Como los datos almacenan a los diseadores, podemos ser preguntados repentinamente por gerencia para originarnos de un montn de preocupaciones de privacidad. Cmo nuestra arquitectura del almacn de datos tienen probabilidad de ser afectado? Aqu hay una lista probable, en nuestra opinin: todo lo que la informacin personal esparci alrededor de nuestra organizacin necesitar ser consolidado y centralizado en una sola base de datos. Slo debera haber un set consistente, limpiado de datos acerca de individuos, y cualquier informacin que no sirve para cualquier propsito identificado deberan ser removidos de todas las bases de datos. los papeles prendarios y esta base de datos de informa-tion centralizada y personal que rodea polticas necesitarn estar definidos, implementados, y revisados cuentas. el servidor conteniendo la base de datos personal centralizada de informacin ser necesidad para estar fsicamente aislado sobre su propio segmento de un trabajo neto de rea local detrs de un paquete filtrando portal de acceso que slo acoge paquetes de servidores aplicativos en los que se confi por fuera. el respaldo y la recuperacin del servidor personal centralizado de informacin necesitarn una forma firme de seguridad fsica y lgica. al menos dos niveles de sensibilidad prendaria necesitarn estar definidos para imple-ment un estndar nuevo de privacidad en su organizacin. La informacin demogrfica general ser asignada un nivel ms bajo de seguridad. Nombres, nmeros de cuenta, y seleccionada informacin financiera y relacionada con la salud sern asignados un nivel ms alto de seguridad. una base de datos de auditora que rastrea cada uso de la informacin personal
debe acompaar la principal base de datos. Esta base de datos de auditora debe implementar el requisito para notificar a cada individuo de todos los usos de l o su la informacin personal, incluyendo quin la recuestora de la informacin es y lo que la aplicacin es. A la base de datos de auditora le pueden comparar require-ments diferente de acceso con la principal base de datos. Si la base de datos de auditora es usada en un modo de la cantidad de cosas, extrae con bomba informes de uso que son enviados por correo electrnico a (o postal enviado por correo) el individuo afectado cuya informacin est siendo usada. Si el individuo afectado puede poner en duda la base de datos de auditora en lnea, entonces est intrnsecamente menos
Seguro que la principal base de datos y probablemente necesidades a estar sentado sobre un servidor diferente, ms pblico. Es importante que la base de datos de auditora contenga como contenido poco comprometedor tan posible pero sea enfocado simplemente sobre revelar los usos finales de informacin. una interfaz debe estar prevista que autentica al recuestor individual y entonces provee una copia de toda su informacin personal almacenada en la base de datos. Una segunda interfaz debe dejar al individuo reto, haga comentarios, o corrija la informacin. un mecanismo debe existir para lo efectivo expurgando de informacin que es considerada sera incorrecta, legalmente inadmisible, o pasado de tiempo. La informacin expurgada debe ser verdaderamente expurgada a fin de que no puede salir a la superficie otra vez posteriormente. Aunque los datos almacenan la comunidad tradicionalmente no ha dado la pauta apoyando cambio social, pensamos que puede ser una mirada astuta en el futuro si nosotros que cada uno considera ya sea la lista precedente de cambios podramos ser imple-mented en nuestras organizaciones. Considrele una panorama futura razonable que merece un poco de planificacin adelantada. Si usted es ms atrevido, y si usted piensa el debate de privacidad terminar como el tipo de acuerdo intermedio descrito en los libros de Brin y Garfinkel, entonces hable con su informtico en jefe y su man-agement mercadotcnico acerca de algunos de estas ideas.
Diseando para Evitar Fracaso Catastrfico Hemos estado acostumbrados a pensar que nuestras edificios grandes, importantes, visibles y computadoras son inherentemente seguros solamente porque son grandes, importantes, y vis-ible. Este mito ha sido desbaratado. Ms que todo, estas clases de edificios y computadoras son lo ms vulnerable. El asalto devastador sobre nuestra infraestructura tambin se ha originado a la vez cuando el almacn de datos ha evolucionado para un estatus como de produccin cercano en muchas de nuestras compaas. Los datos almacenan ahora manage-ment de relacin del cliente de paseos en coche y provee cerca del estatus
de tiempo real rastreando de rdenes, entregas, y pay-ments. El almacn de datos es a menudo el nico lugar donde una vista de cliente y la rentabilidad del producto puede ser ensamblada. El almacn de datos se ha convertido en una herramienta indispensable para correr muchos de nuestros negocios. Cabe eso hacer un mejor trabajo de proteger nuestros almacenes de datos? Hay un tipo de almacn de datos que es inherentemente seguro y menos vulnerable para prdida de cata-strophic?
Los Fracasos Catastrficos Listemos algunas amenazas importantes que pueden dar como resultado un fracaso catastrfico sostenido de un almacn de datos, entendimos por las respuestas prcticas potenciales: La destruccin de la facilidad. Un ataque terrorista puede derribar un edificio o los puede daar seriamente a travs de fuego o anegacin. En estos casos extremos, todo en sitio puede ser perdido, la cinta inclusiva salta y ambientes administrativos. Dolorosa como es discutir, tal prdida puede incluir el personal de tecnologa de la informacin que saben contraseas y comprenden la estructura del almacn de datos. El sabotaje deliberado por una decidida persona de confianza. Los acontecimientos del 11 de septiembre,
2001 demostraron que las tcticas de terrorismo incluyen la infiltracin de nuestro Los sistemas por individuos expertos que ganan acceso a los puntos ms sensitivos De control. Una vez en calidad del control, el terrorista puede destruir lo Sistema, lgicamente y fsicamente.
Cyberwarfare. No es noticioso que los piratas informticos puedan interrumpir a sistemas y puedan hacer estragos. Los acontecimientos del 11 de septiembre deberan eliminar algunas suposiciones ingenuas restantes que estas incursiones son inofensivas o constructivas porque exponen desperfectos prendarios en nuestros sistemas. Hay usuarios expertos de la computadora entre nuestros enemigos que activamente tratan hoy de acceder a la informacin no autorizada, alteran informacin, y desactivan a nuestros sistemas. Los meses cuntas veces en recientes tenemos adverados la negativa de servicio ataca de gusanos del software que ha asumido el control de servidores o computadoras personales? No creemos por un minuto que stos sean solamente el trabajo De cros del escrito. Sospechamos que algunos de estos esfuerzos son carreras de costumbre por ciberterroristas. Los solo fracasos del punto (delibere o no). Una categora general final de prdida de cata-strophic proviene de exposicin indebida para singularizar fracasos del punto, ya sea los fracasos son causados deliberadamente o no. Si la prdida de una unidad de hardware, una sola lnea de comunicacin, o una sola persona lleva hacia abajo el almacn de datos por un extendido perodo de tiempo, en ese entonces tenemos un problema con la arquitectura.
Antagonizando Fracasos Catastrficos Ahora que hemos identificado varios fracasos catastrficos potenciales, fijemos nuestra atencin en respuestas posibles: Los sistemas profundamente distribuidos. El solo la mayora de acercamiento efectivo y poderoso para evitar fracaso catastrfico del almacn de datos es una arquitectura profundamente distribuida. El almacn de datos de la empresa debe estar hecho de computadoras mltiples, sistemas operativos, tecnologas de la base de datos,
Las aplicaciones analticas, los caminos de comunicaciones, las posiciones, el personal, y las copias en lnea de los datos. Las computadoras fsicas deben estar ubicadas en posiciones muy separadas, idealmente en partes diferentes de los Estados Unidos O a travs del mundo. Untar el hardware fsico con muchos nodos de inde-pendent en gran medida reduce la vulnerabilidad del almacn a sabo-tage y solo fracasos del punto. Implementando los datos almacn simultneamente con sistemas operativos diversos (por ejemplo, Linux, Unix, y NT) en gran medida le reduce la vulnerabilidad del almacn a los gusanos, los ataques sociales de ingeniera, y los piratas informticos expertos explotando vulnera-bilities especfico. Durante los siguientes 20 aos, muchos de los avances amorosos arquitectnicos interesantes en el almacenar datos estarn en construir sistemas a profundamente distribuidos. Aunque construyendo y administrar una informacin profundamente distribuida almacn suena difcil, hemos estado por aos sosteniendo la opinin que todos nosotros hacemos esto de cualquier manera! Muy pocos almacenes grandes de datos de la empresa estn centralizados en una sola mquina monoltica. Iguale caminos de comunicacin. Aun un implemen-tation distribuido del almacn de datos puede ser comprometido si depende tambin pocos caminos de comunicacin. Afortunadamente, la Internet es una robusta red de comunicaciones que es altamente parallelized y se adapta a s mismo continuamente para el suyo cambiando topologa. Nuestra impresin es que los arquitectos de la Internet estn muy preocupados Acerca de los fracasos anchos en sistema debido a la negativa de ataques de servicio y otras interrupciones de inten-tional. El colapso de la Internet global no es probablemente no la preocupacin ms grande. La Internet es localmente vulnerable si centros (donde los monaguillos de Web de alto rendimiento traban un embargo directamente para el hueso raquis de la Internet) que hacen cambiar llave son atacados. Cada datos locales almacenan pareja debera tener un plan para conectarse a la Internet si el centro conmutativo local es comprometido. Con tal que los caminos multimodos redundantes de acceso como los dedicados vnculos rgades y bajo en caloras satel de su edificio para la Internet fomenten reduce vulnerabilidad. El extendido rea de almacenamiento se conecta (SANs). Un SAN es tpicamente un grupo de respaldo y unidades de disco de alto rendimiento que los dispositivos conectaron juntos por fibra muy de alta velocidad canalizan tecnologa. En vez de ser un servidor del archivo, este grupo de disco conduce puestas en
evidencia una interfaz que se bloquea a ras hacia computadoras logrando acceso al SAN que hace los paseos en coche parecen estar relacionados al plano posterior de cada computadora. Los SANs le ofrecen al menos tres enormes beneficios a un almacn endurecido de datos. Un solo SAN somtico puede ser 10 kilmetros en la extensin. Esto quiere decir que las unidades de disco, los sistemas del archivo, y los dispositivos de apoyo pueden estar ubicados en edificios separados en un campus medianamente grande. En segundo lugar, El respaldo y copiarse puede ser disco realizado para el disco en velocidades extraordinarias a travs del SAN. Y la tercera parte, desde todos los discos en un SAN es un recurso compartido para procesadores anexos, los sistemas aplicativos mltiples pueden ser resueltos en contra para acceder a los datos adentro paralelamente. Esto es especialmente apremiante en un ambiente de slo lectura cierto.
Los respaldos diarios para los medios de comunicacin extrables tomados para obtener almacenamiento. Hemos sabido de este por aos, pero ahora es hora de tomar en serio todo esto ms. No importa qu otras protecciones que ponemos en colocan, nada provee la seguridad del lecho de roca que fuera de la Internet y afianzadamente almacen fsicos medios de comunicacin provea. Sin embargo, antes de precipitarse a comprar el ltimo dispositivo de alta densidad, dele pensamiento considerable en lo que se refiere a qu tan duro ser leer los datos de lo mediano de almacenamiento, cinco, y aun diez aos en el futuro. Portales de acceso que filtran estratgicamente paquete acomodado. Necesitamos aislar los servidores cruciales de nuestro almacn de datos a fin de que no sean directamente accesibles de las redes de rea local usadas dentro de nuestros edificios. En un configura-tion tpico, una aplicacin que el servidor compone pone en duda, cules son pasados a un servidor separado de la base de datos. Si el servidor de la base de datos est apartado atrs un portal de acceso que filtra paquete, el servidor de la base de datos slo puede recibir paquetes del mundo exterior viniendo del servidor aplicativo en el que se confi. Esto quiere decir que todo lo que otras formas de acceso son ya sea prohibidas o debe estar conectado localmente para el servidor de la base de datos detrs del portal de acceso. Esto quiere decir que administra-tor de la base de datos con privilegios del sistema debe tener sus terminales conectadas para esta red interior a fin de que sus actos administrativos y contraseas escritas fuera de peligro no pueden ser detectados por buscadores de paquetes en la red normal adentro
El edificio.
La autenticacin permitida en papel del cuello de botella y el acceso. Los almacenes de datos pueden ser comprometidos si hay formas diferentes de ms para acceder a ellas y si la seguridad no se controla centralmente. Reparo en que no dijimos centralmente localizado; Ms bien, dijimos centralmente controlado. Una solucin apropiada era un servidor Ligero de Protocolo de Acceso a Directorios (LDAP) controlando todo fuera de lado el acceso del portal de acceso para los datos el almacn. El servidor LDAP da rienda suelta a que Todos los usuarios peticionarios a ser autenticados en una forma uniforme sin tener en cuenta ya sea ellos estn dentro del edificio o entrando por la Red de una posicin remota. Una vez autenticado, los socios del servidor del directorio lo El usuario con un denominado papel. El monaguillo aplicativo entonces toma la
decisin en una pantalla por la base de la pantalla en lo que se refiere a ya sea el usuario autenticado merece ver que la informacin bas sobre su papel. Como nuestros datos que los almacenes cultivan para miles de usuarios y centenares de papeles bien definidos, las ventajas de esta arquitectura del cuello de botella en la que se convirtiiste significativos. Hay mucho que podemos hacer para fortificar nuestros almacenes de datos. En aos pasados nuestros almacenes de datos se han vuelto demasiado crticos para las operaciones de nuestro organi-zations para permanecer tan expuestos como lo han sido. Hemos tenido la llamada del wakeup.
La Propiedad Intelectual y la Feria Acostumbran Las organizaciones que crean informacin tienen tremendo poder poltico y mayormente haber tenido xito en afirmar derechos permanentes de la propiedad para el informa-tion que crean. Esta clase de informacin incluye grabaciones de obras de arte, como las canciones, las pelculas, y las producciones de vdeo, as como tambin los moldes noticiosos y deportivos y anchos, y las expresiones registradas oficialmente de opinin, como financieros boletines de prensa. Todo este tiene un impacto bastante significativo en el almacn de datos. Uno debe ser extraordinariamente precavido acerca de coleccionar informacin de una fuente exterior. Desde que la mayor parte de nuestros organismos tienen mucho dinero, debemos ser muy adversos en riesgo para evitar una accin legal basada en el reclamo que asignamos informacin que no nos perteneci o estaba bajo licencia. Por esto, y porque la tecnologa copiadora de los medios de comunicacin est hecho mucho ms restrictivo, el concepto original de uso justo de informacin encontr en un trabajo registrado oficialmente comprado como un libro mayormente ha sido eviscerado. El uso justo puede valer todava legalmente para un individuo, pero no puede ser posible para una empresa grande. Aunque el pblico general pudo haber considerado que Napster fue inofensivo o aun beneficioso, los tribunales tomaron una vista sumamente negativa del archivo de Napster compartiendo y cort totalmente el aire de Napster completamente. A menos que hay algo de cambio significativo en la ley o un reto constitucional atinado, la escritura en la pared es clara. La informacin creada le pertenece al dueo, quien tiene muy por largo tiempo derechos para el control absoluto de esa informacin. Si usted tiene suerte, usted puede alquilar la informacin, pero usted no la poseer, y no hay forma prctica para hacer uso justo de esa informacin, al menos con la tecnologa de la que sabemos hoy.
Las Tendencias Culturales en Datos Almacenando Cerraremos este captulo describiendo las tendencias culturales significativas siguiendo y teniendo un impacto en datos almacenando.
Ingenindose de acuerdo con las reglas a travs de la Empresa En los pasados 20 aos a los que el mundo de los negocios se hizo marcadamente ingeniarse de acuerdo con las reglas en vez de ingeniarse por instinto o caminando por los pasillos. Toda la generacin actual de gerentes comerciales se ha criado adentro vuelta en datos
El anlisis y la importancia de indicadores cruciales de funcin. El puro tamao y la complejidad de demanda abrumadora de negocios detallaron medidas. Y finalmente, queriendo controlar todos individuales posiciones de memoria, subcategoras del producto, y aun clientes individuales pueden dar como resultado economas significativas. Todo esto requiere una inundacin bblica de nmeros y las medidas. Aunque comercializar a los gerentes y los otros analistas estratgicos en el mundo de los negocios ha estado cuantitativamente orientado para la mayor parte de los ltimos 20 aos, slo recientemente tenga a los administradores de operaciones de las bases abrazados el potencial completo del almacn de datos. Mucho de la maniobra reciente proviene del nfasis nuevo sobre integrar todos los procesos que miran hacia cliente del negocio en un todo libre de irregularidades as es que ambas personas de operaciones y el cliente pueden ver todos los procesos de inmediato en un solo armazn comprensible. Sin embargo, lograr integracin completa (la Empresa para la Iniciativa de las Amricas) de la aplicacin de la empresa es un proceso muy complicado que usualmente implica reemplazar el proceso de transacciones en lnea primario (OLTP) los sistemas operacionales. Somos slo partway a travs de este proceso sobre una escala global. Sin embargo, las presiones competitivas y financieras para lograr esta integracin slo aumentarn en los siguientes 20 aos. As, aunque esto continu evolucin de ingenindose de acuerdo con las reglas (usted le puede llamar datos almacenando, gestor de relaciones con el cliente, o Empresa para la Iniciativa de las Amricas) no puede ser la tendencia del tech ms alto en los siguientes 20 aos, es en ciertos aspectos la tendencia ms importante y penetrante de la que tendremos que ocuparnos.
La Confianza Aumentada en Sophisticated Afine Indicadores de Funcin Los gerentes comerciales siempre han tenido una relacin de odio de amor con indicadores cruciales energticos (KPIs) de funcin, especialmente esos se derivaron de modelos matemticos de sophisti-cated. Si trabajan, son fantsticos, excepto tan pronto como producen un resultado inexplicable o equivocado, sufren una cada desastrosa en cred-ibility. La minera de datos y los modelos sofisticados de pronosticacin gradualmente son gain-ing una masa crtica de respeto,
especialmente en ciertas reas aplicativas, como el anlisis de previsin econmica, de promociones, ptimo ponindole precio a los algoritmos, la deteccin de fraude, y el anlisis de amenaza. La comunidad que extrae de la mina datos parece haber aprendido la leccin para no vender con exceso sus tcnicas sofisticadas pero ms bien enfocar la atencin en xitos que traen el dinero al meollo del asunto. Generalmente, consideramos que las herramientas analticas sofisticadas son clientes sin afectacin de los datos almacenan. En muchos casos, los datos almacenan saques a mano fuera de sets de observacin como archivos de physi-cal para estas herramientas, donde son tramitados y analizados repetidamente mientras el almacn principal de datos est ocupado sirvindole a otros clientes. La llave mana para los datos almacena al gerente manteniendo a estos clientes sofisticados debe (1) asegurarse de que estos clientes en verdad destinan el almacn de datos como la plataforma para datos limpiados en vez de representar extraccin primaria de datos mismas
(2) eduque a estos clientes en relacin a la forma de taladrar a travs de las dimensiones conformadas de la empresa para instrumentar observaciones amplias y poderosas, y (3) desarrollar a una asociacin efectiva para apartar con la mano datos en ambas direcciones para la herramienta de minera de datos y de la herramienta de minera de datos.
El Comportamiento Es el Entoldado Nuevo Aplicacin En los 1980s, los datos dominantes almacenan aplicacin fue embarques y parte. Estbamos encantados simplemente para ver cunto fue el producto fuera de la puerta a los mercados diversos. En los 1990s, la rentabilidad fue la informacin dominante aplicacin del almacn. Descubrimos eso con el diseo correcto del almacn de datos, podramos cortar en rodajas y podramos jugar a los dados la rentabilidad de nuestros negocios por productos, clientes, acontecimientos promocionales, tiempo, y muchas otras dimensiones. Aunque los embarques, la parte y la rentabilidad ciertamente permanecen importantes, adentro lo
Los 2000s que parece que tenemos un entoldado nuevo aplicacin el comportamiento. Como lo Las anteriores aplicaciones, el comportamiento la manera muchas cosas y alcances para todas las esquinas de Nuestro negocio. Los clientes tienen comportamiento de compra de comportamiento, de pago, producto Devuelva comportamiento, vuelva a comprar comportamiento, soporte comportamiento de peticin, y recom El comportamiento de mendacin. Los productos tienen behav de fiabilidad de comportamiento, de atractivo en el mercado Ior, y ordenando comportamiento de estacin. Los empleados tienen comportamiento de productividad, Vendiendo comportamiento, comportamiento vacacional de tomadura, y comportamiento de liderazgo. Sitio Web Las visitas tienen comportamiento de clic efectivo, sitan behav de navegacin de comportamiento, de privacidad Ior, y comportamiento de confianza. El comportamiento es una perspectiva poderosa para agrandar el barco Los ments y la parte y las aplicaciones de rentabilidad que ya sabemos cmo hacer. Claramente, sin embargo, el comportamiento es un concepto ms elusivo. Si la rentabilidad iguala La renta menos los gastos, en ese entonces qu es el comportamiento?
Las Aplicaciones Empacadas Han Golpeado Su Punto Alto
Durante el empuje de empuje los das de la alharaca publicitaria de la Internet, muchas tiendas de tecnologa de la informacin estaban sobrecogidas por las demandas nuevas de comercio electrnico. La mayora de tiendas de tecnologa de la informacin supieron que les faltasen las habilidades para construir su Web y sus datos orientados en gestor de relaciones con el cliente almacena sistemas. Esto le abri el camino a que los vendedores aplicativos del paquete se ocupen de esta necesidad con paquetes de cargas y ejecuciones para el anlisis de Web y de gestor de relaciones con el cliente. Sin embargo, con comercio electrnico haciendo una pausa y aspirando profundamente, va de compras ora lo ha hecho el tiempo para considerar ms pensativamente los trueques en confiar en el paquete de propiedad de un vendedor exterior para una porcin del almacn de datos. No tomamos la posicin aqu que las aplicaciones empacadas son malas, pero respetuosamente sugerimos esos proveedores del paquete y ESO las tiendas la necesidad para alcanzar un mejor suelo intermedio. Aqu hay
La idea central: Los proveedores aplicativos del paquete no pueden ser los datos almacenan. Y esto incluye a los vendedores ms grandes de Planificacin del Recurso de la Empresa (la tasa de proteccin efectiva). Las barreras propietarias de la mayor parte de los paquetes de aplicaciones derrotan la habilidad de ESO para controlar y publicar sus datos de la empresa en una forma manifiesta. Los paquetes de aplicaciones en lugar de eso deberan enfocar la atencin en realizar sus tareas especficas muy bien y entonces deberan proveer la funcin ms flexible y alta forma posible para la organizacin de tecnologa de la informacin para extraer todos los datos del paquete para alojar en un almacn separado de datos.
La Integracin Aplicativa Tiene Que Termine por Alguien
Mencionamos ms temprano tan integrante las aplicaciones de la empresa para lograr una vista que mira hacia cliente coherente a menudo requieren reemplazar los sistemas de produccin OLTP. ste no es un polizonte apagado en un esfuerzo para sacar la casa de loza de datos del gancho. Como datos la calidad surge, es casi imposible limpiar datos incompatibles surge corriente abajo de la fuente. La informacin se ha perdido. En muchos casos el apareamiento de datos de sistemas incompatibles no es log-ically posible. A largo plazo, el almacn de datos debe seguir, no debe llevar la delantera, el esfuerzo de la Empresa para la Iniciativa de las Amricas. No significamos por esto para perder las esperanzas acerca de crear dimen-sions conformado y hechos conformados. Estamos tratando de advertirle que esta tarea estar distante ms fcil si comienza con los sistemas de produccin. Finalmente, usted debera ser mismo con-cerned si usted (los datos almacenan al gerente) no es invitado a estar en el pizarrn de arquitectura de la Empresa para la Iniciativa de las Amricas de su organizacin. Usted es uno de los clientes ms importantes de este proceso, y la alta gerencia de su organizacin debera comprender esto.
Los Datos Almacenan Subcontratar Necesidades Una Sobria Determinacin de Riesgo A la altura de la alharaca publicitaria de la Internet hubo una esperanza que los aplicativos pases proveedores de servicios (los spides) le podran quitar mucho de la carga de desarrollarse y support-ing las clases nuevas de almacenes de datos requeridos para el comercio electrnico. Algunos de estos tambin estaba afiliado con proveedores aplicativos (discutido anterior) del paquete. La atraccin potencial de un Protocolo de Sesin AppleTalk del almacn de datos permanece muy autntica, pero otra vez, con el beneficio de la pausa que todos nosotros experimentamos, evaluamos los riesgos del Protocolo de Sesin AppleTalk modelo as como tambin las ventajas. Si ya no estamos en una prisa desesperada implementar nuestro comercio electrnico y nuestro almacn electrnico, por qu estamos dispuestos a nosotros confiarle una responsabilidad estratgica a una persona ajena? Antes de que arrojemos afuera al beb con el agua de bao, antojmonos las ventajas del Protocolo de Sesin AppleTalk modelan para vivienda de loza de datos:
el Protocolo de Sesin AppleTalk ya tiene habilidades que la tienda de tecnologa de la informacin no tiene y quiz no puede obtener sin dificultad. el Protocolo de Sesin AppleTalk ha configurado una coleccin completa de compo-nents del hardware y del software que son conocidas para trabajar bien juntos. el Protocolo de Sesin AppleTalk tiene capacidad del hardware de repuesto para originarse de demandas explosivas de Internet o para la recuperacin de desastre. el Protocolo de Sesin AppleTalk ha centralizado economas de escala para respaldo y la recuperacin. los costos del Protocolo de Sesin AppleTalk pueden ser espordicos y manejados en una forma ms visible que un departamento interno. el Protocolo de Sesin AppleTalk se encarga de su propia administracin de personal. Antagonizando estas ventajas muy potenciales apremiantes son los riesgos: definiendo un almacn de datos a ras de acuerdo de servicio es una tarea sofisticada, y no hay mucha experiencia de la industria haciendo esto. Cueste lo que cueste, este acuerdo debera provenir de su organizacin, no de los abogados trabajando para el Protocolo de Sesin AppleTalk! un ASP puede entrar en quiebra. Un acuerdo de custodia de cdigo de la fuente no es mucha consolacin en tal caso. un Protocolo de Sesin AppleTalk puede mejorar su software en su propio horario. En todo caso, el ASP probablemente no querr hacer modificaciones aduaneras para las ofertas estndar del software si mantiene a muchos clientes a travs de muchas aplicaciones. un Protocolo de Sesin AppleTalk puede mantener a sus competidores. Usted no tiene visibilidad directa de los mtodos prendarios de un Protocolo de Sesin AppleTalk. En este punto hacemos una apuesta en contra del modelo comercial puro del remoto Protocolo de Sesin AppleTalk para aplicaciones de almacenamiento de datos. Ms bien, pensamos unas ambas partes de giv-ing ms modelo viables lo que necesitan es para una entidad como de spid corra una implementacin del almacn de datos del inhouse donde hay uso compartido significativo de habilidades con el personal local de tecnologa de la informacin. De este modo, muchas de las ventajas del
modelo de Protocolo de Sesin AppleTalk pueden ser real-ized al reducir los riesgos.
En Cerrar La mejor forma para destruir este libro debe regresar al comienzo. Barriendo todos los detalles y las tcnicas, la moneda de oro para el profesional del almacn de datos debe escuchar el negocio. Consistentemente escuchando a los usuarios nos trae de regreso a lo que - se supone - hace. Durante los siguientes 20 aos, podemos navegar a travs de que todos los cambios tcnicos, organizativos, y polticos que ocurrirn si conservemos nuestros ojos en el horizonte. Despus de todo, nuestro trabajo es publicar los datos correctos.
Glosario
24/7 3NF
La disponibilidad operacional 24 horas un da, 7 das a la semana. Vea Tercera forma normal.
Acumulando mesa de hecho de la foto El tipo de mesa de hecho con mltiplo sale en citas representando los hitos principales de una proceso relativamente de breve duracin o la tubera. El hecho que la mesa es vuelta a visitar y actualizada como la actividad ocurre. Un registro est colocado en una mesa de hecho de la foto de atesoramiento una sola vez, cundo el artculo que representa es primera creada. Contraste con mesa Peridica de hecho de la foto y mesa de hecho de Transaction-Grain. Los costos basados en actividades Los costos que son reportados como una medida de la actividad requirieron en vez de sobre un invariable valor fijado por la aduana. Vea Dotaciones. El aditivo (los hechos) Las medidas en una mesa de hecho que puede agregarse a
travs de todas las dimensiones. Las proporciones y los precios unitarios no son generalmente aditivos. Las averiguaciones ad hoc Las averiguaciones que se formul por el usuario impulsivamente. El ataque ad hoc se refiere a la dificultad una base de datos tiene en antici-pating el patrn de averiguaciones. Las ms esas averiguaciones son ad hoc, lo ms simtrico el modelo de la base de datos debe estar a fin de que todas las averiguaciones se ven lo mismo. Esto es una de las fuerzas del acercamiento dimensional de modelado.
389
El navegante del agregado El estrato de software entre el cliente y los datos de relaciones que intercepta el Lenguaje de Solicitud Estructurado del cliente (el lenguaje normalizado de consulta) y transforma ese lenguaje normalizado de consulta, si lo puede hacer, acostumbrar agrega eso est presente en alguna parte del almacn de datos. El navegante del agregado, por definicin, escuda la aplicacin del usuario de necesitar saber si un agregado es presente. En este sentido, un agregado se comporta como un ndice. Algn suppli-ers de la base de datos de relaciones ha incorporado capacidades de navegacin del agregado en sus sistemas de gestin de base de datos (DBMSs). Agregados El reconocimiento mdico rema en una base de datos, casi siempre creada por otro de sum-ming registra en la base de datos con el objeto de la funcin perfeccionadora de averiguacin. Los datos algunas veces sumarios precalculados llamados. Vea navegante del Agregado. Algoritmo receta matemtica. El mtodo estndar para computar algo; Esencialmente una
Alias (el lenguaje normalizado de consulta) Un identificador alfanumrico pequeo en una expresin de lenguaje normalizado de consulta que respalda un nombre fsico de la mesa. El inventario ubicado El inventario que ha estado asignado para embarque para una tienda o cliente particular antes de eso en verdad ha sido enviado. Dotaciones La asignacin o la prorrata de valores medidos (usualmente los costos) para varias cuentas, clientes, productos, o las transacciones. Por ejemplo, los costos generales fijos en una planta manufacturera son a menudo asignados a las lneas del producto diversas hechas en la planta. Concesin La cantidad sustrada del precio de lista de un producto, tpicamente como resultado de una promocin o un trato. Usualmente mostrado en la factura pero designado uno fuera de la concesin de la factura. La aplicacin analtica Las aplicaciones de acceso de datos Prebuilt intentaron pues menos usuarios asiduos del almacn de datos. Tpicamente
accionado por parmetros con flexibilidad para analizar incontables permutaciones. Un repre-sents tan aplicativo una oportunidad para narrar de forma resumida las costumbres mejores analticas de una organizacin. El procesamiento analtico Destinando que datos para propsitos analticos soporten comercial toma de decisiones, versus el procesamiento operacional, donde los datos se usa para dirigir el negocio. El procesamiento analtico a menudo implica anlisis de la tendencia, comparaciones perodos a perodo, y entrenndose. ANSI Cuerpo humano Instituto Nacional Americano de Normalizacin, el que publica estndares reconocidos para un alcance de negocios, profesiones, y las industrias.
La respuesta colocada Las filas regresaron al usuario final como resultado de una expresin de lenguaje normalizado de consulta presentada a un sistema de gestin de base de datos de relaciones. La restriccin aplicativa (el lenguaje normalizado de consulta) La porcin de la clusula WHERE en el lenguaje normalizado de consulta que define una restriccin sobre los valores, usualmente dentro de una mesa de dimensin. Para ser contrastado con una restriccin de la juntura. Los centros de compras de datos Architected almacenan arquitectura del autobs. Los datos de la sede
ASCII ASCII. Un carcter de 8 pedacitos establece codificacin. El ASCII slo puede mantener a 127 personajes, lo cual no es suficiente para uso internacional. La sede Prolong ASCII y UNICODE. Activo tem eso aparece en el balance de situacin de una compaa que representa algo posedo por la compaa o algo adeudado a la compaa por alguien ms. Los prstamos bancarios son activos de punto de vista del banco porque son debidos al banco. La mesa asociativa Vea cuadro puente.
Los datos atmicos Los datos ms detallados y granulares captados por un proceso de negocio. Los datos atmicos deben ser hechos disponibles en el rea de presentacin de datos para originarse de imprevisible respecto a las averiguaciones del hoc. Atributo Una columna (el campo) en una mesa de dimensin.
La dimensin de auditora Una dimensin especial que etiqueta cada fila de la mesa de hecho con metadatos operacionales (por ejemplo, el linaje de datos y la confianza) cuando la fila es creada. Autenticacin El paso de determinar la identidad del cliente peticionario. La solo autenticacin de factor usualmente se basa en una contrasea
simple y es menos que nada plan seguro de autenticacin. La autenticacin de dos factores puede requerir Lo Que Usted Know (una contrasea) con Lo Que Usted Possess (una tarjeta plstica) y es lo suficientemente seguro para los cajeros automticos de bancos. Otros dos planes de autenticacin de factor requieren Lo Que Usted Know con Quin Usted Es, usando dispositivos biomtricos de tomografa, como huella digital, retina, o sistemas basados en voces. El rezago de trabajo promedio de orden La promedia longitud de tiempo que las rdenes han estado esperando a cumplirse. El ndice de B-Tree Un ndice de relaciones que es en particular til para columnas de high-cardinality. El ndice de B-Tree hace un rbol de valores de una lista de ides de la fila que tienen el valor de la hoja. Los ndices de B-Tree son casi una porquera para columnas de low-cardinality porque cuestan mucho espacio y ellos usualmente no pueden ser com-bined con otros ndices al mismo tiempo para aumentar el foco de las restricciones. Contraste con ndice Bitmap.
Las ventas de la lnea de fondo (de una promocin) El volumen de ventas que habra ocurrido si no haba habido promocin en vigor. La puntuacin de comportamiento La figura de mrito que es asignado a un cliente basado en pur-chase modela o patrones de crdito. Tambin llamado una puntuacin de segmentacin. Las puntuaciones de comportamiento pueden extenderse desde etiquetas simples de segmentacin como medio alto,, o pueden mugir para complicar resultados numricos de una aplicacin de minera de datos. El grupo de estudio de comportamiento Grupo numeroso de clientes o productos que son usados en un anlisis del usuario o informe pero cul no pueden estar definidos constriendo sobre los atributos dimensionales y son demasiados grandes para ser enumerados por una clusula de lenguaje normalizado de consulta Indiana. El grupo de estudio de conducta a menudo est definido de un anlisis original que asla comportamiento de compra de interesante comportamiento o de crdito. BI Vea inteligencia Comercial.
El ndice Bitmap Unas las mayoras de tcnica de indexacin de relaciones asignan para columnas con un nmero limitado de valores potenciales (cardinality humilde). La mayora de optimizadores pueden combinar ms que un ndice del bitmapped en una sola averiguacin. Contraste con ndice de B-Tree. Brick y mortero Un negocio fsicamente tangible, como una tienda, a distincin de los negocios virtuales o basados en la Web. Vea tambin Clic y pegue con argamasa. Cuadro puente Una mesa con una multien parte llave captando uno muchos para muchos rela-tionship que se acomod por la granularidad natural de una solo mesa de hecho o la mesa unidimensional. Viene a cruzar entre la mesa de hecho y la mesa de dimensin para permitir dimensiones de muchos valores o jerarquas harapientas. Algunas veces llamado un ayudante o mesa asociativa. La averiguacin de vistazo SELECCIONE averiguacin BIEN DEFINIDA en una mesa unidimensional para mostrarle al usuario los valores de un atributo o la
combinacin de atributos. Navegador El software del cliente de la computadora personal (la PC) que se comunica con servidores de Web y exhibe Web contenta (el texto, la imagen, audia, de vdeo) en la PC. La funcin principal del navegador es ejecutar el programa de Lenguaje de Etiquetacin de Hipertexto (el HTML) descargado del servidor remoto de Web. Autobs Originalmente usado en la industria elctrica de poder para referirse a la estructura comn proveer poder; En ese entonces acostumbr en la industria de la computadora a referirse a una especificacin estndar de la interfaz. En el almacn de datos, el autobs refiere a El acoplamiento mutuo normalizado que deja centros de compras separados de datos coexistir tilmente. Los datos de la sede almacenan arquitectura del autobs.
El lifecycle dimensional comercial Una metodologa para planificar, diseando, implementando, y mantener almacenes de datos, tan descritos en La Data Warehouse Lifecycle Toolkit (Wiley, 1998). La A comercial de inteligencia (el BI) el trmino genrico para describir apalancar los activos internos y externos de informacin del organi-zation para hacer mejores decisiones comerciales. La medida comercial La funcin comercial y mtrica captada por un sistema operacional y representado como un hecho en un modelo dimensional. El proceso comercial sustentados por ah Las principales actividades operacionales o los procesos
Un sistema de la fuente, como las rdenes, del cual los datos pueden ser recolectados en ayuda lo Los propsitos analticos del almacn de datos. Escoger el proceso comercial es La primera parte de cuatro teclean pasos en el diseo de un modelo dimensional.
Byte (la B)
Unidad de medida, consistente en 8 pedacitos de datos.
El escondite En un navegador de Internet, el disco que el espacio destin para copias temporales de la tienda de Web objeta de tal manera que si son pedidos otra vez, no necesitan ser idos a traer de Internet pero pueden ser obtenidos localmente. Ms generalmente, un escondite son un espacio de almacenamiento tem porary para objetos o los datos esperaron ser usados dentro de poco. Cannibalization El crecimiento de ventas de un producto dando lugar a que lo desacelerando de ventas de otro producto. Usualmente en lo referente a dos productos hechos por el mismo fabricante. Cardinality El nmero de valores nicos para una columna dada en una mesa de relaciones. El punto bajo que el cardinality refiere para un nmero limitado de valores, referente al nmero global de filas en la mesa. El producto cartesiano Un set comprendido de todas las combinaciones posibles de restricciones mltiples.
El causal (el factor o la dimensin) Something que es considerado ser la causa de alguna otra cosa. Los factores causales en el comercio al por menor usualmente se refieren a los anuncios, los despliegues, los cupones, y las reducciones de precio. Una dimensin causal describe estos factores causales. La mesa centpeda de hecho de la A de la mesa de hecho con demasiadas dimensiones (a menudo ms que 20), la conduccin para un dibujo tcnico que se parece a un ciempis con numerosas llaves extranjeras se asoci para numerosas Tablas de dimensin. Los ciempieses tpicamente
El resultado cuando los diseadores traten de representar relaciones jerrquicas con una proliferacin de dimensiones de la separata en vez de anidado dentro de una sola dimensin. Plan contable El catlogo de cuentas usado por el libro mayor general. Un plan contable uniforme es un plan contable aplicado consistentemente a travs de una organizacin. Haga mantequilla En un servicio de suscripcin, la proporcin de clientes perdi en contra de clientes ganados. Informtico en jefe El Jefe de Informacin dentro de una organizacin. El clic y el mortero Un negocio hbrido con ambos un basado en la Web y una presencia fsicamente tangible. Contraste con Brick y mortero. Clickstream El cuerpo humano complejo de acciones tomadas de un usuario en un navegador de Internet.
El clickstream puede incluir ambos los clics reales (el navegador pide) y Las respuestas del servidor para esas peticiones. El clickstream toma la forma de El servidor de Web pone en bitcora, donde cada registro del leo del servidor de Web le corresponde a un soltero El acontecimiento de la pgina.
El Clic Efectivo La accin de lograr un localizador de recursos uniforme (el URL; La pgina de Web) dando un clic sobre un botn o un enlace, usualmente localiz en un sitio Web diferente. Columna Los datos estructuran eso contiene una informacin individual tem dentro de una fila
(El registro). El equivalente para un campo de la base de datos.
La llave compleja Teclee una mesa de la base de datos hecha de varias columnas. Tal como llave Concatenated. La llave global en una mesa tpica de hecho es un subconjunto de las llaves extranjeras en la mesa de hecho. En otras palabras, usualmente no requiere que cada clave extranjera garantice unicidad de una fila de la mesa de hecho.
La llave concatenada
Vea llave Compleja.
Las dimensiones conformadas Las dimensiones son conformadas cuando son ya sea exactamente igual (incluyendo las llaves) o uno es un subconjunto perfecto del otro. Ms importante, la fila que los encabezados produjeron en la respuesta se sedimenta de dos que differ-ent conform dimensiones debe poder ser a lo que se correspondi perfectamente. Los hechos conformados Los hechos de Tablas mltiples de hecho son conformados cuando las definiciones tcnicas de los hechos son equivalentes. Los hechos conformados estn permitido tener el mismo nombre en Tablas separadas y pueden estar combinados y comparados matemticamente. Si los hechos no se conforman, en ese entonces las interpretaciones diferentes deben recibir nombres diferentes.
El centro de compras consolidado de datos Los centros de compras de datos que combinan medidas comerciales de negocio mltiple va en procesin. Algunas veces designado uno centro de compras que se secunda a ras de datos. Contraste con centro de compras de datos de Primeros Niveles. Restriccin La frase en el lenguaje normalizado de consulta DONDE la clusula. Una restriccin es ya sea una restriccin de la juntura o una restriccin aplicativa. Continuamente preciado (los hechos) La medida numrica que usualmente es differ-ent cada vez que est medido. Las medidas continuamente preciadas deberan ser hechos en la mesa de hecho a distincin de atributos discretos que corresponden a una mesa de dimensin. Contribucin Benefciese en un negocio medido sustrayendo las concesiones, los descuentos, los costos de confeccionar, y los costos de ventas del ingreso bruto. Vea ganancias y prdidas. Cookie Un pequeo archivo del texto colocado en la PC de un usuario por un navegador de Internet en respuesta a una peticin especfica de un servidor remoto de Web. El contenido de la galleta es especificado por el servidor de Web y slo puede ser ledo de belong-ing de servidores de Web para el dominio que se especific en la galleta. Copiacartas El archivo tradicional del encabezado de COBOL que describe todas las columnas en un subyacente fichero de datos. La mesa de fondo La mesa de hecho o la dimensin pospone en una situacin heterognea del producto que est supuesta a extenderse a lo largo de todos los productos de inmediato. Contraste con Tablas de clases de negocio Aduaneras. Vea tambin productos Heterogneos. El costo bas optimizador El software en una base de datos relacional que intenta disuadir lo mo cmo tramitar la averiguacin asignando costos estimados para las alternativas diversas de consulta de tablas.
La mesa de cobertura para una promocin Una mesa de hecho, tpicamente factless, eso registra todos los productos que estn sobre una promocin en una tienda dada, sin tener en cuenta si vendi o no. Prueba de redundancia cclica redundancia. Vea suma de verificacin Cclica de
Gestor de relaciones con el cliente Vea gestor de relaciones con el cliente. La cruz vendindose La tcnica de aumentar ventas por ah vender una nueva lnea de productos para los clientes existentes. Vea tambin que vende arriba. Cubo El nombre para una estructura dimensional en una plataforma multidimensional de la base de datos de procesamiento o en lnea y analtica (OLAP), originalmente en lo referente al caso de tres dimensiones simple de producto, el mercado, y el tiempo.
La mesa de clase de negocio aduanera La mesa de hecho o la dimensin pospone en una situacin heterognea del producto que contiene hechos o atributos especficos para un set de productos, donde esos hechos o esos atributos son incompatibles con los otros sets de productos. Contraste con Tablas De Fondo. Vea tambin productos Heterogneos. El archivo maestro del cliente La lista maestra de clientes de la compaa, usualmente mantenido por el sistema operacional que tramita orden registrado. El cliente haciendo buena pareja El esfuerzo para identificar a un cliente humano individual a travs de sistemas mltiples por Social Security Number, la direccin, u otros indicadores. Gestor de relaciones con el cliente (la gestor de relaciones con el cliente) Los procesos operacionales y analticos que enfocan sobre mejor entender y reparar clientes para maximizar relaciones mutuamente propicias con cada cliente.
La suma de verificacin cclica (la prueba de redundancia cclica) de redundancia Un algoritmo que es til para check-ing dos detalles complicados, como los registros del cliente, a ver si cualquier cosa han cambiado. La prueba de redundancia cclica puede ser almacenada con un registro existente, y en ese entonces la prueba de redundancia cclica puede ser computada en un registro entrante. Si hay algunas diferencias, los CRCs sern diferentes. Esto elimina el requisito para revisar cada campo de con-stituent en el registro. La herramienta de acceso de datos Una herramienta del cliente que pone en duda, va a traer, o manipula datos almacen en una base de datos relacional, preferentemente un modelo dimensional hallado en el rea de presentacin de datos. Contraste con una herramienta que escenifica Datos. El cubo de datos Vea Cubo.
El extracto de datos El proceso de copiar datos de un sistema operacional para cargar eso en un almacn de datos. El centro de compras de datos Un subconjunto lgico y fsico del rea de presentacin del almacn de datos. Originalmente, los centros de compras de datos fueron definidos como altamente subconjuntos agregados de datos, a menudo escogidos para contestar una pregunta comercial especfica. Esta definicin fue inexplotable porque condujo a los centros de compras de datos de la tobera que fueron inflexibles y no podran ser combinados con el uno al otro. Esta primera definicin ha sido reemplazada, y el centro de compras de datos es ahora definido como un set flexible de datos, idealmente se basa en los datos ms atmicos (granular) posibles extraer de una fuente de opera-tional, y presentado en un modelo simtrico (dimensional) que es ms resiliente cundo encarado con averiguaciones inesperadas del usuario. Los centros de compras de datos pueden Sea vinculado usar tcnicas que se practican a travs cuando sus dimensiones son conformadas. Decimos que estos centros de compras de datos estn relacionados al autobs del almacn de datos. En su forma ms simplista, un centro de compras de datos representa datos de un solo proceso comercial.
Minera de datos Una clase de averiguaciones no orientadas, a menudo en contra de los datos ms atmicos, eso la bsqueda para encontrar patrones inesperados en los datos. Los resultados ms valiosos de minera de datos aglomeran, clasificar, estimar, predecir, y encontrar cosas que ocurren juntos. Hay muchas clases de herramientas que juegan un papel en la minera de datos. Las herramientas principales los incluyen rboles de decisiones, redes de nervios, memoria y cased herramientas basadas de razonamiento, herramientas de visualizacin, algoritmos genticos, lgica confusa, y estadsticas clsicas. Generalmente, el extraer de la cantera datos es un cliente del almacn de datos. El rea de presentacin de datos El lugar donde los datos del almacn son organizados, almacenados, y disponibles pues directo poniendo en duda por usuarios, los datos acceden a las herramientas, y otras aplicaciones analticas. Todo poniendo en duda toma posicin social en el rea de presen-tation de datos. Los datos en el rea de presentacin deben ser dimensionales y atmicos (y posiblemente resumido, tan apropiado) y deben pegrsele a la arquitectura del autobs del almacn de datos. Tpicamente llamado una serie de centros de compras integrados de datos. Contraste con el rea de escenificacin de Datos. La comprobacin de calidad de datos El paso durante el proceso de escenificacin de datos de produccin donde los datos son probados para la consistencia, la plenitud, y la adaptabilidad para publicar para la comunidad del usuario. El rea de escenificacin de datos Un rea de almacenamiento y un set de procesos que limpian, transforman, se combinan, deduplicate, grupo familiar, archivo, y preparan datos de la fuente para el uso en el almacn de datos. El rea que escenifica datos es todo en medio del sistema de la fuente y el servidor de presentacin de datos. No poniendo en duda debera terminar en el rea de escenificacin de datos porque el rea que escenifica datos normalmente no es establecido para manejar seguridad de grano fino, indexa o agregaciones para perfor-mance, o la integracin amplia de datos a travs de fuentes mltiples de datos. Contraste con el rea de presentacin de Datos. La herramienta de escenificacin de datos Un programa de aplicacin tpicamente residente en ambos el cliente y el servidor que ayuda en los datos de
produccin extrae transforman carga apfisis. Contraste con herramientas de acceso de datos. La tobera de datos Ocurre cuando datos estn disponibles adentro espordicas especficas en la aplicacin bases de datos, donde la inversin pequea ha sido hecha para compartir datos comunes, como cliente o producto, con otros sistemas operacionales. Unarchitected, centros de compras de datos de la tobera es desastroso como ellos que meramente el perpetu comi aislado, incompatibles puntos de vista de la organizacin. El almacn de datos La conglomeracin del almacn de datos de una organizacin escenificando y las reas de presentacin, donde los datos operacionales son especficamente struc tured para la funcin de averiguacin y de anlisis y la facilidad de uso. Vea almacn de datos de la Empresa.
Los datos almacenan arquitectura del autobs La arquitectura para el rea de presentacin del almacn de datos basado en conform dimensiones y hechos. Sin adherencia para la arquitectura del autobs, un centro de compras de datos es una aplicacin auto sostenible de la tobera. Los datos almacenan matriz del autobs La herramienta acostumbr crear, documentar, y communi-cate la arquitectura del autobs, donde las filas de la matriz identifican los procesos comerciales del organi-zation y las columnas representan las dimensiones conformadas. La interseccin de dimensiones pertinentes aplicables para cada proceso comercial est entonces marcada. El aplicacin de computadora de la A de sistema de gestin de base de datos (el sistema de gestin de base de datos) cuyo propsito exclusivo es almacenar, recuperar, y modificar datos en una forma altamente estructurada. Los datos en un sistema de gestin de base de datos usualmente son compartidos por una coleccin variada de aplicaciones. El suministro de los das (el inventario) El nmero de das el inventario actual nivel durara en el cambio oficial de ventas. Administrador de base de datos El administrador de la base de datos, una posicin de tecnologa de la informacin de mayor categora requiriendo comprensin extensiva de base de datos y los datos la tecnologa del almacn, as como tambin los usos de datos corporativos. DD Vea dimensin Degenerada. El nombre original
Sistema de apoyo para la toma de decisiones (DSS) para datos almacenando.

El almacn de datos usando datos para hacer decisiones en una organizacin. Oye Tambin la inteligencia Comercial.
En nuestra opinin, es todava el mejor nombre porque es la justificacin razonada comercial para
Descifre La descripcin textual se asoci con un mando de operacin, bandera, o indicador.
Degenere dimensin Una llave de dimensin, como un nmero de transaccin, el nmero de factura, el nmero del boleto, o el nmero de conocimiento de embarque, eso no tiene atributos y por lo tanto no se asocia para una mesa real de dimensin. El lado de demanda El flujo de procesos en un negocio comenzando con termin inventario de bienes y progresando a travs para las ventas del cliente. Contraste con el sector real. La minidimensin demogrfica Vea Minidimensiones.
Denormalize Permitiendo redundancia en una mesa a fin de que la mesa pueda permanecer plana, en vez de snowflaked o normalizado, para optimizar perfor-mance y facilidad de uso. El equivalente para Secundar clase normal (2NF). Reducciones drsticas Tal Como Embarques. Usualmente se refiere a un almacn tirando hacia abajo inventario en respuesta a las rdenes del cliente.
Dimensin Una entidad independiente en un modelo dimensional que sirve de un punto de entrada o como un mecanismo para cortar en rodajas y jugar a los dados las medidas de aditivo localiz en la mesa de hecho del modelo dimensional. La mesa de dimensin Una mesa en un modelo dimensional con unas que se singularizan en parte columnas primarias y cruciales y descriptivas de atributo. El almacn dimensional de datos El set de Tablas para soporte de decisin diseado como dibujos tcnicos unidos en estrella. El modelado dimensional Una metodologa para los datos lgicamente modeladores para la funcin de averiguacin y la facilidad de uso que empieza de un set de acontecimientos de measure-ment de base. En el ambiente de sistema de gestin de base de datos de relaciones, una mesa de hecho se construye generalmente con un registro para cada medida discreta. Esta mesa de hecho est entonces rodeada de un set de Tablas de dimensin describiendo precisamente lo que es conocido en el contexto de cada registro de medida. Por la estructura de charac-teristic de un modelo dimensional, es a menudo llamado un dibujo tcnico de la estrella. Los modelos dimensionales han resultado comprensibles, previsibles, extensibles, y altamente resistentes para el ataque ad hoc de grupos de usuarios de busi-ness por su naturaleza simtrica previsible. Los modelos dimensionales son la base de muchos realces de funcin de sistema de gestin de base de datos, acercamientos poderosos inclusivos de indexacin y agregaciones. Los modelos dimensionales son la base para el desarrollo incremental y distribuido de casas de loza de datos a travs del uso de dimensiones conformadas y los hechos conformados. Los modelos dimensionales son tambin el fundamento lgico para todos los sistemas OLAP. El servidor del directorio Un servidor, cul puede ser mirado tan un poco que los datos almacenan, que manutenciones rastrean de todos los usuarios de un sistema como bien como todos los recursos disponible en el sistema, como servidores de la base de datos, los servidores del archivo, las impresoras, y los recursos de comunicaciones. La forma del estndar de la industria a comunicar con un servidor del directorio es el Ligero Protocolo de Acceso a Directorios (LDAP).
Ensucie dimensin del cliente La dimensin del cliente en la cual la misma persona puede aparecer mltiplo cronometra, probablemente no con ortografas exactamente iguales de nombre u otros atributos. Discreto (la dimensin atribuye) Datos, usualmente textual, esas las tomas sobre una fija escala de valores, como el sabor de un producto. Los datos textuales discretos siempre deberan ser maniobrados como atributos en una mesa de dimensin a distincin de datos numricos preciados contin uously eso corresponden a una mesa de hecho. Dominio (1) Un alcance especfico de direcciones Internets asignadas a un solo usuario de la Internet. El nombre de dominio es un nombre del texto nico, a menudo cesando en .com, . (2) En una dimensin, la coleccin completa de valores legales de los cuales los valores reales estn derivativos para un atributo.
Las junturas de dos caones El paralelo mltiple se asocia entre una mesa unidimensional y una mesa de hecho. Entrnese a travs El acto de pedir datos de modo semejante etiquetados de dos o ms hecho las Tablas en un soltero reportan, casi siempre implicar averiguaciones separadas que son mancomunadas juntos en un segundo paso por encabezados que hace juego de la fila. Profundice El acto de sumar un encabezado de la fila o reemplazar un encabezado de la fila en un informe para abatir las filas de la respuesta coloc ms finamente. Entrnese arriba El acto de quitar un encabezado de la fila o reemplazar un encabezado de la fila en un informe para resumir las filas de la respuesta colocada. La agregacin algunas veces dinmica designada. DSS Vea Sistema de Apoyo para la Toma de Decisiones.
Mora cronometra La longitud de tiempo que una pgina especfica de Web est disponible para mirar en el navegador de un usuario. El ingreso devengado El ingreso que una compaa tiene permiso de reportar en un lapso de tiempo dado basado con tal que un servicio durante ese lapso de tiempo. El dinero pagado en el avance no puede ser reportado como el ingreso hasta que sea ganado. Los despliegues del pasillo de fin comestibles y tiendas de droga. Una forma de promocin en tienda de
La integracin de la aplicacin de la empresa (la Empresa para la Iniciativa de las Amricas) En un sentido general, lo reengineer-ing de sistemas operacionales de la fuente para dar consistencia de la empresa. En un sentido del producto, un set de productos que tratan de facilitar comunicacin nivelada en la transaccin entre sistemas de la fuente potencialmente operacionales incompatibles.
El almacn de datos de la empresa (EDW) La conglomeracin del almacn de datos de una organizacin escenificando y las reas de presentacin. Los otros en la industria Refirase al EDW como un estrato centralizado, atmico, y normalizado del almacn de datos, sin dar aclaraciones si tal sistema est disponible para usuario final poniendo en duda y profundice. Advertimos contra esta interpretacin del EDW, prefiriendo pensar acerca del EDW como la unin posible ms abrumadora de stag-ing y servicios de presentacin, tomado como un todo. La aplicacin de planificacin del recurso de la empresa (la tasa de proteccin efectiva) Una clase de aplicaciones en las que se puso la mira extenderse a lo largo de una cierta cantidad o todo el negocio funciona de una empresa completa. Las aplicaciones de tasa de proteccin efectiva a menudo son destacadas en bases de datos relacional, y los diccionarios de datos para estas aplicaciones pueden contener miles de Tablas. Una organizacin adquiriendo una aplicacin principal de tasa de proteccin efectiva usualmente debe suspender operacin existiendo aplicaciones del legado y debe reestructurar procesos fundamentales de busi-ness alrededor del sistema de tasa de proteccin efectiva. Los sistemas de tasa de proteccin efectiva a menudo contienen el equivalente de una tienda operacional (los desarrollos organizativos) de datos porque usualmente son
Capaz de informacin operacional de tiempo real de tiempo real o cercana, pero los sistemas de tasa de proteccin efectiva hasta que 2002 tengan, no hicieron buenos almacenes de datos porque tienen, no proveyeron funcin de averiguacin de usuario final aceptable o un ambiente flexible para importar datos de terceros. El diagrama de relacin de entidad (ERD) (ER) Los dibujos de cajas y lneas para comunicar la relacin entre Tablas. Ambos modelos tercera de forma normal (3NF) y dimensionales pueden ser representados como diagramas ER porque ambos consisten en Tablas de relaciones unidas. La diferencia crucial entre los modelos es el grado de normalizacin de dimensin. Un modelo dimensional es
Un segundo modelo normal de la forma (2NF).
El acceso igual La promesa original de bases de datos relacional: La habilidad para recuperar datos basados en cualquier criterios presenta en los datos. ETL Vea Extract-Transform-Load.
Acontecimiento Vea acontecimiento Page. Mesa de hecho de la A de la mesa que monitorea acontecimiento, frecuentemente factless, donde las dimensiones de la mesa es trada juntos para describir un acontecimiento, como una descripcin de seguro de un accidente del automvil. El ASCII extendido La extensin del Cdigo Estndar Americano para que Infor-Mation Interchange incluyan a europeo destacaron caracteres y otros personajes especiales. Esta codificacin utiliza a los personajes 128 elevados en el formato de ASCII de 8 pedacitos. Vea ASCII y UNICODE. El costo extendido El coste por unidad multiplicado por una cantidad para darle un valor aditivo. El lenguaje extensible (XML) del Apunte Un primo de HTML que provee estructur cambio de datos entre fiestas. XML contiene datos y metadatos pero ninguna informacin de formateo. Contraste con HTML. XML es un armazn flexible, fuertemente jerrquico para asignarle etiquetas a fildea dentro de un docu-ment. XML no especifica lo que las etiquetas deberan ser. Est tramando
organizaciones diversas o grupos de la industria para definir y usar sets coherentes de etiquetas, y este esfuerzo es el factor principal del gating desacelerando el uso comn de XML. El extracto transforma carga (ETL) El set de procesos por los cuales los datos operacionales de la fuente estn preparados para el almacn de datos. Los procesos primarios de la zona de estacionamiento de datos de la trastienda de los datos almacenan, antes de cualquier presen-tation o poniendo en duda. Consiste en extraer datos operacionales de una aplicacin origen, transformarla, cargar e indexar eso, calidad asegurndole a ella, y publicndola.
Hecho Una medida comercial de funcin, tpicamente numrico y aditivo, eso es almacenada en una mesa de hecho. La dimensin de hecho Una dimensin especial acostumbr identificar medidas sumamente escasas, dismiles en una sola mesa de hecho. La mesa de hecho En un dibujo tcnico de la estrella (el modelo dimensional), la mesa central con funcin numrica que las medidas caracterizaron por una llave compleja, cada uno de cuyos elementos son una llave extranjera sacada de una mesa de dimensin. La mesa de hecho Factless Una mesa de hecho que no tiene hechos pero captura cierto muchos a muchas relaciones entre la dimensin teclea. La mayora a menudo soli representar acontecimientos o proveer informacin de cobertura que no aparece en otras Tablas de hecho. Protocolo de transferencia de archivos (el FTP) El protocolo de / protocolo entre redes de protocolo de control de transmisin que sirve para trasladarse archiva entre computadoras. El filtro sobre el hecho rema Un tipo de restriccin aplicativa que constrie sobre los valores numricos de uno o ms hechos. Usado para el valor agrupndose. El centro de compras de datos de primeros niveles Un centro de compras de datos que se deriv de un solo sistema primario de la fuente. Contraste con centro de compras Consolidado de datos. La jerarqua fija de profundidad Una jerarqua altamente previsible con un nmero fijo de niveles. Contraste con jerarqua Harapienta. FK Vea llave Extranjera.
Lima plana Una estructura simple de datos, a menudo implementado en una computadora central, eso confa en archivos poco de relaciones, como archivos de mtodo de acceso a la memoria virtual de la IBM.
La llave extranjera (FK) Una columna en una mesa de la base de datos de relaciones cuyos valores son sacados de los valores de una llave primaria en otra mesa. En un dibujo tcnico de la juntura de estrella, los componentes de un hecho complejo ponen sobre una mesa llave son llaves extranjeras con relacin a cada uno de las Tablas de dimensin. Armazn El acercamiento unificador, orientador y arquitectnico, as como en la arquitectura del autobs de la casa de loza de datos. DE clusula (el lenguaje normalizado de consulta) La clusula de lenguaje normalizado de consulta que lista las Tablas requiri por la averiguacin. Libro mayor general (G/L) El libro mayor que representa los activos de la organizacin, los adeudos, la equidad, el ingreso, y el gasto. Los restos G/L se balance a travs de las operaciones que se compensan mutuamente para cuentas de debe y haber.
El geogrfico sistema de informacin (GIS) Una aplicacin hbrida combinando base de datos y trazando un mapa de tecnologa. Tpicamente, en un GIS, las averiguaciones pueden ser con-structed de mapas, y los mapas pueden ser redimidos como resultado de una averiguacin. Mil millones de bytes (el gygabyte) Un billn bytes. GIS Vea Geogrfico sistema de informacin.
GMROI El regreso vulgar del margen sobre el inventario, el igual para el nmero de vueltas de inventario multiplicado por el por ciento vulgar del margen. Una medida del regreso en cada dlar invirti dinero en inventario. Grano El significado de una sola fila en una mesa de hecho. La declaracin del grano de una mesa de hecho es el segundo de cuatro pasos cruciales en el diseo de un modelo dimensional. Granularidad Grano. El nivel de detalle captado en el almacn de datos. Vea
Hora del Meridiano de Greenwich (la hora media de Greenwich) La hora oficial local en el cero grada longitud, lo cual atraviesa de lado a lado la Londres cercana Royal Navy Observatory. El por ciento vulgar del margen porcentaje de ingreso bruto. Ganancia bruta La ganancia bruta expresada como un
El ingreso bruto menos el costo de los bienes.
Ingreso bruto El ingreso total abon a una compaa por sus clientes. Si el ingreso bruto se calcula antes de los descuentos aplicables, en ese entonces la cantidad real pagada por los clientes es llamada el ingreso neto. AGRPESE POR clusula (el lenguaje normalizado de consulta) La clusula de lenguaje normalizado de consulta que excepcionalmente lista los artculos no agregados en la lista SELECTA, es decir, todo lo que no sea una
SUMA, CONDE, MIN, LLEGUEN AL LMITE, o AVG. Interfaz Grfica del Usuario La grfica interfaz de usuario. Un estilo de interfaz de la computadora caracteriz por ventanas, iconos, el uso de grficos, y el uso de un ratn apuntando dispositivo. La mesa del ayudante Vea cuadro puente. Los productos heterogneos Un set de productos tpicamente caracterizados por muchos atributos incompatibles del producto y hechos mensurables. Un reto caracterstico del diseo en ambientes financieros de servicio. Vea mesa De Fondo y mesa de clase de negocio Aduanera. La relacin jerrquica Una relacin donde los rollos de datos arriba en niveles ms altos de resumen en una serie de estricto muchos para una relaciones.
Las jerarquas se reflejan por columnas adicionales en la mesa atmica de dimensin. Householding El esfuerzo para asignar una cuenta o un individuo a un agarre de casa de cuentas o individuos para comercializar propsitos. El lenguaje del apunte del estndar de la A de Lenguaje de Etiquetacin de Hipertexto (el HTML) para definir las caractersticas de presentacin de documentos de Web. Los datos de azogues de contra de HTML y el formateo pero no contienen metadatos. Contraste con XML. El HTML no es uno general lenguaje de programacin. El protocolo de Traslado de hipertexto (el HTTP) Las comunicaciones emiten el protocolo de Internet. El HTTP especifica la forma en la cual un navegador y un sitio Web intercambian informacin. El informe de impacto Al reportar con un cuadro puente, el factor que oprime asignado a la dimensin multipreciada est ignorado. Los totales resultantes proveen un resumen para cualquier caso en el cual la dimensin multipreciada fue compleja, sin tener en cuenta la extensin de la participacin. Contraste con informe Oprimido. La A de la matriz del autobs de implementacin la versin ms detallada de la matriz del autobs del almacn de datos donde las Tablas de hecho son identificadas para cada proceso comercial, as como tambin la granularidad de la mesa de hecho y las medidas. El ndice Una estructura de datos se asoci con una mesa que es lgicamente ordenada por los valores de una llave y usado para mejorar funcin de la base de datos y poner en duda velocidad de acceso. Los ndices de B-Tree sirven para campos de high-cardinality, y los ndices bitmap sirven para campos del cardinality mediano y bajo. La Internet La coleccin mundial de enlaces de comunicacin y los servicios que son vinculados usando el Protocolo Internet (el protocolo entre redes).
Proveedor de servicio de Internet (el ISP) Una compaa u organizacin que le provee la conectividad de la Internet al pblico a travs del uso de lneas telefnicas, cablegrafe, o los satlites. Los ISPs a menudo ofrecen un alcance de servicios, como correo electrnico, hospedaje de pginas Web, y acceso aplicativo, y le proveen la conectividad a computadora personal del cliente usando protocolos de / protocolo entre redes de protocolo de control de transmisin. DIRECCIN IP La direccin numrica de un anfitrin particular o la subred de comunicacin en la Internet. nasele a la restriccin (el lenguaje normalizado de consulta) La porcin del lenguaje normalizado de consulta DONDE la clusula que las manutenciones de libro las relaciones de la juntura entre el hecho posponen y que la dimensin pospone.
Grupo Unido de Expertos en Fotografa, formato de compresin de imagen JPG An estndar por el Grupo grfico en la foto Unido de Expertos. Es en particular adecuado complicar imgenes como fotos. Una imagen de Grupo Unido de Expertos en Fotografa puede estar ajustada para ofrecer compresin alta con prdida resultante de calidad de imagen o compresin baja con calidad alta de imagen. El nmero juliano de da Una representacin de una fecha del calendario como la cuenta simple de das desde principio de una poca, como el 1 de enero de 1900. El cierto Juliano que los dtiles son numeradas en los millones y no es usado a menudo como la base literal de valores de fecha. La dimensin de trastos viejos An abstraiga dimensin con lo descifra para un grupo de banderas de low-cardinality e indicadores, por consiguiente removiendo las banderas de la mesa de hecho. LDAP El Protocolo de Acceso a Directorios ligero, un estndar actualmente al que se accedi por la mayor parte de los vendedores principales de sistemas para describir a los usuarios de un trabajo neto y los recursos disponibles en una red. Vea servidor del Directorio. Adeudo Un artculo que aparece en el balance de situacin de una compaa que representa dinero que la compaa le debe a alguien ms. Los depsitos bancarios son adeudos de punto de vista de un banco porque deben ser reembolsados. El alza de una promocin El incremento de ventas sobre el valor de la lnea de fondo que puede ser atribuido a los efectos de una promocin. La lnea del individuo de rubro contable An de un documento de control como un usu-ally de la factura identificando un solo producto dentro de la factura. La mayora a menudo usada como el grano de la mesa asociada de hecho. El diseo lgico La fase de un diseo de la base de datos concernido con identificar las relaciones entre los elementos de datos. Contraste con diseo Fsico.
La fiesta de prdida (el seguro) que Cualquier individuo o entidad asociaron con un reclamo (una prdida), las partes agraviadas inclusivas, los testigos, los abogados, y otros pases proveedores de servicios. El atributo de low-cardinality colocado Un set de atributos que tienen un cardi-nality muy bajo referente al nmero de filas en la dimensin de base, como datos demogrficos externos para un set de clientes. Puede ser manipulado como un arbotante de dimensin. Vea tambin a Cardinality. Muchos para muchos la A de relacin la relacin de datos lgicos en la cual el valor de un elemento de datos puede existir en combinacin con muchos valores de otro elemento de datos, y viceversa. Muchos para una relacin Vea relacin de One-To-Many.
Las dimensiones de muchos valores Normalmente, una mesa de hecho posee slo a connec tions para las dimensiones representando un solo valor, como un solo tiempo o un solo producto. Pero ocasionalmente, es vlida conectar un registro de la mesa de hecho para una dimensin representando un nmero indefinido de valores, como el nmero de simultneo diagnostica un paciente puede tener al momento de un solo tratamiento. En este caso decimos que la mesa de hecho tiene una dimensin de muchos valores. Tambin las llamadas dimensiones Multivalued. Tpicamente maniobrado utilizador un cuadro puente. El anlisis de la canasta de mercado Un tipo de anlisis en ambientes por menor que trata de comprender todos los productos compr por un cliente en un solo acontecimiento de sonido corto y metlico de tienda. El anlisis de la canasta de mercado es un ejemplo de afinidad agrupando eso trata de encontrar cosas que ocurren juntos. Comercialice crecimiento Un resultado deseable de una promocin que causa que las ventas globales de una categora del producto aumenten en lugar de cannibalizacin causante. Mster en Administracin de Empresas Maestro en Administracin de Empresas, una universidad graduada o una universidad grada requerir comprensin extensiva de qu tan comercial los negocios son organizados y manejados.
La jerarqua de la mercanca Un set de atributos en la dimensin del producto eso defina uno ascendiente muchos para una relacin. Comn para todo manufactur-ing y ambientes por menor. Los datos Meta Cualquier datos sostuvieron que para soportar las operaciones o el uso de un almacn de datos, similares para una enciclopedia para el almacn de datos. Casi todos los datos escenificando y las herramientas de acceso requieren algunos metadatos privados en forma de las especificaciones o el estatus. Hay pocos estndares coherentes para metadatos mirados en un sentido ms amplio. Distinguido de la informacin primaria en la dimensin y Tablas de hecho.
Emigre Moviendo los datos de una computadora a otro o de un formato del archivo a otro. Minidimensions Los subconjuntos de una dimensin grande, como cliente, eso son suspendidos de pronto en dimensiones separadas, ms pequeas y artificiales para controlar el crecimiento de explo-sive de una dimensin grande, rpidamente cambiante. Los atributos continuamente demogrficos cambiantes de un cliente son a menudo modelados como una minidimensin separada. La reflejada base de datos Una organizacin fsica de datos donde la entera base de datos es duplicada en separadas unidades de disco. Las reflejadas bases de datos ofrecen un nmero de funcin y ventajas administrativas.
Modelando aplicaciones Un cliente sofisticado del almacn de datos con capacidades analticas que transforman o entienden la salida del almacn de datos. Las aplicaciones modeladoras incluyen a pronosticar modelos, mod-els de reprimenda de comportamiento que el grupo y clasifican comportamiento de compra del cliente o comportamiento de crdito del cliente, los modelos de asignacin que toman cuestan datos del almacn de datos y propagan los costos a travs de agrupamientos del producto o agrupamientos del cliente, y la mayora de herramientas de minera de datos. El indicador ms reciente Un atributo, tpicamente usado
Escriba 2 dimensiones lentamente cambiantes, eso indica el perfil ms actual.
La multidimensional base de datos La base de datos en la cual los datos se replantean en cubos de datos, a distincin de Tablas en una plataforma de la base de datos de relaciones. OLAP multidimensional (MOLAP) Las implementaciones analticas de procesamiento en lnea dedicadas no el dependiente en bases de datos relacional. Aunque Los sistemas MOLAP no escalan para los tamaos que los sistemas de bases de datos relacional pueden, tpicamente ofrecen mejor funcin y herramientas ms apretadamente integradas que sus contrapartes de relaciones. El lenguaje normalizado de consulta Multipass La capacidad de averiguacin sustentada por algn acceso de datos labra adentro que los resultados de averiguaciones del dibujo tcnico de estrella de la separata son columna combinada por columna por las dimensiones conformadas. No la misma cosa como una unin, cul es una fila por combinacin de la fila de averiguaciones de la separata. Multitable nasele a la averiguacin Uno de los dos tipos de caracterstica de averiguaciones en un ambiente del almacn de datos. Implica la anexin de uno o ms Tablas de dimen-sion para una sola mesa de hecho. Contraste con averiguaciones de Vistazo. Las dimensiones Multivalued Vea dimensiones de muchos valores.
La llave natural El identificador usado por los sistemas operacionales. La nota natural que las llaves a menudo tienen empotr significado. Pueden aparecer como atributos de dimensin en los modelos dimensionales pero no deberan servir de la mesa de dimensin llave primaria, lo cual siempre debera ser una llave vicaria. Nonadditive (los hechos) filas. Un hecho que lgicamente no puede agregarse entre
Puede ser numrico y por consiguiente usualmente debe estar combinado en una computacin Con otros hechos antes de agregarse a travs de filas. Si la lata poco numrica, slo Est usado en las restricciones, las cuentas, o los agrupamientos.
Normalice Una tcnica lgica de modelado que elimina redundancia de datos separando los datos en muchas entidades discretas, cada uno del cual se convierte en una mesa en un sistema de gestin de base de datos de relaciones.
Nulo Un campo de dato o registro para el cual ningn valor existe. Evitamos que llaves nulas en la mesa de hecho asignando una dimensin llave vicaria identifiquen No Se Aplica, para Estar Resuelto, u otras condiciones Huecas . Desarrollos organizativos Vea tienda Operacional de datos.
Fuera de las concesiones de la factura Tpicamente el trato o las sustracciones relatadas en promocin de la lista le pone precio a mostrado en la factura. La parte de derivar el importe de factura de la red, cul es lo que se supone que el cliente paga sobre este rubro contable. Fuera de los descuentos de la factura Las sustracciones tpicamente relatadas en condiciones financieras de la lista le ponen precio a mostradas en la factura. La parte de derivar el importe de factura de la red, cul es lo que se supone que el cliente paga sobre este rubro contable. Un para muchas relacin
El elemento de datos, pero no viceversa.
Una relacin lgica de datos en la cual el valor
De un elemento de datos puede existir en combinacin con muchos valores de otro
El procesamiento analtico en lnea (OLAP) OLAP es un set holgadamente definido de princi-ples eso provee un armazn dimensional para soporte de decisin. El trmino que OLAP tambin est acostumbrado a definir a una confederacin de vendedores que la oferta los productos de la base de datos poco de relaciones, multidimensionales pusieron la mira en soporte de decisin. Contraste con proceso de transacciones En Lnea. El proceso de transacciones en lnea (OLTP) La descripcin original para todas las actividades y sistemas se asoci con entrar en datos de fuente fidedigna en una base de datos. La mayora frecuentemente usada con referencia a bases de datos relacional, aunque OLTP puede ser usada genricamente para describir cualquier envi-ronment de proceso de transacciones. Contraste con procesamiento analtico En Lnea.
La tienda operacional (los desarrollos organizativos) de datos Un reconocimiento mdico establecido de Tablas sentndose entre los sistemas operacionales y el almacn de datos o una particin especialmente caliente administrada del almacn de datos mismo. El principal motivo para un ODS es proveer informacin inmediata de resultados operacionales si ni el sistema de opera-tional ni el almacn normal de datos puede proveer acceso satisfactorio. Porque un ODS es necesariamente un extracto de los datos operacionales,
Tambin puede desempear el papel de fuente para el almacn de datos.
El sistema operacional registrado Un sistema operacional para captar datos acerca de las operaciones de una compaa y un negocio tramita. Necesariamente no puede ser un sistema de transaccin o un sistema de relaciones. HAGA EL PEDIDO POR clusula (el lenguaje normalizado de consulta) Clusula de lenguaje normalizado de consulta que determina el ordenamiento de filas en la respuesta se sediment.
La A de la mesa del arbotante que la mesa secundaria de dimensin adjunt a una mesa de dimensin. Una mesa del arbotante es una interpretacin fsica del diseo de una sola mesa lgica de dimensin. Ocurre cuando una mesa de dimensin es snowflaked. La P y L Vea dibujo tcnico de Ganancias Y Prdidas.
Mande a llamar (1) Una pgina de Web es un documento en formato de HTML que se exhibi por un navegador. La pgina de trmino tambin se usa para describir un documento compuesto consistente en el documento HTML mismo y los objetos auxiliares como las imgenes o suena eso es de lo que se hizo un download para el navegador tan dirigido por el HTML de la pgina. La unidad (2) Bsica de datos almacenados. El acontecimiento Page Se refiere a una pgina de Web o el marco hizo un download de un servidor de Web para un navegador, exclusivo de cualquier contenido auxiliar. La base de datos de nio en padre La organizacin jerrquica de datos tpicamente requiriendo un encabezado y un set de rubros contables. La va de entrada dimensional de modelado despoja toda la informacin del encabezado (el padre) en dimensiones separadas y deja la llave original de nota natural del padre como una dimensin degenerada. Anlisis gramatical Pudriendo campos operacionales, como un nombre o direccin, en partes elementales estndar. Las Tablas subdivididas Las Tablas (y sus indices asociados) que son administradas tan fsicamente ponga aparte Tablas pero aparezca lgicamente como una sola mesa. Las Tablas grandes de hecho son candidatas para dividir en partes, a menudo por la fecha. La particin de discos puede mejorar la averiguacin y funcin de mantenimiento. La particin de discos de historia La correspondencia natural entre las entradas de la mesa de dimensin y el hecho ponen sobre una mesa filas cuando un tipo 2 lentamente cambiando dimensin ha sido implementado. Un tipo 2 lentamente
cambiando dimensin divide en partes a su conservador porque cada valor de su llave vicaria es administrado correctamente para conectarse al intervalo contemporneo correcto de registros de hecho. La mesa peridica de hecho de la foto Un tipo de mesa de hecho que representa funcin comercial al final de cada normal, previsible lapso de tiempo. Las fotos diarias y mensualmente las fotos son comunes. Las fotos son requeridas adentro Un nmero de negocios, como seguro, dnde la historia de transaccin es demasiado complicado para ser utilizado como la base para computar fotos al vuelo. Un registro separado est colocado en una mesa peridica de hecho de la foto cada perodo sin tener en cuenta ya sea cualquier actividad ha tenido lugar en la cuenta subyacente. Contraste con foto de Transaccin de hecho de la mesa y de Atesoramiento
La mesa de hecho.
El diseo fsico La fase de un diseo de la base de datos siguiendo el diseo lgico que identifica la real base de datos pospone y las estructuras del ndice acostumbraron implementar el diseo lgico. PK Vea llave Primaria.
El sistema de punto de venta (el punto de venta) El dinero en efectivo registra y computadoras en reserva asociadas en un ambiente por menor. Portal Un sitio Web diseado para ser el primer punto de entrada para visitas para Internet. Los sitios del portal usualmente presentan una variedad ancha de las capacidades de contenido y de bsqueda para tentar a las visitas a usarlos. Los portales son a menudo seleccionados como navegador a casa pginas. Price apunte anlisis La anomala de ventas del producto por cada precio discreto de transaccin. Requiere que una mesa de hecho con grano aceptable represente cada punto de precio separadamente. La llave primaria (PK) Una columna en una mesa de la base de datos que es excepcionalmente diferente para cada fila en la mesa. El archivo maestro del producto La lista maestra de productos de una compaa, usualmente de azogue principal por una manufactura o la compra ordena aplicacin operacional. El dibujo tcnico de ganancias y prdidas (P y L) La P y L, tambin conocido como un estado de prdidas y ganancias, es el ordenamiento lgico clsico de ingresos y los costos para representar un progres-sion de ingresos brutos hasta una ltima lnea que representa ganancia neta. El dibujo tcnico de rentabilidad a menudo es llamado el dibujo tcnico ms dimensional energtico porque deja el negocio renta de la rebanada y de dados, costado, y la ganancia por sus dimensiones primarias, como cliente y producto. Promocin Un acontecimiento, usualmente planificado comercializando, eso presenta uno o ms artculos causales como anuncios, despliegues, o reducciones de precio. Tambin el pensamiento de como un trato o algunas veces
como un contrato. Apoderado An alterne servidor de Web que se origina de una peticin de la pgina de Web para reducir la carga en un servidor primario de Web o red. Pseudotransaction Un paso necesitado en algunos sistemas del extracto de datos de produccin donde un sistema legado poco transaccional es analizado para ver qu cambi del extracto previo. Estos cambios son entonces convertidos en transacciones artificiales (seudo) para ser cargados en los datos almacenan. Publicando los datos correctos La forma ms sucinta para describir la responsabilidad global del almacn de datos. Los datos son correctos si satisface lo
Los requisitos del negocio. El acto de publicar es conducido finalmente por las necesidades del usuario comercial. El efecto de interfaz de usuario de la A de la lista fcilmente bajable en una herramienta de acceso de datos que exhibe una lista de opciones para el usuario. Las listas ms fcilmente bajables interesantes en un almacn de datos provienen de averiguaciones de vistazo sobre un atributo de dimensin. La averiguacin La peticin del usuario para informacin almacenada en un almacn de datos. Con un sistema de gestin de base de datos de relaciones, la averiguacin es un lenguaje normalizado de consulta que la declaracin SELECTA pas de la aplicacin de acceso de datos (tpicamente en la mquina del cliente del usuario final). La jerarqua harapienta Una jerarqua con una estructura desequilibrada y arbitrariamente profunda que usualmente se describi en el avance de cargar los datos. Algunas veces llamado una jerarqua de profundidad de variable. Los organigramas a menudo son jerarquas harapientas. Vea cuadro puente. Las particiones autnticas de tiempo Un set fsicamente separado y especialmente administrado de Tablas, con la excepcin de los datos convencionales almacena, a soportar ms requisitos de acceso de tiempo real. Vea tambin tienda Operacional de datos. El cdigo de razn Un campo usado en conjuncin con una dimensin de transaccin a describir por qu tuvo lugar la transaccin. Razono que los cdigos son de valor para los regresos y las cancelaciones y para describir por qu algo cambi. Redundancia Almacenando ms que una ocurrencia de los datos.
La integridad de referencia (Rhode Island) La condicin obligatoria en un almacn de datos donde todas las llaves en las Tablas de hecho son las llaves extranjeras legtimas referente a la dimensin pospone. En otras palabras, todos los componentes de la llave de hecho son subconjuntos de las llaves primarias encontradas en la dimensin posponen en todo momento.
Referencia La identidad del contexto previo de un URL. En otras palabras, si usted da un clic sobre un enlace en A de la pgina y serpentea arriba en B de la pgina, las sedes del servidor de Web de la B de la pgina paginan Uno como la referencia. Los monaguillos de Web pueden poner en bitcora referencias automticamente, lo cual es una forma muy til para ver por qu una visita vino a su sitio Web. El sistema de gestin de base de datos de relaciones (RDBMS) El sistema de gestin de base de datos basado en el modelo de relaciones que soporta el alcance completo de lenguaje normalizado de consulta de stan-dard. Usa una serie de Tablas unidas con filas y columnas para organizar y almacenar datos. Rhode Island Vea integridad De Referencia. Rendimiento de la inversin Rendimiento del capital invertido, usualmente expresado como una tasa describiendo el crecimiento de una inversin durante su duracin de una vida.
Las dimensiones de caracterizaciones de papeles La situacin donde una sola mesa fsica de dimensin aparezca varias veces en una sola mesa de hecho. Cada uno de los papeles de dimensin son representados como una mesa lgica separada con nombres nicos de la columna a travs de puntos de vista. Movimiento hacia arriba Taladro Arriba. Reme Para presentar niveles ms altos de resumen. Vea
Un registro en una mesa de relaciones.
El encabezado de la fila Los componentes poco agregados del lenguaje normalizado de consulta seleccionan lista. Siempre listado en el grupo de lenguaje normalizado de consulta por clusula. Factura de venta venta.
Vendido.
El documento operacional de control que describe una
Usualmente contiene rubros contables mltiples que cada uno representa un producto separado
Dimensionalidad SCD
La habilidad para acomodar requisitos futuros de crecimiento.
Vea Lentamente cambiando dimensiones.
Dibujo tcnico El diseo lgico o fsico de un set de base de datos pospone, indicar la relacin entre las Tablas. Que se el secunda a ras centro de comprasLa sede Consolid centro de compras de datos. HAGA UNA SELECCIN BIEN DEFINIDO (SQL) La declaracin de lenguaje normalizado de consulta que suprime duplicado rema en el set de respuesta. SELECCIONE Lista de la lista (el lenguaje normalizado de consulta) de especificaciones de la columna que sigue a SELECT y llega antes DE en una averiguacin de lenguaje normalizado de consulta. Cada detalle en la lista selecta
genera una columna en el set de respuesta. El estrato semntico An interconecte estrato colocado entre el usuario y la estructura fsica de la base de datos. Semiadditive (el hecho) El hecho numrico que puede agregarse a lo largo de algunas dimensiones en una mesa de hecho pero no otros. Los niveles de inventario y los balances no pueden ser Aadido a lo largo de la dimensin de tiempo pero puede ser promediado tilmente sobre la dimensin de tiempo. Sesin La coleccin de acciones tomadas de una visita del sitio Web al visitar el sitio Web fuera dejarlo. Tambin designado una visita. Los despliegues del estante Etiquetas, perchas, promocionales usadas en un ambiente por menor. u otras mecanismos
Unidad de control de inventarios
Vea unidad de control de inventarios.
La habilidad de rebanada y de dados para acceder a un almacn de datos a travs de cualquier de su dimen-sions igualmente. Cortar en rodajas y jugar a los dados es el proceso de separarse y combinar datos del almacn en combinaciones aparentemente interminables. Lentamente cambiando dimensiones (SCD) La tendencia de dimensin rema para cambiar gradualmente u ocasionalmente con el paso del tiempo. Un tipo 1 SCD es una dimensin a cuyos atributos est sobre-escrita cuando el valor de un atributo cambia. Un tipo 2 SCD es una dimensin donde una fila nueva es creada cuando el valor de un atributo cambia. Un tipo 3 SCD es una dimensin donde una columna vieja alterna es creada cuando un atributo cambia. Foto Vea ya sea mesa de hecho de la foto de Atesoramiento o Periodic le toma instantneas a la mesa de hecho. Copo de nieve Una dimensin normalizada donde una dimensin plana de la mesa, sola est descompuesta en una estructura del rbol con potencialmente muchos niveles de anidamiento. En el modelado dimensional, el hecho pone sobre una mesa en ambos un copo de nieve y el dibujo tcnico de la estrella sera idntico, pero las dimensiones en un copo de nieve se replantean en tercera forma normal, usualmente so capa de ahorros del espacio y mantienen habilidad. Aunque el snowflaking puede ser apreciado como una floritura para el modelo dimensional, snowflaking generalmente compromete al usuario comprende habilidad y haciendo una lectura ligera la funcin. Los ahorros del espacio tpicamente son insignificantes referente al tamao global de los datos almacena. Las Tablas normalizadas Snowflaked de dimensin pueden existir en la zona de estacionamiento para facilitar mantenimiento de dimensin. El tipo Para poner en secuencia datos segn criterios llamados.
El sistema de la fuente Un sistema operacional de registro cuya funcin es captar las transacciones u otra mtrica de funcin de procesos de un negocio. Alternativamente, el sistema de la fuente puede ser externo para el organiza-tion pero todava captura informacin que se necesita en el almacn de datos.
Escaso Una mesa de hecho que tiene relativamente pocos de todas las combinaciones posibles de valores de la llave. Una base de datos de movimiento del producto de la tienda de comestibles es considerada escasa porque slo 5 para 10 por ciento de todas las combinaciones cruciales para producto, tienda, y el da ser presente. La base de datos del aviador frecuente de una aerolnea es sumamente escasa porque muy pocos del cliente, nmero de vuelo, y las combinaciones de da en verdad aparecen en la base de datos. El fracaso Sparsity Una situacin que ocurre cuando una mesa del agregado es creada que no es sensiblemente ms pequea que la mesa en la cual se basa. Para
Instancia, si slo una unidad de control de inventarios en cada marca est muy convencida a favor de un da dado, entonces un agregado de marca por un da ser del mismo tamao como la mesa baja. Lenguaje normalizado de consulta Lenguaje de solicitud lenguaje estndar para acceder a bases de datos relacional. estructurado, el
Star una dibujo tcnico La representacin genrica de un modelo dimensional en una base de datos relacional en la cual una mesa de hecho con una llave compleja es adjuntada a un nmero de dimensin pospone, cada uno con una sola llave primaria. El dibujo tcnico Star Vea a Star unir dibujo tcnico.
Unidad de control de inventarios (la unidad de control de inventarios) Un trmino estndar en confeccionar y los ambientes por menor para describir un producto individual. Subrogacin El acto de una compaa de seguros vendiendo las derechas quedndose en un reclamo, como la facultad procesal alguien para daos. Sector real La parte de la cadena de valor en una compaa manufacturera que comienza con rdenes de compra para ingredientes y parte y termina con bienes de fin-ished hacen inventario. Fsicamente, el sector real es la operacin manufacturera. Contraste con lado de Demanda. Subrogue llave Las llaves de entero que estn secuencialmente asignadas segn se necesite en la zona de estacionamiento para poblar una mesa de dimensin y la juntura para la mesa de hecho. En la mesa de dimensin, la llave vicaria es la llave primaria. En la mesa de hecho, la llave vicaria es una llave extranjera para una dimensin especfica y puede ser de la llave primaria de la mesa de hecho, aunque esto no es requerido. Una llave vicaria usualmente no puede ser interpretada por s mismo. Es decir, no es una llave bonita de cualquier modo. Las llaves vicarias son requeridas en muchas situaciones de la casa de loza de datos para manipular lentamente cambiando dimensiones, as como tambin atinando mal o datos inaplicables. Tambin conocido como llaves artificiales, el entero teclea, llaves sin
sentido, llaves de poco nota natural, y llaves sintticas. Los proveedores sindicados de datos Las compaas que coleccionan datos, limpio eso, el paquete eso, y lo revende. a.c. Nielsen e IRI son el suppli-ers sindicado principal de datos pues la tienda de comestibles y la droga almacenan datos del escner, e IMS Health y Tecnologa de la Informacin de la Fuente (Walsh Amrica) son el jefe sindic proveedores de datos
Para datos farmacuticos.
Mesa campos). Para llevar
La coleccin de filas (los registros) que tienen asoci columnas (los
El consumidor compra.
TCP/IP El protocolo de protocolo de control de transmisin, el protocolo de commu-nication bsico de la Internet, consistente en un estrato de transporte (el protocolo entre redes) y un estrato aplicativo (el protocolo de control de transmisin).
La inconsistencia temporal La tendencia de una base de datos OLTP para cambiar sus relaciones primarias de datos desde momento hasta el momento como transacciones es tramitada. Esta inconsistencia tiene un impacto en usuarios en dos formas primarias: (1) la base de datos cambia constantemente como la ponen en duda a ella, y (2) la vieja historia no est necesariamente conservada. La temporal reduccin de precio (TPR) La tcnica promocional en ambientes por menor. Terabyte (la tuberculosis) Bytes de un trilln (1012). Dimensione atributos que son en verdad
Textual (la dimensin atribuye) del texto o se comportan como texto.
La tercera forma normal (3NF) El acercamiento del diseo de la base de datos que elimina redun-dancy y por consiguiente facilita insercin de filas nuevas en Tablas en uno La aplicacin OLTP sin introducir datos excesivos trabando problemas. Algunas veces referido para tan normalizado. 3NF Vea Tercera forma normal.
Cronometre cambiar de posicin de una promocin La tendencia de algunas promociones para causar al cliente para diferir compras hasta la promocin no tiene lugar y entonces no marca compra despus de la promocin para un perodo prolongado. En los casos ms serios, la promocin no logra nada excepto para dejar al cliente comprar barato productos. Cronometre golpear el suelo con los pies Etiquetando cada registro con el tiempo los datos fue procesado o se guard. Topologa sistema. TPR La organizacin de dispositivos fsicos y las conexiones en un
Vea Temporal reduccin de precio.
Transaccin La indivisible unidad de trabajo. Un sistema de proceso de transacciones o realiza una transaccin entera o eso no realiza ninguna parte de la transaccin. La mesa de hecho de transaccin El tipo de mesa de hecho en la cual la granularidad de la mesa del hecho es una fila para el nivel mnimo de detalle captado por una transaccin. Un registro en una mesa de hecho de transaccin es presente slo si un acontecimiento de transaccin en verdad ocurre. Contraste con mesa Peridica de hecho de la foto y mesa de hecho de la foto de Atesoramiento. Transbordos Los embarques de producto que ocurren entre los almacenes pertenecindole al fabricante o detallista.
Tendiendo serie temporal.
Analizando datos representando ocurrencias mltiples en una
Se vuelve (el inventario) El nmero de por en un perodo dado (usualmente un ao) que el inventario debe ser completamente reabastecido para continuar con la tasa obedecida de ventas. 24/7 La disponibilidad operacional 24 horas un da, 7 das a la semana.
Brillando intermitentemente base de datos La tendencia de una de proceso de transacciones base de datos a constantemente cambiar los datos el usuario trata de poner en duda. Tipo 1 Una tcnica de dimensin (SCD) lentamente cambiante donde al atributo cambiado le es sobre-escrita. Tipo 2 Una tcnica de dimensin (SCD) lentamente cambiante donde un registro nuevo de dimen-sion con una llave vicaria nueva se le crea reflejar el cambio. Tipo 3 Una tcnica de dimensin (SCD) lentamente cambiante donde una columna nueva se suma a la mesa de dimensin para captar el cambio.
UNICODE El UNICODE en todo el mundo estndar de carcter es un sistema de codificacin de carcter diseado para soportar el intercambio, yendo en procesin, y dis-play de los textos escritos de los lenguajes diversos del mundo moderno, incluyendo hebreo japons, chino, rabe,, cirlico, y muchos otros. Adems, soporta textos clsicos e histricos de muchos lan-guages escrito. UNICODE es una implementacin de 16 pedacitos, lo cual quiere decir que 65,535 personajes pueden ser ASCII soportado, diferente, lo cual puede mantener slo 127, o ASCII extendido, lo cual mantiene 255. Liberacin 2.1, la liberacin actual
De UNICODE, define 38,887 de los carcteres posibles.
Cdigo universal de productos (el cdigo universal de productos)
El
bar
estndar codific valor encontrado en la mayora de tienda de comestibles y la mercanca de la tienda de droga. El recurso universal Locator (el URL) La direccin del texto de un objeto especfico en la Red Mundial. Usualmente consiste en tres partes: Un prefijo describiendo el protocolo de protocolo de control de transmisin a soler recuperar eso (por ejemplo, el HTTP), un nombre de dominio (por ejemplo, webcom.com), y un nombre del documento (por ejemplo, el ndice. html). Tal URL sera formateado como http://wwindex.html Cdigo universal de productos Vea cdigo universal de productos.
Que vende arriba Vendiendo un producto o servicio para un cliente existente, donde la meta es obligar al cliente a comprar una versin de valor ms cara o ms alto que previamente comprado. Vea Cruz vendindose.
URL
Vea localizador Universal del recurso.
Aprecie agruparse (los hechos) Agrupar hechos en el valor flexible se agrupa tan especificado en una mesa de definicin de la banda. La cadena de valor La secuencia de procesos que describen el movimiento de productos o los servicios a travs de una tubera de creacin original para las ventas finales. El crculo de valor En algunas organizaciones, la secuencia de acontecimientos o procesos ms de cerca se parece a un crculo, en vez de una cadena, centrado en datos de fondo, como el registro paciente de tratamiento en la asistencia mdica para la salud. La jerarqua de profundidad variable Vea jerarqua Harapienta.
El atributo de anchura variable colocado La situacin donde un nmero variado de dimen-sion atribuyen es sabida, a merced de la duracin de la relacin, como el caso con prospectos que evolucionan en clientes. LA VISTA (SQL) La declaracin de lenguaje normalizado de consulta que crea copias lgicas de una mesa o una averiguacin de com-plete que puede ser usada separadamente en una declaracin SELECTA. Los puntos de vista son semnticamente independientes, as es que los papeles separados de una dimensin usualmente son implementados como puntos de vista. El territorio virgen La porcin de almacenamiento en disco que est desocupado antes de una carga de datos. En una esttica base de datos no experimentando insertos o actualizaciones en su sitio y con una orden primaria de tipo con el tiempo como el trmino principal en el tipo, todas las tomas de carga de datos colocan en territorio virgen. Web Ponga en cortocircuito por nada del mundo Web Ancha, la coleccin de servidores y navegadores que hablan mutuamente usando el protocolo de HTTP. Webhouse El almacn de datos evolucion para una forma nueva por la
existencia de Internet. Sitio Web Un monaguillo de Web, o la coleccin de servidores de Web, eso se aparece ante usuarios como una entidad integrada con un sistema bien definido de hiper-enlaces estando conectado
Sus componentes.
El informe oprimido Al usar un cuadro puente, los hechos en la mesa de hecho estn multiplicado por el cuadro puente oprimiendo factor para apropiadamente asignarle los hechos a la dimensin multipreciada. Contraste con informe de Impacto. XML Vea Lenguaje Extensible del Apunte.
X IND E
A Contabilidad, 173186 aproximadamente, 173 Presupuestando estudio de casos de proceso, 180185, 174
Los datos generales del libro mayor, 175180 OLAP, 185186 Las soluciones analticas empacadas, 185186 La dimensin del estado de cuenta, financiero Servicios, 203 Acumulando Tablas de hecho de la foto, 134135. Vea tambin peridico Las Tablas de hecho de la foto; Transaccin Las Tablas de hecho del grano Acumulando foto para Las admisiones rastreando, 244246 Acumulando foto para la orden La tubera de cumplimiento Los clculos de atraso, 130 Las mltiples unidades de medida, 130132 La gerencia de orden, 128132 La mtrica de espejo retrovisor, 132 Acumulando hecho del grano de la foto Tablas, 18 Acumulando tiempo real de la foto La particin, 138139 La corriente alterna Nielsen, 16 Adamson, Chris, 183 El aditivo (los hechos), 17 La complacencia aditiva, 188
Ocpese de anlisis gramatical, gestor de relaciones con el cliente, 147150 La afinidad agrupndose. Vea anlisis de la canasta de mercado La mesa de hecho del clickstream del agregado, 298 agreg hechos como los atributos,
CRM, 152 Los navegantes del agregado, 390 Agregados, 390 La loza de agregacin de estrategia, de datos
La casa construyendo, 356357 La aerolnea el estudio de casos frecuente del aviador Las granularidades mltiples de la mesa de hecho, 230232 Transporte, 230234 Algoritmos, 390 Alias (el lenguaje normalizado de consulta), 390 El inventario ubicado, 390 Dotaciones, 390 Los hechos del encabezado para aplicarle delineador tem, 121 122 Concesin, 390 Alterne realidad, 101 Alternativa (o complementario) La poltica acumulando foto, Seguro, 315 AOL, 285 La aplicacin analtica, 390 Desarrollo, 338 Desarrollo, lifecycle analtico Las aplicaciones rastrean, 363364 Especificacin, lifecycle analtico Las aplicaciones rastrean, 362364 La analtica gestor de relaciones con el cliente, 143145 El procesamiento analtico, 390
419
El dilema de / investigacin de operaciones de operador booleano AND, 195 visitas annimas de Web, 284 El ANSI, 390 el set de respuesta, 391 La restriccin aplicativa (el lenguaje normalizado de consulta), 391 la integracin aplicativa, la loza de datos Alojando tendencias culturales, 386 aplicativos pases proveedores de servicios
(Los spides), 386387 Los centros de compras de datos del architected. Vea datos La arquitectura del autobs del almacn Los requisitos arquitectnicos, datos Zona de estacionamiento, 8 Las llaves artificiales. Veo que el substituto teclea ASCII, 391 Activo, 391 Las Tablas asociativas, 163. Vea tambin Cuadros puentes Atkinson, Toby, 150 Los datos atmicos, 2223, 391 El modelado dimensional, 12 Las jerarquas de atributo, la orden Transacciones, 111 Atributos, 20, 391 La dimensin de auditora, 391 Servicios financieros, 202 Administracin de recursos humanos, 193194 Las transacciones de la pliza de seguros, 314 Autenticacin, 391 El rezago de trabajo promedio de orden, 391
Respaldos, 382 Poniendo en el banco estudio de casos, 20 Las ventas de la lnea de fondo (de una promocin), 392 La puntuacin de comportamiento, 392 El grupo de estudio de comportamiento, 160, 392 El BI. la inteligencia comercial See (el BI)
Facturando extensin de la mesa de hecho para mostrar Rentabilidad, 265266 La identificacin biomtrica, 374
El bitmap indexa, 392. Vea tambin ndices del rbol de B El snowflaking y, 56 bifurcan dimensin, financieros
Servicios, 203 El ladrillo y el mortero, 392. Vea tambin clic Y el mortero Cuadros puentes, 163, 392 Asocindose, 166 Brin, David, 377 El vistazo pone en duda, 392 El navegador esconde en reserva, datos rastreando, 286287 Navegadores, 392 Haciendo una lectura ligera Teclee atributos, 157 El snowflaking y, 56 B-tree indexa, 391. Vea tambin bitmap ndices Presupuestando proceso, 180185 El hecho consolidado pospone, 184185 Autobs, 78, 392. Vea tambin almacn de datos La arquitectura del autobs La arquitectura del autobs, 13 Lifecycle dimensional comercial, 393 Los datos almacenan edificio, 332334 La inteligencia comercial (el BI), 393 La medida comercial, 393 El proceso comercial, 393 Seleccin, comercio al por menor, 3334 Diligenciadores, 342343 Los requisitos comerciales Los datos almacenan edificio, 340347 La documentacin postrecaudatoria y El seguimiento, 345347 La priorizacin y el consenso,
346347 Los requisitos comerciales efectuando cobros Las entrevistas cntricas en datos, 345 El flujo de entrevista, 343344 Lance, 343 El resumen de noticias, 344345
El ndice
421
Los diligenciadores comerciales de planeamiento previo de requisitos, la eleccin del foro 342 343, 341 Prepare equipo de requisitos, 341342 Los expertos comerciales de materia, 338 Los analistas comerciales del sistema, 338 Bytes (la B), 393
carbono El escondite, 393 la cannibalizacin, 393 cardinality, 393

Los expedidores del cargamento, el transporte, 234235 El producto cartesiano, 393 La prevencin catastrfica de fracaso, 379382 Las dimensiones causales, 393 Servicios financieros, 202 Comercio al por menor, 4648 Los factores causales, 393 El hecho centpedo pospone, 393394 Con demasiadas dimensiones, 58 Ciempieses, 57 Plan contable, 394 El libro mayor general la foto peridica, 175176 Oficial de operaciones principal (el informtico en jefe) 307, 394 La privacidad En Lnea de los nios El acto de proteccin (COPPA), 377 Haga mantequilla, 394 Reclama acumular foto, Seguro, 323324 Reclama transacciones, seguro, 321323 La clase de servicio, transporte, 236237 El clic y el mortero, 394. Vea tambin ladrillo
Y el mortero
Clickstream, 277, rastreo 281292, de 394 datos, el centro de compras de datos 282287 clickstream, empresa Los datos almacenan y, dimensiones 299300 clickstream, dimensin de acontecimiento 287292, 289290 Pagine dimensin, dimensin de referencia 288289, dimensin de sesin 291292, Tablas de hecho 290291 clickstream, agregado 292294, 298 Los acontecimientos de la pgina, el clic efectivo 295297, 394
De la circuito cerrado analtica gestor de relaciones con el cliente, 145 El Cdigo en Mtodos Dentales y Nomenclatura, 258 Columnas, 394 Las jerarquas comerciales del cliente, 161168 Las jerarquas de profundidad fija, 162 Las jerarquas variables de profundidad, 162168 La adquisicin complementaria Foto, 9394 Complique dibujos tcnicos, dimensional El modelado y, 1012 La mezcla teclea, 18, 394 Combine llaves, 61 Las llaves concatenadas, 18, 61. Vea tambin La mezcla teclea Informacin confidencial, datos Almacn, 4 Las dimensiones conformadas, 394 Los datos almacenan arquitectura del autobs, 8287 La pliza de seguros peridica Foto, 316 Los hechos conformados, 394 Los datos almacenan autobs Arquitectura, 87 La pliza de seguros la foto peridica, 316317 Conformando los hechos, 329

Libroespañol

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Libroespañol

Uploaded by

Copyright:

Available Formats

El Almacn de Datos Toolkit

La Segunda Edicin El Gua Cabal para

Editor publicista: Robert Ipsen

Complique Acontecimientos de Asistencia Mdica para la Salud

269 269 271 271 273 274

305 306 307 309 309 310

316 316 316 318 318

33 0 Captulo 1 El 2 El 33 La 16 Construyendo el Almacn de Datos 33 Lifecycle 33 Inters 3 Gerencia 33 Presteza 3

3 36 Justificacin 3 36 Dotacin 37 de personal 3

Proyecto 3 Requisitos 34 Requisitos 3 Comerciales 3 Seguimiento 3

Instalacin 35 Lifecycle 35 Dimensional 35 Fsico 35

3 56 La 57 El 8 La 58 La 61 Estrategia Inicial de Indexacin 3 y el Desarrollo 35 Dimensin 3 de Hecho 3

Captulo 1: La Cartilla Dimensional de Modelado

Captulo 2: Comercio Al Por Menor

Captulo 6: Gestor De Relaciones Con El Cliente

Captulo 13: Asistencia Mdica Para La Salud

Captulo 16: Construyendo el Almacn de Datos

Captulo 17: Presente Imperativos y Futuro Punto de Vista

El sitio Web del panion

almacenamiento de datos de marcas interesndole.

Figura 1.1 Los elementos bsicos del almacn de datos.

El Vocabulario Dimensional de Modelado

Los hechos ms tiles en una mesa de hecho son numricos y aditivos.

Comercio Al Por Menor EL CARBONO HAPTE R

del diseo como descendemos en los detalles intrincados de nuestros negocios.

El Modelo Dimensional 1. El Proceso Comercial 2. Grano 3. Dimensiones 4. Hechos

Datos Realidades Figura 2.1 pasos.

Teclee aporte para el proceso dimensional del diseo de cuatro

Paso 3. Escoja las Dimensiones

La Dimensin de Fecha La llave de fecha (PK) La fecha Atribuye a TBD

La Dimensin de Promocin La promocin de la Llave de promocin (PK) Atribuye a TBD

La Dimensin d Producto El producto de la Lla del producto (PK Atribuye a TBD

Podemos computar la ganancia bruta sustrayendo la cantidad costada del dlar de la

La Dimensin de Promocin de Dimensin de la Tienda de Dimensin del

Figura 2.4 Feche dimensin en el dibujo tcnico de ventas por menor.

Salg a en Salga citas citas Tecl ee

Enero Enero Enero Enero Enero Enero

2002 2002 2002 2002 2002 2002

F2002-01 F2002-01 F2002-01 F2002-01 F2002-01 F2002-01

F2002-01 Poco Da D Fiesta F2002-01 Poco Da D Fiesta

Product o La Descripcin del Producto Teclee

Marque Categora Descripci Descripcin n

El Sourdough Ligero Sano Asado Al Horno el Pan El Pozo Asado Pan

Red Panadera Panadera

La Minicanela Gratis Gruesa Rueda

La Dimensin de Promocin de Dimensin de la Tienda de Dimensin de Fecha

La Cantidad de Ventas 5,088

cado dentro de la jerarqua de la mercanca se parecera a esto:

El Dlar de Ventas Ventas Cantidad

El Pozo Asado Al Horno$3,009

El Dlar de Ventas Content gorda Gordo A Non

Poniendo en duda el dibujo tcnico de ventas por menor.

Ventas El Nombre de Promocin Ninguna Promocin

Almacene Dimensin La Dimensin de Promocin

nuestra representacin simplista) es apabullante.

La descripcin del Departamento de la Llave del departamento (PK)

Figura 2.12 A medias la dimensin del producto del snowflaked.

La mesa centpeda de hecho con demasiadas dimensiones.

Inventario EL CARBONO HAPTE R

Tienda Minorista Inventario

Tienda Minorista Ventas Figura 3.1 El subconjunto de la cadena de valor de un detallista.

La Dimensin de Fecha Los atributos de datos de la Llave de fecha (PK)

Creo que 3.2 la Tienda inventaran dibujo tcnico peridico de la foto.