<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Best Data Model for moving from DW to Delta lake in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34407#M25162</link>
    <description>&lt;P&gt;It all depends on the use case.&lt;/P&gt;&lt;P&gt;3NF is ideal for transactional systems. So for a data warehouse/lakehouse that might not be ideal.&lt;/P&gt;&lt;P&gt;However there certainly are cases where it is interesting.&lt;/P&gt;&lt;P&gt;Star schema's are def still relevant, BUT with the processing power of spark you can decide to flatten it beforehand (so joining all dims with the fact and write it). Like that you have to do less joins at query runtime, which is often faster.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;IMO the beauty of all this is the freedom you get. You are not locked into a certain model. Start with what you think is a good approach, and see where it gets you.&lt;/P&gt;&lt;P&gt;The good old Inmon/Kimball theory is still valid up to a certain point (fact tables, SCD etc) but a lot has also become obsolete.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In my lakehouse I have a mix of flattened star schema's, actual star schema's and plain tables (bronze/silver).&lt;/P&gt;</description>
    <pubDate>Thu, 25 Nov 2021 08:13:53 GMT</pubDate>
    <dc:creator>-werners-</dc:creator>
    <dc:date>2021-11-25T08:13:53Z</dc:date>
    <item>
      <title>Best Data Model for moving from DW to Delta lake</title>
      <link>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34405#M25160</link>
      <description>&lt;P&gt;I’m curious what Databricks recommends how we model the data.&amp;nbsp;Do they recommend that the data be in 3rd normal form (3NF).&amp;nbsp;Or should be it be dimensionally modeled (facts and dimensions)&lt;/P&gt;</description>
      <pubDate>Wed, 24 Nov 2021 20:26:25 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34405#M25160</guid>
      <dc:creator>StephanieAlba</dc:creator>
      <dc:date>2021-11-24T20:26:25Z</dc:date>
    </item>
    <item>
      <title>Re: Best Data Model for moving from DW to Delta lake</title>
      <link>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34406#M25161</link>
      <description>&lt;P&gt;I think that everyone can get what they like as all of them are fully supported (denormalized table or star/snowflake schema thanks to Spark SQL)&lt;/P&gt;</description>
      <pubDate>Wed, 24 Nov 2021 22:06:17 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34406#M25161</guid>
      <dc:creator>Hubert-Dudek</dc:creator>
      <dc:date>2021-11-24T22:06:17Z</dc:date>
    </item>
    <item>
      <title>Re: Best Data Model for moving from DW to Delta lake</title>
      <link>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34407#M25162</link>
      <description>&lt;P&gt;It all depends on the use case.&lt;/P&gt;&lt;P&gt;3NF is ideal for transactional systems. So for a data warehouse/lakehouse that might not be ideal.&lt;/P&gt;&lt;P&gt;However there certainly are cases where it is interesting.&lt;/P&gt;&lt;P&gt;Star schema's are def still relevant, BUT with the processing power of spark you can decide to flatten it beforehand (so joining all dims with the fact and write it). Like that you have to do less joins at query runtime, which is often faster.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;IMO the beauty of all this is the freedom you get. You are not locked into a certain model. Start with what you think is a good approach, and see where it gets you.&lt;/P&gt;&lt;P&gt;The good old Inmon/Kimball theory is still valid up to a certain point (fact tables, SCD etc) but a lot has also become obsolete.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In my lakehouse I have a mix of flattened star schema's, actual star schema's and plain tables (bronze/silver).&lt;/P&gt;</description>
      <pubDate>Thu, 25 Nov 2021 08:13:53 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/best-data-model-for-moving-from-dw-to-delta-lake/m-p/34407#M25162</guid>
      <dc:creator>-werners-</dc:creator>
      <dc:date>2021-11-25T08:13:53Z</dc:date>
    </item>
  </channel>
</rss>

