What are the pros and cons of using a dimensional model (Kimball) vs a normalized model (Inmon)?

Kimball's dimensional model, using a star schema, is favored for its simplicity, performance, and business-centric focus. It is easy to understand, enhances query speed with denormalized structures, and aligns with business needs, making it ideal for data marts tailored to specific departments.

The base of EDW is implement on data model the 3 normal form with time handling. Use 4NF or using superior techniques is not very common and maybe move to ensemble data modeling a little. But you can use any normal forms to implement it.

The Inmon approach's emphasis on data consistency and integrity makes it particularly suitable for organizations with stringent compliance requirements, such as finance and healthcare sectors. Its design facilitates robust audit trails and data lineage, ensuring that data remains accurate and compliant with regulations. Additionally, Inmon's centralized approach can aid in implementing organization-wide data governance policies, making it easier to control access and ensure data security across the entire data ecosystem.

Inmon's normalized model is a robust approach to enterprise data warehousing, emphasizing data integrity and consistency by reducing redundancy. It offers flexibility and scalability, accommodating various data sources and evolving business needs, while also reducing data storage requirements for large datasets.

While the Kimball approach offers agility by allowing incremental development and easier incorporation of new data sources, this flexibility can sometimes lead to challenges in maintaining data quality. In rapidly evolving business environments, where changes in data structures and definitions are common, ensuring consistency across multiple data marts can be problematic. Therefore, organizations leveraging Kimball must invest in strong data validation and reconciliation processes to mitigate potential inconsistencies and maintain high data quality standards.

Dimensional models simplify data by mirroring business users' perspectives, enhancing understanding and ease of querying, even for non-technical users. They boost performance through denormalization and pre-calculated aggregates, optimizing query efficiency. Focusing on specific business processes, these models enable iterative development and quicker time-to-value, aligning with modern business agility.

Use normal form techniques more advance, more reduce the redundacy in data and get more tables; then you have these points: Cons: Use several joins to get a entity. In this case, the performance maybe affect. Pros: Support the reusability of table easier on data model, that affect possitively the integration and quality control of the data. In my opinion; this is the reason to use the 3NF on the data model: to balance the performance aspect with the integration and quality aspects.

Complexity: Crafting and executing a fully normalized model can be intricate and time-intensive, demanding specialized expertise and considerable initial investment. Performance: Complex joins across numerous tables may hinder query performance, particularly in ad-hoc analysis and reporting scenarios. Steeper Learning Curve: The model's intricacy can pose challenges for business users to comprehend and query directly.

A final solution may include a bit of both. Data can be warehoused in an RDBMS with a "Normalized" PDM. Although not always as disciplined as 3rd Form. There's a point of diminishing return for "over-governance" but largely managed here. Not always the most agile due to extensive rigor to ensure accurate analysis and reporting downstream. Thay serves the IT folks. But, as mentioned, the normalized model may not be intuitively obvious for business community so... With the Normalized/Governed PDM as input, an access layer is added that more closely resembles a Star/Snowflake model. This presentation is much more intutive for user community. Key... Any underlying PDM quality issues are magnified in this layer.

Choose Kimball for specific business processes, agile development, and easy reporting. Opt for Inmon for enterprise-wide integration, governance, and flexibility in complex data environments. Kimball suits simpler data structures and is easier to implement, while Inmon requires more expertise for normalization and design. Evaluate performance needs and scalability when dealing with high data volume and velocity.

Remember that both techniques can complement each other because it work in different part of the data architecture; Kimball approach for data mart or Inmon approach for data warehouse: depend how you design the data architecture; this is a main point!

The choice between Kimball and Inmon depends on your unique circumstances. By carefully considering your business needs, data characteristics, and technical capabilities, you can make an informed decision that aligns with your data warehousing goals.