1. Alta performance en el acceso a datos
2. Dimensional Model
2.1. Presenta informacion estandar, intuitiva y con un alta performance
2.2. Modelo tridimensional. Star-join
2.3. Mas legible al usuario final
2.4. Mas escalable
3. ER Model
3.1. Util para capturar transacciones
3.2. Administrar los datos
3.3. Evita redundancia de datos
3.4. Es portable
3.5. Dificil para el usuario final
4. 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.
5. Ventajas del Modelo dimensional contra el plan malevolo de mojojo
5.1. Jag älskar dig.
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.3. Las tablas de hecho representan el proceso de negocio
6.4. ER VS DM
6.4.1. Un diagrama ER puede dividirse en muchos diagramas DM
6.4.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.4.3. Transformacion de ER a DM
6.4.3.1. Separar el diagrama de ER en sus procesos de negocios y modelar cada uno por separado.
6.4.3.2. Seleccionar los muchos-a-muchos relaciones en el modelo ER que contiene hechos sin clave y designarlos como tablas de hechos
6.4.3.3. Desnormalizar todas las tablas restantes en tablas planas conectadas directamente a las tablas de hechos
6.5. Puntos Fuertes del DM
6.5.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.5.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.5.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.5.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.5.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. Una Tabla de hechos y varias de dimenciones
8.2.2.1. Las tablas de hechos contienen datos numericos
8.2.2.2. Las tablas dimensionales contienen informacion textual
9. Grupo 6
9.1. Fortalezas de DM
9.1.1. First, the dimensional model is a predictable, make the user interfaces more understandable and to make processing more efficient.
9.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.
9.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.
9.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.
9.1.3.2. no query tool or reporting tool needs to be reprogrammed to accommodate the change
9.1.3.3. all old applications continue to run without yielding different results.
9.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
9.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.
9.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.
9.2. 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.
9.3. ER vs DM
9.3.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.
9.3.2. JJF - DM separa los procesos de negocio del diagrama de ER
9.3.3. DM toma relaciones muchos a muchos y construye "tablas de hechos"
9.3.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.
9.3.5. ER Orientado a transacciones DM Orientado a consultas
10. DM
10.1. High Performance Access
10.2. Fact Table Facts: Facts about certain combinations of foreign keys. Eg: Dollars sold. Numerical and additive.
10.3. Dimensional Model: Multipart Key Table "Fact" Dimension tables w/ Primary Key Star-like structure
10.4. Dimensional Tables: Descriptive Textual Information Attributes: Constraints in Queries (Row headers in SQL answer)
10.5. Highly recognizable to the end users, "their business"
11. Permite acceder con gran facilidad
12. Grupo 3
12.1. ER
12.1.1. Tecnica de diseño logico
12.1.2. Quita la redundancia de datos, cosa que beneficia las transacciones.
12.1.3. El usuario final no puede navegarlo
12.1.4. No permite consultas
12.1.5. No se puede recuperar intuitivamente la informacion
12.2. DM
12.2.1. Tecnica de diseño logico utilizado para la presentacion de datos
12.2.2. Es dimensional
12.2.3. Compuesto por una tabla que tiene una llave multipartita y un conjunto de pequeñas tablas llamadas tablas dimensionales
12.2.4. El diseño es entendible por el usuario
12.3. ER vs DM
12.3.1. De un solo diagrama ER se desprenden varios diagramas DM
13. Grupo 9 JMF-NB-ES La comunidad del anillo
13.1. ER model
13.1.1. Logical design technique that seeks to remove the redundancy in data.
13.1.2. The highest art form of ER modeling is to remove all redundancy in the data.
13.1.3. Uses Normalization
13.1.4. Better performance when making querys
13.1.5. Removes rendundant data
13.1.6. The success of transaction processing in relational databases is mostly due to the discipline of ER modeling.
13.1.7. Even the simple examples,creates a database of dozens of tables that are linked together by a bewildering spider web of joins.
13.2. ER vs. DM
13.2.1. ER is that a single ER diagram breaks down into multiple DM diagrams
13.2.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
13.2.3. Select those many-to-many relationships in the ER model and to designate them as fact tables.
13.2.4. Denormalize all tables
13.2.5. DM model of a data warehouse will consist of somewhere between 10 and 25 similar star join schemas
13.2.6. Each star join will have 4 to 12 tables
14. Grupo 2
14.1. ER
14.1.1. GG Evitar redundancia de datos
14.1.2. GG Procesamiento de transacciones
14.1.3. Asegurar la consistencia de los datos
14.1.4. No es utilizable directamente por los usuarios finales
14.1.5. Uso de optimizadores basados en costo
14.1.6. Mala performance en querys complejas
14.1.7. Esquemas complejos en aplicaciones enterprise
14.1.8. Se descompone en múltiples DM
14.1.9. Tiene la desventaja de que es dificil de entender
14.2. Modelo estrella
14.3. DM
14.3.1. Consultas mas complejas
14.3.2. Alta performance
14.3.3. Esquema sencillo
14.3.4. Fact tables con datos numericos
14.3.5. Dimension tables con información textual (utilizados en las constraints)
14.3.6. Esquemas entendibles por el usuario final
14.3.7. Amigable para los usuarios finales en la generaciòn de consultas
15. Grupo 4
15.1. ER
15.1.1. Técnica de Diseño Lógico que intenta remover la redundancia en los datos.
15.1.2. Ventajas
15.1.2.1. Agiliza las consultas a la información, mediante la indexación de datos.
15.1.2.2. Evita inconsistencia de los datos
15.1.2.3. Transacciones deterministicas
15.1.2.4. Facilita el almacenamiento y manipulación de los datos
15.1.3. Desventajas
15.1.3.1. Imposible de navegar
15.1.3.2. Dificil de entender
15.2. DM
15.2.1. Técnica de diseño lógico que presenta los datos en un estándar y permite un acceso de alto rendimiento.
15.2.2. Es dimensional
15.2.3. Estructura "de estrella"
15.2.4. redundancia de los datos
15.3. de ER a DM (Corvi - La Frazia 2016)
15.3.1. 1 - Convertir el diagrama de ER en un conjunto de mùltiples diagramas DM.
15.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.
15.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.
16. FB
16.1. Ventajas ante el modelo ER
16.1.1. Es un framework
16.1.2. Resiste los cambios inesperados en el comportamiento del usuario, cada dimensión es equivalente
16.1.3. Es extensible
16.1.4. Posee estándares que resuelven situaciones de modelado comunes (estilo patrones)
16.1.5. Soporta diversa cantidad de software para agregados para agilizar consultas