Almacenamento de datos e planificación de recursos empresariais | DWH e ERP

ARQUIVO DATOS CENTRAL: HISTORIA ED EVOLUCIÓNS

Os dous temas dominantes da tecnoloxía corporativa na década de 90 foron i data warehouse e ERP. Durante moito tempo estas dúas poderosas correntes formaron parte da TI corporativa sen nunca ter interseccións. Era case coma se fosen materia e antimateria. Pero o crecemento de ambos fenómenos levou inevitablemente á súa intersección. Hoxe as empresas afrontan o problema de que facer co ERP e data warehouse. Este artigo explicará cales son os problemas e como as empresas están a abordalos.

AO INICIO…

Ao principio estaba o data warehouse. Almacén de datos foi creado para contrarrestar o sistema de aplicación de procesamento de transaccións. Nos primeiros tempos a memorización de datos pretendía ser só un contrapunto ás aplicacións de procesamento de transaccións. Pero hoxe en día hai visións moito máis sofisticadas do que a data warehouse. No mundo actual o data warehouse insírese dentro dunha estrutura que se pode denominar Fábrica de Información Corporativa.

A FÁBRICA DE INFORMACIÓN CORPORATIVA (CIF)

A Fábrica de Información Corporativa ten compoñentes arquitectónicos estándar: un nivel de transformación e integración de código que integra o datos mentres eu datos móvense do contorno de aplicación cara ao contorno de data warehouse da empresa; a data warehouse da empresa onde o datos historias detalladas e integradas. O data warehouse da empresa serve como base sobre a que se poden construír todas as outras partes do medio ambiente data warehouse; un almacén de datos operativos (ODS). Un ODS é unha estrutura híbrida que contén algúns aspectos do data warehouse e outros aspectos dun ambiente OLTP; data marts, onde os diferentes departamentos poden ter a súa propia versión do data warehouse; a data warehouse de exploración na que os “filósofos” da compañía poden enviar as súas consultas durante 72 horas sen que afecte a data warehouse; e unha memoria de liña próxima, na que datos vello e datos os detalles a granel pódense almacenar de xeito económico.

ONDE ERP SE UNE A LA FÁBRICA DE INFORMACIÓN CORPORATIVA

O ERP fusiona coa Fábrica de Información Corporativa en dous lugares. Primeiro como aplicación básica (línea de base) que proporciona i datos da aplicación a data warehouse. Neste caso i datos, xerados como subproduto dun proceso de transacción, intégranse e cárganse no data warehouse da empresa. O segundo punto de unión entre ERP e CIF e ODS. De feito, en moitos ambientes o ERP úsase como un ODS clásico.

No caso de que se utilice ERP como aplicación básica, o mesmo ERP tamén se pode utilizar no CIF como ODS. En calquera caso, se se quere empregar o ERP en ambas as funcións, debe haber unha distinción clara entre as dúas entidades. Noutras palabras, cando o ERP desempeña o papel de aplicación central e ODS, hai que distinguir as dúas entidades arquitectónicas. Se unha soa implementación de ERP tenta desempeñar ambas funcións simultaneamente, inevitablemente haberá problemas no deseño e implementación desa estrutura.

SEPARAR ODS E APLICACIÓNS BÁSICAS

Hai moitas razóns que levan á división dos compoñentes arquitectónicos. Quizais o problema máis revelador para separar os diferentes compoñentes dunha arquitectura é que cada compoñente da arquitectura ten a súa propia visión. A aplicación de referencia ten un propósito diferente ao da ODS. Intente solapar

unha visión de aplicación de referencia sobre o mundo dunha ODS ou viceversa non é unha forma correcta de traballar.

En consecuencia, o primeiro problema dun ERP no CIF é verificar se existe distinción entre as aplicacións de referencia e as ODS.

MODELOS DE DATOS NA CORPORATIVA FÁBRICA DE INFORMACIÓN

Para conseguir a cohesión entre os distintos compoñentes da arquitectura CIF, debe existir un modelo de datos. Os modelos de datos serven de enlace entre os distintos compoñentes da arquitectura, como as aplicacións de referencia e o ODS. Os modelos de datos convértense na “folla de ruta intelectual” para obter o sentido correcto dos distintos compoñentes arquitectónicos do CIF.

Indo da man con esta noción, a idea é que debería haber un modelo grande e único de datos. Obviamente ten que haber un modelo de datos para cada un dos compoñentes e ademais debe existir un camiño sensato que conecte os distintos modelos. Cada compoñente da arquitectura: ODS, aplicacións de referencia, data warehouse da empresa, etc.. – precisa dun modelo propio datos. E por iso ten que haber unha definición precisa de como estes modelos datos interactúan entre si.

MOVE I DATOS DO ERP EN DATA ALMACENAMENTO

Se a orixe de datos é unha aplicación de referencia e/ou un ODS, cando o ERP insire o datos en data warehouse, esta inserción debe realizarse no nivel máis baixo de "granularidade". Simplemente resuma ou agregue i datos como saen da aplicación ERP baseline ou ERP ODS non é o correcto. O datos os detalles son necesarios en data warehouse para formar a base do proceso DSS. Tal datos serán remodelados de moitas maneiras mediante data marts e exploracións de data warehouse.

O desprazamento de datos desde o entorno de aplicación de referencia ERP ata o data warehouse da empresa faise dun xeito razoablemente relaxado. Este movemento ocorre aproximadamente 24 horas despois da actualización ou creación no ERP. O feito de ter un movemento "preguiceiro" do datos en data warehouse da empresa permite o datos procedente do ERP para “depositar”. Unha vez que eu datos están almacenados na aplicación de liña base, entón pode mover con seguridade o datos de ERP na empresa. Outro obxectivo alcanzable grazas ao movemento "preguiceiro" do datos é a clara delimitación entre procesos operativos e DSS. Cun movemento "rápido" do datos a liña divisoria entre DSS e operativo segue sendo vaga.

O movemento de datos desde o ERP ODS ata data warehouse da empresa realízase periódicamente, normalmente semanalmente ou mensualmente. Neste caso o movemento de datos baséase na necesidade de “limpar” o vello datos historiadores. Por suposto, o ODS contén i datos que son moito máis recentes que os datos historiadores atopados en data warehouse.

O desprazamento de datos en data warehouse case nunca se fai "por xunto" (de forma maiorista). Copia unha táboa do entorno ERP a data warehouse non ten sentido. Un enfoque moito máis realista é mover as unidades seleccionadas do datos. Só o datos que cambiaron desde a última actualización de data warehouse son os que deberían ser trasladados ao data warehouse. Unha forma de saber cales datos cambiaron desde a última actualización é mirar as marcas de tempo do datos atopado no entorno ERP. O deseñador selecciona todos os cambios que se produciron desde a última actualización. Outro enfoque é utilizar técnicas de captura de cambios datos. Con estas técnicas analízanse rexistros e cintas de diario para determinar cales son datos debe moverse do entorno ERP ao de data warehouse. Estas técnicas son mellores porque os rexistros e as cintas de diario pódense ler desde ficheiros ERP sen afectar máis a outros recursos ERP.

OUTRAS COMPLICACIÓNS

Un dos problemas de ERP en CIF é o que ocorre con outras fontes de aplicacións ou con datos das SAO que deben contribuír data warehouse pero non forman parte do entorno ERP. Dada a natureza pechada do ERP, especialmente SAP, intentando integrar claves de fontes externas datos con i datos que veñen do ERP ao mover o datos en data warehouse, é un gran reto. E cales son exactamente as probabilidades de que i datos de aplicacións ou ODS fóra do contorno ERP integraranse no data warehouse? As probabilidades son en realidade moi altas.

BUSCAR DATOS HISTÓRICO DE ERP

Outro problema con i datos de ERP é o derivado da necesidade de ter datos historiadores dentro do data warehouse. Normalmente o data warehouse necesidades datos historiadores. E a tecnoloxía ERP normalmente non almacena estes datos histórico, polo menos non ata o punto de que sexa necesario no data warehouse. Cando unha gran cantidade de datos a historia comeza a acumularse no ambiente ERP, ese ambiente debe ser limpo. Por exemplo, supoña que a data warehouse debe estar cargado con cinco anos de datos histórico mentres que o ERP conserva un máximo de seis meses destes datos. Sempre que a empresa estea satisfeita con recoller unha serie de datos historiadores a medida que pasa o tempo, entón non hai ningún problema en utilizar o ERP como fonte para o data warehouse. Pero cando o data warehouse ten que retroceder no tempo e conseguir deuses datos historias que non foron previamente recollidas e gardadas polo ERP, entón o ambiente ERP vólvese ineficiente.

ERP E METADATOS

Outra consideración a facer sobre o ERP e data warehouse é o dos metadatos existentes no contorno ERP. Do mesmo xeito que os metadatos flúen do contorno ERP ao data warehouse, os metadatos deben moverse do mesmo xeito. Ademais, os metadatos deben transformarse no formato e estrutura requiridos pola infraestrutura do data warehouse. Hai unha gran diferenza entre os metadatos operativos e os metadatos DSS. Os metadatos operativos son principalmente para o programador e o

programador. Os metadatos DSS son principalmente para o usuario final. Os metadatos existentes en aplicacións ERP ou ODS deben converterse, e esta conversión non sempre é sinxela e sinxela.

FONTE DE DATOS DO ERP

Se se usa ERP como provedor de datos para data warehouse debe haber unha interface sólida que move o datos de entorno ERP a entorno data warehouse. A interface debe:

• ▪ ser doado de usar
• ▪ permitir o acceso a datos do ERP
• ▪ tomar o significado de datos que están a piques de ser trasladados ao data warehouse
• ▪ coñecer as limitacións do ERP que poden xurdir ao acceder ao datos do ERP:
• ▪ integridade referencial
• ▪ relacións xerárquicas
• ▪ relacións lóxicas implícitas
• ▪ convenio de aplicación
• ▪ todas as estruturas de datos apoiado polo ERP, etc.
• ▪ ser eficiente no acceso datos, proporcionando:
• ▪ movemento directo de datos
• ▪ adquisición do cambio datos
• ▪ apoiar o acceso oportuno a datos
• ▪ comprender o formato de datos, etcétera… INTERFACCIÓN CON SAP A interface pode ser de dous tipos, propia ou comercial. Algunhas das principais interfaces comerciais inclúen:

• ▪ SAS
• ▪ Prims Solutions
• ▪ D2k, etc. MÚLTIPLES TECNOLOXÍAS ERP Tratar o entorno ERP coma se fose unha soa tecnoloxía é un gran erro. Hai moitas tecnoloxías ERP, cada unha coas súas propias fortalezas. Os vendedores máis coñecidos do mercado son:

• ▪ SAP
• ▪ Oracle Financials
• ▪ PeopleSoft
• ▪ JD Edwards
• ▪ Baan SAP SAP é o software ERP máis grande e completo. As aplicacións SAP inclúen moitos tipos de aplicacións en moitas áreas. SAP ten fama de ser:

• ▪ moi grande
• ▪ moi difícil e caro de implementar
• ▪ precisa de moitas persoas e consultores para implantarse
• ▪ require persoas especializadas para a súa implantación
• ▪ leva moito tempo a implementar Ademais, SAP ten a reputación de memorizar o seu datos con moito coidado, o que dificulta que alguén fóra da área SAP acceda a eles. O punto forte de SAP é que é capaz de capturar e almacenar unha gran cantidade de datos. Recentemente SAP anunciou a súa intención de estender as súas aplicacións a data warehouse. Hai moitos pros e contras de usar SAP como provedor data warehouse. Unha vantaxe é que SAP xa está instalado e que a maioría dos consultores xa coñecen SAP.
  As desvantaxes de ter SAP como provedor data warehouse hai moitos: SAP non ten experiencia no mundo de data warehouse Se SAP é o provedor de data warehouse, hai que “sacar” i datos de SAP a data warehouse. Dato un historial de SAP de sistema pechado, é improbable que sexa fácil introducir i desde SAP nel (???). Hai moitos entornos legados que alimentan SAP, como IMS, VSAM, ADABAS, ORACLE, DB2, etc. SAP insiste nun enfoque "non inventado aquí". SAP non quere asociarse con outros provedores para usar ou crear data warehouse. SAP insiste en xerar todo o seu software por si mesmo.

Aínda que SAP é unha empresa grande e poderosa, intenta reescribir a tecnoloxía de ELT, OLAP, a administración do sistema e mesmo o código principal de dbms é só tolo. En lugar de adoptar unha actitude de cooperación cos provedores de data warehouse Desde hai moito tempo, SAP seguiu o enfoque de "ellos mellor saben". Esta actitude frea o éxito que SAP podería ter na área de data warehouse.
A negativa de SAP a permitir que os provedores externos accedan de forma rápida e graciosa aos seus datos. A esencia mesma de usar a data warehouse é de fácil acceso datos. Todo o historial de SAP baséase en dificultar o acceso datos.
A falta de experiencia de SAP no manexo de grandes volumes de datos; no campo de data warehouse hai volumes de datos nunca visto por SAP e xestionar estas grandes cantidades de datos cómpre ter tecnoloxía adecuada. Aparentemente SAP non é consciente desta barreira tecnolóxica que existe para entrar no campo de data warehouse.
Cultura corporativa de SAP: SAP fixo un negocio de conseguir o datos do sistema. Pero para iso hai que ter unha mentalidade diferente. Tradicionalmente, as empresas de software que eran boas para introducir datos nun ambiente non foron boas para conseguir que os datos fosen para outro lado. Se SAP consegue realizar este tipo de cambios, será a primeira empresa en facelo.

En resumo, é cuestionable se unha empresa debe seleccionar SAP como o seu provedor data warehouse. Hai riscos moi graves por un lado e moi poucas recompensas por outro. Pero hai outro motivo que desanima a elección de SAP como provedor data warehouse. Porque todas as empresas deberían ter o mesmo data warehouse de todas as outras empresas? O data warehouse é o corazón da vantaxe competitiva. Se todas as empresas adoptasen o mesmo data warehouse sería difícil, aínda que non imposible, conseguir unha vantaxe competitiva. SAP parece pensar que a data warehouse pódese ver como unha cookie e isto é un sinal máis da súa mentalidade de "obter os datos en" das aplicacións.

Ningún outro provedor de ERP é tan dominante como SAP. Sen dúbida haberá empresas que seguirán o camiño de SAP pola súa data warehouse pero presuntamente estes data warehouse SAP será grande, caro e levará moito tempo para crear.

Estes entornos inclúen actividades como o procesamento de caixeiros bancarios, os procesos de reserva de compañías aéreas, os procesos de reclamacións de seguros, etc. Canto máis rendible era o sistema de transaccións, máis evidente era a necesidade de separar o proceso operativo e o DSS (Decision Support System). Non obstante, cos sistemas de RRHH e persoal, nunca se enfronta a grandes volumes de transaccións. E, por suposto, cando unha persoa é contratada ou deixa a empresa este é un rexistro dunha transacción. Pero en relación con outros sistemas, os sistemas de recursos humanos e de persoal simplemente non teñen moitas transaccións. Polo tanto, nos sistemas de RRHH e persoal non é totalmente obvio que haxa necesidade dun DataWarehouse. En moitos aspectos, estes sistemas representan a fusión de sistemas DSS.

Pero hai outro factor que debes ter en conta se tes que tratar con almacéns de datos e PeopleSoft. En moitos ambientes, i datos dos recursos humanos e persoais son secundarios ao negocio principal da empresa. A maioría das empresas dedícanse á fabricación, venda, prestación de servizos, etc. Os recursos humanos e os sistemas de persoal adoitan ser secundarios (ou apoiar) a principal liña de negocio da empresa. Polo tanto, é equívoco e inconveniente data warehouse separado para recursos humanos e apoio persoal.

PeopleSoft é moi diferente de SAP neste sentido. Con SAP, é obrigatorio que haxa un data warehouse. Con PeopleSoft, non está tan claro. Un almacén de datos é opcional con PeopleSoft.

O mellor que se pode dicir para i datos PeopleSoft é que o data warehouse pódese usar para arquivar i datos relativos a antigos recursos humanos e persoais. Unha segunda razón pola que unha empresa querería utilizar a data warehouse a

prexuízo do ambiente PeopleSoft é permitir o acceso e acceso gratuíto a ferramentas de análise, para datos por PeopleSoft. Pero máis aló destas razóns, pode haber casos nos que é preferible non ter un almacén de datos para datos PeopleSoft.

En resumo

Hai moitas ideas sobre a construción dun data warehouse dentro de un software ERP.
Algúns destes son:

• ▪ Ten sentido ter un data warehouse iso é como calquera outra cousa na industria?
• ▪ Que tan flexible é un ERP data warehouse software?
• ▪ Un ERP data warehouse o software pode xestionar un volume de datos que está situado nundata warehouse arena"?
• ▪ Cal é a gravación de rastrexo que fai o provedor de ERP ante un fácil e barato, en termos de tempo, datos? (Cal é o historial dos provedores de ERP na entrega de datos económicos, a tempo e de fácil acceso?)
• ▪ Cal é a comprensión do provedor de ERP da arquitectura DSS e da fábrica de información corporativa?
• ▪ Os provedores de ERP entenden como conseguir datos dentro do medio ambiente, pero tamén entende como exportalos?
• ▪ Que aberto está o provedor de ERP ás ferramentas de almacenamento de datos?
  Todas estas consideracións deben terse en conta para determinar onde colocar data warehouse que acollerá i datos de ERP e outros datos. En xeral, a menos que exista unha razón convincente para facer o contrario, recoméndase a construción data warehouse fóra do entorno do provedor de ERP. CAPÍTULO 1 Visión xeral dos puntos clave da organización de BI:
  Os repositorios de información funcionan ao revés da arquitectura de intelixencia empresarial (BI):
  A cultura corporativa e as TI poden limitar o éxito na creación de organizacións de BI.

A tecnoloxía xa non é o factor limitante para as organizacións de BI. A pregunta para os arquitectos e os planificadores de proxectos non é se existe a tecnoloxía, senón se poden implementar efectivamente a tecnoloxía dispoñible.

Para moitas empresas a data warehouse é pouco máis que un depósito pasivo que distribúe o datos aos usuarios que o precisen. O datos extráense dos sistemas fonte e enchéganse en estruturas de destino de data warehouse. O datos tamén se poden limpar con sorte. Non obstante, non se engade nin recolle ningún valor adicional datos durante este proceso.

Esencialmente, o Dw pasivo, no mellor dos casos, só proporciona i datos limpo e operativo para as asociacións de usuarios. A creación de información e a comprensión analítica dependen totalmente dos usuarios. Xulgue se o DW (Almacén de datos) é un éxito é subxectivo. Se xulgamos o éxito pola capacidade de recoller, integrar e limpar de forma eficiente o datos corporativo nunha base previsible, entón si, o DW é un éxito. Por outra banda, se observamos a recollida, consolidación e explotación da información por parte da organización no seu conxunto, entón o DW é un fracaso. Un DW proporciona pouco ou ningún valor de información. Como resultado, os usuarios vense obrigados a conformarse, creando así silos de información. Este capítulo presenta unha visión completa para resumir a arquitectura de BI (Business Intelligence) da empresa. Comezamos cunha descrición da BI e despois pasamos ás discusións sobre o deseño e desenvolvemento da información, en lugar de simplemente proporcionar información. datos aos usuarios. Despois, as discusións céntranse en calcular o valor dos teus esforzos de BI. Concluímos definindo como IBM aborda os requisitos arquitectónicos de BI da súa organización.

Descrición da arquitectura de Organización de BI

Os poderosos sistemas de información orientados ás transaccións son agora comúns en todas as grandes empresas, o que permite igualar as condicións de xogo para as corporacións de todo o mundo.

Sen embargo, seguir sendo competitivo agora require sistemas de orientación analítica que poidan revolucionar a capacidade da empresa para redescubrir e utilizar a información que xa posúe. Estes sistemas analíticos derivan da comprensión da riqueza de datos dispoñible. A BI pode mellorar o rendemento en toda a empresa. As empresas poden mellorar as relacións entre clientes e provedores, mellorar a rendibilidade dos produtos e servizos, xerar ofertas novas e mellores, controlar o risco e, entre outras moitas ganancias, reducir os gastos de forma espectacular. Con BI a túa empresa comeza por fin a utilizar a información do cliente como un activo competitivo grazas a aplicacións que teñen obxectivos de mercado.

Ter as ferramentas comerciais adecuadas significa ter respostas definitivas a preguntas clave como:

• ▪ Cal dos nosos clientes fannos gañar máis, ou fannos perder cartos?
• ▪ Onde viven os nosos mellores clientes en relación a tenda/ almacén que frecuentan?
• ▪ Cales dos nosos produtos e servizos se poden vender de forma máis eficaz e a quen?
• ▪ Que produtos se poden vender de forma máis efectiva e a quen?
• ▪ Que campaña de vendas ten máis éxito e por que?
• ▪ Que canles de venda son máis eficaces para que produtos?
• ▪ Como podemos mellorar as relacións coas nosas mellores persoas clientes? A maioría das empresas teñen datos formas aproximadas de responder a estas preguntas.
  Os sistemas operativos xeran grandes cantidades de produto, cliente e datos mercado desde puntos de venda, reservas, atención ao cliente e sistemas de soporte técnico. O reto é extraer e explotar esta información. Moitas empresas só se benefician de pequenas fraccións das súas datos para análises estratéxicas.
  I datos restante, moitas veces unido con i datos derivada de fontes externas, como informes gobernamentais e outra información adquirida, é unha mina de ouro que está á espera de ser explorada e datos só precisan ser refinados no contexto da información da súa organización.

Este coñecemento pódese aplicar de varias maneiras, que van dende o deseño dunha estratexia corporativa global ata a comunicación persoal cos provedores, pasando por call centers, facturación, Internet e outros puntos. O entorno empresarial actual indica que DW e as solucións de BI relacionadas evolucionen máis aló da execución das estruturas comerciais tradicionais. datos que eu datos normalizados a nivel atómico e “granxas estrela/cubo”.

O que se necesita para seguir sendo competitivo é unha fusión de tecnoloxías tradicionais e avanzadas nun esforzo por apoiar un amplo panorama analítico.
Para concluír, a contorna xeral debe mellorar o coñecemento do conxunto da empresa, procurando que as actuacións realizadas como resultado das análises realizadas sexan útiles para que todos se beneficien.

Por exemplo, digamos que clasificas o teu clientes en categorías de alto ou baixo risco.
Se esta información é xerada por un extractor de modelos ou outros medios, debe ser introducida no DW e ser accesible a calquera persoa, mediante calquera ferramenta de acceso, como informes estáticos, follas de cálculo, táboas ou procesamento analítico en liña (OLAP). .

Porén, na actualidade, gran parte deste tipo de información permanece en silos datos dos individuos ou departamentos xeradores da análise. A organización, no seu conxunto, ten pouca ou ningunha visibilidade para a comprensión. Só combinando este tipo de contido de información no DW da súa empresa pode eliminar os silos de información e elevar o seu ambiente DW.
Hai dous grandes obstáculos para desenvolver unha organización de BI.
En primeiro lugar, temos o problema da propia organización e da súa disciplina.
Aínda que non podemos axudar cos cambios das políticas organizativas, podemos axudar a comprender os compoñentes da BI dunha organización, a súa arquitectura e como a tecnoloxía de IBM facilita o seu desenvolvemento.
A segunda barreira a superar é a falta de tecnoloxía integrada e coñecemento dun método que aborde todo o espazo de BI en oposición a só un pequeno compoñente.

IBM está a facer fronte aos cambios na tecnoloxía de integración. É a súa responsabilidade proporcionar un deseño coidadoso. Esta arquitectura debe desenvolverse cunha tecnoloxía escollida para unha integración sen restricións, ou, cando menos, cunha tecnoloxía que se adhira aos estándares abertos. Ademais, a dirección da súa empresa debe asegurarse de que o compromiso de BI se realiza segundo o previsto e non permitir o desenvolvemento de silos de información derivados de axendas ou obxectivos de interese propio.
Isto non quere dicir que o ambiente de BI non sexa sensible a reaccionar ás diferentes necesidades e requisitos dos diferentes usuarios; en cambio, significa que a implementación desas necesidades e requisitos individuais realízase en beneficio de toda a organización de BI.
Na figura 9 pódese atopar unha descrición da arquitectura da organización de BI na páxina 1.1. A arquitectura mostra unha rica mestura de tecnoloxías e técnicas.
Desde a visión tradicional, a arquitectura inclúe os seguintes compoñentes do almacén

Capa atómica.

Esta é a base, o corazón de todo o DW e, polo tanto, dos informes estratéxicos.
I datos almacenados aquí conservará a integridade histórica, as relacións de datos e inclúen métricas derivadas, ademais de ser limpas, integradas e almacenadas mediante a extracción de modelos.
Todo o uso posterior destes datos e a información relacionada derívase desta estrutura. Esta é unha excelente fonte para a minería datos e para informes con consultas SQL estruturadas

Depósito operativo de datos ou informe baseado en datos(Almacenamento de datos operativos (ODS) ou informes base de datos.)

Esta é unha estrutura de datos específicamente deseñados para informes técnicos.

I datos almacenadas e informadas arriba, estas estruturas poden finalmente propagarse ao almacén a través da zona de espera, onde poderían utilizarse para a sinalización estratéxica.

Zona de escenificación.

A primeira parada para a maioría datos destinada ao entorno de almacén é a zona de organización.
Aquí eu datos intégranse, límpanse e transfórmanse datos beneficios que poboarán a estrutura do almacén

Data marts.

Esta parte da arquitectura representa a estrutura de datos usado específicamente para OLAP. A presenza de datamarts, se i datos almacénanse nos esquemas de estrelas superpostos datos multidimensional nun contorno relacional, ou nos ficheiros de datos O confidencial utilizado por tecnoloxía OLAP específica, como DB2 OLAP Server, non é relevante.

A única limitación é que a arquitectura facilita o uso de datos multidimensional.
A arquitectura tamén inclúe tecnoloxías e técnicas Bi críticas que destacan como:

Análise espacial

O espazo é unha inesperada información para o analista e é fundamental para completar a resolución. O espazo pode representar información sobre as persoas que viven nun determinado lugar, así como información sobre onde está fisicamente ese lugar en relación ao resto do mundo.

Para realizar esta análise, debes comezar vinculando a túa información ás coordenadas de latitude e lonxitude. Isto denomínase "xeocodificación" e debe formar parte do proceso de extracción, transformación e carga (ETL) a nivel atómico do seu almacén.

Minería de datos.

A extracción de datos permite ás nosas empresas aumentar o número de clientes, para predecir tendencias de vendas e permitir a xestión das relacións con clientes (CRM), entre outras iniciativas de BI.

A extracción de datos debe, polo tanto, integrarse coas estruturas de datos da Dwhouse e apoiado por procesos de almacén para garantir o uso eficaz e eficiente da tecnoloxía e técnicas relevantes.

Como se indica na arquitectura de BI, o nivel atómico do Dwhouse, así como os datamarts, son unha excelente fonte de datos para extracción. Esas mesmas instalacións tamén deben ser destinatarias dos resultados da extracción para garantir a dispoñibilidade para o público máis amplo.

Axentes.

Hai varios "axentes" para examinar o cliente para cada punto, como os sistemas operativos da empresa e o propio dw. Estes axentes poden ser redes neuronais avanzadas adestradas para coñecer as tendencias en cada punto, como a demanda futura de produtos baseada en promocións de vendas, motores baseados en regras para reaccionar a un datas conxunto de circunstancias, ou mesmo simples axentes que informan de excepcións aos “altos executivos”. Estes procesos prodúcense xeralmente en tempo real e, polo tanto, deben estar estreitamente vinculados ao seu movemento datos. Todas estas estruturas de datos, tecnoloxías e técnicas garanten que non pasarás a noite xerando unha organización da túa BI.

Esta actividade desenvolverase en pasos incrementais, para pequenos puntos.
Cada paso é un esforzo de proxecto independente e denomínase unha iteración na súa iniciativa DW ou BI. As iteracións poden incluír a implementación de novas tecnoloxías, comezando con novas técnicas, engadindo novas estruturas datos , cargando i datos adicional ou coa ampliación da análise do seu contorno. Este parágrafo é discutido máis en profundidade no capítulo 3.

Ademais das estruturas tradicionais de DW e das ferramentas de BI, hai outras funcións da túa organización de BI para as que debes deseñar, como:

Puntos de contacto de cliente (Toque de cliente puntos).

Como con calquera organización moderna, hai unha serie de puntos de contacto de clientes que indican como ter unha experiencia positiva para a túa clientes. Existen canles tradicionais como venda polo miúdo, centralitas, correo directo, publicidade multimedia e impresa, así como canles máis actuais como correo electrónico e web, datos os produtos con algún punto de contacto deben ser adquiridos, transportados, limpos, procesados ​​e despois poboados nas instalacións datos da BI.

Fundamentos de datos asociacións operativas e de usuarios (Operational

bases de datos e comunidades de usuarios).
Ao final dos puntos de contacto do clientes atópanse os fundamentos de datos das comunidades de usuarios e aplicacións da empresa. O datos existentes son datos tradicional que hai que unir e fusionar co datos que flúen desde os puntos de contacto para satisfacer a información necesaria.

Analistas. (Analistas)

O principal beneficiario do entorno de BI é o analista. É el quen se beneficia da actual extracción de datos operativo, integrado con diferentes fontes de datos , aumentada con funcións como análise xeográfica (xeocodificación) e presentada en tecnoloxías de BI que permiten extracción, OLAP, informes SQL avanzados e análise xeográfica. A interface de analista principal para o ambiente de informes é o portal de BI.

Non obstante, o analista non é o único que se beneficia da arquitectura de BI.
Xerentes, grandes asociacións de usuarios, e mesmo membros, provedores e clientes deberían atopar beneficios na BI empresarial.

Bucle de retroalimentación.

A arquitectura de BI é un ambiente de aprendizaxe. Un principio característico do desenvolvemento é permitir estruturas persistentes de datos para ser actualizado pola tecnoloxía de BI utilizada e polas accións realizadas polo usuario. Un exemplo é a puntuación dos clientes.

Se o departamento de vendas modela as puntuacións dos clientes para utilizar un servizo novo, entón o departamento de vendas non debería ser o único grupo que se beneficia do servizo.

Pola contra, a extracción de modelos debería realizarse como parte natural do fluxo de datos dentro da empresa e as puntuacións dos clientes deberían converterse nunha parte integrada do contexto da información do almacén, visible para todos os usuarios. A Suite IBM centrada en Bi-bI, que inclúe DB2 UDB, DB2 OLAP Server inclúe a maioría dos principais compoñentes tecnolóxicos, definidos na Figura 1.1.

Usamos a arquitectura tal e como aparece nesta figura do libro para darnos un nivel de continuidade e demostrar como cada produto de IBM encaixa no esquema global de BI.

Proporcionar contido de información (Proporcionar Contido informativo)

Deseñar, desenvolver e implementar o seu contorno de BI é unha tarefa desalentadora. O deseño debe abarcar os requisitos empresariais actuais e futuros. O debuxo arquitectónico debe estar completo para incluír todas as conclusións atopadas durante a fase de deseño. A execución debe permanecer comprometida cun único propósito: desenvolver a arquitectura de BI tal e como se presenta formalmente no deseño e baseada nos requisitos empresariais.

É particularmente difícil argumentar que a disciplina garantirá un éxito relativo.
Isto é sinxelo porque non desenvolves un ambiente de BI dunha soa vez, pero faino en pequenos pasos ao longo do tempo.

Non obstante, identificar os compoñentes de BI da súa arquitectura é importante por dous motivos: guiará todas as decisións de arquitectura técnica posteriores.
Poderás planificar conscientemente un uso particular da tecnoloxía aínda que quizais non teñas que repetir a necesidade da tecnoloxía durante varios meses.

Comprender suficientemente os requisitos da túa empresa influirá no tipo de produtos que adquiras para a túa arquitectura.
Deseñar e desenvolver a súa arquitectura garante que o seu almacén sexa

non é un evento aleatorio, senón un "ben pensado" coidadosamente construído. ópera da arte como un mosaico de tecnoloxía mixta.

Deseñar o contido da información

Todo o deseño inicial debe centrarse e identificar os compoñentes clave de BI que será necesario para o ambiente global agora e no futuro.
Coñecer os requisitos empresariais é importante.

Mesmo antes de que comece calquera deseño formal, o planificador do proxecto adoita identificar un ou dous compoñentes de inmediato.
Non obstante, o equilibrio de compoñentes que pode ser necesario para a súa arquitectura non se pode atopar facilmente. Durante a fase de deseño, a parte principal da arquitectura vincula a sesión de desenvolvemento de aplicacións (JAD) nunha procura para identificar os requisitos empresariais.

Ás veces, estes requisitos pódense confiar a ferramentas de consulta e informes.
Por exemplo, os usuarios afirman que se queren automatizar un informe actual deben xeralo manualmente integrando dous informes actuais e engadindo cálculos derivados da combinación do datos.
Aínda que este requisito é sinxelo, define unha determinada funcionalidade da característica que debe incluír ao mercar ferramentas de informes para a súa organización.

O deseñador tamén debe cumprir requisitos adicionais para obter unha imaxe completa. Queren os usuarios subscribirse a este informe?
Xéranse subconxuntos de informes e envíanse por correo electrónico a varios usuarios? Queren ver este informe no portal da empresa? Todos estes requisitos forman parte da simple necesidade de substituír un informe manual como solicitan os usuarios. O beneficio deste tipo de requisitos é que todos, usuarios e deseñadores, entenden o concepto de informes.

Non obstante, hai outro tipo de empresas que debemos planificar. Cando os requisitos empresariais se indican en forma de preguntas estratéxicas comerciais, o deseñador experto é doado discernir os requisitos de medida/feito e dimensións.

Se os usuarios de JAD non saben como expresar os seus requisitos en forma de problema comercial, o deseñador adoita proporcionar exemplos para iniciar a sesión de recollida de requisitos.
O deseñador experto pode axudar aos usuarios a comprender non só o comercio estratéxico, senón tamén como formalo.
O enfoque de recollida de requisitos é discutido no capítulo 3; polo momento só queremos sinalar a necesidade de deseñar para todo tipo de requisitos de BI.

Un problema estratéxico empresarial non só é un requisito empresarial, senón tamén unha pista de deseño. Se tes que responder a unha pregunta multidimensional, entón tes que memorizar, presentar i datos dimensional, e se precisa almacenar o datos multidimensional, debes decidir que tipo de tecnoloxía ou técnica vai empregar.

Implementas un esquema de estrela de cubo reservado ou ambos? Como podes ver, mesmo un simple problema comercial pode influír significativamente no deseño. Pero este tipo de requisitos empresariais son habituais e entendidos, polo menos por deseñadores e planificadores con experiencia en proxectos.

Houbo suficiente discusión sobre tecnoloxías e soporte OLAP, e hai unha ampla gama de solucións dispoñibles. Ata agora mencionamos a necesidade de reunir informes sinxelos cos requisitos dimensionais empresariais, e como estes requisitos inflúen nas decisións técnicas de arquitectura.

Pero cales son os requisitos que non entenden facilmente os usuarios ou o equipo de Dw? Necesitará algunha vez análise espacial?
Os modelos de extracción de datos serán unha parte necesaria do teu futuro? Quen sabe?

É importante ter en conta que este tipo de tecnoloxías non son moi coñecidas polas comunidades de usuarios xerais e os membros do equipo de Dw, en parte, isto pode deberse a que normalmente son xestionadas por algúns expertos técnicos internos ou de terceiros. É un caso extremo dos problemas que xeran este tipo de tecnoloxías. Se os usuarios non poden describir os requisitos comerciais ou enmarcalos de forma que lles brinde orientación aos deseñadores, poden pasar desapercibidos ou, peor, simplemente ignorados.

Máis problemático faise cando o deseñador e o desenvolvedor non poden recoñecer a aplicación dunha destas tecnoloxías avanzadas pero críticas.
Como a miúdo escoitamos dicir aos deseñadores: "ben, por que non o deixamos de lado ata que consigamos esta outra cousa? “¿Están realmente interesados ​​nas prioridades ou simplemente evitan requisitos que non entenden? O máis probable é que sexa a última hipótese. Digamos que o seu equipo de vendas comunicou un requisito comercial, como se indica na Figura 1.3, como podes ver, o requisito enmárcase na forma dun problema empresarial. A diferenza entre este problema e o problema dimensional típico é a distancia. Neste caso, o equipo comercial quere coñecer, mensualmente, as vendas totais dos produtos, almacéns e clientes que viven a menos de 5 millas do almacén onde compran.

Por desgraza, os deseñadores ou arquitectos poden simplemente ignorar o compoñente espacial dicindo: "temos o cliente, o produto e o datos do depósito. Mantemos a distancia ata outra iteración.

"Resposta errónea. Este tipo de problema empresarial é todo sobre BI. Representa unha comprensión máis profunda do noso negocio e un espazo analítico robusto para os nosos analistas. A BI está máis aló da simple consulta ou informes estándar, ou mesmo OLAP. Isto non quere dicir que estas tecnoloxías non sexan importantes para a túa BI, pero por si soas non representan o ambiente de BI.

Deseño para o contexto da información (Deseño de contido informativo)

Agora que identificamos os requisitos empresariais que distinguen varios compoñentes fundamentais, deben incluírse nun deseño arquitectónico global. Algúns dos compoñentes de BI forman parte dos nosos esforzos iniciais, mentres que algúns non se implementarán durante varios meses.

Non obstante, todos os requisitos coñecidos reflíctense no deseño de xeito que cando necesitemos implementar unha tecnoloxía determinada, estamos preparados para facelo. Algo sobre o proxecto reflectirá o pensamento tradicional.

Este conxunto de datos úsase para apoiar usos posteriores de datos dimensional guiada polos problemas de Negocio que identificamos. A medida que se xeran documentos adicionais, como o desenvolvemento do deseño datos, comezaremos a formalizar como i datos espalláronse no medio ambiente. Comprobamos a necesidade de representar i datos de forma dimensional, dividíndoos (segundo necesidades específicas específicas) en data marts.

A seguinte pregunta a responder é: como se construirán estes data marts?
Constrúes as estrelas para soportar os cubos, ou só os cubos, ou só as estrelas? (ou cubos dereitas, ou estrelas dereitas). Xerar arquitectura para mercados de datos dependentes que requiren unha capa atómica para todos datos adquirido? Permitir que os centros de datos independentes adquiran i datos directamente desde os sistemas operativos?

Que tecnoloxía de cubo intentarás estandarizar?

Tes cantidades enormes de datos necesario para a análise dimensional ou necesitas cubos da túa forza de vendas nacional semanalmente ou ambos? Crea algo tan poderoso como DB2 OLAP Server para finanzas ou cubos Cognos PowerPlay para a súa organización de vendas, ou ambos? Estas son as grandes decisións de deseño arquitectónico que afectarán o teu ambiente de BI de aquí en diante. Si, estableceches a necesidade de OLAP. Agora como vai levar a cabo ese tipo de técnica e tecnoloxía?

Como afectan os teus deseños algunhas das tecnoloxías máis avanzadas? Supoñamos que identificou unha necesidade de espazo na súa organización. Agora debes recordar as edicións do debuxo arquitectónico aínda que non teñas pensado facer compoñentes espaciais durante varios meses. O arquitecto debe proxectar hoxe en base ao que se necesita. Prever a necesidade de análise espacial que xere, almacene, realice e proporcione acceso datos espacial. Isto, á súa vez, debería servir de limitación respecto ao tipo de tecnoloxía de software e ás especificacións da plataforma que podes considerar actualmente. Por exemplo, o sistema de administración de base de datos a capa relacional (RDBMS) que realizas para a túa capa atómica debe ter unha extensión espacial robusta dispoñible. Isto garantiría o máximo rendemento ao utilizar xeometría e obxectos espaciais nas túas aplicacións analíticas. Se o teu RDBMS non pode xestionar datos (espacial-céntrico) internamente, polo que terás que establecer a base de datos (espacial-céntrico) externo. Isto complica a xestión dos problemas e compromete o seu rendemento xeral, sen esquecer os problemas adicionais creados para os seus DBA, xa que probablemente teñan unha comprensión mínima dos conceptos básicos de datos espacial tamén. Por outra banda, se o seu motor RDMBS xestiona todos os compoñentes espaciais e o seu optimizador é consciente das necesidades especiais (por exemplo, a indexación) dos obxectos espaciais, entón os seus DBA poden xestionar facilmente a xestión dos problemas e pode maximizar o rendemento.

Ademais, cómpre axustar a área de proba e a capa do ambiente atómico para incluír a limpeza de enderezos (a

elemento clave para a análise espacial), así como o posterior aforro de obxectos espaciais. A sucesión de edicións de debuxo continúa agora que introducimos a noción de dirección clara. Por unha banda, esta aplicación ditará o tipo de software necesario para o seu esforzo ETL.

Necesitas produtos como Trillium para proporcionarlle un enderezo limpo ou un provedor de ETL da túa elección para proporcionar esa función?
Polo momento é importante que aprecies o nivel de deseño que debes completar antes de comezar a implementar o teu almacén. Os exemplos anteriores deberían demostrar a multitude de decisións de deseño que deben seguir a identificación de calquera requisito empresarial en particular. Se se toman correctamente, estas decisións de deseño promoven a interdependencia entre as estruturas físicas do seu contorno, a selección da tecnoloxía utilizada e o fluxo de propagación do contido da información. Sen esta arquitectura de BI convencional, a súa organización estará suxeita a unha mestura caótica de tecnoloxías existentes, no mellor dos casos unidas libremente para proporcionar unha aparente estabilidade.

Manter o contido da información

Achegar o valor da información á túa organización é unha tarefa moi difícil. Sen a suficiente comprensión e experiencia, nin unha planificación e deseño adecuados, incluso os mellores equipos fracasarán. Por outra banda, se tes unha gran intuición e unha planificación detallada pero sen disciplina para a execución, acabas de perder o teu diñeiro e o teu tempo porque o teu esforzo está condenado ao fracaso. A mensaxe debe ser clara: se carece dunha ou máis destas habilidades, comprensión/experiencia ou disciplina de planificación/deseño ou implementación, paralizará ou destruirá o edificio da organización de BI.

O teu equipo está suficientemente preparado? Hai alguén no teu equipo de BI que entenda o vasto panorama analítico dispoñible nos contornos de BI e as técnicas e tecnoloxías necesarias para manter esa paisaxe? Hai alguén no teu equipo que poida recoñecer a diferenza entre aplicacións avanzadas

informes estáticos e OLAP, ou as diferenzas entre ROLAP e OLAP? Un dos membros do teu equipo recoñece claramente como extraer e como pode afectar o almacén ou como o almacén pode soportar o rendemento da extracción? Un membro do equipo entende o valor de datos tecnoloxía baseada no espazo ou en axentes? Tes alguén que aprecie a aplicación única das ferramentas ETL fronte á tecnoloxía de corretor de mensaxes? Se non tes un, obtén un. BI é moito máis grande que unha capa atómica normalizada, OLAP, esquemas en estrela e un ODS.

Ter a comprensión e a experiencia para recoñecer os requisitos de BI e as súas solucións é esencial para a súa capacidade para formalizar adecuadamente as necesidades dos usuarios e deseñar e implementar as súas solucións. Se a túa comunidade de usuarios ten dificultades para describir os requisitos, o traballo do equipo do almacén é proporcionar esa comprensión. Pero se o equipo do almacén

non recoñece a aplicación específica da BI, por exemplo, a minería de datos, entón non é o mellor que os ambientes de BI se limiten a miúdo a ser repositorios pasivos. Non obstante, ignorar estas tecnoloxías non diminúe a súa importancia nin o efecto que teñen na aparición das capacidades de intelixencia empresarial da súa organización, así como no panorama da información que pretende fomentar.

A planificación debe incluír a noción de debuxo, e ambas requiren unha persoa competente. Ademais, o deseño require unha filosofía de almacén de equipo e o cumprimento dos estándares. Por exemplo, se a súa empresa estableceu unha plataforma estándar ou identificou un RDBMS particular que quere estandarizar na plataforma, a responsabilidad de todos os integrantes do equipo é de cumprir eses estándares. Xeralmente un equipo expón a necesidade de estandarización (ás comunidades de usuarios), pero o propio equipo non está disposto a adherirse aos estándares establecidos tamén noutras áreas da empresa ou quizais mesmo en empresas similares. Isto non só é hipócrita, senón que establece que a empresa é incapaz de explotar os recursos e investimentos existentes. Non significa que non haxa situacións que xustifiquen unha plataforma ou tecnoloxía non estandarizadas; con todo, os esforzos do almacén

deberían gardar celosamente os estándares da empresa ata que os requisitos empresariais dicten o contrario.

O terceiro compoñente clave necesario para construír unha organización de BI é a disciplina.
Depende en total, igualmente dos individuos e do medio. Os planificadores de proxectos, patrocinadores, arquitectos e usuarios deben apreciar a disciplina necesaria para construír o panorama informativo da empresa. Os deseñadores deben dirixir os seus esforzos de deseño de forma que complementen outros esforzos necesarios na sociedade.

Por exemplo, digamos que a súa empresa constrúe unha aplicación ERP que teña un compoñente de almacén.
Polo tanto, é responsabilidade dos deseñadores do ERP colaborar co equipo do entorno do almacén para non competir nin duplicar traballos xa iniciados.

A disciplina tamén é un tema que debe ser abordado por toda a organización e que adoita establecerse e encomendarse a un nivel executivo.
Os xestores están dispostos a unirse a un enfoque deseñado? Un enfoque que promete crear contido de información que, finalmente, aportará valor a todas as áreas da empresa, pero quizais comprometa as axendas individuais ou departamentais? Lembra o refrán "Pensar en todo é máis importante que pensar só nunha cousa". Este dito é certo para as organizacións de BI.

Desafortunadamente, moitos almacéns centran os seus esforzos en tentar orientar e aportar valor a un determinado departamento ou usuarios específicos, sen ter en conta a organización en xeral. Supoñamos que o executivo solicita axuda ao equipo do fogar. O equipo responde cun esforzo de 90 días que inclúe non só entregar os requisitos de notificación definidos polo xestor, senón asegurar que todos datos base mestúranse a nivel atómico antes de ser introducidas na tecnoloxía do cubo proposta.
Esta incorporación de enxeñería garante que a empresa do fogar se beneficiará datos necesario para o xestor.
Non obstante, o executivo falou con consultoras externas que propuxeron unha aplicación similar con entrega en menos de 4 semanas.

Asumindo que o equipo interno do almacén é competente, o executivo ten unha opción. Quen pode apoiar a disciplina de enxeñería adicional necesaria para cultivar a empresa de activos de información ou pode optar por crear a súa propia solución rapidamente. Este último parece ser elixido con demasiada frecuencia e só serve para crear contedores de información que benefician só a uns poucos ou ao individuo.

Obxectivos a curto e longo prazo

Os arquitectos e os deseñadores de proxectos deben formalizar unha visión a longo prazo da arquitectura xeral e os plans de crecemento nunha organización de BI. Esta combinación de ganancia a curto prazo e planificación a longo prazo representa os dous lados dos esforzos de BI. A ganancia a curto prazo é a faceta da BI que está asociada ás iteracións do teu almacén.

Aquí é onde os planificadores, arquitectos e patrocinadores se centran en cumprir requisitos comerciais específicos. É neste nivel onde se constrúen estruturas físicas, se adquire tecnoloxía e se implementan técnicas. De ningún xeito están feitos para responder a requisitos específicos definidos por comunidades de usuarios particulares. Todo faise co fin de atender requisitos específicos definidos por unha determinada comunidade.
Non obstante, a planificación a longo prazo é a outra faceta da BI. Aquí é onde os planos e deseños aseguraron que se construíse calquera estrutura física, que as tecnoloxías seleccionadas e as técnicas implementadas se fixeran con ollo cara á empresa. É a planificación a longo prazo a que proporciona a cohesión necesaria para garantir que os beneficios empresariais xurdan de calquera beneficio a curto prazo atopado.

Xustifica o teu esforzo de BI

Un data warehouse por si só non ten ningún valor inherente. Noutras palabras, non existe un valor inherente entre as tecnoloxías de almacén e as técnicas de implementación.

O valor de calquera esforzo do almacén atópase nas accións realizadas como consecuencia do entorno do almacén e do contido informativo cultivado ao longo do tempo. Este é un punto crítico para entender antes de intentar estimar o valor de calquera iniciativa de wherehouse.

Con demasiada frecuencia, os arquitectos e deseñadores intentan aplicar valor aos compoñentes físicos e técnicos do almacén cando en realidade o valor se basea nos procesos de negocio que se ven afectados positivamente polo almacén e a información ben adquirida.

Aquí radica o reto de establecer BI: como xustifica o investimento? Se o wherehouse en si non ten valor intrínseco, os deseñadores do proxecto deben investigar, definir e formalizar os beneficios acadados por aqueles individuos que utilizarán o almacén para mellorar procesos comerciais específicos ou o valor da información protexida, ou ambos.

Para complicar as cousas, calquera proceso empresarial afectado polos esforzos de almacenamento podería proporcionar beneficios "considerables" ou "lixeiros". Beneficios considerables proporcionan unha métrica tanxible para medir o retorno do investimento (ROI), por exemplo, converter o inventario un tempo adicional durante un período específico ou para reducir o custo de transporte por envío. É máis difícil definir beneficios sutís, como o acceso mellorado á información, en termos de valor tanxible.

Conecta o teu proxecto para coñecer o Solicitudes empresariais

Con demasiada frecuencia, os planificadores de proxectos intentan vincular o valor do almacén a obxectivos empresariais amorfos. Ao declarar que "o valor dun almacén baséase na nosa capacidade para satisfacer as solicitudes estratéxicas" abrimos a discusión dun xeito ameno. Pero por si só non é suficiente para determinar se ten sentido investir en inventario. É mellor vincular as iteracións do almacén con demandas comerciais específicas coñecidas.

Medición do ROI

Calcular o ROI nun almacén pode ser particularmente difícil. É especialmente difícil se a vantaxe

O principal dunha repetición particular é algo que non é tanxible ou doado de medir. Un estudo descubriu que os usuarios perciben dous beneficios principais das iniciativas de BI:

• ▪ Crear a capacidade de tomar decisións
• ▪ Crear acceso á información
  Estes beneficios son beneficios suaves (ou leves). É doado ver como podemos calcular un ROI en función dun beneficio importante (ou importante) como a redución dos custos de transporte, pero como medimos a capacidade de tomar mellores decisións?
  Este é definitivamente un reto para os planificadores de proxectos cando intentan convencer á empresa de que investir nun esforzo de almacén en particular. O aumento das vendas ou a diminución dos custos xa non son os temas centrais que impulsan o ambiente de BI.
  Pola contra, estás mirando as solicitudes comerciais para un mellor acceso á información para que un departamento particular poida tomar decisións máis rápidas. Estes son motores estratéxicos que resultan ser igualmente importantes para a empresa pero que son máis ambiguos e máis difíciles de caracterizar nunha métrica tanxible. Neste caso, o cálculo do ROI pode ser enganoso, se non irrelevante.
  Os planificadores de proxectos deben ser capaces de demostrar un valor tanxible para que os executivos decidan se paga a pena o investimento nunha determinada iteración. Non obstante, non proporemos un novo método para calcular o ROI, nin presentaremos ningún argumento a favor ou en contra.
  Hai moitos artigos e libros dispoñibles que discuten os fundamentos do cálculo do ROI. Existen propostas de valor especiais, como o valor do investimento (VOI), ofrecidas por grupos como Gartner, que pode investigar. Pola contra, centrarémonos nos aspectos fundamentais de calquera ROI ou outras propostas de valor que teñas que ter en conta. Aplicando ROI Máis aló do argumento sobre os beneficios "duros" fronte aos beneficios "suave" asociados aos esforzos de BI, hai outras cuestións a ter en conta ao aplicar o ROI. Por exemplo:

Atribuír demasiados aforros aos esforzos de DW que chegarían de todos os xeitos
Digamos que a súa empresa pasou dunha arquitectura mainframe a un ambiente UNIX distribuído. Polo tanto, calquera aforro que se poida (ou non) realizar con ese esforzo non se debe atribuír exclusivamente, se é o caso (?), ao almacén.

Non contabilizar todo é caro. E hai moitas cousas a ter en conta. Considere a seguinte lista:

• ▪ Custo de posta en marcha, incluída a viabilidade.
• ▪ Custo do hardware dedicado con almacenamento e comunicacións relacionados
• ▪ Custo do software, incluída a xestión datos e extensións cliente/servidor, software ETL, tecnoloxías DSS, ferramentas de visualización, aplicacións de programación e fluxo de traballo e software de monitorización, .
• ▪ Custo de deseño da estrutura datos, coa creación e optimización de
• ▪ Custo de desenvolvemento de software directamente asociado ao esforzo de BI
• ▪ Custo do soporte in situ, incluíndo a optimización do rendemento, incluíndo o control de versións do software e as operacións de axuda Aplicar o ROI "Big-Bang". Construír o almacén como un esforzo único e xigantesco está condenado ao fracaso, polo que incluso calcular o ROI dunha iniciativa de gran empresa. A oferta é sorprendente e os planificadores seguen facendo débiles intentos para estimar o valor de todo o esforzo. Por que os planificadores intentan poñer un valor monetario á iniciativa empresarial se é amplamente coñecido e aceptado que estimar repeticións específicas é difícil? Como é posible? Non é posible con poucas excepcións. Non o fagas. Agora que establecemos o que non facer ao calcular o ROI, aquí tes algúns puntos que nos axudarán a establecer un proceso fiable para estimar o valor dos teus esforzos de BI.

Obtención do consenso sobre o ROI. Independentemente da súa técnica para estimar o valor dos seus esforzos de BI, debe ser acordada por todas as partes, incluídos os deseñadores de proxectos, patrocinadores e directivos de empresas.

Reducir o ROI en partes identificables. Un paso necesario para calcular razoablemente un ROI é centrar ese cálculo nun proxecto específico. Isto permítelle estimar un valor en función dos requisitos comerciais específicos que se cumpran

Definir os custos. Como se mencionou, hai que considerar numerosos custos. Ademais, os custos deben incluír non só os asociados á iteración única, senón tamén os custos asociados a garantir o cumprimento dos estándares empresariais.

Definir beneficios. Ao vincular claramente o ROI a requisitos empresariais específicos, deberíamos ser capaces de identificar os beneficios que levarán a cumprir os requisitos.

Reducir custos e beneficios en beneficios inminentes. É a mellor forma de basear as túas valoracións no valor actual neto (VAN) en lugar de tentar predecir o valor futuro das ganancias futuras.

Mantén o momento de dividir o teu ROI ao mínimo. Está ben documentado durante o longo período de tempo que se utilizou no teu ROI.

Use máis dunha fórmula de ROI. Existen numerosos métodos para prever o ROI e debes planificar se utilizas un ou máis deles, incluído o valor actual neto, a taxa interna de retorno (IRR) e a amortización.

Definir proceso repetible. Isto é crucial para calcular calquera valor a longo prazo. Debe documentarse un único proceso repetible para todas as subsecuencias do proxecto a seguir.

Os problemas enumerados son os máis comúns definidos por expertos no ambiente de cachorros. A insistencia da dirección en ofrecer un ROI "Big-Bang" é moi desorientadora. Se comezas todos os teus cálculos de ROI desglosándoos en pezas identificables e tanxibles, tes moitas posibilidades de estimar unha valoración precisa do ROI.

Preguntas sobre os beneficios do ROI

Sexa cal sexan os teus beneficios, suaves ou duros, podes usar algunhas preguntas básicas para determinar o seu valor. Por exemplo, usando un sistema de escala simple, do 1 ao 10, pode medir o impacto de calquera esforzo utilizando as seguintes preguntas:

• Como valorarías a comprensión datos seguindo este proxecto da túa empresa?
• Como estimarías as melloras de procesos como resultado deste proxecto?
• Como medirías o impacto dos novos coñecementos e inferencias que agora están dispoñibles con esta iteración
• Cal foi o impacto dos contornos informáticos novos e eficientes como resultado do aprendido? Se as respostas a estas preguntas son poucas, é posible que a empresa non valga a pena o investimento realizado. As preguntas con puntuación alta apuntan a importantes ganancias de valor e deberían servir de guía para unha investigación posterior. Por exemplo, unha puntuación alta para melloras de procesos debería levar aos deseñadores a examinar como se melloraron os procesos. Pode descubrir que algunhas ou todas as ganancias obtidas son tanxibles e, polo tanto, pódese aplicar facilmente un valor monetario. Sacar o máximo proveito da primeira iteración do almacén O maior resultado do esforzo empresarial adoita estar nas primeiras iteracións. Estes primeiros esforzos establecen tradicionalmente o contido de información máis útil para o público e axudan a establecer a base tecnolóxica para as seguintes aplicacións de BI. Normalmente todas as seguintes secuencias de datos dos proxectos de almacén aportan cada vez menos valor adicional á empresa en xeral. Isto é especialmente certo se a iteración non engade novos temas nin responde ás necesidades dunha nova comunidade de usuarios.

Esta función de almacenamento tamén se aplica ás pilas en crecemento de datos historiadores. Como os esforzos posteriores requiren máis datos e canto máis datos vértense no almacén co paso do tempo, a maioría dos datos tórnase menos relevante para a análise utilizada. Estes datos adoitan chamarse datos latentes e sempre é caro mantelos porque case nunca se usan.

Que significa isto para os patrocinadores do proxecto? Esencialmente, os primeiros patrocinadores comparten máis do que custa o investimento. Isto é fundamental porque son o impulso para establecer a ampla capa tecnolóxica e ambiental de recursos do almacén, incluído o orgánico.

Pero estes primeiros pasos aportan o maior valor e, polo tanto, os deseñadores de proxectos moitas veces teñen que xustificar o investimento.
Os proxectos realizados despois da túa iniciativa de BI poden ter custos directos máis baixos (en comparación co primeiro), pero aportan menos valor á empresa.

E os propietarios das organizacións deben comezar a considerar tirar a acumulación datos e tecnoloxías menos relevantes.

Minería de datos: extracción Dati

Numerosos compoñentes arquitectónicos requiren variacións nas tecnoloxías e técnicas de minería de datos.
por exemplo, os diferentes “axentes” para examinar os puntos de interese do clientes, os sistemas operativos da empresa e para o propio dw. Estes axentes poden ser redes neuronais avanzadas adestradas en tendencias POT, como a demanda futura de produtos baseada en promocións de vendas; motores baseados en regras para reaccionar a un conxunto datas de circunstancias, por exemplo, diagnóstico médico e recomendacións de tratamento; ou mesmo simples axentes coa función de denunciar as excepcións aos máximos executivos. Xeralmente estes procesos de extracción datos si

verificar en tempo real; polo tanto, deben estar unidos completamente co movemento de datos eles mesmos.

Procesamento de procesamento analítico en liña

Analítica en liña

A capacidade de cortar, cortar, tirar, perforar e realizar análises
O que-se, está dentro do alcance, o foco da suite tecnolóxica de IBM. Por exemplo, existen funcións de procesamento analítico en liña (OLAP) para DB2 que trae análise dimensional ao motor de software. base de datos mesmo.

As funcións engaden utilidade dimensional a SQL ao tempo que aproveitan todas as vantaxes de ser parte natural de DB2. Outro exemplo de integración OLAP é a ferramenta de extracción, DB2 OLAP Server Analyzer. Esta tecnoloxía permite que os cubos do servidor DB2 OLAP sexan analizados de forma rápida e automática para localizar e informar sobre valores de valores. datos inusual ou inesperado en todo o cubo para o analista de negocios. E, finalmente, as funcións do DW Center proporcionan aos arquitectos un medio para controlar, entre outras cousas, o perfil dun cubo de servidor DB2 OLAP como parte natural dos procesos ETL.

Análise espacial Análise espacial

O espazo representa a metade das áncoras analíticas (conductores) necesarias para unha panorámica
amplo analítico (o tempo representa a outra metade). O nivel atómico do almacén, representado na Figura 1.1, inclúe tanto os fundamentos do tempo como do espazo. Os selos de tempo áncora as análises por tempo e a información de dirección áncora as análises por espazo. As marcas de tempo realizan análises por tempo e a información de enderezos realizan análises por espazo. O diagrama mostra a xeocodificación - o proceso de conversión de enderezos en puntos nun mapa ou puntos no espazo para que se poidan utilizar conceptos como a distancia e o interior/exterior na análise - realizada a nivel atómico e a análise espacial que se pon a disposición dos usuarios. o analista. IBM ofrece extensións espaciais, desenvolvidas co Instituto de Investigación do Sistema Ambiental (ESRI), para base de datos DB2 para que os obxectos espaciais poidan almacenarse como parte normal do ficheiro base de datos relacional. DB2

Os extensores espaciais tamén proporcionan todas as extensións SQL para aproveitar a análise espacial. Por exemplo, as extensións SQL para consultar
a distancia entre enderezos ou se un punto está dentro ou fóra dunha área poligonal definida, son un estándar analítico co Spatial Extender. Consulte o capítulo 16 para obter máis información.

Base de datos- Ferramentas para residentes Ferramentas Base de datos-Residente

DB2 ten moitas funcións SQL residentes en BI que axudan na acción de análise. Estes inclúen:

• Funcións de recursión para realizar análises, como "buscar todas as posibles rutas de voo desde San Francisco a nova York".
• As funcións analíticas de clasificación, funcións acumulativas, cubo e acumulación para facilitar tarefas que normalmente só se producen coa tecnoloxía OLAP, agora son parte natural do motor. base de datos
• A capacidade de crear táboas que conteñan resultados
  Os vendedores de base de datos os líderes mesturan máis capacidades de BI no base de datos o mesmo.
  Os principais provedores de base de datos están mesturando máis capacidades de BI no base de datos o mesmo.
  Isto proporciona un mellor rendemento e máis opcións de execución para as solucións de BI.
  As características e funcións de DB2 V8 explícanse en detalle nos seguintes capítulos:
  Fundamentos de Arquitectura Técnica e Xestión de Datos (Capítulo 5)

• Fundamentos de DB2 BI (Capítulo 6)
• Táboas de consulta materializadas de DB2 (capítulo 7)
• Funcións de DB2 OLAP (Capítulo 13)
• Características e funcións de BI melloradas de DB2 (Capítulo 15) Sistema simplificado de entrega de datos Sistema de entrega de datos simplificado

A arquitectura representada na Figura 1.1 inclúe numerosas estruturas datos físico. Un é o almacén de datos operando. Xeralmente, un ODS é un obxecto orientado ao tema, integrado e actual. Crearías un ODS para apoiar, por exemplo, a oficina de vendas. As vendas de SAO complementaríanse datos de numerosos sistemas diferentes pero só conservaría, por exemplo, as transaccións actuais. O ODS tamén se pode actualizar moitas veces ao día. Ao mesmo tempo, os procesos empuxan o datos integrado noutras aplicacións. Esta estrutura está deseñada especificamente para integrarse datos actual e dinámico e sería un candidato probable para soportar análises en tempo real, como proporcionar aos axentes de servizo clientes a información de vendas actual dun cliente extraendo a información de tendencias de vendas do propio almacén. Outra estrutura que se mostra na figura 1.1 é un estado formal para o dw. Non só é este o lugar para a execución da necesaria integración, a calidade de datos, e da transformación de datos de almacén de entrada, pero tamén é unha zona de almacenamento fiable e temporal para datos réplicas que poderían utilizarse en análises en tempo real. Se decides utilizar un ODS ou unha zona de escenificación, unha das mellores ferramentas para poboar estas estruturas datos usar diferentes fontes operativas é a consulta distribuída heteroxénea de DB2. Esta capacidade ofrécese pola función opcional de DB2 chamada DB2 Relational Connect (só consulta) e mediante DB2 DataJoiner (un produto separado que ofrece capacidade de consulta, inserción, actualización e eliminación a RDBMS distribuídos heteroxéneos).

Esta tecnoloxía permite aos arquitectos datos atar datos produción con procesos analíticos. A tecnoloxía non só pode adaptarse a practicamente calquera das demandas de replicación que poidan xurdir coa análise en tempo real, senón que tamén se pode conectar a unha gran variedade de bases de datos. datos máis populares, incluíndo DB2, Oracle, Sybase, SQL Server, Informix e outros. DB2 DataJoiner pódese usar para encher unha estrutura datos formal como un ODS ou mesmo unha mesa permanente representada no almacén deseñada para a recuperación rápida de actualizacións instantáneas ou á venda. Por suposto, estas mesmas estruturas datos pódese poboar usando

outra tecnoloxía importante deseñada para a replicación de datos, IBM DataPropagator Relational. (DataPropagator é un produto separado para sistemas centrais. DB2 UNIX, Linux, Windows e OS/2 inclúen servizos de replicación de datos datos como característica estándar).
Outro método para moverse datos que opera na empresa é un integrador de aplicacións empresariais tamén coñecido como intermediario de mensaxes. Esta tecnoloxía única permite un control inigualable para a orientación e o movemento. datos arredor da empresa. IBM ten o intermediario de mensaxes máis utilizado, MQSeries, ou unha variación do produto que inclúe os requisitos de e-commerce, IBM WebSphere MQ.
Para obter máis información sobre como aproveitar MQ para soportar un entorno de almacén e BI, visite sitio web do libro. De momento, abonda con dicir que esta tecnoloxía é un excelente medio para capturar e transformar (usando MQSeries Integrator) datos operadores centrados (orientados) contratados para solucións de BI. A tecnoloxía MQ integrouse e empaquetouse en UDB V8, o que significa que as colas de mensaxes agora poden xestionarse coma se fosen táboas DB2. O concepto de soldar mensaxes en cola e o universo de base de datos cabezas relacionais cara a un ambiente de entrega poderoso de datos.

Latencia cero Latencia cero

O obxectivo estratéxico final de IBM é a análise de latencia cero. Segundo se define por
Gartner, un sistema de BI debe ser capaz de inferir, asimilar e proporcionar información aos analistas baixo demanda. O reto, por suposto, é como mesturar datos actual e en tempo real coa información histórica necesaria, como i datos patrón/tendencia relacionado ou comprensión extraída, como a elaboración de perfiles de clientes.

Esta información inclúe, por exemplo, a identificación de clientes alto ou baixo risco ou que produtos i clientes moi probablemente comprarán se xa teñen queixo nos seus carros da compra.

Conseguir a latencia cero depende en realidade de dous mecanismos fundamentais:

• Unión completa de datos que se analizan coas técnicas e ferramentas establecidas creadas por BI
• Un sistema de entrega de datos eficiente para garantir que as analíticas en tempo real estean realmente dispoñibles. Estes requisitos previos para a latencia cero non son diferentes dos dous obxectivos establecidos por IBM e descritos anteriormente. O apareamento próximo de datos Forma parte do programa de integración perfecta de IBM. E crear un sistema de entrega de datos eficiente depende completamente da tecnoloxía dispoñible que simplifica o proceso de entrega de datos. Como resultado, dous dos tres obxectivos de IBM son fundamentais para realizar o terceiro. IBM está a evolucionar conscientemente a súa tecnoloxía para garantir que a latencia cero sexa unha realidade para os esforzos do almacén. Resumo / Síntese A organización de BI ofrece unha folla de ruta para construír o seu entorno
  de forma iterativa. Debe axustarse para reflectir as necesidades da súa empresa, tanto actuais como futuras. Sen unha visión arquitectónica ampla, as iteracións do almacén son pouco máis que implementacións aleatorias do almacén central que pouco fan para crear unha empresa ampla e informativa. O primeiro obstáculo para os xestores de proxectos é como xustificar os investimentos necesarios para desenvolver a organización de BI. Aínda que o cálculo do ROI continuou sendo un piar das implementacións do almacén, é cada vez máis difícil predicir con precisión. Isto levou a outros métodos para determinar se está a recibir o valor do seu diñeiro. O valor do investimento2 (VOI), por exemplo, promóvese como solución. Correspóndelles aos arquitectos de datos e os planificadores de proxectos xeran e proporcionan información deliberadamente ás asociacións de usuarios e non simplemente lles prestan un servizo datos. Hai unha enorme diferenza entre os dous. A información é algo que marca a diferenza na toma de decisións e na eficacia; relativamente, i datos son bloques de construción para derivar esa información.

Aínda que eu sexa crítico coa fonte datos Para atender as solicitudes comerciais, o ambiente de BI debería desempeñar un papel máis importante na creación de contido de información. Debemos tomar os pasos adicionais para limpar, integrar, transformar ou crear contido de información sobre o que os usuarios poidan actuar e, a continuación, debemos asegurarnos de que esas accións e decisións, cando sexan razoables, se reflictan no contorno de BI. Se relegamos o almacén a só servir datos, garante que as asociacións de usuarios crearán o contido informativo necesario para tomar medidas. Isto garante que a súa comunidade poderá tomar mellores decisións, pero a empresa sofre a falta de coñecemento que utilizaron. Dato A medida que os arquitectos e os planificadores de proxectos inician proxectos específicos no entorno de BI, seguen sendo responsables ante a empresa no seu conxunto. Un exemplo sinxelo desta característica de dúas caras das iteracións de BI atópase na fonte datos. Todos os datos que se reciban para solicitudes empresariais específicas deben encherse na primeira capa atómica. Isto garante o desenvolvemento do activo de información empresarial, así como xestionar, abordar as solicitudes específicas dos usuarios definidas na iteración.

Que é o almacén de datos?

Almacén de datos foi o corazón da arquitectura de sistemas de información desde 1990 e admite procesos de información ofrecendo unha sólida plataforma integrada datos datos históricos tomados como base para análises posteriores. O data warehouse ofrecen facilidade de integración nun mundo de sistemas de aplicacións incompatibles. Almacén de datos evolucionou nunha tendencia. Almacén de datos organizar e almacenar i datos necesarios para procesos informativos e analíticos baseados nunha perspectiva temporal histórica longa. Todo isto supón un compromiso considerable e constante na construción e mantemento de data warehouse.

Entón, que é a data warehouse? A data warehouse e:

• ▪ orientado á materia
• ▪ sistema integrado
• ▪ tempo variante
• ▪ non volátil (non se pode borrar)

unha colección de datos utilizados para apoiar as decisións directivas na implementación dos procesos.
I datos inserido en data warehouse na maioría dos casos derivan de contornos operativos. O data warehouse créase por unha unidade de almacenamento, separada fisicamente do resto do sistema, que contén datos transformado previamente por aplicacións que operan con información derivada do contorno operativo.

Definición literal de a data warehouse merece unha explicación en profundidade xa que existen importantes motivacións e significados subxacentes que describen as características dun almacén.

ORIENTACIÓN A MATERIAS ORIENTACIÓN TEMÁTICA

A primeira característica de a data warehouse é que está orientada aos principais actores dunha empresa. A guía dos ensaios a través do datos contrasta co método máis clásico que implica a orientación das aplicacións cara a procesos e funcións, método compartido maioritariamente pola maioría dos sistemas de xestión menos recentes.

O mundo operativo está deseñado en torno a aplicacións e funcións como préstamos, aforros, tarxetas bancarias e confianza para unha entidade financeira. O mundo da dw organízase en torno a temas principais como o cliente, o vendedor, o produto e a actividade. O aliñamento en torno aos temas afecta o deseño e implementación de datos atopado no dw. Máis importante aínda, o tema principal afecta á parte máis importante da estrutura clave.

O mundo da aplicación está influenciado tanto polo deseño da base de datos como polo deseño do proceso. O mundo da dw céntrase exclusivamente no modelado datos e sobre o deseño do base de datos. O deseño de procesos (na súa forma clásica) non forma parte do entorno dw.

As diferenzas entre a elección do proceso/aplicación da función e a elección da materia tamén se revelan como diferenzas no contido do datos a nivel detallado. O datos dos dw non inclúen i datos que non se utilizarán para o proceso DSS mentres se aplican

orientado operativo datos conteñen i datos para satisfacer inmediatamente os requisitos funcionais/de procesamento que poden ou non ter algún uso para o analista DSS.
Outra forma importante en que as aplicacións orientadas ao funcionamento datos difiren de datos de dw está en dei informes datos. O datos operacións manteñen unha relación continua entre dúas ou máis táboas en función dunha regra de negocio que está activa. O datos de dw atravesan un espectro de tempo e as relacións que se atopan no dw son moitas. Moitas regras comerciais (e, en consecuencia, moitas relacións de datos ) están representados no almacén de datos entre dúas ou máis mesas.

(Para unha explicación detallada de como as relacións entre o datos se manexan no DW, remitimos ao tema técnico sobre ese tema.)
Desde ningunha outra perspectiva que a da diferenza fundamental entre unha elección de aplicación funcional/proceso e unha elección de materia, existe unha diferenza maior entre os sistemas operativos e datos e o DW.

INTEGRACIÓN INTEGRACIÓN

O aspecto máis importante do ambiente dw é que i datos atopados dentro do dw son facilmente integrados. SEMPRE. SEN EXCEPCIÓNS. A esencia mesma do ambiente dw é que i datos contidos dentro dos límites do almacén están integrados.

A integración revélase de moitas formas diferentes: en convencións identificadas coherentes, en medicións de variables consistentes, en estruturas codificadas coherentes, en atributos físicos de datos consistente, etc.

Ao longo dos anos, os deseñadores de varias aplicacións tomaron moitas decisións sobre como se debería desenvolver unha aplicación. O estilo e as decisións de deseño individualizadas das aplicacións dos deseñadores revélanse de cen xeitos: en diferenzas de codificación, estrutura clave, características físicas, convencións de identificación, etc. A capacidade colectiva de moitos deseñadores de aplicacións para crear aplicacións inconsistentes é lendaria. A figura 3 expón algunhas das diferenzas máis importantes na forma en que se deseñan as aplicacións.

Codificación: Codificación:

Os deseñadores de aplicacións escolleron a codificación do campo (sexo) de diferentes xeitos. Un deseñador representa o sexo como unha "m" e unha "f". Outro deseñador representa o xénero como un "1" e un "0". Outro deseñador representa o sexo como "x" e "y". Outro deseñador representa o sexo como "masculino" e "feminino". Non importa moito como entra o sexo no DW. A "M" e a "F" son probablemente tan boas como toda a obra.

O que importa é que de calquera orixe derive o campo sexual, ese campo chegue ao DW nun estado integrado consistente. En consecuencia, cando o campo se carga no DW desde unha aplicación onde foi representado no formato "M" e "F", o datos debe converterse ao formato DW.

Medición de Atributos: Medición de Atributos:

Os deseñadores de aplicacións optaron por medir a canalización de varias formas ao longo dos anos. Un deseñador almacena o datos da canalización en centímetros. Outro deseñador de aplicacións almacena o datos do gasoduto en termos de polgadas. Outro deseñador de aplicacións almacena o datos de gasoduto en millóns de pés cúbicos por segundo. E outro deseñador almacena información sobre o gasoduto en termos de metros. Sexa cal sexa a fonte, cando a información da canalización chega ao DW debe medirse do mesmo xeito.

Segundo as indicacións da figura 3, os problemas de integración afectan a case todos os aspectos do proxecto: as características físicas datos, o dilema de ter máis dunha fonte de datos, a cuestión de mostras identificadas inconsistentes, formatos de datos inconsistente, etc.

Sexa cal sexa o tema do deseño, o resultado é o mesmo: i datos deben almacenarse no DW dun xeito singular e globalmente aceptable aínda que os sistemas operativos subxacentes os almacene de forma diferente datos.

Cando o analista de DSS mira o DW, o obxectivo do analista debería ser explotar o datos que están no almacén,

en lugar de preguntarse pola credibilidade ou a coherencia de datos.

VARIENCIA TEMPORAL

Todo o datos no DW son precisos nalgún momento. Esta característica básica do datos no DW é moi diferente dos datos atopado no entorno operativo. O datos do contorno operativo son tan precisos como no momento do acceso. Noutras palabras, no entorno operativo cando se accede a unha unidade datos, espérase que reflicta valores precisos como no momento do acceso. Porque eu datos no DW son precisos xa que nalgún momento (é dicir, non "agora mesmo"), dise que eu datos atopados no DW son "varianza temporal".
A variación temporal de datos por DW refírese de varias maneiras.
O xeito máis sinxelo é que i datos dunha representación DW datos nun longo horizonte temporal: de cinco a dez anos. O horizonte temporal representado para o ambiente operativo é moito máis curto que os valores actuais de ata sesenta e noventa
As aplicacións que deben funcionar ben e estar dispoñibles para o procesamento de transaccións deben levar a cantidade mínima de datos se permiten algún grao de flexibilidade. Así, as aplicacións operativas teñen un curto horizonte temporal, como un tema de deseño de aplicacións de audio.
A segunda forma na que aparece a "varianza temporal" no DW é na estrutura clave. Cada estrutura clave do DW contén, de forma implícita ou explícita, un elemento de tempo, como día, semana, mes, etc. O elemento tempo está case sempre na parte inferior da clave concatenada que se atopa no DW. Nestas ocasións, o elemento tempo existirá de forma implícita, como no caso de que se duplique un ficheiro completo a finais de mes ou trimestre.
A terceira forma en que se mostra a varianza temporal é que i datos do DW, unha vez rexistrado correctamente, non se pode actualizar. O datos dos DW son, para todos os efectos prácticos, unha longa serie de instantáneas. Por suposto, se as instantáneas foron tomadas incorrectamente, entón pódense modificar. Pero supoñendo que as instantáneas se tomen correctamente, non se modifican tan pronto como se toman. Nalgunhas

Nalgúns casos, pode ser pouco ético ou incluso non válido que se modifiquen as instantáneas do DW. O datos operativos, sendo precisos como no momento do acceso, poden ser actualizados segundo sexa necesario.

NON VOLÁTIL

A cuarta característica importante de DW é que non é volátil.
As actualizacións, insercións, eliminacións e modificacións realízanse regularmente nos contornos operativos, rexistro por rexistro. Pero a manipulación básica do datos que son necesarios no DW é moito máis sinxelo. Só hai dous tipos de operacións que ocorren no DW: a carga inicial de datos e acceso a datos. Non hai ningunha actualización do datos (no sentido xeral de actualización) no DW como unha operación de procesamento normal. Hai algunhas consecuencias moi poderosas desta diferenza básica entre o procesamento operativo e o procesamento DW. A nivel de deseño, a necesidade de ser cauteloso sobre as actualizacións anómalas non é un factor no DW, xa que a actualización de datos non se leva a cabo. Isto significa que a nivel de deseño físico pódense tomar liberdades para optimizar o acceso datos, en particular ao tratar os temas de normalización física e desnormalización. Outra consecuencia da sinxeleza das operacións DW está na tecnoloxía subxacente utilizada para executar o ambiente DW. Ter que admitir actualizacións rexistro por rexistro en liña (como adoita ser o caso do procesamento operativo) require que a tecnoloxía teña unha base moi complexa baixo aparente sinxeleza.
A tecnoloxía que admite copias de seguridade e recuperación, transaccións e integridade de datos e a detección e solución da condición de bloqueo é bastante complexa e non é necesaria para o procesamento de DW. As características dun DW, orientación ao deseño, integración de datos dentro do DW, variación horaria e sinxeleza de xestión datos, todo leva a un ambiente moi, moi diferente do ambiente operativo clásico. A fonte de case todas datos de DW son o entorno operativo. É tentador pensar que hai unha redundancia masiva de datos entre os dous ambientes.
De feito, a primeira impresión que teñen moita xente é a de gran redundancia datos entre o ambiente operativo e o ambiente de

DW. Tal interpretación é superficial e demostra unha falta de comprensión do que acontece no DW.
De feito hai un mínimo de redundancia datos entre o ambiente operativo e i datos do DW. Considere o seguinte: I datos son filtrados datas cambiar do ambiente operativo ao ambiente DW. Moitas datos nunca pasan fóra do ambiente operativo. Excepto que i datos necesarios para o procesamento DSS atopan a súa dirección no medio ambiente

▪ o horizonte temporal de datos é moi diferente dun ambiente a outro. O datos no ambiente operativo son moi frescos. O datos no DW son moito máis vellos. Só desde a perspectiva do horizonte temporal, hai moi pouca superposición entre o ambiente operativo e o DW.

▪ O DW contén datos resumo que nunca se atopan no medio

▪ I datos experimentan unha transformación fundamental a medida que pasan á Figura 3 ilustra que a maioría datos modifícanse significativamente sempre que se seleccionen e se movan ao DW. Dito doutro xeito, a maioría dos datos cambia física e radicalmente a medida que se traslada ao DW. Dende o punto de vista da integración non son o mesmo datos que residen no entorno operativo. Á vista destes factores, a redundancia de datos entre os dous ambientes é un evento raro, que leva a menos do 1% de redundancia entre os dous ambientes. A ESTRUTURA DO ALMACÉN Os DW teñen unha estrutura distinta. Hai varios niveis de resumo e detalle que delimitan os DW.
Os distintos compoñentes dun DW son:

• metadatos
• Dati detalles actuais
• Dati de vellos detalles
• Dati lixeiramente resumido
• Dati altamente resumido

De lonxe a principal preocupación é polo datos detalles actuais. É a principal preocupación porque:

• I datos os detalles actuais reflicten os acontecementos máis recentes, que sempre son de grande interese e
• i datos de detalle actual é voluminoso porque se almacena no menor nivel de granularidade e
• i datos Os detalles actuais almacénanse case sempre na memoria do disco, que é rápido de acceder, pero é caro e complexo de usar datos de detalle canto máis vellos sexan datos que se almacenan nalgunha memoria masa. Accédese esporádicamente e gárdase cun nivel de detalle compatible datos detalles actuais. Aínda que non é obrigatorio almacenar nun medio de almacenamento alternativo, debido ao gran volume de datos combinado con acceso esporádico de datos, o soporte de memoria para datos Os datos de detalles máis antigos normalmente non se almacenan no disco. O datos resumidas lixeiramente son datos que se destilan desde o baixo nivel de detalle atopado ata o nivel actual de detalle. Este nivel do DW case sempre se almacena no disco. Os problemas de deseño aos que se enfronta o arquitecto datos na construción deste nivel do DW están:

• Que unidade de tempo é o resumo feito anteriormente
• Que contido, atributos resumirán lixeiramente o contido do datos O seguinte nivel de datos atopado no DW é o de datos altamente resumido. O datos altamente resumidos son compactos e de fácil acceso. O datos moi resumidos atópanse ás veces no ambiente DW e noutros casos i datos moi resumidos atópanse fóra dos muros inmediatos da tecnoloxía que alberga o DW. (en todo caso, i datos altamente resumidos forman parte do DW independentemente de onde i datos están aloxados fisicamente). O compoñente final do DW son os metadatos. En moitos aspectos, os metadatos atópanse nunha dimensión diferente á doutras datos do DW, porque os metadatos non contén ningún datas tomadas directamente do entorno operativo. Os metadatos teñen un papel especial e moi importante en DW. Os metadatos úsanse como:

• un directorio para axudar ao analista de DSS a localizar o contido do DW,
• unha guía para mapear o datos de como eu datos transformáronse do ambiente operativo ao ambiente DW,
• unha guía dos algoritmos utilizados para o resumo entre os datos de detalles actuais ei datos lixeiramente resumido, i datos altamente resumido, os metadatos xogan un papel moito máis importante no ambiente DW que nunca no ambiente operativo MEDIO DE ALMACENAMIENTO DE DETALLE ANTIGO Pódese usar cinta magnética para almacenar ese tipo datos. De feito, hai unha gran variedade de medios de almacenamento que deberían considerarse para o almacenamento antigo datos de detalle. Segundo o volume de datos, a frecuencia de acceso, o custo das ferramentas e o tipo de acceso, é totalmente probable que outras ferramentas necesiten o antigo nivel de detalle no DW. FLUXO DE DATOS Hai un fluxo normal e previsible de datos dentro do DW.
  I datos entran no DW desde o entorno operativo. (NOTA: hai algunhas excepcións moi interesantes a esta regra. Non obstante, case todas datos introducir o DW desde o entorno operativo). Dato que eu datos introduza o DW desde o entorno operativo, transfórmase como se describiu anteriormente. A condición de ingresar no DW, i datos introduza o nivel de detalle actual, como se mostra. Reside alí e úsase ata que ocorre un dos tres eventos:

• é purificado,
• resúmese, e/ou ▪è O proceso obsoleto dentro dun DW móvese i datos detalles actuais a datos de detalles antigos, baseados na idade de datos. O proceso

resumo utiliza o detalle de datos para calcular i datos lixeiramente resumidos e os niveis altamente resumidos de datos. Hai algunhas excepcións ao fluxo mostrado (discutirase máis adiante). Non obstante, normalmente, para a gran maioría dos datos atopado dentro dun DW, o fluxo de datos é como se representa.

USO DO ALMACEN DE DATOS

Non é de estrañar os distintos niveis de datos dentro do DW non reciben diferentes niveis de uso. Como regra xeral, canto maior sexa o nivel de resumo, máis i datos utilízanse.
Moitos usos ocorren en datos moi resumidos, mentres que os vellos datos de detalles case nunca se usan. Hai unha boa razón para mover a organización ao paradigma de utilización de recursos. Máis resumido i datos, canto máis rápido e eficiente é chegar ao datos. Se a tenda descobre que fai moitos procesos a nivel de detalle do DW, entón consúmese unha gran cantidade de recursos da máquina correspondente. É no mellor interese de todos procesar o máis alto nivel de resumo canto antes.

Para moitas tendas, utilizou o analista DSS nun ambiente pre-DW datos a nivel de detalle. En moitos aspectos a chegada a datos un resumo detallado aseméllase a unha manta de seguridade, mesmo cando hai outros niveis de resumo dispoñibles. Unha das actividades do arquitecto datos é retirar ao usuario de DSS do uso constante de datos ao nivel máis baixo de detalle. Hai dúas motivacións á disposición do arquitecto de datos:

• mediante a instalación dun sistema de contracargo, onde o usuario final paga polos recursos consumidos e
• que indican que se pode acadar un tempo de resposta moi bo cando o comportamento con i datos atópase nun alto nivel de resumo, mentres que o mal tempo de resposta provén do comportamento do datos a un nivel baixo OUTRAS CONSIDERACIÓNS Hai outras consideracións de construción e xestión de DW.
  A primeira consideración é a dos índices. O datos en niveis máis altos de resumo pódense indexar libremente, mentres que i datos

en niveis máis baixos de detalle son tan voluminosos que se poden indexar de forma frugal. Do mesmo xeito, i datos en altos niveis de detalle pode ser relativamente facilmente reestruturado, mentres que o volume de datos nos niveis inferiores é tan grande que i datos non se poden renovar facilmente. En consecuencia, o modelo de datos e o traballo formal realizado polo deseño sentou as bases para o DW aplicado case exclusivamente ao nivel de detalle actual. Noutras palabras, as actividades de modelaxe de datos non se aplican aos niveis de resumo, en case todos os casos. Outra consideración estrutural é a da subdivisión de datos por DW.

A partición pódese facer en dous niveis: a nivel de dbms e a nivel de aplicación. Na división a nivel dbms, The dbms infórmase das divisións e contrólaas en consecuencia. No caso de división a nivel de aplicación, só se informa o programador das divisións e déixalle a el a responsabilidade da súa administración.

Baixo o nivel dbms, moito traballo faise automaticamente. Hai moita inflexibilidade asociada coa administración automática de divisións. No caso de divisións a nivel de aplicación de datos do data warehouse, moito traballo pesa sobre o programador, pero o resultado final é flexibilidade na administración de datos en data warehouse

OUTRAS ANOMALÍAS

Mentres que os compoñentes do data warehouse Funcionan como se describe para case todos datos, hai algunhas excepcións útiles que deben ser discutidas. Unha excepción é a de datos datos resumidos públicos. Estes son datos resumos que se calcularon a partir do data warehouse pero son utilizados pola sociedade. O datos Os resumos públicos gárdanse e xestionan no data warehouse, aínda que como se mencionou anteriormente están calculados fóra. Os contadores traballan para producir tales trimestrais datos como ingresos, gastos trimestrais, beneficio trimestral, etc. O traballo realizado polos contadores é externo data warehouse. Non obstante, i datos úsanse “internamente” dentro da empresa – de marketing, vendas, etc. Outra anomalía, que non se falará, é a de datos exteriores.

Outro tipo excepcional datos que se pode atopar nun data warehouse é o dos datos de detalle permanente. Estes provocan a necesidade de almacenar permanentemente o datos a un nivel detallado por motivos éticos o legales. Se unha empresa está expoñendo aos seus traballadores a substancias perigosas hai que facelo datos detallada e permanente. Se unha empresa produce un produto que implique seguridade pública, como pezas de avións, é necesario datos datos permanentes, así como se unha empresa celebra contratos perigosos.

A empresa non pode permitirse o luxo de pasar por alto detalles porque nos próximos anos, en caso de demanda, retirada, defecto de construción disputado, etc. a exposición da empresa pode ser grande. Como resultado, hai un tipo único de datos coñecido como datos de detalle permanente.

RESUMO

Un data warehouse é unha variante temporal, integrada, orientada a obxectos, unha colección de datos non volátiles para apoiar as necesidades de toma de decisións da administración. Cada unha das funcións salientables de a data warehouse ten as súas implicacións. Ademais, hai catro niveis de datos do data warehouse:

• Detalle antigo
• Detalle actual
• Dati lixeiramente recapitulado
• Dati Os metadatos altamente resumidos tamén son unha parte importante do data warehouse. RESUMO O concepto de almacenamento de datos Recentemente recibiu moita atención e converteuse nunha tendencia dos anos 90. Isto débese á capacidade dun data warehouse para superar as limitacións dos sistemas de apoio á xestión como os sistemas de apoio á decisión (DSS) e os sistemas de información executiva (EIS). Aínda que o concepto de data warehouse parece prometedor, implementar i data warehouse pode ser problemático debido aos procesos de almacenamento a gran escala. A pesar da complexidade dos proxectos de almacenamento datos, moitos provedores e consultores que almacenan datos afirman que o almacenamento de datos a corrente non causa ningún problema. Non obstante, ao comezo deste proxecto de investigación case non se realizara unha investigación independente, rigorosa e sistemática. En consecuencia, é difícil dicir o que realmente acontece na industria cando se constrúen data warehouse. Este estudo explorou a práctica de almacenamento de datos contemporáneos que pretende desenvolver unha comprensión máis rica da práctica australiana. A revisión da literatura proporcionou o contexto e as bases para o estudo empírico. Hai unha serie de achados desta investigación. En primeiro lugar, este estudo revelou as actividades que xurdiron durante o desenvolvemento do data warehouse. En moitas áreas, i datos reunidos confirmaron a práctica descrita na literatura. En segundo lugar, as cuestións e problemas que poden afectar o desenvolvemento do data warehouse foron identificados por este estudo. Finalmente, os beneficios obtidos polas organizacións australianas asociadas ao uso de data warehouse foron revelados.

Capítulo 1

Contexto de investigación

O concepto de almacenamento de datos recibiu unha ampla exposición e converteuse nunha tendencia emerxente na década de 90 (McFadden 1996, TDWI 1996, Shah e Milstein 1997, Shanks et al. 1997, Eckerson 1998, Adelman e Oates 2000). Isto pódese ver polo crecente número de artigos sobre o almacenamento de datos en publicacións comerciais (Little e Gibson 1999). Moitos artigos (véxase, por exemplo, Fisher 1995, Hackathorn 1995, Morris 1995a, Bramblett e King 1996, Graham et al. 1996, Sakaguchi e Frolick 1996, Álvarez 1997, Brousell 1997, Clarke 1997, McCar 1997, Edwards 1997, TDWI 1998) informaron importantes beneficios obtidos polas organizacións que implementan i data warehouse. Apoiaron a súa teoría con evidencias anecdóticas de implementacións exitosas, cifras de alto retorno do investimento (ROI) e, tamén, proporcionando pautas ou metodoloxías para desenvolver o data warehouse

(Shanks et al. 1997, Seddon e Benjamin 1998, Little e Gibson 1999). Nun caso extremo, Graham et al. (1996) informaron un rendemento medio dun investimento a tres anos do 401%.

Non obstante, gran parte da literatura actual pasou por alto as complexidades que implica a realización de tales proxectos. Os proxectos de data warehouse normalmente son complexos e a gran escala e, polo tanto, teñen unha alta probabilidade de falla se non se controlan coidadosamente (Shah e Milstein 1997, Eckerson 1997, Foley 1997b, Zimmer 1997, Bort 1998, Gibbs e Clymer 1998, Rao 1998). Requiren grandes cantidades de recursos humanos e financeiros, así como tempo e esforzo para construílos (Hill 1998, Crofts 1998). O tempo típico e os medios financeiros necesarios son de aproximadamente dous anos e de dous a tres millóns de dólares, respectivamente (Braly 1995, Foley 1997b, Bort 1998, Humphries et al. 1999). Este tempo e medios financeiros son necesarios para controlar e consolidar moitos aspectos diferentes do almacenamento de datos (Cafasso 1995, Hill 1998). Xunto ás consideracións de hardware e software, outras funcións, que varían desde a extracción de datos aos procesos de carga de datos, a capacidade de memoria para xestionar actualizacións e o meta datos para a formación de usuarios, debe ser considerado.

No momento en que comezou este proxecto de investigación, había moi pouca investigación académica no campo do almacenamento de datos, especialmente en Australia. Isto foi evidente pola escaseza de artigos publicados sobre o almacenamento de datos de revistas ou outros escritos académicos da época. Moitos dos escritos académicos dispoñibles describían a experiencia dos EUA. A falta de investigación académica na área de almacenamento de datos fixo que se soliciten investigacións rigorosas e estudos empíricos (McFadden 1996, Shanks et al. 1997, Little e Gibson 1999). En particular, estudos de investigación sobre o proceso de implantación de data warehouse cómpre realizar para ampliar os coñecementos xerais sobre a implantación de data warehouse e servirá de base para un futuro estudo de investigación (Shanks et al. 1997, Little e Gibson 1999).

O obxectivo deste estudo, polo tanto, é estudar o que realmente acontece cando as organizacións realizan e utilizan i data warehouse en Australia. En concreto, este estudo suporá unha análise de todo un proceso de desenvolvemento de a data warehouse, a partir da iniciación e planificación ata o deseño e implementación e o seu posterior uso dentro das organizacións australianas. Ademais, o estudo tamén contribuirá á práctica actual identificando áreas onde se poden mellorar aínda máis as prácticas e minimizar ou evitar as ineficiencias e os riscos. Ademais, servirá de base para outros estudos sobre data warehouse en Australia e cubrirá o baleiro que existe actualmente na literatura.

Preguntas de investigación

O obxectivo desta investigación é estudar as actividades implicadas na posta en marcha de data warehouse e o seu uso por organizacións australianas. En particular, estúdanse os elementos relativos á planificación, desenvolvemento, explotación, uso e riscos do proxecto. Polo tanto, a pregunta desta investigación é:

“Cal é a práctica actual data warehouse en Australia?"

Para responder eficazmente a esta pregunta, son necesarias unha serie de preguntas de investigación subsidiarias. En particular, identificáronse tres subpreguntas da literatura, que se presenta no capítulo 2, para guiar este proxecto de investigación: Como son as data warehouse de organizacións australianas? Que problemas atopaches?

Cales son os beneficios experimentados?
Para responder a estas preguntas, utilizouse un deseño de investigación exploratoria empregando unha enquisa. Como estudo exploratorio, as respostas ás preguntas anteriores non están completas (Shanks et al. 1993, Denscombe 1998). Neste caso, é necesaria a triangulación para mellorar as respostas a estas preguntas. Non obstante, a investigación proporcionará unha base sólida para o traballo futuro que examine estas cuestións. No capítulo 3 preséntase unha discusión detallada sobre a xustificación e deseño do método de investigación.

Estrutura do proxecto de investigación

Este proxecto de investigación divídese en dúas partes: o estudo contextual do concepto de almacenamento de datos e a investigación empírica (ver Figura 1.1), cada unha das cales se comenta a continuación.

Parte I: Estudo contextual

A primeira parte da investigación consistiu na revisión da literatura actual sobre varios tipos de almacenamento de datos, incluíndo sistemas de apoio á decisión (DSS), sistemas de información executiva (EIS), estudos de casos de data warehouse e os conceptos de data warehouse. Ademais, os resultados dos foros data warehouse e grupos de reunións de expertos e profesionais dirixidos polo equipo de investigación de Monash DSS, contribuíron a esta fase do estudo que pretendía obter información sobre a práctica de data warehouse e identificar os riscos que implica a súa adopción. Durante este período de estudo contextual, estableceuse a comprensión da área problemática para proporcionar os coñecementos básicos para as investigacións empíricas posteriores. Non obstante, este foi un proceso continuo durante a realización do estudo de investigación.

Parte II: Investigación empírica

O concepto relativamente novo de almacenamento de datos, especialmente en Australia, creou a necesidade dunha enquisa para obter unha imaxe ampla da experiencia do usuario. Esta parte levouse a cabo unha vez establecido o dominio do problema mediante unha ampla revisión da literatura. O concepto de data-warehousing formado durante a fase de estudo contextual utilizouse como entrada para o cuestionario inicial deste estudo. Despois diso, examinouse o cuestionario. Sodes expertos en data warehouse participou na proba. O obxectivo da proba do cuestionario inicial foi comprobar a integridade e a exactitude das preguntas. En función dos resultados da proba, modificouse o cuestionario e enviouse a versión modificada aos participantes da enquisa. Despois analizáronse os cuestionarios devoltos para i datos en táboas, diagramas e outros formatos. O

resultados da análise de datos forman unha instantánea da práctica de almacenamento de datos en Australia.

DESCRIPCIÓN GENERAL DO ALMACÉN DE DATOS

O concepto de almacenamento de datos evolucionou coas melloras na tecnoloxía informática.
Está dirixido a superar os problemas aos que se enfrontan os grupos de apoio ás aplicacións como o Sistema de Apoio á Decisión (DSS) e o Sistema de Información Executiva (EIS).

No pasado, o maior obstáculo destas aplicacións foi a incapacidade destas para proporcionar un base de datos necesarios para a análise.
Isto débese principalmente á natureza do traballo da dirección. Os intereses da dirección dunha empresa varían constantemente segundo o ámbito que se abrangue. Polo tanto i datos fundamentais para estas aplicacións deben poder cambiar rapidamente dependendo da peza a tratar.
Isto significa que i datos deberá estar dispoñible na forma adecuada para as análises solicitadas. De feito, aos grupos de apoio ás aplicacións era moi difícil no pasado recoller e integrar datos de fontes complexas e diversas.

O resto desta sección presenta unha visión xeral do concepto de almacenamento de datos e analiza como data warehouse pode superar os problemas dos grupos de soporte de aplicacións.
O termo "Almacén de datos” foi popularizado por William Inmon en 1990. A súa definición a miúdo citada ve o Almacén de datos como colección de datos orientado a temáticas, integrado, non volátil e variable ao longo do tempo, en apoio ás decisións de xestión.

Usando esta definición Inmon destaca que i datos residindo nun data warehouse deben posuír as seguintes 4 características:

• ▪ Orientado á materia
• ▪ Integrado
• ▪ Non volátil
• ▪ Variable no tempo Por Inmon orientado a materia significa que i datos en data warehouse nas maiores áreas organizativas que se teñen

definido no modelo datos. Por exemplo todos datos sobre i clientes están contidos na área temática CLIENTES. Igualmente todos datos relacionados cos produtos están contidos na área temática PRODUTOS.

Por Integrated Inmon significa que i datos procedentes de diferentes plataformas, sistemas e localizacións combínanse e almacénanse nun só lugar. En consecuencia datos outros similares deben transformarse en formatos coherentes para que se poidan engadir e comparar facilmente.
Por exemplo, o xénero masculino e feminino están representados polas letras M e F nun sistema e por 1 e 0 noutro. Para integralos correctamente, hai que transformar un ou os dous formatos para que os dous formatos sexan iguais. Neste caso poderiamos cambiar M a 1 e F a 0 ou viceversa. Orientado a materia e Integrado indican que o data warehouse está deseñado para proporcionar unha visión funcional e transversal de datos pola empresa.

Por Non volátil quere dicir que i datos en data warehouse permanecer coherente e a actualización de datos non é necesario. En cambio, cada cambio datos orixinais engádese ao base de datos do data warehouse. Isto significa que o histórico dei datos está contido en data warehouse.

Para as variables co tempo, Inmon indica que i datos en data warehouse sempre conteñen ei indicadores de tempo datos normalmente atravesan un determinado horizonte temporal. Por exemplo a
data warehouse pode conter 5 anos de valores históricos de clientes de 1993 a 1997. A dispoñibilidade da historia e dunha serie temporal de datos permite analizar tendencias.

Un data warehouse pode recoller o seu datos de sistemas OLTP; de fontes datos externos á organización e/ou por outros proxectos especiais de sistemas de captura datos.
I datos os extractos poden pasar por un proceso de limpeza, neste caso i datos transfórmanse e intégranse antes de almacenarse no base de datos do data warehouse. Entón eu datos

residentes dentro do base de datos do data warehouse están dispoñibles para os inicios de sesión dos usuarios finais e as ferramentas de recuperación. Usando estas ferramentas o usuario final pode acceder á vista integrada da organización de datos.

I datos residentes dentro do base de datos do data warehouse gárdanse tanto en formato detallado como en formato de resumo.
O nivel de resumo pode depender da natureza do datos. O datos detallado pode consistir en datos actual e datos historiadores
I datos as regalías non están incluídas no data warehouse ata i datos en data warehouse están actualizados.
Ademais de gardar o datos eles mesmos, a data warehouse tamén pode almacenar un tipo diferente de datas chamado METADATOS que describen o datos residentes no seu base de datos.
Hai dous tipos de metadatos: metadatos de desenvolvemento e metadatos de análise.
Os metadatos de desenvolvemento utilízanse para xestionar e automatizar os procesos de extracción, limpeza, mapeamento e carga do datos en data warehouse.
A información contida nos metadatos de desenvolvemento pode conter detalles dos sistemas operativos, detalles dos elementos a extraer, o modelo datos do data warehouse e regras comerciais para a conversión datos.

O segundo tipo de metadatos, coñecido como metadatos analíticos, permite ao usuario final explorar o contido do data warehouse para atopar o datos dispoñibles e o seu significado en termos claros e non técnicos.

Polo tanto, os metadatos analíticos funcionan como ponte entre o data warehouse e aplicacións do usuario final. Estes metadatos poden conter o modelo de negocio, descricións de datos correspondente ao modelo de negocio, consultas e informes predefinidos, información para o acceso dos usuarios e o índice.

Os metadatos de análise e desenvolvemento deben combinarse nun único metadato de contención integrado para funcionar correctamente.

Desafortunadamente, moitas das ferramentas existentes teñen os seus propios metadatos e actualmente non existen estándares para iso

permitir que as ferramentas de almacenamento de datos integren estes metadatos. Para remediar esta situación, moitos comerciantes das principais ferramentas de almacenamento de datos formaron o Meta Data Council que máis tarde se converteu na Meta Data Coalition.

O obxectivo desta coalición é construír un conxunto de metadatos estándar que permita a diferentes ferramentas de almacenamento de datos converter os metadatos.
Os seus esforzos deron lugar ao nacemento da Meta Data Interchange Specification (MDIS) que permitirá o intercambio de información entre os arquivos de Microsoft e os ficheiros MDIS relacionados.

A existencia de datos tanto resumido/indexado como detallado dálle ao usuario a posibilidade de realizar un DRILL DROWN (perforación) desde datos indexados a detallados e viceversa. A existencia de datos historias detalladas permiten a creación de análises de tendencias ao longo do tempo. Ademais, os metadatos analíticos pódense usar como directorio de base de datos do data warehouse para axudar aos usuarios finais a localizar datos necesario.

En comparación cos sistemas OLTP, coa súa capacidade para soportar a análise de datos e informes, o data warehouse vese como un sistema máis axeitado para procesos de información como a realización e resposta a consultas e a elaboración de informes. A seguinte sección destacará as diferenzas dos dous sistemas en detalle.

ALMACÉN DE DATOS CONTRA OS SISTEMAS OLTP

Moitos dos sistemas de información dentro das organizacións están destinados a apoiar as operacións do día a día. Estes sistemas coñecidos como SISTEMAS OLTP, capturan transaccións diarias continuamente actualizadas.

I datos dentro destes sistemas adoitan modificarse, engadirse ou eliminarse. Por exemplo, o enderezo dun cliente cambia a medida que se despraza dun lugar a outro. Neste caso, o novo enderezo rexistrarase modificando o campo do enderezo base de datos. O obxectivo principal destes sistemas é reducir os custos de transacción e, ao mesmo tempo, reducir os tempos de procesamento. Exemplos de sistemas OLTP inclúen accións críticas como entrada de pedidos, nóminas, facturas, fabricación, servizo ao cliente clientes.

A diferenza dos sistemas OLTP, que se crearon para procesos baseados en transaccións e eventos, i data warehouse foron creados para proporcionar soporte para procesos baseados en análises datos e procesos de toma de decisións.

Isto conséguese normalmente integrando i datos de varios sistemas OLTP e externos nun único "contedor" de datos, como se comentou na sección anterior.

Modelo de proceso de almacenamento de datos Monash

O modelo de proceso para data warehouse Monash foi desenvolvido por investigadores do Monash DSS Research Group, e baséase na literatura de data warehouse, sobre experiencia no apoio ao desenvolvemento de campos de sistemas, sobre discusións con provedores de aplicacións para o seu uso data warehouse, sobre un grupo de expertos no uso de data warehouse.

As fases son: Iniciación, Planificación, Desenvolvemento, Operacións e Explicacións. O diagrama explica o carácter iterativo ou evolutivo do desenvolvemento de a data warehouse proceso mediante frechas bidireccionais colocadas entre as distintas fases. Neste contexto, “iterativo” e “evolutivo” significa que, en cada paso do proceso, as actividades de implementación sempre poden propagarse cara atrás cara á fase anterior. Isto débese á natureza dun proxecto data warehouse na que en calquera momento xurdan solicitudes adicionais do usuario final. Por exemplo, durante a fase de desenvolvemento dun proceso data warehouse, unha nova dimensión ou área temática é solicitada polo usuario final, que non formaba parte do plano orixinal, esta debe engadirse ao sistema. Isto provoca un cambio no proxecto. O resultado é que o equipo de deseño debe modificar os requisitos dos documentos creados ata o momento durante a fase de deseño. En moitos casos, o estado actual do proxecto debe remontarse á fase de deseño onde se debe engadir e documentar o novo requisito. O usuario final debe poder ver a documentación específica revisada e os cambios realizados na fase de desenvolvemento. Ao final deste ciclo de desenvolvemento, o proxecto debe obter un excelente feedback tanto dos equipos de desenvolvemento como dos usuarios. A continuación, os comentarios reutilízanse para mellorar un proxecto futuro.

Planificación da capacidade
Dw adoita ser de tamaño moi grande e crecer moi rapidamente (Best 1995, Rudin 1997a) como resultado da cantidade de datos historias que conservan da súa duración. O crecemento tamén pode ser causado por datos engadidos solicitados polos usuarios para aumentar o valor de datos que xa teñen. En consecuencia, os requisitos de almacenamento para datos pode mellorarse significativamente (Eckerson 1997). Así, é esencial asegurar, mediante a planificación da capacidade, que o sistema que se está construíndo poida crecer a medida que medran as necesidades (Best 1995, LaPlante 1996, Lang 1997, Eckerson 1997, Rudin 1997a, Foley 1997a).
Na planificación da escalabilidade da base de datos, débese coñecer o crecemento esperado no tamaño do almacén, os tipos de consultas que se poden realizar e o número de usuarios finais admitidos (Best 1995, Rudin 1997b, Foley 1997a). A creación de aplicacións escalables require unha combinación de tecnoloxías de servidor escalables e técnicas de deseño de aplicacións escalables (Best 1995, Rudin 1997b. Ambas son necesarias para construír unha aplicación altamente escalable. As tecnoloxías de servidor escalables poden facer que sexa fácil e vantaxoso engadir almacenamento, memoria e CPU sen degradar). performance (Lang 1997, Telephony 1997).

Existen dúas tecnoloxías de servidor escalables principais: o procesamento múltiple simétrico (SMP) e o procesamento masivamente paralelo (MPP) (IDC 1997, Humphries et al. 1999). Un servidor SMP normalmente ten varios procesadores que comparten memoria, bus do sistema e outros recursos (IDC 1997, Humphries et al. 1999). Pódense engadir procesadores adicionais para aumentar o seu poder computacional. Outro método para aumentar o poder do servidor SMP, consiste en combinar numerosas máquinas SMP. Esta técnica coñécese como clustering (Humphries et al. 1999). Un servidor MPP, pola contra, ten varios procesadores, cada un coa súa propia memoria, sistema de bus e outros recursos (IDC 1997, Humphries et al. 1999). Cada procesador chámase nodo. Un aumento en poder computacional pódese conseguir

engadindo nodos adicionais aos servidores MPP (Humphries et al. 1999).

Unha debilidade dos servidores SMP é que demasiadas operacións de entrada-saída (E/S) poden conxestionar o bus do sistema (IDC 1997). Este problema non se produce nos servidores MPP xa que cada procesador ten o seu propio sistema de bus. Non obstante, as interconexións entre cada nodo son xeralmente moito máis lentas que o sistema de bus SMP. Ademais, os servidores MPP poden engadir un nivel adicional de complexidade aos desenvolvedores de aplicacións (IDC 1997). Así, a elección entre os servidores SMP e MPP pode verse influenciada por moitos factores, incluíndo a complexidade das aplicacións, a relación prezo/rendemento, a capacidade de procesamento necesaria, as aplicacións dw impedidas e o aumento do tamaño das aplicacións. base de datos de dw e no número de usuarios finais.

Na planificación da capacidade pódense empregar numerosas técnicas de deseño de aplicacións escalables. Un usa varios períodos de notificación como días, semanas, meses e anos. Tendo varios prazos de notificación, o base de datos pódese dividir en pezas agrupadas de xeito manexable (Inmon et al. 1997). Outra técnica é utilizar táboas de resumo que se constrúen mediante un resumo datos da datos detallado. Entón eu datos resumidos son máis compactos que detallados, o que require menos espazo de memoria. Entón o datos de detalle pódese almacenar nunha unidade de almacenamento menos custosa, o que aforra aínda máis almacenamento. Aínda que o uso de táboas de resumo pode aforrar espazo na memoria, requiren moito esforzo para mantelas actualizadas e acordes coas necesidades empresariais. Non obstante, esta técnica úsase amplamente e úsase a miúdo xunto coa técnica anterior (Best 1995, Inmon 1996a, Chauduri e Dayal).
1997).

Definición Almacén de datos Arquitecturas Técnicas Definición de técnicas de arquitectura dw

Os primeiros adoptantes do data warehousing concibiron principalmente unha implementación centralizada do dw na que todas as datos, incluíndo i datos externos, estaban integrados nun único,
almacenamento físico (Inmon 1996a, Bresnahan 1996, Peacock 1998).

A principal vantaxe deste enfoque é que os usuarios finais poden acceder á vista de toda a empresa datos organizacional (Ovum 1998). Outra vantaxe é que ofrece estandarización de datos a través da organización, o que significa que só hai unha versión ou definición para cada terminoloxía utilizada no repositorio dw (metadatos) (Flanagan e Safdie 1997, Ovum 1998). A desvantaxe deste enfoque, por outra banda, é que é caro e difícil de construír (Flanagan e Safdie 1997, Ovum 1998, Inmon et al. 1998). Non moito tempo despois da arquitectura de almacenamento datos centralizado fíxose popular, o concepto de extraer subconxuntos máis pequenos do evolucionado datos para soportar as necesidades de aplicacións específicas (Varney 1996, IDC 1997, Berson e Smith 1997, peacock 1998). Estes pequenos sistemas son derivados do maior data warehouse centralizado. Son nomeados data warehouse departamentos dependentes ou mercados de datos dependentes. A arquitectura de data mart dependente coñécese como arquitectura de tres niveis, onde o primeiro nivel consiste en data warehouse centralizado, o segundo está formado polos depósitos de datos departamental e a terceira consiste no acceso a datos e mediante ferramentas de análise (Demarest 1994, Inmon et al. 1997).

Os data marts adoitan construírse despois do data warehouse centralizado foi construído para satisfacer as necesidades de unidades específicas (White 1995, Varney 1996).
Os data marts almacenan datos moi relevante en relación con unidades particulares (Inmon et al. 1997, Inmon et al. 1998, IA 1998).

A vantaxe deste método é que non haberá datas non integrado e que i datos será menos redundante dentro de data marts como todos datos veñen dun almacén datos integrado. Outra vantaxe é que haberá poucas conexións entre cada data mart e as súas fontes datos porque cada data mart só ten unha fonte de datos. Ademais, con esta arquitectura instalada, os usuarios finais aínda poden acceder á vista xeral de datos

organizacións corporativas. Este método coñécese como método de arriba abaixo, onde os data marts se constrúen despois do data warehouse (pavo real 1998, Goff 1998).
Aumentando a necesidade de mostrar resultados cedo, algunhas organizacións comezaron a construír centros de datos independentes (Flanagan e Safdie 1997, White 2000). Neste caso, os data marts teñen o seu datos directamente desde o básico de datos OLTP e non do almacén centralizado e integrado, eliminando así a necesidade de ter o almacén central in situ.

Cada data mart require polo menos unha ligazón ás súas fontes datos. Unha desvantaxe de ter varias conexións para cada data mart é que, en comparación coas dúas arquitecturas anteriores, a sobreabundancia de datos aumenta significativamente.

Cada data mart debe almacenar todos os datos datos localmente para non ter ningún efecto nos sistemas OLTP. Isto fai que i datos almacénanse en diferentes data marts (Inmon et al. 1997). Outra desvantaxe desta arquitectura é que leva á creación de interconexións complexas entre os data marts e as súas fontes de datos. datos que son difíciles de levar a cabo e controlar (Inmon et al. 1997).

Outra desvantaxe é que os usuarios finais non poden acceder á información xeral da empresa porque i datos dos diferentes datamarts non están integrados (Ovum 1998).
Outra desvantaxe é que pode haber máis dunha definición para cada terminoloxía empregada nos data mart que xera inconsistencias de datos na organización (Ovum 1998).
A pesar das desvantaxes comentadas anteriormente, os data marts independentes aínda atraen o interese de moitas organizacións (IDC 1997). Un factor que os fai atractivos é que son máis rápidos de desenvolver e requiren menos tempo e recursos (Bresnahan 1996, Berson e Smith 1997, Ovum 1998). En consecuencia, serven principalmente como proxectos de proba que poden usarse para identificar rapidamente beneficios e/ou imperfeccións do proxecto (Parsaye 1995, Braly 1995, Newing 1996). Neste caso, a parte que se vai implementar no proxecto piloto debe ser pequena pero importante para a organización (Newing 1996, Mansell-Lewis 1996).

Ao examinar o prototipo, os usuarios finais e a administración poden decidir se continuar ou deter o proxecto (Flanagan e Safdie 1997).
Se a decisión é continuar, os mercados de datos para outras industrias deberían construírse un a un. Hai dúas opcións para os usuarios finais en función das súas necesidades na construción de matrices de datos independentes: integrado/federado e non integrado (Ovum 1998)

No primeiro método, cada novo data mart debe construírse baseándose nos data mart e no modelo actuais datos usado pola empresa (Varney 1996, Berson e Smith 1997, Peacock 1998). A necesidade de utilizar o modelo datos da empresa significa que hai que garantir que só hai unha definición para cada terminoloxía empregada nos data marts, isto tamén é para garantir que se poidan combinar diferentes data marts para dar unha visión xeral da información da empresa (Bresnahan 1996). Este método chámase de abaixo cara arriba e é mellor cando hai unha limitación de medios financeiros e de tempo (Flanagan e Safdie 1997, Ovum 1998, Peacock 1998, Goff 1998). No segundo método, os data marts construídos só poden satisfacer as necesidades dunha unidade específica. Unha variante do data mart federado é o data warehouse distribuídos no que o base de datos O middleware de Hub Server úsase para combinar moitos data marts nun só repositorio datos distribuído (White 1995). Neste caso, i datos as empresas están distribuídas en varios data mart. As solicitudes dos usuarios finais son enviadas a base de datos middleware de concentrador de servidor, que extrae todos os datos solicitado polos data marts e devolve os resultados ás aplicacións do usuario final. Este método proporciona información comercial aos usuarios finais. Non obstante, os problemas dos mercados de datos independentes aínda non están eliminados. Hai outra arquitectura que se pode usar que se chama data warehouse virtual (Blanco 1995). Non obstante, esta arquitectura, que se describe na Figura 2.9, non é unha arquitectura de almacenamento de datos. datos real xa que non move a carga dos sistemas OLTP a data warehouse (Demarest 1994).

De feito, as peticións de datos dos usuarios finais pasan aos sistemas OLTP que devolven resultados despois de procesar as solicitudes dos usuarios. Aínda que esta arquitectura permite aos usuarios finais xerar informes e realizar solicitudes, non pode proporcionar o

datos histórico e visión xeral da información da empresa como i datos dos diferentes sistemas OLTP non están integrados. Polo tanto, esta arquitectura non pode satisfacer a análise de datos complexos como as previsións.

Selección de aplicacións de acceso e recuperación datos

O propósito de construír a data warehouse é transmitir información aos usuarios finais (Inmon et al. 1997, Poe 1996, McFadden 1996, Shanks et al. 1997, Hammergren 1998); unha ou máis aplicacións de acceso e recuperación datos debe proporcionarse. Ata a data, existe unha gran variedade destas aplicacións entre as que o usuario pode escoller (Hammergren 1998, Humphries et al. 1999). As aplicacións que seleccione determinan o éxito do seu esforzo de almacenamento datos nunha organización porque as aplicacións son a parte máis visible data warehouse ao usuario final (Inmon et al. 1997, Poe 1996). Para ter éxito a data warehouse, debe ser capaz de soportar as actividades de análise de datos do usuario final (Poe 1996, Seddon e Benjamin 1998, Eckerson 1999). Así, debe identificarse o “nivel” do que quere o usuario final (Poe 1996, Mattison 1996, Inmon et al. 1997, Humphries et al. 1999).

En xeral, os usuarios finais pódense agrupar en tres categorías: usuarios executivos, analistas empresariais e usuarios avanzados (Poe 1996, Humphries et al. 1999). Os usuarios executivos necesitan un fácil acceso a conxuntos predefinidos de informes (Humphries et al. 1999). Pódese acceder facilmente a estas proporcións coa navegación por menú (Poe 1996). Ademais, os informes deben presentar información utilizando representacións gráficas como táboas e modelos para transmitir información rapidamente (Humphries et al. 1999). Os analistas empresariais, que quizais non teñan as capacidades técnicas para desenvolver informes dende cero por si mesmos, deben ser capaces de modificar os informes actuais para satisfacer as súas necesidades específicas (Poe 1996, Humphries et al. 1999). Os usuarios avanzados, pola contra, son o tipo de usuarios finais que teñen a capacidade de xerar e escribir solicitudes e informes desde cero (Poe 1996, Humphries et al. 1999). Eles son os que

elaboran informes para outro tipo de usuarios (Poe 1996, Humphries et al. 1999).

Unha vez determinados os requisitos do usuario final, debe realizarse unha selección de aplicacións de acceso e recuperación datos entre todos os dispoñibles (Poe 1996, Inmon et al. 1997).
Acceso a datos e as ferramentas de recuperación pódense clasificar en 4 tipos: ferramentas OLAP, ferramentas EIS/DSS, ferramentas de consulta e informes e ferramentas de minería de datos.

As ferramentas OLAP permiten aos usuarios crear consultas ad hoc, así como as realizadas no base de datos do data warehouse. Ademais, estes produtos permiten aos usuarios afondar desde datos xerais a detalladas.

As ferramentas EIS/DSS proporcionan informes executivos como análise de "e se" e acceso a informes dirixidos por menús. Os informes deben estar predefinidos e combinados con menús para facilitar a navegación.
As ferramentas de consulta e informes permiten aos usuarios producir informes específicos e predefinidos.

As ferramentas de minería de datos utilízanse para identificar as relacións que poderían arroxar nova luz sobre as operacións esquecidas datos do almacén de datos.

Ademais de optimizar os requisitos de cada tipo de usuario, as ferramentas seleccionadas deben ser intuitivas, eficientes e fáciles de usar. Tamén deben ser compatibles con outras partes da arquitectura e poder funcionar con sistemas existentes. Tamén se recomenda escoller ferramentas de acceso e recuperación de datos con prezos e rendemento razoables. Outros criterios a considerar inclúen o compromiso do provedor da ferramenta para apoiar o seu produto e como se desenvolverá en futuras versións. Para garantir o compromiso dos usuarios no uso do almacén de datos, o equipo de desenvolvemento implica aos usuarios no proceso de selección da ferramenta. Neste caso, deberase realizar unha avaliación práctica do usuario.

Para mellorar o valor do almacén de datos, o equipo de desenvolvemento tamén pode proporcionar acceso web ao seu almacén de datos. Un almacén de datos habilitado para a web permite aos usuarios acceder a datos desde lugares remotos ou mentres viaxa. Ademais a información pode

ofrecerse a un custo inferior mediante unha redución dos custos de formación.

2.4.3 Almacén de datos Fase de Operación

Esta fase consta de tres actividades: definición de estratexias de actualización de datos, control das actividades do almacén de datos e xestión da seguridade do almacén de datos.

Definición de estratexias de actualización de datos

Despois da carga inicial, i datos en base de datos do almacén de datos deben actualizarse periodicamente para reproducir os cambios realizados neles datos orixinais. Polo tanto, debe decidir cando actualizar, con que frecuencia debe programarse a actualización e como actualizar os datos. datos. Suxírese actualizar o datos cando o sistema se pode desconectar. A frecuencia de actualización está determinada polo equipo de desenvolvemento en función dos requisitos do usuario. Existen dous enfoques para actualizar o almacén de datos: a actualización completa e a carga continua de cambios.

O primeiro enfoque, a actualización completa, require recargar todo datos dende cero. Isto significa que todo datos necesarios deben ser extraídos, limpos, transformados e integrados en cada actualización. Este enfoque debe evitarse, na medida do posible, porque require moito tempo e recursos.

Un enfoque alternativo é cargar cambios continuamente. Isto engade i datos que se modificaron desde o último ciclo de actualización do almacén de datos. A identificación de rexistros novos ou modificados reduce significativamente a cantidade de datos que se deben propagar ao data warehouse en cada actualización xa que só estes datos engadirase a base de datos do almacén de datos.

Hai polo menos 5 enfoques que se poden usar para retirar i datos novo ou modificado. Para obter unha estratexia eficiente de actualización de datos datos pode ser útil unha mestura destes enfoques que capture todos os cambios no sistema.

O primeiro enfoque, que utiliza marcas de tempo, asume que todos están asignados datos editou e actualizou unha marca de tempo para que poidas identificar todas facilmente datos modificado e novo. Este enfoque, porén, non foi moi utilizado na maioría dos sistemas operativos actuais.
O segundo enfoque é utilizar un ficheiro delta xerado por unha aplicación que contén só os cambios realizados datos. Usar este ficheiro tamén amplía o ciclo de actualización. Non obstante, mesmo este método non se utilizou en moitas aplicacións.
O terceiro enfoque é analizar un ficheiro de rexistro, que basicamente contén información similar ao ficheiro delta. A única diferenza é que se crea un ficheiro de rexistro para o proceso de recuperación e pode ser difícil de entender.
O cuarto enfoque é modificar o código da aplicación. Non obstante, a maioría do código da aplicación é antigo e fráxil; polo tanto, debe evitarse esta técnica.
O último enfoque é comparar datos fontes co ficheiro dei principal datos.

Control das actividades do almacén de datos

Unha vez que o almacén de datos foi liberado aos usuarios, debe ser supervisado ao longo do tempo. Neste caso, o administrador do almacén de datos pode empregar unha ou máis ferramentas de xestión e control para supervisar o uso do almacén de datos. En particular, pódese recoller información sobre as persoas e o tempo no que acceden ao almacén de datos. Veña datos recollido, pódese crear un perfil do traballo realizado que se pode utilizar como entrada na implementación de contracargo do usuario. O contracargo permite que os usuarios sexan informados sobre o custo do procesamento do almacén de datos.

Ademais, a auditoría do almacén de datos tamén se pode utilizar para identificar os tipos de consultas, o seu tamaño, o número de consultas por día, os tempos de reacción das consultas, os sectores alcanzados e a cantidade de consultas. datos procesado. Outro propósito de facer a auditoría do almacén de datos é identificar datos que non están en uso. Estes datos pódense eliminar do almacén de datos para mellorar o tempo

de resposta de execución de consulta e supervisar o crecemento de datos que residen dentro do base de datos do almacén de datos.

Xestión da seguridade do almacén de datos

Un almacén de datos contén datos integrado, crítico, sensible ao que se pode acceder facilmente. Por este motivo, debe estar protexido de usuarios non autorizados. Unha forma de implementar a seguridade é usar a función del SGBD para asignar diferentes privilexios a distintos tipos de usuarios. Deste xeito, debe manterse un perfil de acceso para cada tipo de usuario. Outra forma de protexer o almacén de datos é cifralo como está escrito no base de datos do almacén de datos. Acceso a datos e as ferramentas de recuperación deben descifrar o datos antes de presentar os resultados aos usuarios.

2.4.4 Almacén de datos Fase de implantación

É a última fase do ciclo de implementación do almacén de datos. As actividades a realizar nesta fase inclúen a formación dos usuarios para o uso do data warehouse e a realización de revisións do data warehouse.

Formación de usuarios

A formación do usuario debe realizarse antes de acceder ao datos do almacén de datos e o uso de ferramentas de recuperación. Xeralmente, as sesións deben comezar cunha introdución ao concepto de almacenamento datos, o contido do almacén de datos, o meta datos e as características básicas das ferramentas. Entón, os usuarios máis avanzados tamén poderían estudar as táboas físicas e as características dos usuarios das ferramentas de acceso e recuperación de datos.

Hai moitos enfoques para facer formación de usuarios. Un deles implica unha selección de moitos usuarios ou analistas elixidos entre un conxunto de usuarios, en función das súas habilidades de liderado e comunicación. Están formados persoalmente en todo o que precisan saber para familiarizarse co sistema. Unha vez rematada a formación, volven ao seu posto de traballo e comezan a ensinar a outros usuarios a utilizar o sistema. No

Segundo o que aprenderon, outros usuarios poden comezar a explorar o almacén de datos.
Outro enfoque é formar moitos usuarios ao mesmo tempo, coma se estiveses facendo un curso presencial. Este método é axeitado cando hai moitos usuarios que precisan ser adestrados ao mesmo tempo. Outro método é adestrar a cada usuario individualmente, un por un. Este método é adecuado cando hai poucos usuarios.

O propósito da formación de usuarios é familiarizarte co acceso ao datos e ferramentas de recuperación, así como os contidos do almacén de datos. Non obstante, algúns usuarios poden verse desbordados pola cantidade de información proporcionada durante a sesión de adestramento. Polo tanto, hai que realizar un certo número de sesións de actualización para a asistencia continuada e para responder a preguntas concretas. Nalgúns casos fórmase un grupo de usuarios para proporcionar este tipo de soporte.

Recollida de comentarios

Unha vez que se implementou o almacén de datos, os usuarios poden usar i datos que residen no almacén de datos para diversos fins. Principalmente, os analistas ou usuarios usan i datos no almacén de datos para:

1. 1 Identificar as tendencias da empresa
2. 2 Analizar os perfís de compra de clientes
3. 3 Divide i clientes e de
4. 4 Ofrecer os mellores servizos para clientes - personalizar os servizos
5. 5 Formular estratexias marketing
6. 6 Proporcione presupostos competitivos para análises de custos e axuda ao control
7. 7 Apoiar a toma de decisións estratéxicas
8. 8 Identifica oportunidades para destacar
9. 9 Mellorar a calidade dos procesos empresariais actuais
10. 10 Comproba o beneficio

Seguindo a dirección de desenvolvemento do almacén de datos, poderíase realizar unha serie de revisións ao sistema para obter comentarios

tanto do equipo de desenvolvemento como da comunidade de usuarios finais.
Os resultados obtidos pódense ter en conta para o seguinte ciclo de desenvolvemento.

Dado que o almacén de datos ten un enfoque incremental, é fundamental aprender dos éxitos e erros de desenvolvementos anteriores.

2.5 Resumo

Neste capítulo discutíronse os enfoques presentes na literatura. Na sección 1, tratouse o concepto de almacén de datos e o seu papel na ciencia da decisión. A sección 2 describiu as principais diferenzas entre os almacéns de datos e os sistemas OLTP. Na sección 3 comentamos o modelo de almacén de datos Monash que se utilizou na sección 4 para describir as actividades implicadas no proceso de desenvolvemento dun almacén de datos, estas teses non se basearon nunha investigación rigorosa. O que acontece na realidade pode ser moi diferente do que informa a literatura, non obstante, estes resultados pódense utilizar para crear un fondo básico que subliña o concepto de almacén de datos para esta investigación.

Capítulo 3

Métodos de investigación e deseño

Este capítulo aborda os métodos de investigación e deseño para este estudo. A primeira parte amosa unha visión xenérica dos métodos de investigación dispoñibles para a recuperación de información, ademais de tratarse dos criterios para seleccionar o mellor método para un estudo concreto. Na sección 2, discútanse despois dous métodos seleccionados cos criterios que se acaban de expoñer; deles, elixirase e adoptarase un cos motivos expostos no apartado 3 onde tamén se expoñan os motivos de exclusión do outro criterio. A sección 4 presenta o deseño da investigación e a sección 5 as conclusións.

3.1 Investigación en sistemas de información

A investigación en sistemas de información non se limita só ao ámbito tecnolóxico senón que tamén debe ampliarse para incluír fins de comportamento e organizativos.
Debémosllo ás teses de diversas disciplinas que van dende as ciencias sociais ata as naturais; isto leva á necesidade de utilizar un certo espectro de métodos de investigación que impliquen métodos cuantitativos e cualitativos para os sistemas de información.
Todos os métodos de investigación dispoñibles son importantes, de feito varios investigadores como Jenkins (1985), Nunamaker et al. (1991) e Galliers (1992) sosteñen que non existe un método universal específico para realizar investigacións nos diversos campos dos sistemas de información; de feito un método pode ser axeitado para unha investigación concreta pero non para outras. Isto lévanos á necesidade de seleccionar un método axeitado para o noso proxecto de investigación particular: para esta elección Benbasat et al. (1987) afirman que debe considerarse a natureza e o propósito da investigación.

3.1.1 Natureza da investigación

Os distintos métodos baseados na natureza da investigación pódense clasificar en tres tradicións moi coñecidas na ciencia da información: investigación positivista, interpretativa e crítica.

3.1.1.1 Investigación positivista

A investigación positivista tamén se coñece como estudo científico ou empírico. Búscase: “explicar e predicir o que sucederá no mundo social observando as regularidades e as relacións causa-efecto entre os elementos que o constitúen” (Shanks et al 1993).

A investigación positivista tamén se caracteriza pola repetibilidade, simplificacións e refutacións. Ademais, a investigación positivista admite a existencia de relacións a priori entre os fenómenos estudados.
Segundo Galliers (1992) a taxonomía é un método de investigación incluído no paradigma positivista, que non obstante non se limita a este, de feito existen experimentos de laboratorio, experimentos de campo, estudos de casos, demostracións de teoremas, predicións e simulacións. Mediante estes métodos, os investigadores admiten que os fenómenos estudados poden ser observados de forma obxectiva e rigorosa.

3.1.1.2 Investigación interpretativa

A investigación interpretativa, que a miúdo se denomina fenomenoloxía ou antipositivismo, é descrita por Neuman (1994) como “a análise sistemática do significado social da acción mediante a observación directa e detallada das persoas en situacións naturais, co fin de chegar a unha comprensión e á interpretación de como as persoas crean e manteñen o seu mundo social”. Os estudos interpretativos rexeitan a suposición de que os fenómenos observados se poidan observar obxectivamente. De feito baséanse en interpretacións subxectivas. Ademais, os investigadores interpretativos non impoñen significados a priori aos fenómenos que estudan.

Este método inclúe estudos subxectivos/argumentativos, investigación-acción, estudos descritivos/interpretativos, investigacións futuras e xogos de roles. Ademais destas enquisas e estudos de casos pódense incluír neste enfoque xa que se refiren a estudos de individuos ou organizacións en situacións complexas do mundo real.

3.1.1.3 Investigación crítica

A indagación crítica é o enfoque menos coñecido nas ciencias sociais, pero recentemente recibiu a atención dos investigadores de sistemas de información. A asunción filosófica de que a realidade social é historicamente producida e reproducida polas persoas, así como polos sistemas sociais coas súas accións e interaccións. A súa capacidade, porén, está mediada por unha serie de consideracións sociais, culturais e políticas.

Do mesmo xeito que a investigación interpretativa, a investigación crítica sostén que a investigación positivista non ten nada que ver co contexto social e ignora a súa influencia nas accións humanas.
A investigación crítica, pola súa banda, critica a investigación interpretativa por ser demasiado subxectiva e por non pretender axudar ás persoas a mellorar as súas vidas. A maior diferenza entre a investigación crítica e os outros dous enfoques é a súa dimensión valorativa. Mentres que a obxectividade das tradicións positivistas e interpretativas é predicir ou explicar o status quo ou a realidade social, a investigación crítica pretende avaliar e transformar criticamente a realidade social obxecto de estudo.

Os investigadores críticos adoitan opoñerse ao status quo para eliminar as diferenzas sociais e mellorar as condicións sociais. A investigación crítica ten un compromiso cunha visión procesual dos fenómenos de interese e, polo tanto, é normalmente lonxitudinal. Exemplos de métodos de investigación son os estudos históricos a longo prazo e os estudos etnográficos. A investigación crítica, porén, non foi moi utilizada na investigación de sistemas de información

3.1.2 Finalidade da investigación

Xunto coa natureza da investigación, o seu propósito pode ser usado para guiar ao investigador na selección dun método de investigación particular. A finalidade dun proxecto de investigación está estreitamente relacionada coa posición da investigación en relación ao ciclo de investigación que consta de tres fases: construción da teoría, probas teóricas e perfeccionamento da teoría. Así, en función da temporalización do ciclo de investigación, un proxecto de investigación pode ter unha finalidade explicativa, descritiva, exploratoria ou preditiva.

3.1.2.1 Investigación exploratoria

A investigación exploratoria ten como obxectivo investigar un tema totalmente novo e formular preguntas e hipóteses para futuras investigacións. Este tipo de investigación utilízase na construción da teoría para obter referencias iniciais nunha nova área. Normalmente, utilízanse métodos de investigación cualitativa, como estudos de casos ou estudos fenomenolóxicos.

Non obstante, tamén é posible empregar técnicas cuantitativas como enquisas exploratorias ou experimentos.

3.1.3.3 Investigación descritiva

A investigación descritiva ten como obxectivo analizar e describir con gran detalle unha situación ou práctica organizativa determinada. Isto é apropiado para construír teorías e tamén se pode usar para confirmar ou desafiar hipóteses. A investigación descritiva adoita incluír o uso de medidas e mostras. Os métodos de investigación máis axeitados inclúen as enquisas e a análise de antecedentes.

3.1.2.3 Investigación explicativa

A investigación explicativa trata de explicar por que suceden as cousas. Constrúese sobre feitos que xa foron estudados e trata de atopar as razóns destes feitos.
Así, a investigación explicativa baséase normalmente na investigación exploratoria ou descritiva e é auxiliar para probar e refinar teorías. A investigación explicativa normalmente emprega estudos de casos ou métodos de investigación baseados en enquisas.

3.1.2.4 Investigación preventiva

A investigación preventiva ten como obxectivo predicir os eventos e comportamentos baixo observación que se están a estudar (Marshall e Rossman 1995). A predición é a proba científica estándar da verdade. Este tipo de investigación xeralmente emprega enquisas ou análises datos historiadores. (1989)

A discusión anterior demostra que hai unha serie de métodos de investigación posibles que se poden utilizar nun estudo particular. Non obstante, debe haber un método específico que sexa máis axeitado que os outros para un tipo particular de proxecto de investigación. (Galliers 1987, Yin 1989, De Vaus 1991). Cada investigador, polo tanto, debe avaliar coidadosamente os puntos fortes e débiles de varios métodos, para adoptar o método de investigación máis axeitado e compatible co proxecto de investigación. (Jenkins 1985, Pervan e Klass 1992, Bonomia 1985, Yin 1989, Himilton e Ives 1992).

3.2. Posibles métodos de investigación

O obxectivo deste proxecto foi estudar a experiencia en organizacións australianas con i datos almacenado cun desenvolvemento de data warehouse. Dato que, na actualidade, hai unha falta de investigación na área de almacenamento de datos en Australia, este proxecto de investigación aínda está na fase teórica do ciclo de investigación e ten unha finalidade exploratoria. Explorar a experiencia nas organizacións australianas que adoptan o almacenamento de datos require a interpretación da sociedade real. En consecuencia, o suposto filosófico que subxace ao proxecto de investigación segue a interpretación tradicional.

Despois dun exame rigoroso dos métodos dispoñibles, identificáronse dous posibles métodos de investigación: as enquisas e os estudos de casos, que se poden utilizar para investigacións exploratorias (Shanks et al. 1993). Galliers (1992) defende a idoneidade destes dous métodos para este estudo particular na súa taxonomía revisada dicindo que son axeitados para a construción da teoría. As dúas subseccións seguintes tratan cada método en detalle.

3.2.1 Método de investigación da enquisa

O método de investigación da enquisa procede do antigo método do censo. Un censo consiste en recoller información de toda unha poboación. Este método é caro e pouco práctico, especialmente se a poboación é grande. Así, en comparación cun censo, unha enquisa céntrase normalmente na recollida de información para un pequeno número, ou mostra, dos representantes da poboación (Fowler 1988, Neuman 1994). Unha mostra reflicte a poboación da que se extrae, con diferentes niveis de precisión, dependendo da estrutura da mostra, o tamaño e o método de selección utilizados (Fowler 1988, Babbie 1982, Neuman 1994).

O método de enquisa defínese como “instantáneas de prácticas, situacións ou puntos de vista nun momento determinado, realizadas mediante cuestionarios ou entrevistas, das que se poden extraer inferencias.
made” (Galliers 1992:153) [instantánea de prácticas, situacións ou puntos de vista nun momento determinado, realizada mediante cuestionarios ou entrevistas, das que se poden facer inferencias]. As enquisas tratan de recoller información sobre algún aspecto do estudo, dun determinado número de participantes, facendo preguntas (Fowler 1988). Estes cuestionarios e entrevistas, que inclúen entrevistas telefónicas presenciais e estruturadas, son tamén as técnicas de recollida de datos máis comúnmente empregadas nas investigacións (Blalock 1970, Nachmias e Nachmias 1976, Fowler 1988), pódense utilizar observacións e análises (Gable 1994). De todos estes métodos de recollida do datos, o uso do cuestionario é a técnica máis popular, xa que garante que i datos

recollidas están estruturadas e formateadas, polo que facilita a clasificación da información (Hwang 1987, de Vaus 1991).

Ao analizar i datos, unha estratexia de investigación adoita empregar técnicas cuantitativas, como a análise estatística, pero tamén se poden empregar técnicas cualitativas (Galliers 1992, Pervan).

e Klass 1992, Gable 1994). Normalmente, i datos utilízanse para analizar distribucións e patróns de asociacións (Fowler 1988).

Aínda que as enquisas son xeralmente apropiadas para investigacións que tratan a pregunta "que?" (que) ou derivando del, como "canto" e "cantos", pódense preguntar a través da pregunta "por que" (Sonquist e Dunkelberg 1977, Yin 1989). Segundo Sonquist e Dunkelberg (1977), a investigación de investigación ten como obxectivo desafiar hipóteses, avaliar programas, describir a poboación e desenvolver modelos de comportamento humano. Ademais, as enquisas pódense utilizar para estudar unha determinada opinión da poboación, condicións, opinións, características, expectativas e mesmo comportamentos pasados ​​ou presentes (Neuman 1994).

As enquisas permiten ao investigador descubrir relacións entre a poboación e os resultados son normalmente máis xerais que outros métodos (Sonquist e Dunkelberg 1977, Gable 1994). As enquisas permiten aos investigadores cubrir unha área xeográfica máis grande e chegar a moitos entrevistados (Blalock 1970, Sonquist e Dunkelberg 1977, Hwang e Lin 1987, Gable 1994, Neuman 1994). Finalmente, as enquisas poden proporcionar información que non está dispoñible noutro lugar ou na forma necesaria para as análises (Fowler 1988).

Non obstante, hai algunhas limitacións na realización dunha enquisa. Unha desvantaxe é que o investigador non pode obter moita información sobre o obxecto estudado. Isto débese a que as enquisas se realizan só nun momento determinado e, polo tanto, hai un número limitado de variables e persoas que o investigador pode

estudo (Yin 1989, de Vaus 1991, Gable 1994, Denscombe 1998). Outra desvantaxe é que a realización dunha enquisa pode ser moi custosa en termos de tempo e recursos, especialmente se implica entrevistas cara a cara (Fowler 1988).

3.2.2. Método de investigación de investigación

O método de investigación por indagación implica o estudo en profundidade dunha situación particular dentro do seu contexto do mundo real durante un período de tempo definido, sen ningunha intervención por parte do investigador (Shanks & C. 1993, Eisenhardt 1989, Jenkins 1985). Este método utilízase principalmente para describir as relacións entre as variables que se están a estudar nunha determinada situación (Galliers 1992). As investigacións poden implicar casos únicos ou múltiples, dependendo do fenómeno analizado (Franz e Robey 1987, Eisenhardt 1989, Yin 1989).

O método de investigación de indagación defínese como "unha investigación empírica que estuda un fenómeno contemporáneo dentro do seu contexto real, utilizando múltiples fontes recollidas dunha ou máis entidades como persoas, grupos ou organizacións" (Yin 1989). Non existe unha separación clara entre o fenómeno e o seu contexto e non existe control ou manipulación experimental das variables (Yin 1989, Benbasat et al. 1987).

Hai unha variedade de técnicas para recoller datos que se poden empregar no método de investigación, que inclúe observacións directas, revisións de rexistros de arquivo, cuestionarios, revisión de documentación e entrevistas estruturadas. Conta con diversas técnicas de recolección datos, as investigacións permiten aos investigadores tratar con ambos datos cualitativo e cuantitativo ao mesmo tempo (Bonoma 1985, Eisenhardt 1989, Yin 1989, Gable 1994). Como ocorre co método da enquisa, un investigador da enquisa actúa como observador ou investigador e non como participante activo na organización obxecto de estudo.

Benbasat e outros (1987) afirman que o método de indagación é particularmente axeitado para construír a teoría da investigación, que comeza cunha pregunta de investigación e continúa coa educación.

dunha teoría durante o proceso de recollida datos. Sendo tamén apto para o escenario

de construción da teoría, Franz e Robey (1987) suxiren que o método de investigación tamén se pode usar para a fase de teoría complexa. Neste caso, a partir das evidencias recollidas, verifícase ou refuta unha determinada teoría ou hipótese. Ademais, a enquisa tamén é adecuada para investigacións que traten preguntas de "como" ou "por que" (Yin 1989).

En comparación con outros métodos, as enquisas permiten ao investigador captar información esencial con máis detalle (Galliers 1992, Shanks et al. 1993). Ademais, as enquisas permiten ao investigador comprender a natureza e a complexidade dos procesos estudados (Benbasat et al. 1987).

Hai catro principais inconvenientes asociados ao método de enquisa. O primeiro é a falta de deducións controladas. A subxectividade do investigador pode alterar os resultados e conclusións do estudo (Yin 1989). A segunda desvantaxe é a falta de observación controlada. A diferenza dos métodos experimentais, o investigador investigador non pode controlar os fenómenos estudados xa que son examinados no seu contexto natural (Gable 1994). A terceira desvantaxe é a falta de replicabilidade. Isto débese a que é improbable que o investigador observe os mesmos eventos e non pode verificar os resultados dun estudo en particular (Lee 1989). Finalmente, como consecuencia da non replicabilidade, é difícil xeneralizar os resultados obtidos dunha ou varias investigacións (Galliers 1992, Shanks et al. 1993). Todos estes problemas, porén, non son insalvables e poden, de feito, ser minimizados polo investigador aplicando as accións adecuadas (Lee 1989).

3.3. Xustificar a metodoloxía de investigación adoptado

Entre os dous métodos de investigación posibles para este estudo, considérase que o método de enquisa é o máis axeitado. A investigación foi descartada tras unha coidadosa consideración das pertinentes

méritos e debilidades. A idoneidade ou inadecuación de cada método para este estudo é discutido a continuación.

3.3.1. Inadecuación do método de investigación de investigación

O método de investigación require un estudo en profundidade sobre unha situación particular dentro dunha ou máis organizacións durante un período de tempo (Eisenhardt 1989). Neste caso, o prazo poderá exceder do previsto para este estudo. Outra razón para non adoptar o método da enquisa é que os resultados poden sufrir unha falta de rigor (Yin 1989). A subxectividade do investigador pode influír nos resultados e nas conclusións. Outra razón é que este método é máis axeitado para a investigación sobre preguntas de tipo "como" ou "por que" (Yin 1989), mentres que a pregunta de investigación para este estudo é do tipo "que". Por último, pero non menos importante, é difícil xeneralizar os achados dunha ou poucas investigacións (Galliers 1992, Shanks et al. 1993). En base a esta razón, non se elixiu o método de investigación da enquisa xa que non era axeitado para este estudo.

3.3.2. Comodidade do método de busca de investigación

Cando se levou a cabo esta investigación, a práctica do almacenamento de datos non fora moi adoptada polas organizacións australianas. Entón, non había moita información sobre a súa implementación dentro das organizacións australianas. A información dispoñible procedía de organizacións que implementaran ou utilizaran a data warehouse. Neste caso, o método de investigación da enquisa é o máis axeitado xa que permite obter información que non está dispoñible noutro lugar ou na forma necesaria para a análise (Fowler 1988). Ademais, o método de investigación da enquisa permite ao investigador obter unha boa visión das prácticas, situacións ou puntos de vista nun momento determinado (Galliers 1992, Denscombe 1998). Requiriuse unha visión xeral para aumentar os coñecementos sobre a experiencia australiana de almacenamento de datos.

Ademais, Sonquist e Dunkelberg (1977) afirman que os resultados da investigación de enquisas son máis xerais que outros métodos.

3.4. Deseño de investigación de enquisas

A enquisa sobre prácticas de almacenamento de datos levouse a cabo en 1999. A poboación obxectivo estaba formada por organizacións australianas interesadas nos estudos de almacenamento de datos, xa que probablemente xa estaban informadas sobre o datos que almacenan e, polo tanto, poderían proporcionar información útil para este estudo. A poboación obxectivo identificouse mediante unha enquisa inicial a todos os membros australianos do Data Warehousing Institute (Tdwi-aap). Neste apartado explícase o deseño da fase de investigación empírica deste estudo.

3.4.1. Técnica de recolección datos

A partir das tres técnicas utilizadas habitualmente na investigación de enquisas (é dicir, cuestionario por correo, entrevista telefónica e entrevista persoal) (Nachmias 1976, Fowler 1988, de Vaus 1991), adoptouse o cuestionario por correo para este estudo. A primeira razón para adoptar esta última é que pode chegar a unha poboación dispersa xeograficamente (Blalock 1970, Nachmias e Nachmias 1976, Hwang e Lin 1987, de Vaus 1991, Gable 1994). En segundo lugar, o cuestionario por correo é axeitado para participantes altamente educados (Fowler 1988). O cuestionario por correo para este estudo foi dirixido aos patrocinadores, directores e/ou xestores de proxectos de almacenamento de datos. En terceiro lugar, os cuestionarios de correo son axeitados cando se dispón dunha lista de correo segura (Salant e Dilman 1994). TDWI, neste caso, unha asociación de almacenamento de datos de confianza proporcionou a lista de correo dos seus membros australianos. Outra vantaxe do cuestionario por correo fronte ao cuestionario telefónico ou ás entrevistas persoais é que permite aos entrevistados responder con máis precisión, especialmente cando os entrevistados deben consultar notas ou discutir preguntas con outras persoas (Fowler 1988).

Unha desvantaxe potencial pode ser o tempo necesario para realizar cuestionarios por correo. Normalmente, unha enquisa por correo realízase nesta secuencia: cartas por correo, esperar respostas e enviar confirmación (Fowler 1988, Bainbridge 1989). Así, o tempo total pode ser superior ao necesario para entrevistas persoais ou entrevistas telefónicas. Non obstante, o tempo total pódese coñecer de antemán (Fowler 1988, Denscombe 1998). Non se pode coñecer de antemán o tempo dedicado a realizar entrevistas persoais xa que varía dunha entrevista a outra (Fowler 1988). As entrevistas telefónicas poden ser máis rápidas que os cuestionarios postais e as entrevistas persoais, pero poden ter un alto índice de non resposta debido á indisponibilidade dalgunhas persoas (Fowler 1988). Ademais, as entrevistas telefónicas adoitan limitarse a listas de preguntas relativamente curtas (Bainbridge 1989).

Outra debilidade dun cuestionario por correo é a alta taxa de non resposta (Fowler 1988, Bainbridge 1989, Neuman 1994). Non obstante, tomáronse contramedidas asociando este estudo cunha institución de almacenamento de datos de confianza (é dicir, TDWI) (Bainbridge 1989, Neuman 1994), que envía dúas cartas de recordatorio aos non respondedores (Fowler 1988, Neuman 1994) e tamén inclúe unha carta adicional. explicando o propósito do estudo (Neuman 1994).

3.4.2. Unidade de análise

O obxectivo deste estudo é obter información sobre a implantación do almacenamento de datos e o seu uso nas organizacións australianas. A poboación obxectivo está formada por todas as organizacións australianas que implementaron, ou están a implementar, i data warehouse. As organizacións individuais rexístrase entón no nome. O cuestionario foi enviado por correo ás organizacións interesadas en adoptar data warehouse. Este método garante que a información recollida procede dos recursos máis axeitados de cada organización participante.

3.4.3. Mostra da enquisa

A "lista de correo" dos participantes na enquisa foi obtida de TDWI. Desta lista, seleccionáronse 3000 organizacións australianas como base para a mostraxe. Enviouse á mostra unha carta adicional explicando o proxecto e a finalidade da enquisa, xunto cunha folla de respostas e un sobre prepago para devolver o cuestionario cuberto. Das 3000 organizacións, 198 aceptaron participar no estudo. Esperábase un número tan reducido de respostas datas o gran número de organizacións australianas que entón adoptaran ou estaban adoptando a estratexia de almacenamento de datos dentro das súas organizacións. Así, a poboación obxectivo deste estudo está formada só por 198 organizacións.

3.4.4. Contidos do cuestionario

A estrutura do cuestionario baseouse no modelo de almacenamento de datos Monash (discutido anteriormente na parte 2.3). O contido do cuestionario baseouse na análise da literatura presentada no capítulo 2. No Apéndice B pódese atopar unha copia do cuestionario enviado aos participantes na enquisa. O cuestionario consta de seis apartados, que seguen as fases do modelo abordado. Os seis parágrafos seguintes resumen brevemente o contido de cada sección.

Sección A: Información básica sobre a organización
Esta sección contén preguntas relativas ao perfil das organizacións participantes. Ademais, algunhas das preguntas están relacionadas co estado do proxecto de almacenamento de datos do participante. Na análise da enquisa non se revelou información confidencial como o nome da organización.

Sección B: Inicio
As preguntas desta sección están relacionadas coa tarefa de iniciar o almacenamento de datos. Realizáronse preguntas sobre os iniciadores do proxecto, os garantes, as habilidades e coñecementos necesarios, os obxectivos de desenvolvemento de data warehousing e as expectativas dos usuarios finais.

Sección C: Deseño
Esta sección contén preguntas relacionadas coa planificación das actividades data warehouse. En particular, as preguntas foron sobre o alcance de execución, a duración do proxecto, o custo do proxecto e a análise custo/beneficio.

Sección D: Desenvolvemento
Na sección de desenvolvemento hai preguntas relativas ás actividades de desenvolvemento do data warehouse: recollida de requisitos do usuario final, fontes de datos, o modelo lóxico de datos, prototipos, planificación de capacidades, arquitecturas técnicas e selección de ferramentas de desenvolvemento de data warehousing.

Sección E: Funcionamento
Cuestións operativas relacionadas co funcionamento e extensibilidade do data warehouse, como evoluciona na seguinte fase de desenvolvemento. Alí calidade dos datos, as estratexias de actualización de datos, a granularidade de datos, escalabilidade de data warehouse e os problemas de seguridade de data warehouse estaban entre os tipos de preguntas formuladas.

Sección F: Desenvolvemento
Esta sección contén preguntas relacionadas co uso de data warehouse polos usuarios finais. O investigador interesouse pola finalidade e utilidade do data warehouse, as estratexias de revisión e formación adoptadas e a estratexia de control de data warehouse adoptado.

3.4.5. Taxa de resposta

Aínda que as enquisas por correo son criticadas por ter unha baixa taxa de resposta, tomáronse medidas para aumentar a taxa de retorno (como se comentou anteriormente na parte 3.4.1). O termo "taxa de resposta" refírese á porcentaxe de persoas que responden ao cuestionario nunha determinada mostra da enquisa (Denscombe 1998). Para calcular a taxa de resposta neste estudo utilizouse a seguinte fórmula:

Número de persoas que responderon
Taxa de resposta = ——————————————————————————– X 100 Número total de cuestionarios enviados

3.4.6. Proba piloto

Antes de enviar o cuestionario á mostra, examináronse as preguntas mediante a realización de probas piloto, tal e como suxiren Luck e Rubin (1987), Jackson (1988) e de Vaus (1991). O propósito das probas piloto é revelar calquera expresión e pregunta incómodas e ambiguas que sexan difíciles de interpretar, aclarar as definicións e termos empregados e identificar o tempo aproximado necesario para completar o cuestionario (Warwick e Lininger 1975, Jackson 1988, Salant). e Dilman 1994). As probas piloto realizáronse seleccionando materias con características similares ás das materias finais, tal e como suxeriu Davis e Cosenza (1993). Neste estudo, seleccionáronse seis profesionais do almacenamento de datos como suxeitos piloto. Despois de cada proba piloto realizáronse as correccións necesarias. A partir das probas piloto realizadas, os participantes contribuíron a remodelar e restablecer a versión final do cuestionario.

3.4.7. Métodos de análise por Dati

I datos das enquisas recollidas dos cuestionarios pechados foron analizados mediante un paquete de programas estatísticos chamado SPSS. Moitas das respostas foron analizadas mediante estatísticas descritivas. Varios cuestionarios foron devoltos incompletos. Estes foron tratados con maior coidado para garantir que i datos as faltas non foron consecuencia de erros de entrada de datos, senón porque as preguntas non eran adecuadas para o solicitante de rexistro ou o solicitante decidiu non responder a unha ou máis preguntas específicas. Estas respostas que faltaban foron ignoradas durante a análise datos e codificáronse como "-9" para garantir a súa exclusión do proceso de análise.

Á hora de elaborar o cuestionario precodificáronse as preguntas pechadas asignando un número a cada opción. Despois utilizouse o número para preparar o datos durante a análise (Denscombe 1998, Sapsford e Jupp 1996). Por exemplo, había seis opcións enumeradas na pregunta 1 da sección B: consello de administración, alto executivo, departamento de TI, unidade de negocio, consultores e outras. No arquivo de datos de SPSS, xerouse unha variable para indicar «o iniciador do proxecto», con seis etiquetas de valor: «1» para «xunta directiva», «2» para «alto executivo», etc. O uso da escala Likertin nalgunhas das preguntas pechadas tamén permitiu unha identificación sen esforzo dado o uso dos correspondentes valores numéricos introducidos en SPSS. Para as preguntas con respostas non exhaustivas, que non se excluían mutuamente, cada opción foi tratada como unha única variable con dúas etiquetas de valor: '1' para 'marcado' e '2' para 'non marcado'.

As preguntas abertas foron tratadas de forma diferente ás preguntas pechadas. As respostas a estas preguntas non foron introducidas en SPSS. En cambio, foron analizados a man. O uso deste tipo de preguntas permítenos adquirir información sobre as ideas e experiencias persoais expresadas libremente dos entrevistados (Bainbridge 1989, Denscombe 1998). Cando foi posible, realizouse unha categorización das respostas.

Para a análise de datos, utilízanse métodos de análise estatística sinxelos, como a frecuencia de resposta, a media, a desviación estándar e a mediana (Argyrous 1996, Denscombe 1998).
A proba Gamma estaba funcionando ben para obter medidas cuantitativas das asociacións entre datos ordinais (Norusis 1983, Argyrous 1996). Estas probas eran apropiadas porque as escalas ordinais utilizadas non tiñan moitas categorías e podían mostrarse nunha táboa (Norusis 1983).

3.5 Resumo

Neste capítulo describiuse a metodoloxía de investigación e o deseño adoptado para este estudo.

A selección do método de investigación máis axeitado para un estudo concreto ten en conta
consideración dunha serie de regras, incluíndo a natureza e o tipo de investigación, así como os méritos e debilidades de cada método posible (Jenkins 1985, Benbasat et al. 1097, Galliers and Land 1987, yin 1989, Hamilton e ives 1992, Galliers). 1992, Neuman 1994). Dada a falta de coñecemento e teoría existentes sobre a adopción do almacenamento de datos en Australia, este estudo de investigación require un método de investigación interpretativo cunha capacidade exploratoria para explorar as experiencias das organizacións australianas. Seleccionouse o método de investigación elixido para recoller información sobre a adopción do concepto de almacenamento de datos por parte das organizacións australianas. Elixiuse un cuestionario postal como técnica de recollida datos. Xustificacións do método de investigación e da técnica de recollida datos seleccionados serán proporcionados neste capítulo. Ademais, presentouse un debate sobre a unidade de análise, a mostra empregada, as porcentaxes de respostas, o contido do cuestionario, a proba previa do cuestionario e o método de análise do cuestionario. datos.

Deseñar a Almacén de datos:

Combinando a relación de entidades e o modelado dimensional

RESUMO
Almacenamento i datos é un tema de actualidade importante para moitas organizacións. Unha cuestión clave no desenvolvemento do almacenamento informático datos é o seu deseño.
O deseño debe apoiar a detección de conceptos no data warehouse ao sistema herdado e outras fontes de datos e tamén de fácil comprensión e eficacia na implementación de data warehouse.
Gran parte da literatura de almacenamento de datos recomenda o uso de modelado de relacións entidades ou modelado dimensional para representar o deseño de data warehouse.
Neste artigo mostramos como ambas as representacións poden combinarse nun enfoque para o debuxo data warehouse. O enfoque empregado é sistemático

examinado nun estudo de caso e identifícase nunha serie de implicacións importantes cos profesionais.

ALMACENAMIENTO DE DATOS

Un data warehouse adoita definirse como unha “recopilación de datos orientada ao tema, integrada, variable no tempo e non volátil para apoiar as decisións da dirección” (Inmon e Hackathorn, 1994). Orientado ao tema e integrado indica que o data warehouse está deseñado para cruzar os límites funcionais dos sistemas Legaci para ofrecer unha perspectiva integrada de datos.
A variante temporal afecta a natureza histórica ou de serie temporal do datos nunha data warehouse, que permite analizar tendencias. Non volátil indica que o data warehouse non se actualiza continuamente como un base de datos de OLTP. Máis ben actualízase periodicamente, con datos procedentes de fontes internas e externas. O data warehouse está deseñado especificamente para a busca en lugar de actualizar a integridade e o rendemento operativo.
A idea de almacenar i datos non é novo, era unha das finalidades da xestión datos desde os anos sesenta (O Martín, 1982).
I data warehouse ofrecen a infraestrutura datos para sistemas de apoio á xestión. Os sistemas de apoio á xestión inclúen os sistemas de apoio á decisión (DSS) e os sistemas de información executiva (EIS). Un DSS é un sistema de información baseado en ordenador que está deseñado para mellorar a toma de decisións humanas. Un EIS é normalmente un sistema de entrega de datos que permite aos líderes empresariais acceder facilmente á vista de datos.
A arquitectura xeral de a data warehouse destaca o papel de data warehouse en apoio á xestión. Así como ofrecer a infraestrutura datos para EIS e DSS, al data warehouse pódese acceder directamente a través de consultas. O datos incluído nun data warehouse baséanse nunha análise dos requisitos de información de xestión e obtéñense de tres fontes: sistemas legados internos, sistemas de captura de datos de propósito especial e fontes de datos externas. O datos nos sistemas heredados internos son frecuentemente redundantes, inconsistentes, de baixa calidade e almacénanse en diferentes formatos, polo que deben conciliarse e limparse antes de poder cargalos no

data warehouse (Inmon, 1992; McFadden, 1996). O datos procedentes de sistemas de almacenamento datos ad hoc e de fontes datos externos úsanse a miúdo para aumentar (actualizar, substituír) i datos desde sistemas legados.

Hai moitas razóns convincentes para desenvolver a data warehouse, que inclúen unha mellora na toma de decisións mediante o uso efectivo de máis información (Ives 1995), apoio para centrarse en acordos completos (Graham 1996) e redución de datos para EIS e DSS (Graham 1996, McFadden 1996).

Un estudo empírico recente atopou, de media, un retorno do investimento para data warehouse nun 401% despois de tres anos (Graham, 1996). Porén, os outros estudos empíricos de data warehouse atopou problemas significativos, incluíndo dificultade para medir e asignar beneficios, falta de propósito claro, subestimar o propósito e a complexidade do proceso de almacenamento de beneficios. datos, en particular no que se refire ás fontes e á limpeza de datos. Almacenamento i datos pode considerarse como unha solución ao problema de xestión datos entre organizacións. A manipulación de datos como recurso social segue sendo un dos problemas fundamentais na xestión dos sistemas de información en todo o mundo durante moitos anos (Brancheau et al. 1996, Galliers et al. 1994, Niederman et al. 1990, Pervan 1993).

Un enfoque popular para xestionar datos nos anos oitenta foi o desenvolvemento dun modelo datos sociais. Modelo datos social foi deseñado para ofrecer unha base estable para o desenvolvemento de novos sistemas de aplicación e base de datos e a reconstrución e integración de sistemas legados (Brancheau et al.

1989, Goodhue et al. 1988:1992, Kim e Everest 1994). Non obstante, hai moitos problemas con este enfoque, en particular, a complexidade e o custo de cada tarefa e o longo tempo necesario para producir resultados tanxibles (Beynon-Davies 1994, Earl 1993, Goodhue et al. 1992, Periasamy 1994, Shanks 1997). ).

Il data warehouse é unha base de datos separada que coexiste con bases de datos legadas en lugar de substituílas. Permítelle, polo tanto, dirixir a xestión de datos e evitar a costosa reconstrución de sistemas legados.

ENFOQUES EXISTENTES PARA O DESEÑO DE DATOS

ALMACENAMENTO

O proceso de construción e perfeccionamento a data warehouse debería entenderse máis como un proceso evolutivo que como un ciclo de vida de desenvolvemento dos sistemas tradicionais (Desexo, 1995, Shanks, O'Donnell e Arnott 1997a). Hai moitos procesos implicados nun proxecto data warehouse como inicialización, planificación; información adquirida a partir dos requisitos solicitados aos directivos da empresa; fontes, transformacións, limpeza de datos e sincronización desde sistemas legados e outras fontes datos; sistemas de entrega en desenvolvemento; seguimento de data warehouse; e insensatez do proceso evolutivo e construción de a data warehouse (Stinchi, O'Donnell e Arnott 1997b). Neste diario centrámonos en como debuxar datos almacenados no contexto destes outros procesos. Hai unha serie de enfoques propostos para a arquitectura data warehouse en literatura (Inmon 1994, Ives 1995, Kimball 1994 McFadden 1996). Cada unha destas metodoloxías ten unha breve revisión cunha análise dos seus puntos fortes e débiles.

Inmon's (1994) Enfoque para Almacén de datos Proxecto

Inmon (1994) propuxo catro pasos iterativos para deseñar a data warehouse (ver Figura 2). O primeiro paso é deseñar un modelo datos social para entender como i datos pódense integrar en áreas funcionais dentro dunha organización dividindo o datos almacenar en zonas. Modelo datos está feito para almacenamento datos relativos á toma de decisións, incluíndo datos historiadores, e incluídos datos deducidos e agregados. O segundo paso é identificar as áreas temáticas para implementar. Estes baséanse en prioridades determinadas por unha organización en particular. O terceiro paso consiste en debuxar a base de datos para a área temática, preste especial atención á inclusión dos niveis axeitados de granularidade. Inmon recomenda utilizar o modelo de entidades e relacións. O cuarto paso é identificar os sistemas fonte datos necesario e desenvolver procesos de transformación para capturar, limpar e formatear i datos.

Os puntos fortes do enfoque de Inmon son que o modelo datos social proporciona a base para a integración de datos dentro da organización e planificación de apoios para o desenvolvemento iterativo de data warehouse. Os seus defectos son a dificultade e o custo no deseño do modelo datos social, a dificultade para comprender modelos de entidades e relacións empregados en ambos modelos, que datos social e o de datos almacenados por área temática, e a idoneidade de datos do debuxo de data warehouse para a realización de base de datos relacional pero non para base de datos multidimensional.

Aproximación a Ives (1995). Almacén de datos Proxecto

Ives (1995) propón un enfoque de catro pasos para deseñar un sistema de información que considera aplicable ao deseño dun sistema de información. data warehouse (ver Figura 3). O enfoque baséase moito na Enxeñaría da Información para o desenvolvemento de sistemas de información (Martin 1990). O primeiro paso é determinar os obxectivos, os factores críticos e de éxito e os indicadores clave de rendemento. Os procesos de negocio clave e a información necesaria son modelados para levarnos a un modelo datos sociais. O segundo paso consiste en desenvolver unha arquitectura definitoria datos almacenados por áreas, base de datos di data warehouse, os compoñentes tecnolóxicos que son necesarios, o conxunto de apoios organizativos necesarios para implementar e operar data warehouse. O terceiro paso inclúe a selección dos paquetes de software e ferramentas necesarios. O cuarto paso é o deseño detallado e a construción do data warehouse. Ives sinala que o almacenamento datos é un proceso iterativo restrinxido.

Os puntos fortes do enfoque Ives son o uso de técnicas específicas para determinar os requisitos de información, o uso dun proceso estruturado para apoiar a integración de data warehouse, a selección adecuada de hardware e software, e o uso de técnicas de representación múltiple para o data warehouse. Os seus defectos son inherentes á complexidade. Outros inclúen dificultade para desenvolver moitos niveis de base de datos dentro do data warehouse en tempos e custos razoables.

Aproximación de Kimball (1994). Almacén de datos Proxecto

Kimball (1994) propuxo cinco pasos iterativos para deseñar a data warehouse (ver Figuras 4). O seu enfoque está especialmente dedicado ao deseño dun solo data warehouse e sobre o uso de modelos dimensionais con preferencia aos modelos de entidades e relacións. Kimball analiza eses modelos dimensionais porque é máis doado para os líderes empresariais entender os negocios, é máis eficiente cando se trata de consultas complexas e o deseño de base de datos o físico é máis eficiente (Kimball 1994). Kimball recoñece que o desenvolvemento de a data warehouse é iterativo, e iso data warehouse pódense integrar táboas separadas dividíndoas en táboas de dimensións comúns.

O primeiro paso é identificar a área temática concreta a perfeccionar. O segundo e o terceiro pasos son o modelado dimensional. No segundo paso as medidas identifican cousas de interese na área temática e agrúpanse nunha táboa de feitos. Por exemplo, nunha área temática de vendas, as medidas de interese poden incluír a cantidade de artigos vendidos e o dólar como moeda de vendas. O terceiro paso consiste en identificar dimensións que son as formas en que se poden agrupar os feitos. Nunha área temática de vendas, as dimensións relevantes poden incluír artigo, localización e período de tempo. A táboa de feitos ten unha clave de varias partes para vinculala a cada unha das táboas de dimensións e normalmente contén un número moi grande de feitos. Pola contra, as táboas de dimensións conteñen información descritiva sobre dimensións e outros atributos que se poden usar para agrupar feitos. A táboa de feitos e dimensións proposta asociada forma o que se chama esquema en estrela pola súa forma. O cuarto paso consiste en construír a base de datos multidimensional para perfeccionar o patrón de estrelas. O paso final é identificar os sistemas fonte datos necesario e desenvolver procesos de transformación para capturar, limpar e formatear i datos.

Os puntos fortes do enfoque de Kimball inclúen o uso de modelos dimensionais para representar datos almacenado o que facilita a comprensión e conduce a un deseño físico eficiente. Un modelo dimensional que tamén utiliza facilmente ambos sistemas de base de datos relacionais poden ser perfeccionados ou sistemas base de datos multidimensional. Os seus defectos inclúen a falta dalgunhas técnicas para facilitar a planificación ou a integración de moitos patróns de estrelas dentro dun data warehouse e a dificultade de deseñar desde a estrutura desnormalizada extrema a un modelo dimensional a datos no sistema legado.

Aproximación aos datos de McFadden (1996). Deseño de almacén

McFadden (1996) propón un enfoque en cinco pasos para deseñar a data warehouse (ver Figura 5).
O seu enfoque baséase nunha síntese de ideas da literatura e céntrase no deseño dun único data warehouse. O primeiro paso implica unha análise de requisitos. Aínda que as especificacións técnicas non están prescritas, as notas de McFadden identifican as entidades datos especificacións e os seus atributos, e refírese aos lectores Watson e Frolick (1993) para a captura de requisitos.
No segundo paso, deseñarase un modelo de relacións de entidades data warehouse e despois validados polos líderes empresariais. O terceiro paso inclúe a determinación do mapeo a partir de sistemas legados e fontes externas data warehouse. O cuarto paso implica procesos de desenvolvemento, implantación e sincronización datos en data warehouse. No último paso, a entrega do sistema desenvólvese con especial énfase nunha interface de usuario. McFadden sinala que o proceso de debuxo é xeralmente iterativo.

Os puntos fortes do enfoque de McFadden apuntan á participación dos líderes empresariais na determinación dos requisitos e tamén a importancia dos recursos. datos, a súa limpeza e recollida. Entre os seus defectos destaca a falta dun proceso para romper un gran proxecto data warehouse en moitas etapas integradas, e o

dificultade para comprender os modelos de entidade e relación utilizados no deseño de data warehouse.

Non só nos escollen os que están preto de nós.