Sei sulla pagina 1di 15

INTRODUCCION DE DATA MART

Los productos Data Warehouse han nacido para resolver problemas de anlisis de
grandes masas de informacin, en empresas donde una pequea diferencia en el valor de
una variable, puede afectar la cuenta de resultado con unas diferencias de millones de
dlares.

Data Mart se destaca por una definicin de requerimientos ms fcil y rpida. Tambin se
simplifica el desarrollo de todo el mecanismo de su base de datos y con ello baja
substancialmente todo el coste del proyecto, as como su duracin. Normalmente, Data
Mart resuelve aplicaciones a nivel departamental, aunque en ocasiones se desarrolla una
aplicacin que integre todas ellas y proporciona las funciones de un EIS (Executive
Information System). El conocimiento de los meta datos es tan esencial como el
conocimiento de los datos del Data Warehouse. Deben incluir dominio, reglas de
validacin, derivacin y transformacin de los datos extrados.

Tambin describen las bases de datos del Warehouse, incluyendo reglas de distribucin y
control de la migracin hacia los Data Marts. Los procesos que monitorean los procesos
del Warehouse (como extraccin, carga, y uso) crean meta datos que son usados para
determinar que tan bien se comporta el sistema.
Los meta datos, deberan estar disponibles para los usuarios, para ser usados en sus
anlisis. Los administradores pueden manejar y proveer el acceso a travs de los servicio
del repositorio.

El uso efectivo de los Data Marts en un ambiente de Data Warehousing, es un factor
importante para la efectividad del Warehouse. Los Data Marts son diseados para
satisfacer las necesidades especficas de grupos comunes de usuarios (divisiones
geogrficas, divisiones organizacionales, etc.).

Los Data Marts son generalmente, subconjuntos del Data Warehouse, pero pueden
tambin integrar un nmero de fuentes heterogneas, e inclusive ser ms grandes, en
volumen de datos, que el propio Warehouse central.

El concepto Data Mart es una extensin natural del Data Warehouse, y est enfocado a
un departamento o rea especifica, como por ejemplo los departamentos de Finanzas o
Marketing. Permitiendo as un mejor control de la informacin que se est abarcando.



I. QU ES DATA MART?

Un mercado de datos es una forma simple de un almacn de datos que se centra
en un solo tema (o rea funcional), tales como ventas, finanzas o marketing. Los
datos se construyen a menudo y controlados por un nico departamento dentro de
una organizacin. Dado su enfoque de un solo tema, data marts normalmente
dibujan los datos de slo unas pocas fuentes. Las fuentes pueden ser los sistemas
internos de funcionamiento, un almacn central de datos, o datos externos.
Es un pequeos Data Warehouse, para un determinado numero de usuarios, para
un rea funcional, especifica de la compaa. Tambin podemos definir que un
Data Marts es un subconjunto de una bodega de datos para un
propsito especfico.
Su funcin es apoyar a otros sistemas para la toma de decisiones.
Se caracteriza por disponer la estructura ptima de datos para analizar la
informacin al detalle desde todas las perspectivas que afecten a los procesos de
dicho departamento. Por lo tanto para crear el datamart de un rea funcional de la
empresa es preciso encontrar la estructura ptima para el anlisis de su
informacin.

1.1. DIFERENCIAS ENTRE DATA MART Y DATAWAREHOUSE
Un almacn de datos, a diferencia de un mercado de datos, se ocupa de
varios temas y se implementa y controlado por una unidad central de
organizacin, tales como la tecnologa de la informacin corporativa (IT)
grupo normalmente.
A menudo, se le llama un almacn de datos central o la empresa. Por lo
general, un almacn de datos rene los datos de varios sistemas de origen.
Ninguna de estas definiciones bsicas limita el tamao de un mercado de
datos o la complejidad de los datos de apoyo a las decisiones que
contiene. Sin embargo, data marts son ms pequeos y menos complejos
que los almacenes de datos; por lo tanto, por lo general son ms fciles de
construir y mantener. Tabla A-1 se resumen las diferencias bsicas entre un
almacn de datos y un mercado de datos.
Tabla A-1 Diferencias entre un Data Warehouse y Data Mart
Categora Data Warehouse Data Mart
Alcance Corporativo Lnea de negocio (LOB)
Sujeto Mltiple Sujeto individual
Fuentes de datos Muchos Pocos
Tamao (tpico) 100 GB-TB + <100 GB
Tiempo de implementacin Meses o aos Meses


.

1.2. ARQUITECTURA DATAMART
De acuerdo a las operaciones que se deseen o requieran desarrollar, los DM
pueden adoptar las siguientes arquitecturas:
Top-Down: primero se define el DW y luego se desarrollan, construyen y
cargan los DM a partir del mismo. En la siguiente figura se encuentra
detallada esta arquitectura:

Como se puede apreciar, el DW es cargado a travs de procesos ETL y
luego este alimenta a los diferentes DM, cada uno de los cuales recibir los
datos que correspondan al tema o departamento que traten.
Esta forma de implementacin cuenta con la ventaja de no tener que
incurrir en complicadas sincronizaciones de hechos, pero requiere una gran
inversin y una gran cantidad de tiempo de construccin.
Bottom-Up: en esta arquitectura, se definen previamente los DM y luego se
integran en un DW centralizado. La siguiente figura presenta esta
implementacin:


Los DM se cargan a travs de procesos ETL, los cuales suministrarn la
informacin adecuada a cada uno de ellos. En muchas ocasiones, los DM
son implementados sin que exista el DW, ya que tienen sus mismas
caractersticas pero con la particularidad de que estn enfocados en un tema
especfico. Luego de que hayan sido creados y cargados todos los DM, se
proceder a su integracin con el depsito.
La ventaja que trae aparejada este modelo es que cada DM se crea y pone
en funcionamiento en un corto lapso de tiempo y se puede tener una
pequea solucin a un costo no tan elevado. Luego que todos los DM estn
puestos en marcha, se puede decidir si construir el DW o no. El mayor
inconveniente est dado en tener que sincronizar los hechos al momento de
la consolidacin en el depsito.

Dentro de las ventajas de aplicar un Data Mart a un negocio, se han
seleccionado las siguientes:

Son simples de implementar.
Conllevan poco tiempo de construccin y puesta en marcha.
Permiten manejar informacin confidencial.
Reflejan rpidamente sus beneficios y cualidades.
Reducen la demanda del depsito de datos.
1.3. TIPOS DE DATA MART
DATAMART OLAP - ON LINE ANALYTIC PROCESS
Los sistemas OLAP son bases de datos orientadas al procesamiento analtico.
Este anlisis suele implicar, generalmente, la lectura de grandes cantidades de
datos para llegar a extraer algn tipo de informacin til cmo por ejemplo:
tendencias de ventas, patrones de comportamiento de los consumidores,
elaboracin de informes complejos etc.
El acceso a los datos suele ser de slo lectura. La accin ms comn es la
consulta, con muy pocas inserciones, actualizaciones o eliminaciones.
Los datos se estructuran segn las reas de negocio, y los formatos de los
datos estn integrados de manera uniforme en toda la organizacin.
El historial de datos es a largo plazo, normalmente de dos a cinco aos.
Se basan en los populares cubos OLAP, que se construyen agregando, segn
los requisitos de cada rea o departamento, las dimensiones y los indicadores
necesarios de cada cubo relacional. El modo de creacin, explotacin y
mantenimiento de los cubos OLAP es muy heterogneo, en funcin de la
herramienta final que se utilice.
DATAMART OLTP- ON LINE TRANSACTIONAL PROCESSING

Los sistemas OLTP son bases de datos orientadas al procesamiento de
transacciones que pueden involucrar operaciones de insercin, modificacin y
borrado de datos. El proceso transaccional es tpico de las bases de datos
operacionales.
El acceso a los datos est optimizado para tareas frecuentes de lectura y
escritura, como por ejemplo la enorme cantidad de transacciones que tienen
que soportar diariamente las BD de bancos o hipermercados.
Los datos se estructuran segn el nivel aplicacin (programa de gestin a
medida, ERP o CRM implantado, sistema de informacin departamental...)
El historial de datos suele limitarse a los datos actuales o recientes.
Pueden basarse en un simple extracto del datawarehouse, no obstante, lo
comn es introducir mejoras en su rendimiento (las agregaciones y los filtrados
suelen ser las operaciones ms usuales) aprovechando las caractersticas
particulares de cada rea de la empresa. Las estructuras ms comunes en este
sentido son las tablas report, que vienen a ser fact-tables reducidas (que
agregan las dimensiones oportunas), y las vistas materializadas, que se
construyen con la misma estructura que las anteriores, pero con el objetivo de
explotar la reescritura de queries (aunque slo es posibles en algunos SGBD
avanzados, como Oracle).
1.4. COMPONENTES DEL DATAMART
1. Fuentes de Datos
Son las que alimentan de informacin al DataMart, estn diseadas
para registrar grandes cantidades de transacciones. Entre ella tenemos
la base de datos OLTP (Una base de datos para soportar procesos
transaccionales).

Caractersticas:
Son pobladas por usuarios finales.
Se optimizan en funcin a procesos transaccionales.
Se actualizan constantemente.
Contienen mucha informacin de detalle.
2. Procesos de extraccin, transformacin y carga de datos (ETL)

Los datos se encuentran almacenados en base de datos destinados al
registro de transacciones. Es necesario extraer y transformar los datos
antes de cargar los resultados en el Datamart.

Los mismos elementos de datos, si son usados por aplicaciones
diferentes o administrados por diferentes software DBMS, pueden
definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de manera diferente.
Todas estas inconsistencias deben resolverse antes que los
elementos de datos sean almacenados en el Datamart.
Uno de los desafos de cualquier implementacin de Datawarehouse o
Datamart, es el problema de transformar los datos.
La transformacin se encarga de las inconsistencias en los formatos
de datos y la codificacin, que pueden existir dentro de una base de
datos nica y que casi siempre existen cuando mltiples bases de
datos contribuyen al Datamart.
3. Datawarehouse

Un Datawarehouse contiene la informacin de toda la empresa. Cualquier
departamento puede acceder a la informacin de cualquier otro
departamento mediante un nico medio, as como obligar a que los mismos
trminos tengan el mismo significado para todos.

Un Datamart almacena la informacin de un rea o departamento
especifico y un conjunto de Datamart forman un Datawarehouse

Un Datamart es una solucin que, compartiendo tecnologa con el
Datawarehouse (pero con contenidos especficos, volumen de datos ms
limitado y un alcance histrico menor), permita dar soporte a una empresa
pequea, un departamento o rea de negocio de una empresa grande.

El Datamart cubre de manera ptima las necesidades de informes. No es
conveniente efectuar consultas sobre los sistemas transaccionales, debido
a que hay que integrar datos de diversas OLTP.

4. Herramientas de Explotacin o Tecnologas
El Datamart est orientado a la toma de decisiones. Un buen diseo
de la base de datos favorece el anlisis y la recuperacin de datos
para obtener una ventaja estratgica y para facilitar la toma de
decisiones.

El Datamart no est orientado a procesos relacionados con la
operatividad del rea determinada. El Datamart est preparado para
ser explotado mediante herramientas especficas que permiten la
extraccin de informacin significativa y patrones de comportamiento
que permanecen ocultos en un enorme repositorio de datos.
Veamos las herramientas software que existen:
Herramienta de consulta y reporte
Las herramientas de consulta al igual que la mayora de herramientas
visuales, permiten apuntar y dar un click a los mens y botones para
especificar los elementos de datos, condiciones, criterios de
agrupacin y otros atributos de una solicitud de informacin. La
herramienta de consulta genera entonces un llamado a una base de
datos, extrae los datos pertinentes, efecta clculos adicionales,
manipula los datos si es necesario y presenta los resultados en un
formato claro.
Se puede almacenar las consultas y los pedidos de reporte para
trabajos subsiguientes, como est o con modificaciones. El
procesamiento estadstico se limita comnmente a promedios, sumas,
desviaciones estndar y otras funciones de anlisis bsicas. Aunque
las capacidades varan de un producto a otro, las herramientas de
consulta y reporte son ms apropiadas cuando se necesita responder
a la pregunta "Qu sucedi"?
Herramientas de base de datos multidimensionales / OLAP

Las primeras soluciones OLAP (On Line Analytical Processing),
estuvieron basadas en bases de datos multidimensionales (MDDBS).
Un cubo estructural (dos veces un hipercubo o un arreglo
multidimensional) almacenaba los datos para que se puedan
manipular intuitivamente y claramente ver las asociaciones a travs de
dimensiones mltiples Pero este enfoque tiene varias limitaciones:

Las nuevas estructuras de almacenamiento de datos requieren bases
de datos propietarias. No hay realmente estndares disponibles para
acceder a los datos multidimensionales. La segunda limitacin de un
MDDB concierne al desarrollo de una estructura de datos.
Las compaas generalmente almacenan los datos de la empresa en
bases de datos relacionales, lo que significa que alguien tiene que
extraer, transformar y cargar estos datos en el hipercubo.

Sistemas de informacin ejecutivos

Las herramientas de sistemas de informacin ejecutivos (Executive
Information Systems - EIS), proporcionan medios sumamente fciles
de usar para consulta y anlisis de la informacin confiable.
Generalmente se disean para el usuario que necesita conseguir los
datos rpidamente, pero quiere utilizar el menor tiempo posible para
comprender el uso de la herramienta. El precio de esta facilidad de
uso es que por lo general existen algunas limitaciones sobre las
capacidades analticas disponibles con el sistema de informacin
ejecutivo.

Adems, muchas de las herramientas de consulta/reporte
y OLAP/multidimensional, pueden usarse para desarrollar sistemas de
informacin ejecutivos. El concepto de sistema de informacin
ejecutivo es simple: los ejecutivos no tienen mucho tiempo, ni la
habilidad en muchos casos, para efectuar el anlisis de grandes
volmenes de datos. El EIS presenta vistas de los datos simplificados,
altamente consolidados y mayormente estticas.

Herramientas de Data Mining

Data Mining es una categora de herramientas de anlisis open-end.
En lugar de hacer preguntas, se toma estas herramientas y se
pregunta algo "interesante", una tendencia o una agrupacin peculiar,
por ejemplo. El proceso de Data Mining extrae los conocimientos
guardados o informacin predictiva desde el DataMart sin requerir
pedidos o preguntas especficas. Las herramientas Mining usan
algunas de las tcnicas de computacin ms avanzadas para generar
modelos y asociaciones como redes neuronales, deteccin de
desviacin, modelamiento predictivo y programacin gentica. Data
Mininges un dato-conducido, no una aplicacin-conducida.




II. FUENTE DE DATOS

Dentro del diseo de la arquitectura de un sistema de Datawarehouse es conveniente
tener en consideracin los diferentes entornos por los que han de pasar los datos en su
camino hacia el DW o hacia los Data Marts de destino. Dada la cantidad de
transformaciones que se han de realizar, y que normalmente el DW, adems de cumplir
su funcin de soporte a los requerimientos analticos, realiza una funcin de integracin
de datos que van a conformar el Almacn Corporativo1 y que van a tener que ser
consultados tambin de la manera tradicional por los sistemas operacionales, es muy
recomendable crear diferentes reas de datos en el camino entre los sistemas origen y las
herramientas OLAP.
Cada una de estas reas se distingue por las funciones que realizan, de qu manera se
organizan los datos en la misma, y a qu tipo de necesidad pueden dar servicio. El rea
que se encuentra al final del camino es importante, pero no va a ser la nica que
almacene los datos que van a explotar las herramientas de reporting.
Tampoco hay una convencin estndar sobre lo que abarca exactamente cada rea, y la
obligatoriedad de utilizar cada una de ellas. Cada proyecto es diferente, e influyen muchos
factores como la complejidad, el volumen de informacin del mismo, si realmente se
quiere utilizar el Data Warehouse como almacn corporativo o Sistema Maestro de Datos,
o si existen necesidades reales de soporte al reporting operacional.
En los siguientes puntos se explican las reas de datos que suelen utilizarse, y se perfila
una propuesta de arquitectura que hay que adaptar a las necesidades de cada proyecto, y
teniendo en cuenta que la utilizacin de cada rea de datos ha de estar justificada. No
siempre todas son necesarias.




2.1. STAGING AREA

Es un rea temporal donde se recogen los datos que se necesitan de los sistemas
origen.

Se recogen los datos estrictamente necesarios para las cargas, y se aplica el
mnimo de transformaciones a los mismos. No se aplican restricciones de integridad
ni se utilizan claves, los datos se tratan como si las tablas fueran ficheros planos. De
esta manera se minimiza la afectacin a los sistemas origen, la carga es lo ms
rpida posible para acotar la ventana horaria necesaria, y se reduce tambin al
mnimo la posibilidad de error.

Una vez que los datos han sido traspasados, el DW se independiza de los sistemas
origen hasta la siguiente carga. Lo nico que se suele aadir es algn campo que
almacene la fecha de la carga.

Obviamente estos datos no van a dar servicio a ninguna aplicacin de reporting, son
datos temporales que una vez hayan cumplido su funcin son eliminados, de hecho
en el esquema lgico de la arquitectura muchas veces no aparece, ya que su
funcin es meramente operativa.

Algunos autores consideran que la Staging Area abarca ms de lo comentado, o
incluso que engloba todo el entorno donde se realizan los procesos de ETL, en este
documento se considera slo como rea temporal.

2.2. OPERATIONAL DATA STORE


Como su nombre indica, esta rea es la que da soporte a los sistemas
operacionales. El modelo de datos del Almacn de Datos Operacional (ODS) sigue
una estructura relacional y normalizada, para que cualquier herramienta de reporting
o sistema operacional pueda consultar sus datos. Est dentro del Data Warehouse
porque se aprovecha el esfuerzo de integracin que supone la creacin del Almacn
de Datos Corporativo para poder atender tambin a necesidades operacionales,
pero no es obligatorio. Ni siquiera es algo especfico del BI, los ODS ya existan
antes de que surgieran los conceptos de Data Warehousing y Business Intelligence.

No almacena datos histricos, muestra la imagen del momento actual, aunque eso
no significa que no se puedan registrar los cambios. Los datos del ODS se recogen
de la Staging Area, y en este proceso s que se realizan transformaciones, limpieza
de datos y controles de integridad referencial para que los datos estn
perfectamente integrados en el modelo relacional normalizado.

Se debe tener en cuenta que la actualizacin de los datos del ODS no es
instantnea, los cambios en los datos de los sistemas origen no se ven reflejados
hasta que finaliza la carga correspondiente. Es decir, que los datos se refrescan
cada cierto tiempo, cosa que hay que explicar a los usuarios finales, porque los
informes que se lancen contra el ODS siempre devolvern informacin a fecha de la
ltima carga.
Por esta razn es recomendable definir una mayor frecuencia de carga para el ODS
que para el Almacn Corporativo. Se puede refrescar el ODS cada 15 minutos, y el
resto cada da, por ejemplo.

2.3. ALMACEN DE DATOS CORPORATIVOS

El Almacn de Datos Corporativo (DW) s que contiene datos histricos, y est
orientado a la explotacin analtica de la informacin que recoge.

Las herramientas DSS o de reporting analtico consultan tanto los Data Marts como
el Almacn de Datos Corporativo. El DW puede servir consultas en las que se
precisa mostrar a la vez informacin que se encuentre en diferentes Data Marts.

En l se almacenan datos que pueden provenir tanto de la Staging Area como del
ODS. Si ya se realizan procesos de transformacin e integracin en el ODS no se
repiten para pasar los mismos datos al Almacn Corporativo. Lo que no se pueda
recoger desde el ODS s que hay que ir a buscarlo a la Staging Area.
El esquema se parece al de un modelo relacional normalizado, pero en l ya se
aplican tcnicas de desnormalizacin. No debera contener un nmero excesivo de
tablas ni de relaciones ya que, por ejemplo, muchas relaciones jerrquicas que en
un modelo normalizado se implementaran con tablas separadas aqu ya deberan
crearse en una misma tabla, que despus representar una dimensin.

Otra particularidad es que la mayora de las tablas han de incorporar campos de
fecha para controlar la fecha de carga, la fecha en que se produce un hecho, o el
periodo de validez del registro.

Si el Data Warehouse no es demasiado grande, o el nivel de exigencia no es muy
elevado en cuanto a los requerimientos operacionales, para simplificar la estructura
se puede optar por prescindir del ODS, y si es necesario adecuar el Almacn de
Datos Corporativo para servir tanto al reporting operacional como al analtico. En
este caso, el rea resultante sera el DW Corporativo, pero en ocasiones tambin se
denomina como ODS.



2.4. DATA MART

Otra rea de datos es el lugar donde se crean los Data Marts.
stos acostumbran a obtenerse a partir de la informacin recopilada en el rea del
Almacn Corporativo, aunque tambin puede ser a la inversa. Cada Data Mart es
como un subconjunto de este almacn, pero orientado a un tema de anlisis,
normalmente asociado a un departamento de la empresa.

El Data Mart se disea con estructura multidimensional, cada objeto de anlisis es
una tabla de hechos enlazada con diversas tablas de dimensiones. Si se disea
siguiendo el Modelo en Estrella habr prcticamente una tabla para cada dimensin,
es la versin ms desnormalizada. Si se sigue un modelo de Copo de Nieve las
tablas de dimensiones estarn menos desnormalizada y para cada dimensin se
podrn utilizar varias tablas enlazadas jerrquicamente.

Esta rea puede residir en la misma base de datos que las dems si la herramienta
de explotacin es de tipo ROLAP, o tambin puede crearse ya fuera de la BD, en la
estructura de datos propia que generan las aplicaciones de tipo MOLAP, ms
conocida como los cubos multidimensionales.

Si se sigue una aproximacin Top-down para la creacin de los Data Mart, el paso
del rea de DW a esta ha de ser bastante simple, cosa que adems proporciona
una cierta independencia sobre el software que se utiliza para el reporting analtico.
Si por cualquier razn es necesario cambiar la herramienta de OLAP hay que hacer
poco ms que redefinir los metadatos y regenerar los cubos, y si el cambio es entre
dos de tipo ROLAP ni siquiera esto ltimo sera necesario. En cualquier caso, las
reas anteriores no tienen porqu ser modificadas.

III. GESTIONANDO DATA MARTS

En pocas palabras, los pasos ms importantes en la implementacin de un
mercado de datos se van a disear el esquema, construir el almacenamiento
fsico, rellenar el mercado de datos con los datos de los sistemas de cdigo,
acceder a ella para tomar decisiones informadas, y administrar el tiempo.

Esta seccin contiene los siguientes temas:
Disear
Construir
Rellenar
Accesar
Gestionar
3.1. Diseo
La etapa de diseo es el primero en el proceso de data mart. Esta etapa
cubre todas las tareas de inicio de la solicitud para un puesto de datos a
travs de la recopilacin de informacin acerca de los requisitos, y el
desarrollo del diseo lgico y fsico de l data Mart. La etapa de diseo incluye
las siguientes tareas:
Reunir los requisitos tcnicos y de negocio
La identificacin de las fuentes de datos
Seleccin del subconjunto apropiado de los datos
El diseo de la estructura lgica y fsica de la despensa de datos
3.2. Construccin
Este paso incluye la creacin de la base de datos fsica y las estructuras
lgicas relacionadas con el mercado de datos para proporcionar un acceso
rpido y eficiente a los datos. Este paso consiste en las siguientes tareas:
La creacin de las bases de datos y almacenamiento de las
estructuras fsicas, tales como espacios de tabla, asociados con el
mercado de datos
Creacin de los objetos de esquema, como tablas e ndices definidos
en la etapa de diseo
La determinacin de la mejor manera de configurar las tablas y las
estructuras de acceso
3.3. Poblar
El paso de poblar cubre todas las tareas relacionadas con la obtencin de los
datos de la fuente, la limpieza para arriba, modificndolo para el formato y el
nivel de detalle adecuado, y que se incorpore al mercado de datos. Dicho
ms formalmente, el paso de poblar implica las siguientes tareas:
Fuentes de datos de mapeo para orientar las estructuras de datos
La extraccin de los datos
La limpieza y la transformacin de los datos
Carga de datos en el mercado de datos
Creacin y almacenamiento de metadatos
3.4. Acceso
El paso de acceder consiste en poner los datos a utilizar: la consulta de los
datos, su anlisis, la creacin de informes, tablas y grficos, y la publicacin
de los mismos. Por lo general, el usuario final utiliza una herramienta de
interfaz grfica para enviar consultas a la base de datos y mostrar los
resultados de las consultas. El paso de acceder requiere que se realicen las
siguientes tareas:
Configurar una capa intermedia para la herramienta de front-end
para su uso. Esta capa, la metalayer, traduce las estructuras de
bases de datos y los nombres de los objetos en trminos de negocio,
de modo que el usuario final puede interactuar con el mercado de
datos utilizando trminos que se relacionan con la funcin
empresarial.
Mantener y gestionar estas interfaces de negocio.
Configurar y administrar las estructuras de bases de datos, como las
tablas de resumen, que las consultas de ayuda presentadas a travs
de la herramienta de front-end ejecutar rpida y eficientemente.
3.5. Gestionar
Este paso implica la gestin del mercado de datos durante su vida til. En
este paso, a realizar tareas de gestin, tales como los siguientes:
Proporcionar un acceso seguro a los datos
Administrar el crecimiento de los datos
Optimizar el sistema para un mejor rendimiento
Asegurar la disponibilidad de los datos, incluso con los fallos del
sistema