Tecnologías Aplicadas a BI

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Tecnologías Aplicadas a BI por Mind Map: Tecnologías Aplicadas a BI

1. Dimensional Model

1.1. Presenta informacion estandar, intuitiva y con un alta performance

1.2. Modelo tridimensional. Star-join

1.3. Mas legible al usuario final

1.4. Mas escalable

2. ER Model

2.1. Util para capturar transacciones

2.2. Administrar los datos

2.3. Evita redundancia de datos

2.4. Es portable

2.5. Dificil para el usuario final

3. En un data warehouse, una tabla de hechos (o tabla fact) es la tabla central de un esquema dimensional (en estrella o en copo de nieve) y contiene los valores de las medidas de negocio o dicho de otra forma los indicadores de negocio. Cada medida se toma mediante la intersección de las dimensiones que la definen, dichas dimensiones estarán reflejadas en sus correspondientes tablas de dimensiones que rodearán la tabla de hechos y estarán relacionadas con ella.

4. Ventajas del Modelo dimensional contra el plan malevolo de mojojo

4.1. Jag älskar dig.

5. Grupo 3

5.1. ER

5.1.1. Tecnica de diseño logico

5.1.2. Quita la redundancia de datos, cosa que beneficia las transacciones.

5.1.3. El usuario final no puede navegarlo

5.1.4. No permite consultas

5.1.5. No se puede recuperar intuitivamente la informacion

5.2. DM

5.2.1. Tecnica de diseño logico utilizado para la presentacion de datos

5.2.2. Permite acceder con gran facilidad

5.2.3. Es dimensional

5.2.4. Compuesto por una tabla que tiene una llave multipartita y un conjunto de pequeñas tablas llamadas tablas dimensionales

5.2.5. El diseño es entendible por el usuario

5.3. ER vs DM

5.3.1. De un solo diagrama ER se desprenden varios diagramas DM

6. Grupo 10(IR, MM, FR) Lozano-Greenhill

6.1. ER

6.1.1. Técnica de diseño lógico que busca eliminar redundancia en los datos de pequeño y gran volumen.

6.1.2. Desventajas

6.1.2.1. Los usuarios fianles no entiende o recuerdan un modelo ER.

6.1.2.2. No es un modelo con una interfaz manejable para el usuario final.

6.1.2.3. Hay que tener intuición y conocimiento del modelo ER para realizar las consultas.

6.1.3. Ventajas

6.1.3.1. Favorece el procesamiento de consultas transaccionales por su sencillez en la busqueda.

6.1.3.2. Muestra de manera mas tapiada las relaciones existentes entre los distintos datos.

6.1.3.3. Clarificar las relaciones entre los datos

6.2. DM

6.2.1. Tecnica de diseño logico implementado a almacenes de datos.

6.2.2. Presentación de datos intuitiva

6.2.3. Acceso de alta performance

6.2.4. Compuesto por tabla de hechos y tabla de dimensiones

6.2.5. Las tablas de hecho poseen las claves foraneas de las tablas de dimensiones asociadas

6.2.6. La tabla de hechos siempre expresa una relacion de muchos a muchos

6.2.7. Framwork estandar y predecible, lo que lo hace entendible y eficiente.

6.2.8. Extensible a nuevas decisiones, datos y elementos

6.2.9. Las tablas de hecho representan el proceso de negocio

6.3. ER VS DM

6.3.1. Un diagrama ER puede dividirse en muchos diagramas DM

6.3.2. El EM, a diferencia del DM, representa múltiples procesos en un diagrama que nunca se relacionarán en un Data Set, lo que lo hace complejo

6.3.3. Transformacion de ER a DM

6.3.3.1. Separar el diagrama de ER en sus procesos de negocios y modelar cada uno por separado.

6.3.3.2. Seleccionar los muchos-a-muchos relaciones en el modelo ER que contiene hechos sin clave y designarlos como tablas de hechos

6.3.3.3. Desnormalizar todas las tablas restantes en tablas planas conectadas directamente a las tablas de hechos

6.4. Puntos Fuertes del DM

6.4.1. 1. El modelo dimensional es un marco fiable, estándar. Los generadores de informe, las herramientas , y las interfaces utilizadas hacen que los procesos sean mas comprensible y mas eficiente

6.4.2. 2. El marco fiable de la estrella ensambla cambios inesperados de los withstands del esquema en comportamiento del usuario. Cada dimensión es equivalente. Todas las dimensiones se pueden pensar en como los puntos de entrada simétricamente iguales en la tabla del hecho

6.4.3. 3. El modelo dimensional es muy facil y  extensible acomodar nuevos elementos de datos inesperados, como asi tambien nuevas decisiones del diseño

6.4.4. 4.Hay un cuerpo de los acercamientos estándares para el manejo de situaciones de modelado comunes en el mundo de los negocios. Cada uno de estas situaciones tiene un sistema bien-entendido de las alternativas que se pueden programar específicamente en report writers, query tooly otros interfaces utilizadas

6.4.5. 5.Una fuerza final del modelo dimensional es el cuerpo cada vez mayor de utilidades administrativas y los procesos del software que manejan y utilizan los agregados. Recuerde que los agregados son los expedientes sumarios que son lógicamente redundantes con datos bajos ya en el almacén de los datos, pero se utilizan para realzar funcionamiento de la pregunta. Una estrategia agregada comprensiva se requiere en cada medio y los datos de gran tamaño almacenan la puesta en práctica

7. Grupo 1

8. Grupo 7

8.1. ER

8.1.1. Manejo de transacciones

8.1.1.1. Permite transaciiones mas simples y deterministicas

8.1.2. Evita redundancia

8.1.3. Evita inconcistencias

8.1.4. Modelo normalizado

8.1.5. En 1980 nacieron los conceptos de tablas relacionadas

8.1.6. Problemas

8.1.6.1. Dificil de entender o recordar para el usuario finaal

8.1.6.2. No existe un software generico para hacer consultas

8.1.6.3. Poco intiutivo y baja performance para recuperar datos

8.2. DM

8.2.1. Simple para hacer consultas por los usuarios finales

8.2.2. Alta performance en el acceso a datos

8.2.3. Una Tabla de hechos y varias de dimenciones

8.2.3.1. Las tablas de hechos contienen datos numericos

8.2.3.2. Las tablas dimensionales contienen informacion textual

9. Grupo 9 JMF-NB-ES La comunidad del anillo

9.1. ER model

9.1.1. Logical design technique that seeks to remove the redundancy in data.

9.1.2. The highest art form of ER modeling is to remove all redundancy in the data.

9.1.3. Uses Normalization

9.1.4. Better performance when making querys

9.1.5. Removes rendundant data

9.1.6. The success of transaction processing in relational databases is mostly due to the discipline of ER modeling.

9.1.7. Even the simple examples,creates a database of dozens of tables that are linked together by a bewildering spider web of joins.

9.2. DM

9.2.1. High Performance Access

9.2.2. Fact Table Facts: Facts about certain combinations of foreign keys. Eg: Dollars sold. Numerical and additive.

9.2.3. Dimensional Model: Multipart Key Table "Fact" Dimension tables w/ Primary Key Star-like structure

9.2.4. Dimensional Tables: Descriptive Textual Information Attributes: Constraints in Queries (Row headers in SQL answer)

9.2.5. Highly recognizable to the end users, "their business"

9.3. ER vs. DM

9.3.1. ER is that a single ER diagram breaks down into multiple DM diagrams

9.3.2. Thus the first step in converting an ER diagram to a set of DM diagrams is to separate the ER diagram into its discrete business processes and to model each one separately

9.3.3. Select those many-to-many relationships in the ER model and to designate them as fact tables.

9.3.4. Denormalize all tables

9.3.5. DM model of a data warehouse will consist of somewhere between 10 and 25 similar star join schemas

9.3.6. Each star join will have 4 to 12 tables

10. Grupo 2

10.1. ER

10.1.1. GG Evitar redundancia de datos

10.1.2. GG Procesamiento de transacciones

10.1.3. Asegurar la consistencia de los datos

10.1.4. No es utilizable directamente por los usuarios finales

10.1.5. Uso de optimizadores basados en costo

10.1.6. Mala performance en querys complejas

10.1.7. Esquemas complejos en aplicaciones enterprise

10.1.8. Se descompone en múltiples DM

10.1.9. Tiene la desventaja de que es dificil de entender

10.2. DM

10.2.1. Consultas mas complejas

10.2.2. Modelo estrella

10.2.3. Alta performance

10.2.4. Esquema sencillo

10.2.5. Fact tables con datos numericos

10.2.6. Dimension tables con información textual (utilizados en las constraints)

10.2.7. Esquemas entendibles por el usuario final

10.2.8. Amigable para los usuarios finales en la generaciòn de consultas

11. Grupo 4

11.1. ER

11.1.1. Técnica de Diseño Lógico que intenta remover la redundancia en los datos.

11.1.2. Ventajas

11.1.2.1. Agiliza las consultas a la información, mediante la indexación de datos.

11.1.2.2. Evita inconsistencia de los datos

11.1.2.3. Transacciones deterministicas

11.1.2.4. Facilita el almacenamiento y manipulación de los datos

11.1.3. Desventajas

11.1.3.1. Imposible de navegar

11.1.3.2. Dificil de entender

11.2. DM

11.2.1. Técnica de diseño lógico que presenta los datos en un estándar y permite un acceso de alto rendimiento.

11.2.2. Es dimensional

11.2.3. Estructura "de estrella"

11.2.4. redundancia de los datos

11.3. de ER a DM (Corvi - La Frazia 2016)

11.3.1. 1 - Convertir el diagrama de ER en un conjunto de mùltiples diagramas DM.

11.3.2. 2 - Seleccionar las relaciones de muchos a muchos del diagrama de ER que contienen atributos numèricos y de suma; y designarlos como TABLAS DE HECHOS.

11.3.3. 3 - Desnormalizar las tablas sobrantes (del paso dos) en tablas dimensionales y conectarlas a la tabla de hecho. En el caso en que una tabla de dimension estè relacionada con màs de una tabla de hecho, serà representada una por cada esquema de DM.

12. FB

12.1. Ventajas ante el modelo ER

12.1.1. Es un framework

12.1.2. Resiste los cambios inesperados en el comportamiento del usuario, cada dimensión es equivalente

12.1.3. Es extensible

12.1.4. Posee estándares que resuelven situaciones de modelado comunes (estilo patrones)

12.1.5. Soporta diversa cantidad de software para agregados para agilizar consultas

13. asdasdj

14. Grupo 6

14.1. Fortalezas de DM

14.1.1. First, the dimensional model is a predictable, make the user interfaces more understandable and to make processing more efficient.

14.1.2. A second strength of the dimensional model is that the predictable framework of the star join schema withstands unexpected changes in user behavior. Every dimension is equivalent. All dimensions can be thought of as symmetrically equal entry points into the fact table. The logical design can be done independent of expected query patterns. The user interfaces are symmetrical, the query strategies are symmetrical, and the SQL generated against the dimensional model is symmetrical.

14.1.3. A third strength of the dimensional model is that it is gracefully extensible to accommodate unexpected new data elements and new design decisions.

14.1.3.1. First, all existing tables (both fact and dimension) can be changed in place by simply adding new data rows in the table, or the table can be changed in place with a SQL alter table command.

14.1.3.2. no query tool or reporting tool needs to be reprogrammed to accommodate the change

14.1.3.3. all old applications continue to run without yielding different results.

14.1.4. fourth strength of the dimensional model is that there is a body of standard approaches for handling common modeling situations in the business world. Each of these situations has a well-understood set of alternatives that can be specifically programmed in report writers, query tools, and other user interfaces

14.1.5. the growing body of administrative utilities and software processes that manage and use aggregates. Recall that aggregates are summary records that are logically redundant with base data already in the data warehouse, but they are used to enhance query performance. A comprehensive aggregate strategy is required in every medium- and large-sized data warehouse implementation. To put it another way, if you don’t have aggregates, then you are potentially wasting millions of dollars on hardware upgrades to solve performance problems that could be otherwise addressed by aggregates.

14.1.5.1. ll of the aggregate management software packages and aggregate navigation utilities depend on a very specific single structure of fact and dimension tables that is absolutely dependent on the dimensional model. If you don’t adhere to the dimensional approach, you cannot benefit from these tools.

14.2. ER vs DM

14.2.1. En el tercer paso DM toma las tablas restantes y las normaliza en tablas planas, conectandolas a la tabla de hechos por su llave.

14.2.2. JJF - DM separa los procesos de negocio del diagrama de ER

14.2.3. DM toma relaciones muchos a muchos y construye "tablas de hechos"

14.2.4. Cuando una tabla de dimensiones se conecta a mas de una tabla de hechos se  representa en ambos esquemas y se representa a las misma como "conforme" entre ambos modelos dimensionales.

14.2.5. El modelo DM maestro, resultara ser entre 10 y 25 esquemas estrella. Cada combinacion estrella, tendra entre 4 y 12 tablas de dimensiones. Si el diseño se ha realizado correctamente, muchas de estas tablas de dimensiones se compartirán de tabla de hechos a la tabla de hechos. A pesar de que el conjunto global de la combinación en estrella es complejo, el procesamiento de consultas es muy predecible, porque en el nivel más bajo.

14.2.6. ER Orientado a transacciones DM Orientado a consultas