La importancia de los metadatosLos metadatos describen una organizacin en trminos de sus actividades comerciales y los objetos de negocio en el que se realizan las actividades de negocio. Consideremos, por ejemplo, la venta de un producto a un cliente por un empleado. La venta es una actividad empresarial y el producto, cliente y empleado son los objetos de negocio en el que se realiza la actividad de venta. Actividades comerciales y objetos de negocio, ya sea manual o automatizado, se comportan de acuerdo a un conjunto de relaciones y reglas, que se definen por el negocio. Estas actividades y objetos, y las relaciones y las normas que los rigen, proporcionan el contexto en el que los hombres de negocios que utilizan los datos de la empresa todos los das.

Los metadatos es tan importante para el medio ambiente de apoyo a decisiones BI porque ayuda transforman los datos empresariales en informacin. La diferencia entre los datos y la informacin es que la informacin es datos en bruto dentro de un contexto de negocios. Metadatos proporciona ese contexto empresarial; es decir, los metadatos se asegura la correcta interpretacin (basado en las actividades, objetos, relaciones y normas) de lo que los datos de la empresa significa en realidad.

Por ejemplo, cul es el beneficio? Es la cantidad de dinero que queda despus de un producto se ha vendido y todo el mundo que estuvo involucrado en ese producto se ha pagado? O es un clculo ms complicado, como "suma total menos ingresos anuales de coste medio de base por producto menos los gastos generales del personal real menos bonos de produccin anuales acumulados menos los descuentos menos cupones por mayor dividido por doce?" Cada persona de negocios tienen la misma comprensin de lucro? Hay una y slo una de clculo con fines de lucro? Si hay diferentes interpretaciones de lucro, son todas las interpretaciones legtimas? Si hay varias versiones legtimas para clculos de ganancias, luego de mltiples elementos de datos se deben crear, cada uno con su propio nombre nico, definicin, contenido, reglas, relaciones, y as sucesivamente. Toda esta informacin contextual sobre el beneficio es metadatos.

Desde metadatos proporciona el contexto empresarial en el que se utilizan datos de negocio, los metadatos pueden ser vistos como una capa semntica (interpretativo) del entorno de apoyo a decisiones de BI. Esta capa semntica ayuda a los empresarios a navegar a travs de las bases de datos de destino de BI, donde residen los datos de negocio. Tambin ayuda a los tcnicos a gestionar las bases de datos de destino de BI, as como las aplicaciones de BI.

Algunas de las caractersticas importantes de los repositorios de datos y metadatos meta se enumeran a continuacin.

Un repositorio de metadatos se rellena con los metadatos de diferentes herramientas, como las herramientas CASE, herramientas ETL, herramientas OLAP y herramientas de minera de datos.

Metadatos documenta la transformacin y purificacin de datos de origen y proporciona una pista de auditora de las cargas de datos peridicos.

Los metadatos ayuda a rastrear los requisitos de BI de seguridad, medidas de calidad de datos y mtricas de crecimiento (para el volumen de datos, hardware y as sucesivamente).

Metadatos proporciona un inventario de todos los datos de origen que puebla las aplicaciones de BI.

Los metadatos pueden ser gestionados de forma centralizada, o pueden ser distribuidos. De cualquier manera, cada instancia de un componente de datos meta debe ser nico, independientemente de su ubicacin fsica.

Meta tcnica CategoriasHay dos categoras de metadatos: metadatos de negocio y datos tcnicos meta.

Empresas metadatos ofrece la gente de negocios con una hoja de ruta para acceder a los datos de negocio en el entorno de apoyo a las decisiones de BI. Dado que muchas personas de negocios son relativamente no tcnico, deben tener acceso a los metadatos, que define el entorno de apoyo a las decisiones de BI en trminos de negocio que entienden.

Metadatos Tcnica apoya los tcnicos y "usuarios avanzados", proporcionndoles informacin sobre sus aplicaciones y bases de datos, que necesitan a fin de mantener las aplicaciones de BI.

Tabla 7.1 destaca algunas diferencias entre los metadatos de negocio y datos tcnicos meta.

Tabla 7.1. Meta datos empresariales frente a Meta Data Tcnica Meta datos empresarialesMeta Datos tcnicosProporcionada por la gente de negociosOfrecido por tcnicos o herramientasDocumentado en trminos de negocio en los modelos de datos y en los diccionarios de datosDocumentado en trminos tcnicos en las bases de datos, archivos, programas y herramientasUtilizado por la gente de negociosUtilizado por los tcnicos, los "usuarios avanzados", bases de datos, programas y herramientas (por ejemplo, ETL, OLAP)Nombres plenamente explicados en lenguaje de negociosNombres abreviados con caracteres especiales, como "_" (guin bajo) o "-" (guin), utilizado en las bases de datos, archivos y programasRepositorio de metadatos como herramienta de navegacinLos metadatos no es nueva; que siempre ha sido parte de los sistemas operativos. Se puede encontrar en la documentacin de los sistemas, diseos de registros, catlogos de base de datos, y las secciones de declaracin de datos en los programas. El papel de los metadatos en un entorno operativo fue siempre visto como la documentacin de los sistemas, que fue utilizado principalmente por los tcnicos que mantienen los sistemas operativos. Cuando algunos de los sistemas de la documentacin (metadatos) se convirti en obsoleto, el personal tcnico tena suficientes habilidades para leer el cdigo de programacin real para extraer la informacin que estaban buscando, como el significado y contenido de un elemento de datos. As, ms de las veces, los metadatos se trat como una ocurrencia tarda.

En un entorno de apoyo a las decisiones de BI, metadatos adquiere un nuevo nivel de importancia. Una nueva audiencia tiene que ser reparado, a saber, los hombres de negocios. Los metadatos ayuda a localizar, administrar, comprender y utilizar los datos en las bases de datos de destino de BI. Datos Meta tiene un nuevo papel: navegacin, no slo la documentacin. La gente de negocios normalmente no tienen los conocimientos tcnicos, ni el tiempo o el deseo, de descifrar el cdigo de programacin. Asimismo, no quieren quedarse dependiente del departamento de TI para interpretar el sentido y el contenido de los datos despus de que ha sido manipulado por los programas. En lugar de llamar a un programador, una persona de negocios debera ser capaz de acceder a los metadatos, que luego ayudarle a navegar con eficacia a travs del entorno de apoyo a decisiones BI e interpretar los datos de BI. Como se ilustra en la Figura 7.1, los metadatos describe lo que se dispone de datos en la que la base de datos de destino de BI, en que los datos provienen, cmo acceder a ella, cmo perforar hasta los datos detallados para un examen ms detallado, y cmo usarlo.

Figura 7.1. El uso de un Repositorio de Datos Meta como una herramienta de navegacin

Normalizacin de datosSi los datos de negocio haban sido almacenados y utilizados de una manera consistente, aprobado todo el tiempo, no existiran los problemas de redundancia de datos y la inconsistencia que en la actualidad afectan a muchos sistemas operativos en la medida en que lo hacen hoy en da. Por desgracia, los malos hbitos tardan en morir. Los desarrolladores y empresarios todava explcita o implcitamente reutilizar los datos de negocio en los sistemas operativos para diferentes propsitos. Por ejemplo, los desarrolladores todava redefinir explcitamente elementos de datos en sus programas, y la gente de negocios todava redefinen implcitamente (inventan nuevos cdigos para los elementos de datos existentes) para capturar informacin no relacionada. La documentacin de estas redefiniciones tambin sigue siendo pobre o inexistente. Si existe alguna documentacin, rara vez se distribuye a todos los miembros de la organizacin que lo necesita, y es muy rara vez se mantiene al da. Por lo tanto, los empresarios siguen inventar sus propias reglas de negocio y crear sus propios datos redundantes, junto con los procesos redundantes.

Cada equipo de proyecto de BI debe abordar este caos de datos existente y debe hacer todo lo posible para promover la normalizacin de los datos. Mientras que la estandarizacin de los datos de negocio para el medio ambiente de apoyo a decisiones de BI, el equipo del proyecto de BI debe documentar todos los cambios realizados en los datos de manera que todo el mundo puede estar al tanto de ellos. Esta documentacin tiene la forma de metadatos en el repositorio de metadatos. Por ejemplo, un elemento de datos de origen podra ser renombrado para ajustarse a las nuevas normas de nomenclatura, o valores de datos podra ser filtrada, aadi, o transformada para hacer cumplir una regla de negocio. En ambos casos, los datos de BI en la base de datos de destino de BI ya no coincidir con los datos de origen en la base de datos de archivo de origen o la fuente. Los meta datos proporcionaran la navegacin entre los dos.

El uso de aplicaciones de BI sin saber que los datos de negocio ha cambiado y cmo fue cambiado puede ser una experiencia frustrante que a la larga puede acabar con los hombres de negocios ya no querer usar las aplicaciones de BI en absoluto. Eso sera devastador ya que uno de los aspectos ms importantes de una iniciativa de apoyo a las decisiones de BI es proporcionar una manera fcil de usar, intuitivo para las personas de negocios para acceder y consultar los datos. Una aplicacin fcil de usar significa que los hombres de negocios:

No tienen necesidad de ser expertos en tecnologa relacionales

No tienen necesidad de saber Structured Query Language (SQL)

No tienen necesidad de conocer la estructura fsica de las bases de datos

No tienen necesidad de conocer la ubicacin de sus datos

No tienen necesidad de adivinar el significado de los datos

No tienen necesidad de buscar la informacin requeridaClasificaciones de metadatosDado que los proyectos de BI pueden generar un gran nmero de componentes de metadatos, es til para clasificar estos componentes y dar prioridad a ellos para la implementacin gradual.

Agrupaciones de metadatos ComponentesComponentes de datos Meta se pueden clasificar en cuatro grupos meta datos o clasificaciones: de propiedad, caractersticas descriptivas, normas y polticas, y las caractersticas fsicas (Figura 7.2). El repositorio de datos meta debe ser capaz de almacenar los componentes de datos de metadatos de todos los cuatro clasificaciones, como se enumeran a continuacin.

Figura 7.2. Clasificaciones de metadatos

PropiedadTitular de los datos: Los datos son propiedad de la organizacin. Sin embargo, desde que la organizacin sea una persona jurdica y no una persona, alguien en la organizacin debe asumir la autoridad y la responsabilidad de establecer las polticas, determinar las reglas, y establecer normas para los datos de la organizacin. Esta autoridad y responsabilidad pueden ser distribuidos entre los gerentes de lnea de negocio o asignados a un comit propiedad de los datos (cuyos miembros ms probable es que todos o algunos de los gerentes de lnea de negocio). Un ejemplo de propiedad de los datos distribuida es un gerente del departamento de recursos humanos que tiene la autoridad y la responsabilidad de establecer las polticas, reglas y estndares para datos de la nmina, pero no para los datos del producto. Con propiedad de los datos por el comit, el comit establece las polticas, reglas y estndares para todos los datos por consenso, por delegacin a un miembro del comit, o por alguna otra norma comit.

Propietario de la aplicacin: Tradicionalmente, la propiedad ha sido asignado a un sistema como un todo. Puesto que un sistema se compone generalmente de una aplicacin y sus datos ", propiedad del sistema" implica que la misma persona tiene autoridad para establecer polticas, determinar las reglas, y establecer normas para los datos y funcionalidad (la aplicacin). Eso puede ser una condicin vlida para los sistemas operativos donde se origina de datos, pero no es vlido para aplicaciones de BI porque la mayora de la gente de negocios que usan las aplicaciones de BI no son los mismos individuos que se originan los datos operativos. Por lo tanto, los consumidores de informacin de BI pueden ser propietarios de la aplicacin de BI, pero la mayora de ellos no sern dueos de los datos.

Caractersticas descriptivasNombre: Cada objeto de datos, elemento de datos y procesos de negocios deben tener un nombre nico.

Definicin: Cada objeto de datos, elemento de datos y procesos de negocios deben tener una definicin breve explicando lo que es.

Tipo y longitud: Cada elemento de datos debe tener un tipo oficial y la longitud declarada por l, incluso si los elementos de datos en los sistemas de origen o las columnas o celdas en las bases de datos de destino podrn apartarse de ella. Esa desviacin tambin se definira como metadatos bajo el elemento de datos, la columna, o la clula donde ocurri.

Dominio: Cada elemento de datos debe tener un conjunto declarado de valores permitidos, incluso si el conjunto es de todo incluido, como "cualquier carcter, nmero o signo."

Notas: hechos de inters sobre los datos o procesos deben ser incluidos. Este es un cajn de sastre para comentarios de forma libre, como por ejemplo "Disputa entre la ingeniera y la comercializacin en relacin con el significado de Producto Subcomponente Cdigo Tipo fue entregado al comit directivo de BI para su resolucin."

Normas y PolticasRelaciones: Los objetos de datos se relacionan entre s a travs de las actividades empresariales. El repositorio de datos meta debe ser capaz de almacenar informacin sobre estas relaciones.

Las reglas de negocio y polticas de negocio: Estos componentes pueden aplicarse a los datos, as como a los procesos. Pueden ser normas tcnicas de conversin de datos, reglas de dominio de datos de negocio, reglas de integridad de datos de negocios, o las reglas de procesamiento.

Seguridad: Requisitos para la seguridad pueden aplicarse a los datos, metadatos, procesos, bases de datos, aplicaciones (programas y pantallas), herramientas y sitios Web.

Limpieza: Mtricas sobre los totales de reconciliacin ETL y sobre la calidad de los datos de BI deben almacenarse. Las mtricas pueden ser expresados como porcentajes de fiabilidad de una carga de datos (por ejemplo, 89 por ciento de la cdigo de tipo de cliente es vlido) o como registro de cuenta que indica el nmero de registros filtrada (rechazado) y el nmero de registros pasado a travs durante el proceso de ETL.

Aplicabilidad: Los datos no vive para siempre. En ocasiones, los nuevos datos se invent y capturado, y los datos de edad se retir y ya no se utiliza. Dado que las bases de datos de BI almacn de destino de muchos aos de historia, algunas columnas o celdas no tienen valores para todos los perodos de tiempo porque los datos no era aplicable o no exista durante ciertos periodos de tiempo. Si los picos aparecen en los grficos de anlisis de tendencias, el repositorio de metadatos debe ser consultado para determinar la aplicabilidad de ese pedazo particular de datos.

Puntualidad: Hombres de negocios querrn saber cuando los datos de origen fue actualizado y cul de las versiones de los sistemas operativos fueron utilizados para la actualizacin. No todos los sistemas operativos funcionan todos los das o el mismo da del mes. Un sistema operativo se puede ejecutar en el ltimo da natural del mes, mientras que otro puede funcionar en el ltimo da hbil del mes. Algunos sistemas operativos no "cierran el mes" hasta que completen un ajuste ejecutar nueve y cincuenta y seis das despus del ltimo da natural del mes.

Caractersticas FsicasOrigen (fuente): Desde las bases de datos de destino de BI nica almacn de datos operacionales (generados internamente y externamente adquiridos), el origen o la fuente de cada elemento de datos existente debe ser documentado. Una columna en la base de datos destino BI se pueden completar con elementos de datos de mltiples fuentes. Por ejemplo, el saldo en cuenta columna en la tabla de cuentas podra ser poblada de la demanda dato fuerte Saldo de la cuenta en la base de datos fuente de cuenta de cheques y desde el elemento de datos Tiempo Cuenta de Depsito saldo diario en el archivo de transacciones de Cuenta de Ahorros. Por el contrario, el elemento de datos de una fuente puede alimentar a varias columnas en la base de datos de destino de BI. Por ejemplo, el tipo de cdigo de elemento de datos puede ser usada para dos propsitos en el sistema operativo. Los valores de datos "A", "B" y "C" del Cdigo Tipo se pueden utilizar para rellenar la columna Tipo Cdigo Cliente en la tabla de clientes, y los valores de los datos "N", "O" y "P" de del mismo Cdigo Tipo se puede utilizar para rellenar la columna Tipo Cdigo del producto en la tabla de productos.

Ubicacin fsica: Varios componentes de metadatos (por ejemplo, tablas, columnas, nombres de conjuntos de datos) debe describir el lugar donde los datos residen en el entorno de apoyo a las decisiones de BI.

Transformacin: Muy pocos elementos de datos se puede mover del origen al destino sin ningn tipo de transformacin. Como mnimo, el tipo de datos y la longitud pueden tener que cambiar, o los cdigos de un solo carcter pueden tener que traducirse en la mnemotecnia de varios caracteres. En el peor de los casos, largos reglas de negocio pueden requerir transformaciones ms complicadas que implica la edicin, el filtrado, la combinacin, separacin, o la traduccin de los valores de datos.

Derivacin: Este componente almacena el clculo de columnas derivadas. Mientras columnas derivadas son habitualmente no se almacenan en los sistemas operativos, es la norma para almacenarlos en bases de datos de destino de BI.

Agregacin y resumen: Similar a la derivacin, reglas de agregacin y resumen se deben almacenar como metadatos.

Volumen y crecimiento: El tamao y el crecimiento de las bases de datos de destino de BI a menudo son enormes. Por lo tanto, proyectado, as como los volmenes reales deben ser documentados como los metadatos en trminos del nmero de filas y el porcentaje de crecimiento esperado.

La gente de negocios con mayor frecuencia acceden a los componentes de metadatos en la clasificacin caractersticas descriptivas, as como las normas y polticas de clasificacin (Figura 7.3). Los tcnicos suelen tener acceso a los componentes de metadatos en las caractersticas fsicas de clasificacin (Figura 7.4).

Figura 7.3. Meta de uso de datos de Business People

Figura 7.4. Meta de uso de datos por Tcnicos

Priorizacin de los metadatos ComponentesLa captura de todos los componentes de datos de metadatos puede no ser necesario o prctico para todos los proyectos de BI. Sin embargo, la captura de ninguno es inaceptable. Como regla general, los metadatos deben ser un entregable con cada proyecto de BI. Se atender a los empresarios a reconocer sus viejos datos, trazar lo que pas con l (transformacin), busque en las nuevas bases de datos de destino de BI, y determinar cmo usarlo correctamente. En otras palabras, las personas de negocios se beneficiarn enormemente de tener los metadatos disponibles para ayudarles a navegar a travs del entorno de apoyo a decisiones de BI.

No todos los componentes de metadatos tienen el mismo valor a todos los empresarios y todas las aplicaciones de BI. Podra ser til para dar prioridad a los componentes de metadatos en tres grupos: obligatorias, importantes (beneficiosos pero no obligatorias), y opcional. Tabla 7.2 muestra un esquema de priorizacin recomendada para la captura de los componentes de metadatos en un repositorio de metadatos.

Tabla 7.2. Priorizacin de Meta Data Meta Data ComponentesObligatorioImportanteOpcionalPropietarioNombre de datos de negociosNombre Datos tcnicosDefinicinTipo y longitudContenido (dominio)RelacionesNormas y polticas comercialesSeguridadLimpiezaAplicabilidadOportunidadOrigen (fuente)Ubicacin fsica (bases de datos de BI)TransformacinDerivacinAgregacinRecapitulacinVolumen y crecimientoNotas

Todos los componentes de metadatos obligatorios, y otros tantos componentes metadatos importantes como sea posible, deben ser capturados y almacenados en el repositorio de metadatos. Componentes de metadatos opcionales podran ser pospuestas para futuras versiones de aplicaciones de BI.Meta Data Repository DesafosLas buenas ideas son a menudo difciles de implementar. Proporcionar un repositorio de metadatos es una buena idea, pero tambin bastante un reto, independientemente de si se tom la decisin de conceder licencias (comprar) un producto disponible en el mercado o para construir un repositorio desde cero. Esta seccin describe brevemente los desafos que enfrentan en la aplicacin de un repositorio de metadatos (Figura 7.5).

Figura 7.5. Meta Data Repository Desafos

Desafos tcnicosLa construccin de un repositorio de metadatos no es una tarea trivial. Es un proyecto en s mismo, con su propio plan de proyecto, sus propios pasos de desarrollo, y de su propio personal. Todos los retos tecnolgicos que se aplican a las bases de datos y aplicaciones pueden surgir en proyectos de repositorio de metadatos.

Licencias un producto repositorio de metadatos es una alternativa a la construccin de uno, pero las versiones "plain vanilla" de los productos de repositorio de metadatos disponibles en el mercado a menudo no cumplen con todos los requisitos de metadatos de un entorno de apoyo a las decisiones de BI. Por lo tanto, la concesin de licencias de un producto repositorio de metadatos todava requiere un amplio anlisis de las necesidades con el fin de seleccionar el producto adecuado, as como un considerable esfuerzo de implementacin para mejorarla.

Mejora de software con licencia viene con sus propios desafos. El cdigo fuente para el producto puede no estar disponible. El vendedor puede insistir en la incorporacin de las mejoras solicitadas por un precio y en su propia velocidad. El tiempo y el esfuerzo necesarios para aumentar el mantenimiento del producto debido a que las mejoras deben volver a aplicar a los nuevos lanzamientos y versiones del producto repositorio de metadatos con licencia.

Desafos de personalLos metadatos deben ser documentacin "de estar" almacenado en una base de datos, es decir, en el repositorio de metadatos. El almacenamiento de los metadatos como documentos en papel se garantiza para convertirlo en "shelfware" en cuestin de meses, si no semanas. Esto significa que, como mnimo, un administrador de metadatos debe dedicarse a tiempo completo a la gestin del contenido del repositorio de metadatos y el software. Si un repositorio de metadatos se est construyendo como parte del proyecto de BI, con una plantilla de una persona no ser suficiente. El esfuerzo repositorio de metadatos requerir un analista, un modelador de datos, un diseador de la base de datos, y uno o ms desarrolladores.

Retos econmicosAunque muchos expertos BI piensan en los metadatos como el "pegamento" del entorno de apoyo a las decisiones de BI, la mayora de las organizaciones asignan poco o ningn dinero para crear y mantener un repositorio de metadatos. Ellos siguen considerando los metadatos como documentacin de sistemas para los tcnicos, en lugar de una herramienta de navegacin para gente de negocios. El dolor de la frustracin y la confusin de acceso de datos debe menudo llegar a un nivel intolerable ante organismos incluyen los metadatos como una entrega obligatoria y el nivel de sus proyectos de BI.

La falta de metadatos con frecuencia se ha citado como una de las razones del fracaso de aplicaciones de BI.

Usabilidad DesafosEl uso de un repositorio de datos meta debe ser completamente intuitivo. La gente de negocios debera ser capaz de hacer clic en un icono y obtener inmediatamente la informacin solicitada sobre una tabla o columna, un grfico o un informe, o incluso una consulta de negocios. Consultas ms complejas contra el repositorio de metadatos deben ser manejados con macros integrados o personalizados. Sin embargo, la forma ms pulido para presentar los datos meta es incluir en las consultas de BI, como se muestra en la Figura 7.6.

Figura 7.6. Ejemplo de metadatos en un BI de consulta

Desafortunadamente, muchos productos de repositorio de metadatos estn siendo diseados por tcnicos para tcnicos en lugar de para la gente de negocios. Algunos de estos productos todava tienen un lenguaje crptico de metadatos, carecen de capacidades de informes sofisticados, no son sensibles al contexto, y requieren una comprensin del modelo de metadatos que describen los objetos de metadatos y sus relaciones.

Desafos PolticosLa construccin de una solucin de metadatos en toda la empresa es difcil debido a las diferencias departamentales deben reconciliarse y poltica interdepartamentales deben resolverse. Estas disputas, aunque totalmente predecible, rara vez se toman en cuenta cuando se crea el plan del proyecto. Como resultado, los proyectos se retrasan mientras estas cuestiones se abordan o empujados hasta ejecutivos de empresas y los comits de direccin. Esto da la impresin de que los proyectos de BI son difciles, controvertidos, tedioso, drenaje, lento, y en general el trabajo indeseable.

A pesar de todos estos desafos, un repositorio de metadatos es un componente obligatorio de todos los entornos de apoyo a decisiones de BI.El Meta Modelo LgicoIndependientemente de si el repositorio de metadatos tiene licencia o construida, y con independencia del mtodo de aplicacin (centralizado, descentralizado o distribuido, como se explica en el paso 10, Repositorio de metadatos Diseo), el repositorio de metadatos debera apoyar un modelo meta lgica, que refleja los requisitos de metadatos. Al igual que con los datos de negocio, cada componente de los metadatos es nico por la naturaleza. Es importante definir estos singulares objetos de metadatos, su contenido, sus interrelaciones y sus interdependencias, independientemente de la forma en que se almacenan o se puede acceder. La tcnica para esta actividad es el modelado de datos lgicos, slo en este caso se producir un modelo meta lgica.

Un modelo de meta lgica es un modelo de datos que indica los objetos, las relaciones entre los objetos, y la cardinalidad y opcionalidad de las relaciones. La diferencia entre un modelo meta lgica para un repositorio de datos meta y un modelo lgico de datos para una aplicacin de negocios se encuentra en la naturaleza de los objetos. Los objetos en un modelo meta lgica representan los metadatos, como entidad, atributo, definicin, dominio, tabla, columna, y el ndice. Los objetos en un modelo de datos lgicos representan los datos de negocio, tales como clientes, productos, empleados, cuenta, y la ubicacin.

La Entidad-Relacin Meta ModeloSe crea un modelo de meta lgica durante la primera iniciativa de metadatos y se expande con cada iniciativa subsiguiente. La representacin lgica de objetos de datos meta debe ser capturado como un diagrama ER debido a sus definiciones explcitas de los objetos de datos del meta, las relaciones entre ellos, y el contenido de los objetos. La figura 7.7 muestra un ejemplo de un modelo de meta E-R.

Figura 7.7. Entidad-Relacin Meta Modelo. (Lneas verticales cortas indican "uno", y las patas de gallo indican "muchos".)

Un modelo de meta ER ayuda principalmente la gente a entender, comunicar y validar los requisitos de metadatos. Por lo tanto, un modelo ER meta debe ser visto como un modelo de requisitos que debe utilizarse para la evaluacin de productos de repositorio de metadatos y para establecer una lnea de base en el diseo de un repositorio de metadatos personalizados, incluso si su modelo de meta fsica (diseo de base de datos) termina siendo objeto- orientado (OO).

Meta-Meta DataDesde metadatos es la informacin contextual sobre los datos empresariales, los datos meta-meta es la informacin contextual sobre los metadatos. Muchos de los componentes de datos de meta-meta son similares a los de los metadatos. Por ejemplo, todos los objetos de metadatos debe tener componentes que cubren nombre, definicin, tamao y duracin, el contenido, la propiedad, relacin, reglas de negocio, seguridad, limpieza, ubicacin fsica, la aplicabilidad, la puntualidad, el volumen y notas. Los datos de meta-meta para un objeto de metadatos podra tener este aspecto:

Nombre: Entidad

Relacin: en relacin con una o varias tablas

Seguridad: leer por todos, actualizado por el administrador de datos

Propiedad: el administrador de datos

Origen: herramienta CASE ERWIN

Ubicacin fsica: mesa MDRSYSENT

Limpieza: 2 por ciento de datos faltantes

Puntualidad: la ltima actualizacin 01 de noviembre 2002

Volumen y crecimiento: 2.391 filas, la tasa de crecimiento del 1 por ciento anualMeta Data Repository Actividades AnlisisLas actividades para el anlisis de repositorio de datos meta no necesitan ser realizado de forma lineal. Figura 7.8 indica que las actividades se pueden realizar al mismo tiempo. La siguiente lista describe brevemente las actividades asociadas con el Paso 7, Anlisis repositorio de metadatos.

Analizar los requisitos de repositorio de metadatos.

Trabajar con el representante de negocios para determinar y priorizar las necesidades de metadatos para su proyecto BI especfica. Indique cul de los componentes de metadatos son obligatorios, importante y opcional. Si ya existe un repositorio de metadatos, determinar qu necesitan los componentes de metadatos que aadir, en su caso. Modificar la ltima versin del documento de requisitos de aplicacin (revisada durante o despus de la creacin de prototipos).

Analizar los requisitos de interfaz para el repositorio de metadatos.

Ya sea un repositorio de metadatos tiene licencia o construido, debe aceptar los metadatos de distintas fuentes. Metadatos de negocios tendrn que ser extrado de herramientas CASE, documentos de texto u hojas de clculo. Metadatos tcnicos tendrn que ser extrado y combinado de sistema de gestin de base de datos (DBMS) diccionarios, herramientas ETL, herramientas de limpieza de datos, herramientas OLAP, redactores de informes y herramientas de minera de datos.

Analizar la meta de acceso repositorio de datos y requisitos de informacin.

Rellenar una base de datos no tiene sentido a menos que se pueda acceder al contenido, pregunt, e inform. Esto es tan cierto para los metadatos como lo es para los datos empresariales. Identificar los requisitos de acceso a datos meta, los requisitos de seguridad y requisitos de la funcin de ayuda. Evaluar los modos de visualizacin alternativos, como formato de documento porttil (PDF), Hypertext Markup Language (HTML), SQL, consultas enlatadas o los metadatos de propiedad repositorio de informacin de software. Una ayuda sensible al contexto tutorial sera una caracterstica beneficiosa para incluir.

Crear el modelo de meta lgica.

Dibuje el modelo de meta lgica como un modelo ER para mostrar explcitamente las relaciones entre los objetos de metadatos, incluso si va a implementar el repositorio de metadatos como una base de datos OO. En otras palabras, el modelo lgico meta siempre debe ser un modelo ER, mientras que el modelo metafsico (el diseo de bases de datos meta repositorio de datos creada en el paso 10, Repositorio de metadatos Diseo) puede ser un modelo ER o un modelo OO.

Crear los datos meta-meta.

Mientras que el modelo meta lgica muestra los requisitos del repositorio de metadatos de un vistazo, los datos meta-meta se describen los componentes de metadatos requeridos en detalle.

Figura 7.8. Meta Data Repository Actividades AnlisisEntregables resultantes de estas actividadesMetamodelo Lgico

Este modelo de datos es un diagrama ER totalmente normalizada mostrando entidades del kernel, entidades asociativas, entidades caractersticos, relaciones, cardinalidad, opcionalidad, identificadores nicos, y todos los atributos de los objetos del repositorio de metadatos.

Metadatos meta-

Las entidades de metadatos y atributos del modelo de meta lgica deben ser descritos con metadatos. Componentes de datos meta-datos especficos Meta (datos meta-meta) son los nombres de los meta datos, definiciones de metadatos, relaciones de metadatos, identificadores nicos, tipos, longitudes, dominios, reglas de negocio, las polticas y la propiedad de metadatos.Roles involucrados en estas actividadesAdministrador de Data

El administrador de datos recoge los metadatos de negocios en una herramienta CASE durante las actividades de modelado de datos lgicos. Esta meta datos sern una de las fuentes para el repositorio de datos meta. El administrador de datos, en colaboracin con el administrador de metadatos, escribe y publica los estndares de datos. l o ella tambin puede ayudar en la creacin del modelo de metadatos y los datos meta-meta.

Administrador de datos Meta

El administrador de metadatos tiene responsabilidades primarias para almacenar y proporcionar acceso a los metadatos y para mantener el repositorio de metadatos. l o ella debe analizar los requisitos de metadatos, identificar los componentes de metadatos, y producir o mejorar el modelo de meta lgica y los datos meta-meta.

Experto en la materia

El experto en la materia participa en este paso mediante la representacin de los empresarios y sus requisitos de metadatos. El experto en la materia identifica los requisitos de seguridad y propiedad de los datos y trabaja con el administrador de datos, el administrador de metadatos, los propietarios de los datos, y otras personas de negocios para estandarizar los nombres, definiciones, contenidos y reglas de negocio.

Metamodelo Lgico

Este modelo de datos es un diagrama ER totalmente normalizada mostrando entidades del kernel, entidades asociativas, entidades caractersticos, relaciones, cardinalidad, opcionalidad, identificadores nicos, y todos los atributos de los objetos del repositorio de metadatos.

Metadatos meta-

Las entidades de metadatos y atributos del modelo de meta lgica deben ser descritos con metadatos. Componentes de datos meta-datos especficos Meta (datos meta-meta) son los nombres de los meta datos, definiciones de metadatos, relaciones de metadatos, identificadores nicos, tipos, longitudes, dominios, reglas de negocio, las polticas y la propiedad de metadatos.Riesgos de no realizar el paso 7Dado que uno de los objetivos de apoyo a las decisiones de BI es eliminar las incoherencias, los datos de origen deben normalizarse. Normalizacin invariablemente resulta en cambio de gran parte de los datos de origen. Los cambios pueden incluir el cambio de nombre de los datos, la divisin de elementos de datos de una fuente en mltiples columnas de destino, o rellenar una columna de destino de mltiples elementos de datos de origen. Tambin puede significar la traduccin de cdigos en la mnemotecnia, la estandarizacin de los valores de datos (cambiantes), y la filtracin de datos inapropiados o no vlidos. Al final, la gente de negocios no sern capaces de conciliar sus datos de origen operacionales a los datos de destino BI a menos que tengan un rastro de estos cambios. Este rastro se llama metadatos, y la gente de negocios que necesitan para navegar con eficacia a travs del entorno de apoyo a decisiones de BI.

Sin metadatos, los empresarios tendran un tiempo difcil comprensin y el uso de los datos transformados en las bases de datos de destino de BI. Sera tan frustrante como sin rumbo conducir un coche durante semanas o meses sin un mapa, adivinando su camino a su destino. Una vez que los hombres de negocios que perciben la aplicacin de BI como difcil de usar o que piensan los datos de BI no es fiable porque ya no coincide con los datos de origen en los sistemas operativos, podan etiquetar la iniciativa de apoyo a decisiones BI un fracaso.

Capitulo 8Las diferencias en la filosofa de diseo de bases de datosHay una filosofa de diseo completamente diferente detrs de las bases de datos de destino de BI en comparacin con bases de datos operacionales. Tabla 8.1 resume las diferencias entre estos dos tipos de bases de datos.

Bases de datos operacionalesLa intencin de diseo base de datos operativa es evitar que el almacenamiento de los mismos atributos de datos en mltiples lugares y por lo tanto para evitar las anomalas de actualizacin causadas por redundancia. En otras palabras, desde una perspectiva operativa desea evitar el almacenamiento de los mismos datos en varias columnas en varias tablas para que no se consiguen fuera de sincronizacin. El diseo de las estructuras de base de datos normalizados es clave para el desarrollo de bases de datos relacionales en apoyo de esa intencin. La normalizacin se asegura de que se crea los datos, almacenados, y modificado de una manera consistente, no redundante.

Tabla 8.1. Bases de datos operacionales frente a BI Target Bases de datos Bases de datos operacionalesBases de datos de destino de BIOrientado hacia la eliminacin de la redundancia, la coordinacin de las actualizaciones, y la repeticin de los mismos tipos de operaciones muchas veces al da, todos los das (por ejemplo, reservas de vuelos, depsitos y retiros de cuentas bancarias, reservas de habitaciones de hotel).Dirigido a apoyar una amplia gama de consultas e informes. Consultas e informes pueden variar de un analista de negocios a otro o de un departamento a otro. Todas las consultas e informes pueden no ejecutarse en el mismo da y no pueden correr todos los das (por ejemplo, los informes de anlisis de tendencias trimestrales sobre las ventas regionales, mensual de informes de cumplimiento de pedidos).La mayora de los sistemas transaccionales requieren tiempo de respuesta por debajo del segundo.Aunque el tiempo de respuesta es importante, no se puede esperar subseconds. Los tiempos de respuesta tpicos son segundos, minutos u horas.Altamente normalizado para apoyar las actualizaciones y el mantenimiento de la integridad referencial consistentes.Altamente desnormalizado para proporcionar una rpida recuperacin de una amplia gama y una gran cantidad de datos. Datos que pertenece conjuntamente desde una perspectiva de informes analticos se almacena generalmente juntos.Almacenar datos muy poco derivados. Los datos se deriva generalmente de forma dinmica cuando sea necesario.Almacenar grandes cantidades de datos derivados. Esto ahorra tiempo para las consultas e informes.No almacene los datos histricos. Los registros histricos se archivan.Almacenar grandes cantidades de datos histricos, a menudo a un cierto nivel de resumen, pero a menudo a un nivel detallado.Ligeramente resumida, sobre todo para los informes.Muchos niveles de precalculados, datos resumidos, desde la ligera resumen de sumarsimo.

La mayora de los sistemas operativos estn diseados con una filosofa de datos-in (entrada de datos), no una filosofa de datos de salida (Reporte y consulta). El objetivo de una filosofa de datos-in es hacer que la entrada de datos lo ms eficiente posible, corriendo cientos de miles de transacciones por da, mientras que la eliminacin o minimizacin de las redundancias en los datos. La redundancia de datos lleva a inconsistencias y contradicciones son a menudo la razn de datos de mala calidad. Por lo tanto, al tratar de resolver los enormes calidad de datos y redundancia de datos problemas en los sistemas operativos, el objetivo es evitar la redundancia (a excepcin de la redundancia clave, que es inevitable). Este objetivo se logra a travs de la normalizacin.

Mientras que la normalizacin funciona bien para sistemas operativos, los requisitos para la presentacin de informes son diferentes de los requisitos para la entrada de datos. Reporting utiliza los datos que ya se ha creado, lo que significa anomalas de actualizacin no pueden ocurrir. Si bien es de gran beneficio que los datos son consistentes y no redundante como resultado de un diseo de base de datos normalizada, ese mismo diseo hace que la presentacin de informes difcil. Por ejemplo, para crear informes de anlisis de tendencias estratgicas, muchas mesas tienen que ser visitada, y cada fila de esas mesas tiene que ser ledo. Esto no slo es compleja, sino tambin extremadamente ineficiente cuando se ejecuta contra un diseo de base de datos normalizado, ya que requiere mesas de exploracin y la realizacin de grandes mesas mltiples combinaciones. Por esa razn, la mayora de las bases de datos de destino de BI se basan en un diseo multidimensional, en la que los datos de los informes de anlisis de tendencias estratgicas son almacenados de manera precalculada y presummarized.

La figura 8.1 ilustra la diferencia general entre un diseo normalizado operativa y un diseo multidimensional BI.

Figura 8.1. Operacional normalizado frente BI diseos multidimensionales

En este ejemplo, el diseo de la base de datos operativa muestra una base de datos de pedido, donde los clientes se asocian con las rdenes y cada orden se compone de muchos elementos de lnea. Con cada pedido realizado, las lneas tienen que ser restada de una base de datos de inventario separado. El diseo de base de datos destino BI muestra una base de datos con resmenes que se utilizan para identificar las tendencias en el tiempo. En este diseo, pueden existir los mismos datos sobre pedidos, artculos de lnea, y el inventario en mltiples tablas (Resumen Mensual, Resumen Regional, Resumen del producto), si bien resumido por diferentes dimensiones. Mientras que las bases de datos operacionales generalmente almacenan granular de datos (atmicas), bases de datos de destino BI, en su mayor parte, almacenar resumido de datos.

Bases de datos de destino de BIAl contrario de la filosofa (entrada de datos) de datos en los sistemas operativos, la filosofa de los datos de salida (Reporte y consulta) de aplicaciones de BI incluye las siguientes consideraciones de diseo.

Bases de datos de destino de BI estn diseadas para la recuperacin de datos simplificada, de alto rendimiento, no por la eficiencia de almacenamiento y mantenimiento (que son importantes consideraciones de diseo para las bases de datos operacionales) de datos.

Eliminar o minimizar la redundancia de datos no es un objetivo en el diseo de bases de datos de destino de BI. Si una eleccin debe hacerse, la redundancia de datos se ve favorecida por la complejidad, pero la redundancia debe ser controlado. Datos redundantes deben ser consistentes y conciliables.

Supuestos bsicos para el diseo de bases de datos de destino de BI se enumeran a continuacin.

- Los datos se almacenan de tal manera que sea fcilmente accesible en formas que son de inters para las personas de negocios.

- El diseo es impulsado por el acceso y el uso.

- Un diseo normalizado no es necesariamente intuitiva para una persona de negocios, por lo que podra llegar a ser bastante complejo.

- No hay datos de BI se pueden inventar! Todos los datos en las bases de datos de destino de BI deben existir o ser derivable de las fuentes de datos operacionales internos o externos actuales.

Una decisin clave para todas las aplicaciones de BI es si o no, ya qu nivel, para almacenar datos resumidos en las bases de datos de destino de BI. El administrador de base de datos y el desarrollador principal pueden decidir almacenar tanto datos detallados y datos resumidos, ya sea juntos en la misma base de datos destino BI o en diferentes bases de datos de destino de BI. Esta decisin de diseo de base de datos debe basarse en los requisitos de acceso y uso.Diseo de base de datos lgicaDebido a las diferencias en la intencin y propsito entre los sistemas operativos y aplicaciones de BI, diferentes tcnicas de diseo de base de datos han sido ideados para bases de datos de destino de BI. Estos altamente desnormalizado tienda de diseos agrega y resume los datos de una manera multidimensional. Diseos de bases de datos lgicos se documentan como modelos de datos fsicos con los datos tcnicos del meta.

Agregacin y resumen son probablemente las que ms contribuyen a un buen rendimiento de aplicaciones de BI. Si la mayora de los analistas de negocio tienen que ver sus datos de resumen, estos totales deben ser precalculadas y almacenadas para la recuperacin rpida. Es importante discutir el nivel de granularidad con el representante de negocios, as como con otros analistas de negocio que van a utilizar las bases de datos de destino de BI, ya que esperan que el diseo de bases de datos para que puedan perforar hasta un cierto nivel de detalle.

Diseos de bases de datos multidimensionales apoyan la recuperacin rpida de una amplia gama de datos. Dos tcnicas populares de diseo multidimensionales son el esquema en estrella y el esquema de copo de nieve, tanto se describe a continuacin.

El esquema en estrellaEn un esquema en estrella, los datos se representa como una matriz de valores precalculados, llamados hechos, alrededor de la cual se realiza el anlisis. Estos hechos precalculados representan valores de datos operacionales atmicas que han sido presummarized por ciertas dimensiones, tales como cliente, producto, y el tiempo. Una dimensin en un esquema en estrella es similar a una entidad en un modelo de datos lgico: es un objeto de negocio sobre el que se recogen datos para fines comerciales.

El esquema en estrella refleja el punto de vista de una consulta de negocios. Como su nombre lo indica, el esquema en estrella tiene un solo objeto en el medio, se llama la tabla de hechos, que est conectado de forma radial a una serie de objetos, llamados tablas de dimensiones. Figura 8.2 presenta un ejemplo de un esquema en estrella.

Figura 8.2. Estrella de esquema

Un esquema en estrella tiene dos, y slo dos, niveles: la tabla de hechos y una serie de tablas de medidas de un solo nivel. Mesas informativas tienen las siguientes caractersticas:

Una tabla de hechos representa un evento de negocios crtica (una actividad comercial o transaccin, como una venta o una reclamacin).

Los hechos son los aspectos cuantificables del evento de negocios; es decir, son las columnas de la tabla de hechos.

A enlaces de mesa hecho a sus tablas de dimensiones relacionadas (objetos de negocio, como cliente o producto).

Una tabla de hechos tiene una clave compuesta de largo compuesto de las claves principales de las tablas de dimensiones relacionadas (que son las claves externas en la tabla de hechos).

Una serie de tablas de hechos altamente redundantes puede existir para un rea temtica determinada. Cada tabla de hechos podra contener un nivel de agregacin diferente de los mismos datos. Por ejemplo:

- hechos de ventas por tienda, por regin por fecha

- hechos de ventas por producto por tienda por fecha

- hechos de venta por cliente por regin por fecha

Mesas informativas son largas y estrechas: las mesas tienen un inmenso nmero de filas (largas), pero hay relativamente pocas columnas en las tablas (estrechas).

Las tablas de dimensiones tienen caractersticas muy diferentes.

Las tablas de dimensiones son objetos de negocio, que representan las diferentes perspectivas desde las que los hechos en una tabla de hechos se pueden ver y analizar.

Las tablas de dimensiones suelen tener una clave principal de un atributo.

Las tablas de dimensiones se desnormalizar, lo que significa que los datos que pertenecen juntos desde una perspectiva de negocio especfico, como una jerarqua roll-up, se agrupan en una sola mesa. Esto produce algunos valores de datos redundantes, lo que es aceptable en este esquema de diseo.

Las tablas de dimensiones son cortas y anchas: las mesas tienen relativamente pocas filas (corto), pero hay muchas columnas en las tablas (ancho).

Siempre que sea posible, tablas de medidas deben ser compartidos por las tablas de hechos (dimensiones conformes).

Una dimensin es siempre una dimensin de tiempo con los atributos que describen la marca de tiempo, como ao natural, trimestre, estacin, periodo fiscal o perodo contable. Algunos otros ejemplos de tablas de medidas comunes son clientes, productos, polticas, representante de ventas, regin y tienda.

DBMS ms multidimensionales lidiar efectivamente con la optimizacin de las grandes multi-mesa de uniones. Un mtodo para determinar si el DBMS es resolver la consulta de manera eficiente es mirar el plan optimizado para la consulta. Por ejemplo:

Si la tabla de hechos es la ltima tabla unida, esto es un indicador de la optimizacin. Si la tabla de hechos parece estar en algn lugar en el medio, o incluso en algn lugar hacia el principio, el DBMS puede que no sea resolver el JOIN de manera ptima, a menos que se utiliza ms sofisticados algoritmos JOIN.

Si el DBMS no utiliza producto cartesiano JOINs, el DBMS puede tomar las llaves de fila de calificacin y aplicarlas contra un ndice de tabla de hechos de material compuesto, o puede aplicarlos a travs de una interseccin ndice contra mltiples de mesa hecho de ndices de una sola columna.

En cualquier caso, verifique que su DBMS est ejecutando consultas multidimensionales de la manera ms eficiente ya que su rendimiento depende de ello.

El esquema en estrella es el ms popular de esquema de diseo de base de datos para aplicaciones de BI para una variedad de razones.

Se produce el mejor rendimiento para las consultas de anlisis de tendencias e informes que incluyen aos de datos histricos.

Proporciona la mxima flexibilidad para el anlisis de datos multidimensional.

Es apoyado por la mayora de los vendedores de DBMS relacionales con modificaciones en su optimizador DBMS.

Su simplicidad hace que el anlisis de datos complejos y mucho menos difcil que con un diseo normalizado estndar. Es mucho ms fcil hacer preguntas como las siguientes:

- Qu corredor de seguros nos est dando ms o menos el negocio lucrativo?

- Cules son los tipos ms frecuentes de las reclamaciones de este corredor de seguros?

- Cuando son estas afirmaciones se producen?

Las preguntas anteriores son preguntas tpicas de desglose (pidiendo datos ms detallados) y preguntas tpicas enrollables (pidiendo ms datos resumidos).

El copo de nieve de esquemaUn esquema de copo de nieve es una variacin de un esquema en estrella, excepto en un copo de nieve las puntas de la estrella irradian en ms puntos, como se muestra en la Figura 8.3.

Figura 8.3. Copo de nieve de esquema

En los esquemas de copo de nieve, los niveles de las jerarquas en las tablas de dimensiones se normalizan, lo que aumenta el nmero de mesas. Tabla 8.2 lista las ventajas y desventajas de los esquemas de copo de nieve.

Tabla 8.2. Ventajas y desventajas de Ventajas del copo de nieve EsquemasDesventajasEl tamao de las tablas de dimensiones se reduce y el valor de los datos de redundancia se evita porque jerarquas entre padres e hijos ya no estn colapsados.El aumento del nmero de mesas puede afectar negativamente el rendimiento de consulta debido une a la adicional necesaria.Se aumenta la flexibilidad de la aplicacin.Base de Datos de esfuerzo de mantenimiento se incrementa debido a que hay ms tablas que mantener.Diseo de base de datos fsicaDado que las aplicaciones de BI por lo general requieren datos detallados de operacin, as como datos resumidos, y debido a que a menudo tienen que almacenar todos o algunos de esos datos de forma redundante, el tamao de algunas bases de datos de destino de BI pueden ser enormes. Las bases de datos se aproximan o superan un terabyte de datos se llaman grandes bases de datos (VLDBs). Disear VLDBs es un gran reto, y las tareas del da a da de mantenimiento de estos VLDBs estn exigiendo. Muchas de las decisiones de diseo fsico difciles deben hacerse, y algunas mejoras de rendimiento altamente eficaces deben ser utilizados. Las siguientes secciones presentan algunas pautas sugeridas.

Opciones de implementacinCasi todos los DBMS permite al administrador de la base elegir entre una serie de opciones de implementacin. Dar una atencin considerable a la seleccin de las opciones correctas en la aplicacin de una base de datos de destino de BI. Se necesita experiencia para saber qu combinacin de opciones se reunir con el nivel de rendimiento deseado. Decisiones de Implementacin incluyen los siguientes:

Cunto espacio libre para elegir

Cunto espacio de bfer para declarar

Qu tan grande para establecer el tamao de bloque

Ya sea para utilizar cualquier tcnica de compactacin

Colocacin del conjunto de datos fsicaOtra cuestin bsica que afecta el rendimiento es la colocacin de los conjuntos de datos. Los mtodos para lograr una respuesta rpida incluyen combinaciones de:

El almacenamiento de los datos con frecuencia se hace referencia en los dispositivos rpidos.

El almacenamiento de los diferentes niveles de agregacin en diferentes plataformas. Por motivos de rendimiento, puede ser necesario almacenar datos agregados en los servidores de gama media distribuidos manteniendo datos detallados en el mainframe.

Discos Striping en forma intercalada para optimizar entrada / salida (I / O) el uso del controlador. El uso de un montn de pequeos discos en lugar de unos discos grandes, separando esos discos en controladores separados, y escribir los datos a travs de dispositivos aumenta el rendimiento de E / S.

La colocacin de conjuntos de datos de una manera que se evitan largos busca cuando sea posible.

Seleccin de direccin y bsqueda esquemas que requieren pocas busca, preferiblemente slo una por la recuperacin.

La ejecucin de mltiples operaciones en paralelo.

Ten en cuenta tambin la posibilidad de separar los ndices de los datos y ponerlos en discos separados.

ParticionesAsegrese de que las tablas se dividen de manera efectiva a travs de mltiples discos. Esto es particularmente importante para VLDBs en tablas de hechos pueden alcanzar varios cientos de gigabytes. La particin permite que los datos de una tabla "lgico" que se propagan a travs de mltiples conjuntos de datos fsicos. La distribucin de datos fsico se basa en una columna de particin, que es ms comnmente fecha. Dado que una columna de particin debe ser parte de la clave principal de la tabla, la columna de particin no puede ser una columna derivada, y no puede contener valores NULL. Particiones le permite realizar copias de seguridad y restauracin de una parte de una mesa sin afectar la disponibilidad de otras partes de la misma mesa que no estn siendo copia de seguridad o restaurar.

ClusteringDefinir los requisitos de la tabla de racimo, y fsicamente co-localizar tablas relacionadas en la unidad de disco. Clustering es una tcnica muy til para el acceso secuencial de grandes cantidades de datos. La agrupacin se logra a travs de la agrupacin de los ndices que determinan en qu orden secuencial de las filas de las tablas se almacenan fsicamente en los conjuntos de datos. Idealmente, usted quiere agrupar la clave principal de cada mesa para evitar divisiones de pgina, es decir, para asegurarse de que los nuevos registros insertados en las tablas se almacenan de forma secuencial en el disco de acuerdo a las columnas de su ndice de agrupamiento. Usando esta tcnica puede mejorar drsticamente el rendimiento porque el acceso secuencial de los datos es la norma en aplicaciones de BI. Cuando las filas de una tabla ya no se almacenan en el mismo orden que su ndice de agrupamiento (fragmentacin de datos), el rendimiento se ver afectada y la tabla tiene que ser reorganizada.

IndexacinHay dos estrategias de indexacin extremas, ninguna de las cuales es recomendable: una estrategia es ndice de todo, y el otro es para indexar nada. En lugar de virar a estos extremos, el ndice de las columnas que son con frecuencia buscado y que tienen una alta distribucin en valores, como la Cuenta Abierta Fecha. No columnas de ndice que tienen una baja distribucin en valores, como Cdigo de Gnero.

Una vez que usted haya decidido que las columnas de ndice, determinar la estrategia de ndice a utilizar. La mayora de los DBMS proporcionan varios mtodos de acceso para elegir, ya sea de acceso secuencial o acceso directo utilizando cualquiera de los siguientes algoritmos de indexacin conocidos:

B-tree

Picadillo

Archivo invertido

Escaso

Binario

Consulte con su proveedor de DBMS para elegir el mtodo de acceso ms ptimo (algoritmo de indexacin) para el producto DBMS que est utilizando.

ReorganizacionesDe vez en cuando tendr que reorganizar las bases de datos debido a las cargas incrementales fragmentar los conjuntos de datos a travs del tiempo, y las filas insertadas ya no ser almacenada en una secuencia lgica. Esta fragmentacin puede dar lugar a largas cadenas de recuperacin de datos, y el rendimiento puede caer significativamente. La mayora de los DBMS proporcionan rutinas de reorganizacin para reorganizar la base de datos fragmentados con el fin de recuperar el espacio ocupado por los datos eliminados o para mover los registros de zonas de desbordamiento en el espacio libre en reas de datos primarios.

Las actividades bsicas involucradas en la reorganizacin de una base de datos son para copiar la antigua base de datos en otro dispositivo, reblock las filas, y volver a cargarlos. Esto no es un esfuerzo trivial para bases de datos de destino BI. La buena noticia es que todos los DBMS pueden realizar una rutina parcial reorganizacin en las particiones de base de datos, lo cual es otra razn para que el administrador de base de datos para dividir las bases de datos de destino de BI.

Backup y recuperacinDado que el software y el hardware puede fallar, es necesario establecer procedimientos de respaldo y recuperacin. DBMS proporcionan utilidades para realizar copias de seguridad completas, as como las copias de seguridad incrementales. Muchas organizaciones tienen la impresin equivocada de que las bases de datos de destino de BI siempre pueden ser recreados a partir de los datos de origen originales. Olvidan a darse cuenta de que puede tomar mucho tiempo para volver a crear las bases de datos de destino de BI si tienen que volver a ejecutar todo el extracto inicial e histrico / transformar / carga (ETL) programas-suponiendo que los archivos originales estn todava disponibles.

La recuperacin de desastres es tambin un problema para las aplicaciones de BI. Si las cintas o cartuchos de copia de seguridad son destruidos durante un desastre, podra ser difcil de recrear las bases de datos de destino de BI, y podra tomar un tiempo muy largo (si la recuperacin es posible en absoluto). Por esta razn, muchas empresas optan por almacenar sus copias de seguridad de bases de datos en lugares remotos.

Ejecucin de consultas en paraleloPara mejorar el rendimiento de una consulta, romper una sola consulta en componentes para ejecutarse al mismo tiempo. Algunos productos DBMS ofrecen ejecucin paralela transparente, lo que significa que no es necesario saber cmo romper una consulta en componentes porque el DBMS lo hace por usted. El rendimiento se increment en gran medida cuando mltiples partes de una consulta en paralelo en varios procesadores. Otras aplicaciones de la ejecucin de consultas en paralelo estn cargando las particiones de tablas, ndices de construccin, y la exploracin o la clasificacin de las tablas. El procesamiento paralelo es un concepto muy importante para las aplicaciones de BI y debe considerarse siempre que sea posible.Diseo de base de datos ActividadesLas actividades para el diseo de la base de datos no necesitan ser realizado de forma lineal. Figura 8.4 indica que las actividades se pueden realizar al mismo tiempo. La siguiente lista describe brevemente las actividades asociadas con el Paso 8, Diseo de base de datos.

Revise los requisitos de acceso a datos

El administrador de base de datos debe revisar el acceso a los datos y requisitos de anlisis (informes, consultas), los cuales fueron analizados y finalizados durante el Paso 6, de prototipos de aplicaciones. l o ella tambin tiene que revisar los resultados de prototipos con el desarrollador principal de aplicacin para ayudar a determinar el esquema de diseo ms apropiado para las bases de datos de destino de BI.

Determinar los requisitos de agregacin y resumen.

Antes de comprometerse con el esquema de diseo final de las bases de datos de destino de BI, el administrador de base de datos necesita para ultimar los requisitos de agregacin de datos y resumen con el representante de negocios y el desarrollador principal de la aplicacin. Preste mucha atencin a la agregacin y explosin resumen y explosin de datos en general. La gente de negocios a menudo piden los datos "por si acaso" que se necesitarn algunos das, y luego rara vez utilizan, si alguna vez.

Disear las bases de datos de destino de BI.

Las afirmaciones generalizadas de que todas las aplicaciones de BI son slo de anlisis multidimensional y reporte multidimensional no son verdad! Por ejemplo, algunos analistas financieros (estadsticos) informar al director de finanzas o el director general enfticamente indicar sus requisitos similares a esta: "Tengo que ser capaz de hacer cualquier pregunta de los datos detallados de cualquier manera No trates de boxear. en cualquier patrn de informes predeterminados. No tengo ninguno! " Estos analistas necesitan total de flexibilidad ad hoc con los datos detallados histricos y siempre estn dispuestos a renunciar a prestaciones, incluso si esto significa que sus consultas tendr una duracin de horas o toda la noche. Aunque estos tipos de analistas son definitivamente en la minora, existen, y usted debe tomar sus requisitos de acceso a datos en consideracin. Por lo tanto, mientras que los diseos de la mayora de las bases de datos de destino de BI se basarn en un esquema multidimensional, algunos se basan en un esquema de entidad-relacin. Diseos de bases de datos estn documentados como modelos de datos fsicos.

Los requisitos de acceso a datos y la agregacin de datos y requisitos de integracin determinarn el diseo de bases de datos ms adecuada. Si hay patrones de informes evidentes o si los requisitos piden capacidades rebanada y anlisis de los dados, entonces el diseo de bases de datos ms adecuado es una multidimensional. Si no hay requisitos de informacin y si los analistas de negocios insisten en que necesitan acceso ad hoc a sus datos de detalle, a continuacin, el diseo ms apropiado es el diseo de entidad-relacin, que es ms normalizada con pocos o ningn agregaciones o resmenes.

Estos no son los nicos dos esquemas de diseo aplicables para bases de datos de destino de BI. Para algunos tipos de requisitos de acceso y anlisis, un diseo hbrido puede ser el ms apropiado.

Disear las estructuras de base de datos fsicos.

Clustering, particionamiento, indexacin, y adecuada colocacin de los conjuntos de datos son las cuatro caractersticas ms importantes del diseo de base de datos fsica. El administrador de base de datos debe agrupar las tablas utilizadas con mayor frecuencia con el fin de reducir el movimiento del brazo de disco. l o ella tambin debe determinar dnde colocar los conjuntos de datos y cmo particionar tablas en varios discos. Finalmente, l o ella tiene que seleccionar una estrategia de ndice.

Construir las bases de datos de destino de BI.

Las bases de datos fsicos se construyen cuando el lenguaje de definicin de datos (DDL) se ejecuta en el DBMS. El administrador de bases de datos utiliza el DDL para describir las estructuras de base de datos (por ejemplo, grupos de almacenamiento, particiones de base de datos) para el DBMS.

Se establece la seguridad de base de datos cuando el lenguaje de control de datos (DCL) se ejecuta en el DBMS. En las bases de datos relacionales estndar, se impone la seguridad en la tabla o vista nivel. Debido a la naturaleza dimensional de las bases de datos de destino de BI, la capacidad de profundizar en los datos de detalle, a veces a travs de bases de datos, presenta un riesgo para la seguridad a menudo se pasa por alto.

Conceder autoridad de base de datos, ya sea a individuos oa grupos en los que se han asignado los individuos. La gestin de la seguridad a nivel individual puede convertirse rpidamente en una pesadilla de mantenimiento, por lo que la mayora de las organizaciones prefieren configurar identificadores de grupo (grupo ID). Cada grupo ID se concede alguna forma de crear, leer, actualizar, eliminar (CRUD) el acceso a las mesas. Una pista de auditora puede entonces mostrar que especfica "ID de usuario" en las que el ID de grupo accede a la base de datos. Si hay una violacin de la seguridad, el "infiltrado" a menudo puede ser localizado a travs de esta pista de auditora.

Desarrollar procedimientos de mantenimiento de bases de datos.

Una vez que la base de datos en produccin, ser importante reservar un tiempo para realizar copias de seguridad de bases de datos o la reorganizacin de tablas fragmentadas. Por lo tanto, establecer procedimientos para hacer frente a las funciones de mantenimiento de bases de datos.

Preprese para monitorear y ajustar los diseos de bases de datos.

Una vez que se lleva a cabo la aplicacin de BI, las bases de datos de destino de BI tienen que ser monitoreados y afinado. El mejor diseo de base de datos no garantiza continu el buen desempeo, en parte porque las tablas se fragmentan y en parte por el uso real del objetivo BI bases de datos de cambios en el tiempo. Supervisar el rendimiento de las consultas en tiempo de ejecucin con una utilidad de supervisin del rendimiento que tiene la capacidad de diagnstico. No ayuda a saber que el rendimiento se ha degradado sin conocer las causas. Diagnstico de problemas de rendimiento suele ser mucho ms difcil que descubrirlos.

Preprese para monitorear y ajustar los diseos de la consulta.

Puesto que el rendimiento es un reto como en aplicaciones de BI, debe explorar todos los trucos del oficio para abordar este problema. Ejecucin de consultas en paralelo es uno de esos trucos que podran impulsar el rendimiento de consulta.

Figura 8.4. Diseo de base de datos ActividadesEntregables resultantes de estas actividadesModelo de datos fsico

El modelo de datos fsico, tambin conocido como el diseo de base de datos lgica, es un diagrama de las estructuras de base de datos fsicos que contendrn los datos de BI. Dependiendo del esquema de diseo de base de datos seleccionada, este diagrama puede ser un diagrama entidad-relacin, un diagrama de esquema en estrella, o un diagrama de copo de nieve. Muestra las tablas, columnas, claves primarias, claves forneas, cardinalidad, reglas de integridad referencial, e ndices.

El diseo fsico de las bases de datos de destino de BI

Los componentes de diseo de base de datos fsicos incluyen la colocacin de conjunto de datos, la colocacin ndice, particin, agrupacin, y la indexacin. Estos componentes de base de datos fsicos se deben definir al DBMS cuando se crean las bases de datos de destino de BI.

Lenguaje de definicin de datos

El DDL es un conjunto de instrucciones SQL que le dice a los DBMS qu tipos de estructuras de base de datos fsicos para crear, como bases de datos, espacios de tablas, tablas, columnas e ndices.

Lenguaje de control de datos

El DCL es un conjunto de instrucciones SQL que le dice a los DBMS qu tipos de acceso CRUD a conceder a personas, grupos, programas y herramientas.

Bases de datos de destino de BI Fsicas

Running (ejecucin) las sentencias DDL y DCL construye las bases de datos de destino de BI reales.

Procedimientos de mantenimiento de bases de datos

Estos procedimientos describen el tiempo y la frecuencia asignada para la realizacin de las actividades de mantenimiento de bases de datos en curso, como las copias de seguridad de bases de datos, la recuperacin (incluida la recuperacin de desastres), y reorganizaciones de bases de datos. Los procedimientos tambin deben especificar el proceso para y la frecuencia de las actividades de supervisin del rendimiento.Roles involucrados en estas actividadesDesarrollador principal de aplicaciones

El desarrollador principal de aplicaciones y el administrador de base de datos deben revisar todas las lecciones aprendidas durante las actividades de creacin de prototipos. El desarrollador principal aplicacin debe ayudar al administrador de la base determinar qu consultas e informes se pueden ejecutar en paralelo y qu tipo de seguridad se necesitan.

Administrador de Data

El administrador de datos debe proporcionar el modelo de datos lgicos y los metadatos para el administrador de la base. El modelo de datos lgicos y los meta datos ser til para el administrador de base de datos cuando l o ella disea las bases de datos de destino de BI. Esto es cierto incluso si un esquema de diseo de base de datos multidimensional fue elegido porque las entidades y relaciones en el modelo de datos lgicos son el punto de partida perfecto para disear medidas y dimensiones normalizadas conformada copo de nieve.

Administrador de base de datos

El administrador de base de datos tiene la responsabilidad primordial para el diseo de bases de datos. l o ella necesita saber los caminos de acceso, pesan los volmenes de datos proyectados y factores de crecimiento, y comprender las limitaciones de la plataforma. l o ella debe crear y ejecutar el DDL y DCL para construir las bases de datos fsicos. Adems, l o ella es responsable de la eleccin de las opciones de aplicacin ms adecuadas.

Los administradores de bases de datos, no los programadores, deberan disear bases de datos. Diseo de base de datos por lo general es y debe ser parte de la descripcin del trabajo de los administradores de bases de datos, ya que requiere una formacin especial a productos especficos en el optimizador del DBMS.

Desarrollador principal ETL

El proceso ETL depende de la base de datos de diseo. El desarrollador principal ETL debe participar en las actividades de diseo de base de datos con el fin de mantenerte informado de cualquier cambio de diseo de bases de datos que afectarn el proceso de ETL o las especificaciones de programacin ETL.Los riesgos de no realizar el trmite 8Las mesas no son archivos planos en una base de datos, y no son slo una forma diferente para almacenar casualmente algunos datos. Motores DBMS relacional se basan en conjuntos internos intrincados de reglas. Estas reglas deben ser entendidos y seguidos. Organizaciones contratan administradores de bases de datos para hacer precisamente eso. Sin embargo, con demasiada frecuencia los programadores que no estn muy familiarizados con el funcionamiento interno de sus motores DBMS se les permite disear las bases de datos de destino de BI, y disean ellos mal. Esto podra tener un efecto catastrfico en el rendimiento. De hecho, podra matar a la aplicacin de BI, si no toda la iniciativa de apoyo a decisiones de BI.Capitulo9Estrategias de implementacinHay varios tipos de estrategias de implementacin de BI de apoyo a decisiones con todas las combinaciones imaginables de las bases de datos de destino de BI (por ejemplo, almacn de datos operativa y de almacenamiento de datos de la empresa; almacn Web y datos marts; almacenes de exploracin y bases de datos de minera de datos, data marts y data marts operacionales [oper marts]). Con mucho, la estrategia de aplicacin ms popular es un entorno de mercado de datos.

Independientemente de la implementacin de la estrategia se selecciona, hay una manera correcta y una manera incorrecta de ponerlo en prctica. El camino equivocado es la construccin de un conjunto de bases de datos de destino de BI independientes, cada uno con su propio proceso de ETL independiente. Este enfoque no va a producir un entorno de apoyo a decisiones integrada y reconciliada BI porque la creacin de procesos ETL separadas no es diferente de desarrollo de sistemas de apoyo a las decisiones de copa tradicionales.

La forma correcta de poner en prctica una estrategia elegida es construir un entorno de apoyo a las decisiones de BI en la que todas las bases de datos de destino de BI se integran y se reconciliaron. Cuando la construccin de este entorno, es fundamental para llevar a cabo las transformaciones de datos comunes para todas las bases de datos de destino de BI slo una vez y para reconciliar estas transformaciones de datos de vuelta a la operativa archivos de origen y bases de datos de origen. Esto demostrar la validez de los datos en las diversas bases de datos de destino BI. Tambin es importante conciliar todos los datos a travs de las diferentes bases de datos de destino de BI con el fin de demostrar la consistencia de los datos entre las distintas bases de datos de destino BI. Ambos procesos de reconciliacin se logra mejor con un esfuerzo coordinado para todos los ETL bases de datos de destino BI, como se ilustra en la Figura 9.2.

Figura 9.2. Estrategia de Implementacin Integrado BI

La regla ETL ms importante para una estrategia de implementacin de BI integrada es compartir un proceso de ETL coordinada. Esto es lo que diferencia a BI desde un enfoque tradicional de apoyo a decisiones.Preparacin para el Proceso ETLEl proceso ETL comienza con los preparativos para el reformateo, conciliar, y la limpieza de los datos de origen.

Cmo reformatear: Los datos de origen que residen en varios diferentes archivos de origen y bases de datos de origen, cada uno con su propio formato, tendr que ser unificados en un formato comn durante el proceso ETL.

Conciliacin: La enorme cantidad de datos de las organizaciones de los puntos a la redundancia de escalonamiento, que invariablemente resulta en inconsistencias asombrosas. Estos tienen que ser encontrado y reconciliado durante el proceso ETL.

Limpieza: Los datos sucios encontrados durante el anlisis de datos y creacin de prototipos tendrn que ser limpiados durante este proceso.

Antes de disear el proceso de ETL, es necesario revisar lo siguiente:

Record diseos de la actual, as como los archivos de origen histricas

Descripcin de datos bloques para la actual, as como las bases de datos fuente histricas

Especificaciones de datos de limpieza de los elementos de datos de origen

La mayor fuente de datos para el proceso de ETL son datos operativos actuales de los sistemas operativos, pero algunos de los datos de origen puede ser archivada datos histricos.

Tabla 9.1. Conjuntos de Programas ETL Carga inicialCargar HistricoCarga IncrementalPoblacin inicial de las bases de datos de destino de BI con los datos de funcionamiento actualPoblacin inicial de las bases de datos de BI de destino con datos histricos archivadosPoblacin permanente de las bases de datos de destino de BI con los datos de funcionamiento actual123

Si los requisitos de datos incluyen un par de aos de la historia para ser rellenados desde el principio, tres conjuntos de programas ETL deben ser diseados y desarrollados, que se enumeran en la Tabla 9.1.

Si se toma la decisin de escribir los programas de ETL en un lenguaje de procedimientos (por ejemplo, C ++ o COBOL), las especificaciones de transformacin para los tres conjuntos de programas deben estar preparados y entregados a los desarrolladores de ETL. Si se utiliza una herramienta ETL, instrucciones de ETL (datos tcnicos meta) se deben crear para los tres conjuntos de procesos de carga. Los metadatos tcnicos ETL reflejarn la misma lgica que habra sido escrito en programas personalizados si ninguna herramienta ETL haba estado disponible. Los datos tcnicos meta deben ser almacenados en un repositorio de datos meta.

La carga inicialEl proceso de preparacin de los programas de carga inicial es muy similar a un proceso de conversin del sistema, como el que muchas organizaciones realizan cuando se mueven sus sistemas operativos antiguos a una planificacin de recursos empresariales (ERP) de producto. En general, la primera tarea de un proceso de conversin del sistema es mapear elementos de datos seleccionados de los archivos de origen o bases de datos de origen a los elementos de datos ms adecuadas en los archivos de destino o bases de datos de destino. Un "elemento de datos ms adecuada" en una base de datos de archivo de destino o de destino es uno que es el ms parecido en el nombre, definicin, tamao, longitud y funcionalidad que el elemento de datos de origen. La segunda tarea de un proceso de conversin sistema es escribir los programas de conversin (transformacin) para transformar los datos de origen. Estos programas de conversin tambin deben resolver registros duplicados, haga coincidir las claves primarias y truncar o ampliar el tamao de los elementos de datos.

Por lo general, falta de programas de conversin, y por desgracia tambin falta en la mayora de los procesos ETL, son la limpieza y la reconciliacin de datos. Organizaciones en repetidas ocasiones se pierda principales oportunidades de poner orden en su caos de datos cuando se siguen "chupar y desembolsar" los datos del origen al destino inmediato. Su nica preocupacin es que la estructura de la base receptora no rechaza los datos de origen por razones tcnicas, tales como claves duplicadas, o tipo de datos y violacines de longitud. Eso no es lo suficientemente bueno para aplicaciones de BI, porque los empresarios esperan que la calidad de los datos y la consistencia de los datos por razones de negocios. Por lo tanto, en el diseo de los procesos de carga, limpieza de datos y la reconciliacin deben formar parte del flujo de procesos ETL.

La carga histricaEl proceso de carga histrica podra ser visto como una extensin del proceso de carga inicial, pero este tipo de conversin es ligeramente diferente porque los datos histricos son datos estticos. En contraste con los datos activos operacionales, los datos esttica ha cumplido su objetivo operacional y est archivado a fuera de lnea de dispositivos de almacenamiento. La implicacin es que, como expira algunos datos antiguos y algunos nuevos datos se aaden en los ltimos aos, los diseos de registros de archivos archivados por lo general no estn en sintona con los diseos de registros de los archivos operacionales actuales. Por lo tanto, los programas de conversin escritas para los archivos operacionales actuales por lo general no se pueden aplicar a los archivos histricos archivados sin algunos cambios. Por ejemplo, en un sistema operativo que cambian con frecuencia, no es raro que los cinco aos de los archivos histricos archivados tienen cinco (o ms) los diseos de registros ligeramente diferentes. A pesar de las diferencias en los diseos de registros pueden no ser drstica, todava tienen que reconciliarse. Adems, la limpieza de los datos no puede ser el mismo en todos los archivos guardados. Lo que antes era vlido en un archivo histrico ya no sea vlida. Las especificaciones de transformacin de datos tienen que hacer frente a estas diferencias y reconciliarlos. Todos estos factores contribuyen a las razones por las que el proceso de ETL puede ser muy largo y muy complicado.

La carga incrementalUna vez que los procesos para poblar las bases de datos de destino de BI con datos iniciales e histricos se han ideado, otro proceso debe estar diseado para la carga incremental en curso (mensual, semanal o diaria). Cargas incrementales se puede lograr de dos maneras, extraer todos los registros o deltas solamente, como se muestra en la Tabla 9.2. El diseo del proceso de extraccin ETL ser diferente dependiendo de la opcin est seleccionada.

Tabla 9.2. Cargar opciones incrementales Extracto Todos Los RegistrosSlo Extraer DeltasExtraer los datos de origen de todos los registros operativos, sin importar si los valores de datos han cambiado desde la ltima carga ETL o no.Datos de origen extraer slo de aquellos registros operativos en los que algunos valores de datos han cambiado desde la ltima carga ETL ("cambio neto").

Extraer todos los archivos a menudo no es una opcin viable debido a los volmenes enormes de datos implicados. Por lo tanto, muchas organizaciones optan por extractos delta (extrayendo slo los registros que cambiaron). Disear programas de ETL para la extraccin de delta es mucho ms fcil cuando los datos de origen reside en las bases de datos relacionales y la marca de tiempo se puede utilizar para determinar los deltas. Pero cuando los datos se almacenan en archivos planos sin una marca de tiempo, el proceso de extraccin puede ser significativamente ms compleja. Es posible que tenga que recurrir a la lectura de las pistas de auditora operacional para determinar qu registros han cambiado.

Una alternativa puede ser la de extraer una copia completa del archivo de origen para cada carga, y luego comparar el nuevo extracto al extracto anterior para encontrar los registros que cambiar y crear su propio archivo delta. Otra alternativa es pedirle al personal de sistemas operativos para agregar una marca de tiempo del sistema para sus archivos operacionales. De vez en cuando pueden estar de acuerdo en hacerlo si el cambio a sus sistemas operativos es trivial y no afecta a muchos programas. Sin embargo, en la mayora de las operaciones de los casos los administradores no estarn de acuerdo en que, debido a los cambios en sus estructuras de archivos tambin requeriran cambios en sus programas de entrada y de actualizacin de datos. Cdigo adicional tendra que ser por escrito para esos programas para capturar la fecha y hora del sistema. No sera rentable para que cambien sus sistemas operativos de misin crtica y pasan mucho tiempo en la regresin prueba-slo para el beneficio de una aplicacin de BI.

Procesamiento de Registros eliminadosOtro aspecto que debe ser considerado cuidadosamente para cargas incrementales es que los registros de origen operacionales borrados. Cuando ciertos registros son lgicamente borrados de los archivos de origen y bases de datos fuente (marcado como eliminado, pero no se elimina fsicamente), las filas correspondientes no pueden ser borrados automticamente de las bases de datos de destino de BI. Despus de todo, uno de los principales requisitos de las bases de datos de destino BI es para almacenar datos histricos.

El proceso ETL debe seguir una serie de reglas de negocio, que debe definir cundo una delecin operativa debe propagar en las bases de datos de destino de BI y cuando no debera. Por ejemplo, tal vez est siendo borrado un registro operativo porque fue creado anteriormente por error, o porque el registro est siendo archivada, o porque los sistema almacena operativos slo las transacciones "abiertos" y elimina los "cerrados". Lo ms probable, las reglas de negocio sera afirmar que debe eliminar la fila relacionada de la base de datos destino BI slo en el caso en que se cre el registro en el error. Dado que los datos de BI sus base de datos almacena objetivo histricos, las reglas de negocio probablemente no permitir borrar la fila relacionada en los otros dos casos.

Cuando los registros se eliminan fsicamente de los archivos de origen o bases de datos de origen, que nunca se sabe si est extrayendo slo los deltas. Programas de extracto de Delta estn diseados para extraer slo aquellos registros existentes en el que uno de los valores de datos ha cambiado; no pueden extraer registros que no existen. Una forma de encontrar los registros eliminados fsicamente es leer las pistas de auditora operativa. Otra opcin es extraer una copia completa del archivo fuente, compare el nuevo extracto al extracto anterior para encontrar los registros que se han eliminado, y luego crear sus propios archivos delta. En cualquier caso, una vez que se identifican los registros eliminados, el proceso ETL tiene que seguir una serie de reglas de negocio para decidir si debe o no eliminar fsicamente las filas relacionadas de las bases de datos de destino de BI.El diseo de los Programas ExtractoDesde la perspectiva de los sistemas operativos, la forma ms favorecida para crear extractos podra ser simplemente duplicar todo el contenido de los archivos de origen operativos y bases de datos de origen y dar los duplicados en el equipo del proyecto de BI. Sin embargo, los desarrolladores de ETL tendran la carga de trabajo con archivos de gran tamao cuando slo necesitan un subconjunto de los datos de origen.

Desde la perspectiva del proyecto de BI, la forma ms favorecida para crear extractos podra ser la de ordenar, filtrar, limpiar, y agregar todos los datos requeridos en un solo paso si es posible y para hacerlo bien en la fuente. Sin embargo, en algunas organizaciones que podran afectar los sistemas operativos en un grado tal que las funciones de negocio operacionales tendran que ser suspendido por varias horas.

La solucin suele ser un compromiso: los programas estn diseados para extraer el procesamiento ETL ms eficiente, pero siempre con un enfoque en conseguir los datos de origen necesarios lo antes posible. El objetivo es conseguir que fuera del camino de los sistemas operativos para que las funciones diarias del negocio no se ven afectados. Esto es ms fcil decirlo que hacerlo, por una serie de razones.

La seleccin y combinacin de los datos de los archivos de origen y bases de datos de origen puede ser un reto debido a la alta redundancia de datos en los sistemas operativos. Los programas de extracto deben saber cul de los archivos de cdigo fuente redundante o bases de datos de origen son los sistemas de registro. Por ejemplo, el elemento de datos misma fuente (por ejemplo, Nombre del cliente) puede existir en decenas de archivos de origen y bases de datos de origen. Estos hechos redundantes tienen que ser resuelto y consolidado, que implica una serie de especie y combinar medidas, impulsadas por una serie de tablas de bsqueda de referencias cruzadas teclas especficas y valores de datos.

Otra manera de producir extraer archivos pequeos y relativamente limpias es extraer slo aquellos elementos de datos de origen que son necesarios para la aplicacin de BI y resolver slo los problemas de calidad de datos de origen que se refieren a las reglas de dominio de datos de negocios, sin tratar de resolver y consolidar ocurrencias redundantes de datos. Sin embargo, incluso que el compromiso no va a funcionar en muchas organizaciones grandes, porque el proceso de datos en la limpieza podra ralentizar el proceso de extraccin, que a su vez atar los sistemas operativos ms tiempo que es aceptable.

En muchas organizaciones grandes, el equipo del proyecto de BI es la suerte de conseguir tres o cuatro horas de tiempo de procesamiento en contra de los sistemas operativos antes de que esos sistemas operativos tienen que "ir a vivir" para las funciones operativas del siguiente da hbil. Esta es la razn principal por la que poblar las bases de datos de destino de BI se divide en tres procesos independientes: extraccin, transformacin y carga (Figura 9.3).

Figura 9.3. Procesos ETLEl diseo de los programas de transformacinUsando la regla 80/20, 80 por ciento del trabajo de ETL se produce en la "T" (transformar) parte cuando se requiere la integracin de datos extensas y limpieza de datos, mientras que la extraccin y carga representa slo el 20 por ciento del proceso ETL.

Fuente Problemas de DatosEl diseo de los programas de transformacin puede llegar a ser muy complicado cuando los datos se extrae de un entorno operativo heterogneo. Algunos de los problemas tpicos de datos de origen se describen a continuacin.

Inconsistente claves principales: Las claves principales de los registros de datos de origen no siempre coinciden con la nueva clave principal de las tablas de BI. Por ejemplo, podra haber cinco archivos de clientes, cada uno con una llave de cliente diferente. Estas diferentes claves de los clientes se consolidaran o transformados en una de las claves del cliente BI estandarizado. La clave del cliente BI probablemente sera un nuevo sustituto clave ("-up hecho") y no se correspondera con cualquiera de las teclas de operacin, como se ilustra en la Figura 9.4.

Figura 9.4. Resolucin de Inconsistente claves principales

Valores de datos inconsistentes: Muchas organizaciones duplican muchos de sus datos. El trmino duplicado normalmente significa que el elemento de datos es una copia exacta de la original. Sin embargo, con el tiempo, estos duplicados terminan con completamente diferentes valores de datos a causa de anomalas de actualizacin (actualizaciones inconsistentes aplicadas a los duplicados), que tienen que ser reconciliada en el proceso ETL.

Diferentes formatos de datos: Los elementos de datos como fechas y monedas pueden ser almacenados en un formato completamente diferente en los archivos de origen de lo que se almacenan en las bases de datos de destino de BI. Si ya existen mdulos de fecha y de conversin de divisas, que necesitan ser identificados; de lo contrario, la lgica para esta transformacin tiene que ser desarrollado.

Valores de datos inexactos: la lgica de limpieza tiene que ser definido para corregir los valores de datos inexactos. Parte de la lgica de los datos-limpieza puede llegar a ser extremadamente complicado y largo. La correccin de una violacin de datos puede tener varias pginas de las instrucci