Las bases de datos juegan un papel importante en el mundo de los negocios, a través de ellas las empresas obtienen información que les permite tomar decisiones sobre el lanzamiento, distribución y elaboración de su producto o servicio
2.1 Base de Datos Multidimensionales
Una base de datos multidimensional (MDB) es un tipo de base de datos que se ha optimizado para data warehouse y aplicaciones de procesamiento analítico en línea (OLAP). Las bases de datos multidimensionales se crean con frecuencia usando entradas de las bases de datos relacionales existentes. Mientras que a una base de datos relacional se accede normalmente mediante una consulta de Lenguaje de Consulta Estructurado (SQL).
Una base de datos multidimensional –o un sistema de gestión de base de datos multidimensional (MDDBMS)– implica la capacidad de procesar rápidamente los datos en la base de datos a fin de que las respuestas se pueden generar rápidamente. Varios proveedores ofrecen productos que utilizan bases de datos multidimensionales. Los enfoques de cómo se almacenan los datos y la interfaz de usuario pueden variar.
Conceptualmente, una base de datos multidimensional utiliza la idea de un cubo de datos para representar las dimensiones de los datos disponibles para un usuario.
2.1.1. Data WareHouse
Data warehouse o bodega de datos es una colección de información coorporativa derivada directamente de los sistemas operacionales (DB) y de algunos datos externos.
Su propósito es soportar la toma de decisiones en un negocio (no las operaciones del negocio).
Características de un DW:
● Orientado a un tema
● Integración
● Variante en el tiempo
● No volátil
DW Orientado a un tema
● Organizado en torno a grandes temas, como: clientes, productos, ventas (Otros ejemplos...)
● Centrándose en el modelado y análisis de los datos para los tomadores de decisiones, no en las operaciones diarias o procesamiento de transacciones.
● Provee una visión simple y concisa sobre cuestiones temáticas particulares por exclusión de los datos que no son útiles en el proceso de apoyo a las decisiones.
2.1.2. Data Mart
Un Data Mart es una forma sencilla de un Data Warehouse (almacén de datos) que se centra en un único tema o área funcional, como Ventas o Finanzas o Marketing. Por esto, se conoce a menudo como base de datos departamental.
Los data marts aceleran los procesos comerciales al dar acceso a la información en un almacén de datos o un data store operativo en cuestión de días, y no meses o periodos más largos. Como un data mart tan solo contiene los datos aplicables a un ámbito comercial concreto, resulta una forma rentable de obtener información explotable rápidamente.
Un data mart puede crearse desde un almacén de datos existente (enfoque de arriba abajo) o desde otras fuentes, como sistemas operativos internos o datos externos. Es parecido a un almacén de datos; se trata de una base de datos relacional que almacena datos transaccionales (valor temporal, orden numérico, referencia a uno o más objetos) en columnas y filas, simplificando su organización y acceso.
3 tipos de data marts
Existen tres tipos de data marts: dependientes, independientes e híbridos. Se clasifican según su relación con el almacén de datos y las fuentes de datos que se utilizan para crear el sistema.
1.- Data marts dependientes
Un data mart dependiente se crea a partir de un almacén de datos empresariales existente. Es el enfoque de arriba abajo que empieza almacenando todos los datos comerciales en una única ubicación y luego se extrae una porción claramente definida de los datos cuando se necesita analizarlos.
Para formar un almacén de datos, se agrega un conjunto de datos concreto (en forma de agrupamiento) a partir del almacén, se reestructuran y luego se cargan al data mart, donde pueden realizarse consultas. Pueden ser una visión lógica o un subconjunto físico del almacén de datos:
Visión lógica: una tabla/vista virtual separada lógicamente —aunque no físicamente— del almacén de datos
Subconjunto físico: extracción de datos que constituye una base de datos separada físicamente del almacén de datos
Los datos granulares (el nivel inferior de datos del conjunto diana) del almacén de datos sirven como única referencia para todos los data marts dependientes que se creen.
2.-Data marts independientes
Un data mart independiente es un sistema autónomo (creado sin utilizar ningún almacén) que se centra en una única disciplina o área del negocio. Los datos se extraen de fuentes internas o externas (o de ambas), se procesan y luego se cargan al repositorio del data mart, donde se almacenan hasta que son necesarios para análisis comerciales.
Los data marts independientes no son difíciles de diseñar y desarrollar. Son ventajosos para lograr objetivos a corto plazo, pero pueden resultar farragosos de gestionar (cada cual con su propia herramienta de ETL y lógica) a medida que las necesidades de la empresa crecen y se complican.
3. Data marts híbridos
Un data mart híbrido combina datos de un almacén de datos existente con otros sistemas de fuentes operativas. Aúna la velocidad y el énfasis en el usuario final de un enfoque de arriba a abajo con las ventajas de la integración corporativa del método de abajo a arriba.
2.1.3. Sistemas OLTP
La administración de datos transaccionales mediante sistemas de equipos se conoce como procesamiento de transacciones en línea (OLTP). Los sistemas de OLTP registran interacciones empresariales a medida que se producen en el funcionamiento diario de la organización y admiten consultas de estos datos para realizar inferencias.
Datos transaccionales
Los datos transaccionales son información que realiza un seguimiento de las interacciones relacionadas con las actividades de una organización. Estas interacciones normalmente son transacciones comerciales, tales como pagos recibidos de los clientes, pagos realizados a los proveedores, movimiento de productos en el inventario, pedidos obtenidos o servicios entregados. Los eventos transaccionales, que representan a las transacciones, normalmente contienen una dimensión de tiempo, algunos valores numéricos y referencias a otros datos.
Normalmente, las transacciones deben ser atómicas y coherentes. Atomicidad significa que una transacción completa siempre se realiza, correctamente o con error, como una unidad de trabajo y nunca se deja en un estado medio completado. Si no se puede completar una transacción, el sistema de base de datos debe revertir todos los pasos que se han hecho como parte de esa transacción. En los RDBMS tradicionales, esta reversión sucede automáticamente si no se puede finalizar una transacción. Coherencia significa que las transacciones dejan siempre los datos en un estado válido. (Estas son descripciones muy informales de atomicidad y coherencia. Hay definiciones más formales de estas propiedades, como ACID).
Las bases de datos transaccionales posibilitan una coherencia alta de las transacciones mediante el uso de diversas estrategias de bloqueo, como el bloqueo pesimista, para asegurarse de que todos los datos son altamente coherentes dentro del contexto de la empresa, para todos los usuarios y procesos.
La arquitectura de implementación más común que utiliza datos transaccionales es el nivel de almacén de datos en una arquitectura de 3 niveles. Una arquitectura de 3 niveles normalmente consta de un nivel de presentación, un nivel de lógica de negocios y un nivel de almacén de datos. Una arquitectura de implementación relacionada es la arquitectura de n niveles, que puede tener varios niveles intermedios para el control de la lógica de negocios.
Desafíos
La implementación y el uso de un sistema de OLTP pueden crear algunos problemas:
Los sistemas de OLTP no siempre son buenos para controlar agregados en grandes cantidades de datos, aunque hay excepciones, como una solución basada en SQL Server bien planeada. Los análisis de los datos, que se basan en cálculos agregados de millones de transacciones individuales, hacen un uso muy intensivo de los recursos en un sistema de OLTP. Pueden tardar en ejecutarse y puede provocar una ralentización porque bloqueen otras transacciones de la base de datos.
Si se realizan informes y análisis de los datos que estén muy normalizados, las consultas tienden a ser complejas, ya que la mayor parte de ellas tienen que anular la normalización de los datos mediante réplicas. Además, las convenciones de nomenclatura de los objetos de base de datos en los sistemas de OLTP tienden a ser breves y concisas. El aumento de la normalización, junto con unas convenciones de nomenclatura breves, hacen que sea difícil para los usuarios empresariales realizar consultas en los sistemas de OLTP sin la ayuda de un DBA o desarrollador de datos.
El almacenamiento del historial de transacciones de forma indefinida y el almacenamiento de demasiados datos en cualquier tabla puede provocar una ralentización del rendimiento de las consultas, en función del número de transacciones almacenadas. La solución habitual consiste en mantener una ventana de tiempo relevante (por ejemplo, el año fiscal actual) en el sistema de OLTP y descargar los datos históricos a otros sistemas, como un data mart o un almacenamiento de datos.
2.1.4. Sistemas OLAP
OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o cubos OLAP) que contienen datos resumidos de grandes bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.
Los sistemas, también llamados Cubos OLAP por su característica multidimensional permiten analizar bases de datos relacionales con mucho volumen y variedad. Esto reduce notablemente el tiempo y los recursos empleados en el análisis. Estos análisis derivan en informes que permiten mejorar la toma de decisiones y las operaciones productivas.
La rapidez de los cubos OLAP radica en que son vectores donde la información está jerárquicamente organizada. Puede contener por tanto múltiples dimensiones, así como varios vectores, lo cual extiende la capacidad del cubo OLAP. Por ejemplo, dentro de un período de tiempo podrían existir varias dimensiones. “Año 2015”, “Segundo semestre de 2015” y “septiembre 2015” serían tres dimensiones distintas. Otras dimensiones podrían referirse a lugares, productos por categorías, stocks, gastos e ingresos, etc. Las posibilidades son casi infinitas.
El gran debe de los sistemas OLAP es que no se pueden realizar cambios en su estructura. Por la manera que almacenan y gestionan la información, para modificar algo de su estructura es necesario rediseñar el cubo OLAP por completo.
Creados a partir de las tablas de las bases de datos relacionales, los cubos OLAP suelen trabajar la información en varios pasos como pueden ser segmentar la información, filtrarla, profundizar y sintetizarla. Todo ello a una gran velocidad y permitiendo al usuario conseguir los datos analizados en un tiempo récord.
2.1.5. Operaciones Analíticas Básicas de los Sistemas OLAP
Consolidación: Comprende el conjunto de datos. Esto puede involucrar acumulaciones simples o agrupaciones complejas que incluyen datos interrelacionados.
Drill-Down: OLAP puede moverse en la dirección contraria y presentar automáticamente datos detallados que abarcan datos consolidados.
Slicing and Dicing: Se refiere a la capacidad de visualizar a la Base de Datos desde diferentes puntos de vista.
2.1.6. Vista de Datos de los sistemas OLAP
Vista de Datos: como cubos es una extensión de la manera normal en que los usuarios de negocios interactúan con los datos. Por ejemplo la mayoría de los usuarios desearía como se desarrollan las ventas a lo largo del tiempo. Para ello se necesitaría ver varias planillas de calculo.
2.1.7. Modelo de Datos de los sistemas OLAP.
Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la información se almacena multidimensionalmente, para ser visualizada en varias dimensiones de análisis.
El sistema MOLAP utiliza una arquitectura de dos niveles: la bases de datos multidimensionales y el motor analítico. La base de datos multidimensional es la encargada del manejo, acceso y obtención del dato.
El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El nivel de presentación se integra con el de aplicación y proporciona un interfaz a través del cual los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a varios usuarios acceder a la misma base de datos multidimensional.
La información procedente de los sistemas operacionales, se carga en el sistema MOLAP, mediante una serie de rutinas por lotes. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos por lotes, para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas. Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través de la interfase, y la lógica de aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.
Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un datawarehouse para proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica. El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato. El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.
El motor ROLAP se integra con niveles de presentación, a través de los cuáles los usuarios realizan los análisis OLAP. Después de que el modelo de datos para el datawarehouse se ha definido, los datos se cargan desde el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así es requerido por el modelos de datos. Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del datawarehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.
Sistemas HOLAP
Un desarrollo un poco más reciente ha sido la solución OLAP híbrida (HOLAP), la cual combina las arquitecturas ROLAP y MOLAP para brindar una solución con las mejores características de ambas: desempeño superior y gran escalabilidad. Un tipo de HOLAP mantiene los registros de detalle (los volúmenes más grandes) en la base de datos relacional, mientras que mantiene las agregaciones en un almacén MOLAP separado.
2.2. Sistemas de Gestión del conocimiento.
Knowledge Management System (Sistema de gestión del conocimiento) se refiere a los sistemas informáticos para gestionar el conocimiento en las organizaciones, que soportan la creación, captura, almacenamiento y distribución de la información. Estos sistemas son una parte mas de la estrategia de Gestión del Conocimiento dentro de las organizaciones.
La idea de un sistema KM es permitir a los empleados tener un acceso completo a la documentación de la organización, origenes de información y soluciones. El tipico ejemplo es la empresa donde un ingeniero conoce la composiciones de metales que podria reducir el nivel del ruidos en motores. Compartiendo esta información, se podria ayudar a diseñar motores mas efectivos o podria ayudar y dar ideas a otros componenes de la organización a diseñar mejores equipamientos o a mejorar los productos. Otro ejemplo podría ser el departamento comercial que necesita información sobre los clientes y puede consultar la información recopilada por otros compañeros al respecto. O el departamento de sistemas que tienes todos sus manuales de administración y documentación informatizados y es facil buscar soluciones a problemas presentados anteriormente en dicha información.
2.2.1. Preparación de los Datos.
El segundo paso del proceso de minería de datos, como se indica en el siguiente diagrama, consiste en consolidar y limpiar los datos identificados en el paso Definir el Problema
Los datos pueden estar dispersos en la organización y almacenados en distintos formatos. IBM DB2 Intelligent Miner for Data puede utilizar como datos de entrada archivos planos, donde estos también pueden contener incoherencias como datos faltantes “missings” , fuera de rango “outliers” o simplemente contener errores.
Por ejemplo: los datos pueden mostrar que un cliente adquirió un producto incluso antes de haber nacido o que el cliente compra regularmente en una tienda situada a 3.000 kilómetros de su casa. Antes de empezar a generar modelos, se debe solucionar estos problemas. Normalmente se trabaja con un conjunto de datos muy grande y no se puede comprobar cada transacción. Es por ello que este paso es de suma importancia ya que es aquí donde se tendrá que realizar las correspondientes y verificaciones para obtener resultados fehacientes.
Calidad en los Datos
El éxito de las actividades de Data Mining se relaciona directamente con la calidad de los datos.
Muchas veces resulta necesario pre-procesar los datos antes de derivarlos al modelo de análisis. El pre-procesamiento puede incluir transformaciones, reducciones o combinaciones de los datos.
La semántica de los datos debe ayudar para la selección de una conveniente representación y las bondades de la representación elegida gravitan directamente sobre la calidad del modelo y de los resultados posteriores.
Problemas con los Datos
En la fase de Preparación de Datos, pueden suceder una diversidad de casos:
• Demasiados datos:
— Datos corruptos o con ruido.
— Datos redundantes (requieren factorización).
— Datos irrelevantes.
— Excesiva cantidad de datos (muestreo).
• Pocos datos:
— Atributos perdidos (missings).
— Valores perdidos.
• Poca cantidad de datos
— Datos fracturados.
— Datos incompatibles.
— Múltiples fuentes de datos.
2.2.2. Minería de Datos.
El datamining (minería de datos), es el conjunto de técnicas y tecnologías que permiten explorar grandes bases de datos, de manera automática o semiautomática, con el objetivo de encontrar patrones repetitivos, tendencias o reglas que expliquen el comportamiento de los datos en un determinado contexto.
Básicamente, el datamining surge para intentar ayudar a comprender el contenido de un repositorio de datos. Con este fin, hace uso de prácticas estadísticas y, en algunos casos, de algoritmos de búsqueda próximos a la Inteligencia Artificial y a las redes neuronales.
De forma general, los datos son la materia prima bruta. En el momento que el usuario les atribuye algún significado especial pasan a convertirse en información. Cuando los especialistas elaboran o encuentran un modelo, haciendo que la interpretación que surge entre la información y ese modelo represente un valor agregado, entonces nos referimos al conocimiento. Vea más diferencias entre datos, información y conocimiento
Aunque en datamining cada caso concreto puede ser radicalmente distinto al anterior, el proceso común a todos ellos se suele componer de cuatro etapas principales:
* Determinación de los objetivos. Trata de la delimitación de los objetivos que el cliente desea bajo la orientación del especialista en data mining.
* Preprocesamiento de los datos. Se refiere a la selección, la limpieza, el enriquecimiento, la reducción y la transformación de las bases de datos. Esta etapa consume generalmente alrededor del setenta por ciento del tiempo total de un proyecto de data mining.
* Determinación del modelo. Se comienza realizando unos análisis estadísticos de los datos, y después se lleva a cabo una visualización gráfica de los mismos para tener una primera aproximación. Según los objetivos planteados y la tarea que debe llevarse a cabo, pueden utilizarse algoritmos desarrollados en diferentes áreas de la Inteligencia Artificial.
* Análisis de los resultados. Verifica si los resultados obtenidos son coherentes y los coteja con los obtenidos por los análisis estadísticos y de visualización gráfica. El cliente determina si son novedosos y si le aportan un nuevo conocimiento que le permita considerar sus decisiones.
2.2.3. Patrones.
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias
