Cmo Construir Un Data Mart Usando Microsoft BI Stack Parte 1 - Introduccin Y Anlisis OLTP DatabaseEn primer lugar, como una pequea introduccin, me gustara darle la mano a mano que si usted est interesado en comprender todo el SDLC de desarrollo mercado de datos, este post es slo un preludio de toda la serie de publicaciones que se ocupan de la tarea de creacin de un proyecto de BI completa utilizando la tecnologa Microsoft, a partir de la realizacin de un poco recognisances de datos, a travs de la creacin de rutinas ETL y la lgica de cdigo SQL, cubos, informes y, finalmente, la implementacin y solucin de puesta a punto.As que si usted est interesado en seguir adelante a travs de los prximos posts, usted debera ser capaz de tener una buena comprensin de la forma de llevar un proyecto similar de principio a fin utilizando enfoque similar (enlaces a puestos restantes de esta serie se aadirn a la parte inferior de esta pgina, ya que se acumulan si desea ir por delante).Adems, voy a estar poniendo todos los archivos correspondientes a cada puesto de esta serie en mi carpeta pblica SkyDrive (aqu est elENLACE) si desea descargar los recursos, ejemplos de cdigo, archivos de solucin, etcLa razn por la que decid venir para arriba con una serie de mensajes que describen cmo construir un mercado de datos desde cero es porque, aunque hay un gran nmero de materiales y publicaciones relacionadas con las metodologas, enfoques y direccin general y el know-how en el desarrollo de un robusto mercado de datos, siempre he sentido que no es lo suficientemente prctico, pragmtico, la informacin de las tuercas y de pernos sobre el tema.S, hay un montn de artculos y libros sobre reinos individuales de BI que le ensear cmo convertirse en desarrollador ELT competente o un experto programador MDX, pero casi ninguno de ellos toman el enfoque prctico y aplicarlo desde el principio hasta su fin.Dicho esto, por favor, tambin tenga en cuenta que los proyectos de desarrollo mart mayora de los datos o de almacenamiento de datos son bastante complejos y hacer frente a una gran cantidad de complejidades especficas de negocio, por lo tanto es imposible para una entrada de blog corto para cubrir esos.Por lo tanto, lo que se ver en los prximos posts se refiere a los principios ms bsicos y rudimentarios y enfoques para la creacin de un mercado de datos tpico.Esto, sin embargo, debera ser suficiente para dar a nadie una visin digna del proceso que luego se pueden aplicar a otros proyectos, sin enturbiar el agua en exceso.Anlisis de bases de datos OLTPVamos a contemplar que todo el trabajo antesala que precede a los aspectos tcnicos est detrs de nosotros.El estudio de viabilidad se ha llevado a cabo, los usuarios finales entrevistados, proyecto firmado etc y nosotros, como desarrolladores, finalmente tener la oportunidad de tener en nuestras manos sucias y mirar los datos.Sin ms prembulos, vamos a explorar el primer aspecto del desarrollo del mercado de datos - los datos transaccionales.Algunos podran argumentar que se puede construir un mercado de datos en los datos procedentes de fuentes distintas de la base de datos OLTP y que este paso no debe ser el nmero uno en su orden del da, es decir, debe estar entrevistando a las partes interesadas, la realizacin de anlisis de viabilidad, etc ... Estoy de acuerdo con todos esas premisas.Sin embargo, es mucho ms fcil de explicar el flujo de datos si tenemos algo familiar para trabajar con (en este caso nuestra base de datos de edad y de confianza PUBS).Adems, todos los requisitos previos no tcnicos la informacin se puede encontrar en otros recursos por lo que este no ser el foco de este post.Adems, tenga en cuenta que medianas y grandes proyectos suele tener una persona "datos", como parte del equipo;alguien que tiene una buena comprensin de los sistemas transaccionales, as como las reglas de negocio que gobiernan los estrictamente desde el punto de vista de datos.Por lo general, los modeladores de datos, trabajando en conjunto con el analista (s) negocio llenarn ese papel.Sin embargo, no es raro que un desarrollador se encarga de definir y disear el esquema de base de datos dimensional, as que preprate para arrimar el hombro, sobre todo cuando slo un pequeo mercado de datos, no es un gran almacn de datos empresariales es lo que se requiere.Para seguir en usted necesitar una copia de la base de datos PUBS restaurado en su instancia de MS SQL Server.Explicacin detallada sobre cmo lograr esto se puede encontrar en numerosos lugares en Internet (Google es tu amigo), sin embargo, para su comodidad, tambin incluido como parte de los archivos de solucin que se pueden encontrar en mi carpeta de SkyDriveAQU.El esquema de base de datos recin creada debe mirar ms o menos de acuerdo con la imagen de abajo.

La tabla de claves en el diagrama ERD anterior es la tabla que contiene los registros dbo.sales transaccionales de cada nmero de la venta por ejemplo, orden, fecha de pedido, la cantidad o tienda id donde se realiz la transaccin.Transacciones de venta se convertir en el punto focal de nuestra solucin, sin embargo, otras tablas son tan importantes.Vamos a correr rpidamente a travs de algunas de las entidades para ver cul es el valor que representan para la solucin general. dbo.stores y dbo.titles tablas contienen informacin sobre qu libros se venden a las tiendas que por lo tanto son tiles y vale la pena tomar en consideracin mesa dbo.publishers contiene informacin editores.A medida que cada ttulo tiene un editor asignar a la misma, puede ser digno de su inclusin en el diseo general como a los usuarios finales lo desea, puede utilizar esta informacin para su posterior anlisis de ventas mesa dbo.authors contiene informacin sobre la cual los autores son responsables de escribir cada libro.Lo ms probable es que se analizaron los datos de ventas de ttulos, sin embargo, dado el hecho de que la informacin de los autores es de fcil acceso;podemos tambin querer tomar en consideracin mesa dbo.Employee contiene datos sobre los empleados que trabajan para cada uno de los editores que en el contexto de las ventas es irrelevante a pesar sobre el valor nominal pueda parecer lo contrario dbo.jobs tabla contiene informacin sobre los detalles del empleo para los empleados editoriales que no presentan ningn valor en esta etapa mesa dbo.titleauthor, adems de seguimiento de porcentaje de regalas dado a varios autores tambin acta como una mesa de bridge (de muchos a muchos relacin) entre dbo.titles y mesas dbo.authors.Dado el hecho de que tanto se utilizar, esta tabla debe incluirse mesa dbo.roysched pistas rangos de las regalas sobre la base de la cantidad de libros vendidos.En esta etapa, a pesar de que esta informacin afecta a los datos sobre los beneficios, esta mesa puede ser tratada como irrelevante para la informacin general de las ventas y no ser tenido en cuenta dbo.pub_info tabla no se utiliza en este proyecto como la bodega de que los datos no tienen un impacto directo en la informacin de ventas dbo.discounts parece incompleto (slo tres registros con muchos valores NULL) por lo que en esta etapa no se utilizarn como parte del proyectoUna vez que tenemos las tablas de referencia definidos, es hora de mirar a los atributos individuales y determinar qu columnas contienen informacin importante que podemos pensar en llevar al otro lado en nuestro mercado de datos.Seleccin de cada tabla identificada como una buena fuente de informacin, echemos un vistazo a su contenido y lo que se puede utilizar para sacar el mximo provecho de los datos almacenados teniendo en cuenta la diferencia entre el valor medido y un valor descriptivo.En el almacn de datos de valores medidos se traducen en medidas y valores descriptivos se traducen en atributos dimensionales.Muchos desarrolladores tendrn diferentes opiniones sobre cul es la mejor manera de disear un almacn de datos.Sin embargo, hay caractersticas comunes que usted puede esperar para ver en todos ellos.La primera caracterstica comn es un conjunto de valores que se utilizan para los informes.Estos se llaman medidas.Por ejemplo, las unidades de inventario y ventas de dlares se pueden considerar medidas.Otra caracterstica comn que se encuentra en los almacenes de datos es un conjunto de dimensiones.Dimensiones describen los datos medidos.Ejemplos de dimensiones incluyen las fechas en que se documentaron las unidades de inventario o el cdigo postal de los clientes que compraron un producto en particular.Ms informacin sobre las medidas frente al tema dimensiones se puede encontrar en Internet (que describe sus caractersticas, no es el propsito de este post);alternativamente, usted puede leer los libros ampliamente considerados y materiales publicados a partir de dos pioneros ms prolficos de los conceptos de modelado de datos y almacenamiento de datos, Ralph Kimball y Bill Inmon.Tambin, ya que ni este post, ni otros mensajes posteriores se tratarn temas como la granularidad, degenerado, chatarra o dimensiones de rol, mesas de bridge etc en amplios detalles, por favor, tenga en cuenta que un proyecto tpico almacn de datos es mucho ms complicado y complejo, y usted probablemente tendr que estar familiarizado con este tipo de complejidades.Volver a nuestros datos y explorar qu tipo de informacin de las tablas descritas anteriormente sostienen que pueden ser de inters para los usuarios de almacenes de datos. Seleccin de un subconjunto de los registros de la tabla dbo.sales revela ese atributo qty es un buen candidato para una medida, ya que es cuantificable, aditivo y puede proporcionar a un usuario de negocios con la informacin que l / ella ms probable es que desee analizar.Otros campos son ms descriptivos y pueden ser utilizados para proporcionar un contexto a la cantidad de ventas por ejemplo ord_date nos puede decir cuando la orden ha pasado, stor_id describe qu lugar del orden se origin a partir etc Algunos de estos atributos ser necesario incluir claves como dimensionales como forman un vnculo con otras tablas que a su vez contienen atributo de datos por ejemplo stor_id ms descriptivo necesita mesa dbo.stores de referencia a fin de que nosotros para saber ms detalles de tiendas como la ubicacin o el nombre Seleccin de la tabla de dbo.titles revela algunos hechos interesantes.En primer lugar, la columna de ttulo contiene descripciones tiles correspondientes a cada title_id que tambin se agrupan segn el tipo de individuo.Potencialmente, esto puede permitir rodar ttulos por tipo de clasificacin.Por otra parte, tenemos una columna de precio que es imprescindible en la bsqueda de los importes monetarios, no slo las cantidades que obtenemos de mesa dbo.sales Mirando a la mesa dbo.publishers podemos ver que los nombres de las editoriales, junto con algunos detalles de la ubicacin ocupan la mayora de los datos.Editorial atributo de nombre sera algo que podramos considerar el uso en el informe para que podamos dimensionar nuestros datos por esos atributos mesa dbo.authors contiene, como su nombre indica, los detalles relativos a los autores.Es un buen ejemplo de una tabla que tiene datos que pueden ser tiles desde el punto de vista de la dimensin como la mayora de sus atributos son descriptivos En cuanto a los datos de dbo.titleauthor cuadro revela que este objeto es necesario para conectar dbo.authors y dbo.titles juntos.Por lo tanto, las dos columnas - au_id y title_id - que constituyen las claves compuestas son esenciales para ser incluidos mesa dbo.stores, de manera similar a la tabla dbo.authors, contiene principalmente datos descriptivos referentes a lugares y nombres de tiendas.Este es otro buen ejemplo de una dimensin con todos los atributos que presenta un valor para un posible recorte repot, cortar en cubitos y obtencin de detallesAdems de los objetos que hemos analizado que pueden convertir potencialmente / fusionar en cualquiera de las tablas de hecho (s) o tablas de dimensiones, casi todos los mercados de datos tambin incluyen una dimensin sinttico que contiene las fechas y los formatos correspondientes, que se rellena con base en las necesidades especficas del negocio.A pesar de que esta tabla no participa en el mismo proceso que atravesamos al modelar dimensiones y hechos sobre la base de la base de datos OLTP, es imprescindible tener en cuenta su estructura como parte de la planificacin general de esquema OLAP como fechas (junto con sus valores derivados) son casi siempre imprescindible para proporcionar un contexto valioso para el hecho analizado (ms sobre cmo construir una tabla DimDates para esta solucin en el post posterior de esta serie, comprobar a cabo alternativamenteESTEpuesto de solucin ms completa).Parece que ahora debemos tener suficientes detalles conceptuales alrededor de los objetos, los datos que poseen y si son tiles para proceder con el desarrollo de soluciones de data mart.En elpuesto el prximovoy a mirar algunas trampas arquitectnicas cuando se mueve a la siguiente fase de desarrollo y empezar a desarrollar el cdigo base para avanzar en la creacin de esquemas OLAP.