REALIZACIOM DE ETL COMPLETO BI

http://www.alankoo.com/2009/06/implementando-dimensiones-scd2-con-sql.html

http://sqlconqueror.com/2014/02/13/resumen-de-evento-construyendo-hechos-y-dimensiones-lentamente-cambiantes-para-tu-dw/

http://blogs.solidq.com/es/business-analytics/cargar-slowly-changing-dimensions-sin-castigar-a-nuestro-dwh-relacional/

http://rimenri.blogspot.com/2008/04/data-warehouse-medidas-y-dimensiones.html

http://vidooly.com/video/TRMlJWRoOAE

http://portalsql.com/index.php/category/tutoriales/sql-server-integration-services/

https://www.youtube.com/watch?v=5sCps3iIL_E

https://www.youtube.com/watch?v=Ye4xIeii3hI

https://www.youtube.com/watch?v=cFph1Gf-kv8

Lección 1: Introducción a la estrella y del copo de nieve esquemas

Antes de diseñar un almacén de datos, es necesario comprender algunos patrones de diseño comunes que se utilizan para un DW, es decir, los esquemas de estrella y copo de nieve. Estos esquemas se desarrollaron en la década de 1980. En particular, el esquema de la estrella está tan ampliamente utilizado que se ha convertido en una especie de norma informal para todo tipo de business intelligence (BI) aplicaciones.

informar problemas con un esquema normalizado

Esta lección comienza con esquema relacional normalizado. Vamos a suponer que usted tiene que crear un informe de negocio de un esquema relacional en la base de datos de la muestra AdventureWorks2012. El informe debe incluir la cantidad de ventas para las ventas por Internet en diferentes países durante varios años. La tarea (o incluso desafío) es para averiguar qué tablas y columnas que usted necesitaría para crear el informe. Se empieza por investigar qué tablas almacenar los datos que necesita, como se muestra en la Figura 1-1, que fue creado con la utilidad de diagramas en SQL Server Management Studio

Incluso para este relativamente simple informe, que acabaría con 10 Tablas. Usted necesita las tablas de ventas y las tablas que contienen información sobre los clientes. El esquema de base de AdventureWorks2012 es altamente normalizada; está pensado como un ejemplo de esquema para soportar aplicaciones de línea de negocio. Aunque tal esquema funciona muy bien para las aplicaciones de línea de negocio, que puede causar problemas cuando se utiliza como la fuente para los informes, como se verá en el resto de esta sección. La normalización es un proceso en el que se definen las entidades de tal manera que una sola tabla representa exactamente una entidad. El objetivo es tener un esquema completo y no redundante. Cada pieza de información debe ser almacenada exactamente una vez. De esta manera, usted puede hacer cumplir la integridad de datos. Usted tiene un lugar para cada pieza de datos, y porque cada elemento de datos se almacena sólo una vez, usted no tiene problemas de consistencia. Sin embargo, después de una normalización adecuada, por lo general terminan con muchas mesas. En una base de datos que soporta una aplicación de LOB para una empresa, es posible terminar con miles de tablas!

Encontrar las tablas y columnas adecuadas que necesita para un informe puede ser doloroso en una base de datos normalizado, simplemente por el número de tablas involucradas. Añadir a esto el hecho de que los desarrolladores de bases de datos fuerzas nada para mantener buenas convenciones de nombres en una base de datos LOB. Es relativamente fácil encontrar las tablas

pertinentes en AdventureWorks2012, porque las tablas y columnas tienen nombres significativos. Pero imagínese si la base de datos contenía tablas denominadas Table1 Table2, y así sucesivamente, y columnas nombradas Columna1, Columna2, y así sucesivamente. Encontrar los objetos que necesita para su informe sería una pesadilla. Las herramientas como SQL pueden ayudar. Por ejemplo, podría crear un entorno de prueba, trate de insertar algunos datos a través de una aplicación LOB, y tienen SQL identificar donde se insertó los datos. Un esquema normalizado no es muy narrativa. No se puede detectar fácilmente la ubicación de almacenamiento para los datos que mide algo, como la cantidad de ventas en este ejemplo, o los datos que da contexto a estas medidas, como los países y años. Además, una consulta que une a 10 mesas, como sería necesario en la presentación de informes de ventas por países y años, no sería muy rápido. La consulta también leer grandes cantidades de Data- ventas durante varios años-y por lo tanto podría interferir con el trabajo transaccional regular de inserción y actualización de los datos. Otro problema en este ejemplo es el hecho de que no hay ninguna tabla de búsqueda explícita para las fechas. Hay que extraer años desde la fecha o columnas de fecha / hora en las tablas de ventas, tales como OrderDate de la tabla SalesOrderHeader en este ejemplo. La extracción de años a partir de una columna de fecha no es tan importante; sin embargo, la primera pregunta es, ¿tiene los datos del almacén de la base de datos de línea de negocio para varios años? En muchos casos, las bases de datos LOB se purgan después de cada nuevo año comienza fiscal. Incluso si usted tiene todos los datos históricos para las operaciones de venta, es posible que tenga un problema que muestra los datos históricos correctamente. Por ejemplo, usted podría tener sólo la última dirección del cliente (de la que se extrae de país actual del cliente), lo que podría impedir que el cálculo de las ventas históricas por país correctamente. Las muestras AdventureWorks2012 base de datos almacena todos los datos en una sola base de datos. Sin embargo, en una empresa, es posible que tenga múltiples aplicaciones de línea de negocio, cada una de las cuales podría almacenar datos en su propia base de datos. Usted también podría tener parte de los datos de ventas en una base de datos y parte en otro. Y usted podría tener datos de los clientes en ambas bases de datos, y sin una identificación común. En tales casos, se enfrenta a los problemas de cómo combinar todos estos datos y cómo identificar qué cliente de una base de datos es en realidad lo mismo que un cliente de otra base de datos. Por último, la calidad de los datos podría ser baja. La vieja regla, "la basura en basura", se aplica a los análisis también. Partes de los datos podrían ser desaparecidos; otras partes podrían estar equivocados. Incluso con buenos datos, usted todavía puede tener diferentes representaciones de los mismos datos en diferentes bases de datos. Por ejemplo, el género en una base de datos podría ser representado por las letras F y H, y en otra base de datos con los números 1 y 2. Los problemas mencionados en esta sección son indicativos de los problemas que llevaron a los diseñadores a crear diferentes esquemas para aplicaciones de BI. Los esquemas de estrella y copo de nieve son tanto simplificada y narrativa. Un almacén de datos debe utilizar diseños de estrellas y / o copo de nieve. También tendrá a veces encontrar el modelo dimensional término usado para un esquema de DW. Un modelo tridimensional consta en realidad de dos esquemas de estrella y copo de nieve. Este es un buen momento para introducir los esquemas de estrella y copo de nieve.

estrella de esquema

A menudo, una imagen vale más que mil palabras. La Figura 1-2 muestra un esquema de la estrella, un diagrama creado en SSMS de un subconjunto de las tablas de la base de datos ejemplo

AdventureWorksDW2012. En la Figura 1-2, se puede ver fácilmente cómo el esquema de la estrella debe su nombre se asemeja a una estrella. Hay una sola mesa central, llamada tabla de hechos, rodeado de varias tablas denominadas dimensiones. Un esquema de la estrella cubre un área de negocio. En este caso, el esquema cubre ventas por Internet. Un almacén de datos de la empresa abarca múltiples áreas de negocio y se compone de múltiples esquemas de la estrella (y / o del copo de nieve).

La tabla de hechos se conecta a todas las dimensiones con las claves externas. Por lo general, todas las claves externas en conjunto identifican de forma exclusiva cada fila de la tabla de hechos, y por lo tanto forman colectivamente una clave única, para que pueda utilizar todas las claves externas como una clave principal compuesta de la tabla de hechos. También puede agregar una clave simple. La tabla de hechos está en el lado "varios" de sus relaciones con las dimensiones. Si se va a formar una proposición de una fila en una tabla de hechos, es posible expresar con una frase como: "Un cliente compró el producto B con fecha C en cantidad D para la cantidad E." Esta propuesta es un hecho; es así como la tabla de hechos obtuvo su nombre.

El esquema de la estrella evolucionado a partir de un modelo conceptual de un cubo. Usted puede imaginar todas las ventas como una gran caja. Cuando busca un problema en los datos de ventas, se utiliza una técnica de divide y vencerás: cortar el cubo sobre diferentes categorías de clientes, productos, o el tiempo. En otras palabras, que se mire el cubo sobre sus dimensiones. Por lo tanto, los clientes, los productos, y el tiempo representan las tres dimensiones en el modelo conceptual del cubo de ventas. Las tablas de dimensiones (dimensiones) obtuvieron su nombre de este modelo conceptual. En un modelo lógico de un esquema en estrella, puede representar a más de tres dimensiones. Por lo tanto, un esquema de la estrella representa un hipercubo multidimensional. Como usted ya sabe, un almacén de datos se compone de varios esquemas de estrellas. Desde una perspectiva empresarial, estos esquemas de estrella están conectados. Por ejemplo, usted tiene los mismos clientes en ventas como en la contabilidad. Usted trata con muchos de los mismos productos en ventas, inventario, y la producción. Por supuesto, su negocio se lleva a cabo al mismo tiempo sobre las diferentes áreas de negocio. Para representar el negocio

correctamente, debe ser capaz de conectar los varios esquemas de estrellas en su almacén de datos. La conexión es simple - usted utiliza las mismas dimensiones para cada esquema de estrella. De hecho, las dimensiones deben ser compartidos entre varios esquemas de estrellas. Dimensiones tienen relaciones de clave externa con varias tablas de hechos. Dimensiones con conexiones a varias tablas de hechos se llaman compartidos o dimensiones conformadas. Figura 1-3 muestra una dimensión conformada de la base de datos ejemplo AdventureWorksDW2012 con dos tablas de hechos diferentes que comparten la misma dimensión.

Copo de nieve de esquema

Figura 1-4 muestra una vista más detallada de la dimensión DimDate de la base de datos ejemplo AdventureWorksDW2012. Los atributos resaltados muestran que la dimensión se desnormalizará. No está en tercera forma normal. En la tercera forma normal, todas las columnas que no son clave deben depender nontransitively en la tecla. Una forma diferente de decir esto es que no debe haber ninguna dependencia funcional entre columnas sin clave. Usted debe ser capaz de recuperar el valor de una columna no clave sólo si conoce la clave. Sin embargo, en la dimensión

DimDate, si se conoce el mes, es obvio que conoce el trimestre natural, y si se conoce el trimestre natural, ya sabes el semestre calendario. En un esquema de la estrella, dimensiones se desnormalizar. Por el contrario, en un esquema normalizado LOB, usted dividir la tabla en varias tablas si usted encuentra una dependencia entre columnas sin clave. La Figura 1-5 muestra un ejemplo tan normalizado para las mesas DimProduct, DimProductSubcategory y DimProductCategory de la base de datos AdventureWorksDW2012.

La dimensión DimProduct no se desnormalizará. La tabla DimProduct no contiene el nombre de la subcategoría, sólo el valor ProductSubcategoryKey para la clave externa para la tabla de búsqueda DimProductSubcategory. Del mismo modo, la tabla DimProductSubcategory no contiene un nombre de categoría; sólo tiene el ProductCategoryKey clave externa de la tabla DimProductCategory. Este diseño es típico de un esquema de base de datos LOB. Se pueden imaginar múltiples dimensiones diseñados de una manera normalizada similar, con una tabla de hechos central conectado por claves foráneas para dimensionar las tablas, que están conectados con claves

externas para buscar tablas, que están conectados con claves externas a las tablas de búsqueda de segundo nivel.

Granularidad Nivel

él número de dimensiones relacionadas con una tabla de hechos define el nivel de granularidad de análisis que puede obtener. Por ejemplo, si no hay dimensión productos está conectado a una tabla de hechos de ventas, no se puede obtener un informe en el producto de nivel-usted puede obtener un informe de ventas de todos los productos únicos. Este tipo de granularidad es también llamada la dimensionalidad de un esquema de la estrella. Pero hay otro tipo de granularidad, lo que le permite saber qué nivel de información de una clave externa dimensión representa en una tabla de hechos. Diferentes tablas de hechos pueden tener diferente granularidad en una conexión a la misma dimensión. Esto es muy típico en la presupuestación y planificación de escenarios. Por ejemplo, usted no piensa que el cliente A vendrá con fecha B para almacenar C y comprar el producto D para la cantidad E. En cambio, piensa en un nivel más alto es posible que el plan para vender la cantidad de productos E C en cuarto B en todo tiendas en esa región a todos los clientes en esa región. Figura 1-7 muestra un ejemplo de una tabla de hechos que utiliza un mayor nivel de granularidad que las tablas de hechos introducidos hasta el momento. En la base de datos AdventureWorksDW2012, la tabla FactSalesQuota es la tabla de hechos con los datos de planificación. Sin embargo, los planes se hacen para los empleados sólo en el nivel por trimestre. El plan es que todos los clientes, todos los productos, y así sucesivamente, porque este esquema en estrella utiliza sólo las dimensiones DimDate y DimEmployee. Además, la planificación se produce a nivel trimestral. Al investigar el contenido, se podía ver que todos los planes para una cuarta parte están obligados a el primer día del cuarto. Usted no necesita utilizar el DateKey; usted podría tener sólo columnas CalendarYear y CalendarQuarter en la tabla de hechos FactSalesQuota. Aún se podía realizar une a DimDate usando estas dos columnas que están presentes en la tabla DimDate también. Sin embargo, si usted quiere tener una clave externa a la dimensión DimDate, usted necesita el DateKey. Una clave externa debe referirse a valores únicos en el lado "uno" de la relación. La combinación de CalendarYear y CalendarQuarter es, por supuesto, no es único en la dimensión DimDate; se repite aproximadamente 90 veces en cada trimestre.

auditoría y Lineage

Además de tablas para los informes, un almacén de datos también puede incluir tablas de auditoría. Para cada actualización, debe auditar que hizo la actualización, cuando se hizo, y cuántas filas fueron transferidos a cada tabla de dimensiones y de hecho en su DW. Si también auditar la cantidad de tiempo que se necesitaba para cada carga, se puede calcular el rendimiento y tomar medidas si se deteriora. Puede almacenar esta información en una tabla de auditoría o tablas. Sin embargo, usted debe darse cuenta de que la auditoría no le ayuda a no ser que se analiza la información con regularidad. Tablas de auditoría contienen información a nivel de lote acerca de las cargas regulares DW, pero es posible que también desee o la necesidad de contar con información más detallada. Por ejemplo, es posible que desee saber donde cada fila de una tabla de dimensiones y / o hecho de vino y cuando se añadió. En tales casos, debe agregar columnas correspondientes a las tablas de dimensiones y de hechos. Tal información detallada auditoría también se llama linaje en la terminología DW. Para recoger cualquiera auditoría o información de linaje, es necesario modificar el proceso de extracción, transformación y carga (ETL) se utiliza para cargas DW adecuadamente. Si su herramienta ETL es Integration Services de SQL Server (SSIS), entonces debe usar el registro de SSIS. SSIS tiene un amplio soporte de registro. Además, SSIS también tiene soporte para información de linaje

https://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos