{"id":2385,"date":"2026-03-03T10:13:59","date_gmt":"2026-03-02T23:13:59","guid":{"rendered":"https:\/\/www.dynamicwebtraining.com.au\/blog\/?p=2385"},"modified":"2026-03-03T10:23:58","modified_gmt":"2026-03-02T23:23:58","slug":"star-vs-snowflake-schemas","status":"publish","type":"post","link":"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas","title":{"rendered":"Power BI Data Modelling: Star vs Snowflake Schemas"},"content":{"rendered":"\n<p><strong>A Power BI data model<\/strong> or semantic model is the set of tables, relationships, and calculations loaded into Power BI\u2019s in-memory engine. A schema refers to how these tables are organized. It underpins all reports and visuals. A high-quality model delivers fast, reliable analytics; a poor model often causes slow refreshes and incorrect results.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Fact and Dimension Tables: The Building Blocks of Power BI Data Model<\/h2>\n\n\n\n<p>In practice, a model consists of <strong>fact tables<\/strong> and <strong>dimension tables<\/strong>.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Fact Tables:<\/strong> Fact tables store events or transactions and contain numeric measures, for example, <strong>sale orders<\/strong> table. A fact table is typically very large and grows over time.<\/li>\n\n\n\n<li> <strong>Dimension Tables:<\/strong> Dimension tables describe entities, for example, Products, Customers, Dates with a unique key and a descriptive attribute for filtering, grouping and slicing in reports. They usually have a small number of rows relative to the fact table. Each has a primary key that matches a foreign key in the fact table, plus descriptive attributes such as product name, category, store region or date attributes.<\/li>\n<\/ul>\n\n\n\n<p>This distinction between fact and dimension tables is a foundational topic in <a href=\"https:\/\/www.dynamicwebtraining.com.au\/power-bi-training-courses\">Power BI training courses<\/a> because nearly every performance issue traces back to modelling mistakes.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-dominant-color=\"b6c6c2\" data-has-transparency=\"false\" style=\"--dominant-color: #b6c6c2;\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"1024\" src=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-1024x1024.webp\" alt=\"Fact Table vs Dimension Table Comparison\" class=\"wp-image-2386 not-transparent\" srcset=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-1024x1024.webp 1024w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-300x300.webp 300w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-150x150.webp 150w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison.webp 1080w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Figure 1: A comparison table showing the differences between Fact tables (quantitative events) and Dimension tables (descriptive attributes) in Power BI.<\/figcaption><\/figure>\n\n\n\n<p>A true semantic model always uses fact and dimension tables with one-to-many relationships; the \u201cone\u201d side is the dimension table. Avoid mixing them in a single table. For example, putting product categories, customer names, and sales all in a single \u201cSales\u201d table not only bloats the table but also makes measure calculations error prone. Keeping tables separated ensures that DAX filter contexts propagate cleanly from dims to facts, and each table\u2019s columns compress efficiently.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Why not use a single flat table?<\/h2>\n\n\n\n<p>Sometimes users load all data into one large table instead of separate facts and dimensions. While Power BI will \u201cwork\u201d with a single table, this is not a true semantic model. Flattening facts and dimensions into one huge table generally creates a bigger model that only marginally speeds up trivial queries yet performs <strong>much worse<\/strong> on real analytical queries.<\/p>\n\n\n\n<p>By contrast, a true semantic model separates facts and dims. Dimension tables enable slicing and filtering, while fact tables enable aggregation. This clean separation is what Power BI\u2019s engine (VertiPaq) is optimized for.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Normalized vs Denormalized Data:<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Normalised data (relational design):<\/strong> Data is split into multiple related tables, so each fact is stored once, reducing redundancy and protecting integrity (often described via normal forms such as 3NF).<\/li>\n\n\n\n<li><strong>Denormalised data (performance\/usage optimisation):<\/strong> Data is intentionally restructured to reduce joins and improve read\/query usability by pre-joining commonly accessed attributes. This is done after a sound normalised design exists.<\/li>\n<\/ul>\n\n\n\n<p>In Power BI we most often use a <strong>star schema<\/strong> or a <strong>snowflake schema<\/strong>. A <strong>star schema<\/strong> has one central fact table and multiple dimension tables radiating out from it. A <strong>snowflake schema<\/strong> normalizes one or more dimensions into sub-tables: one or more dimension tables are split into related lookup tables (like <kbd>Product \u2192 ProductCategory \u2192 ProductSubcategory<\/kbd>).<\/p>\n\n\n\n<p>These schemas have different trade-offs in Power BI:<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Star and Snowflake Schemas Defined<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Star Schema:<\/strong> The fact table directly joins to each dimension table. One fact table with simple one-to-many relationships to each dimension. There are <em>no<\/em> intermediate lookup tables. All descriptive attributes for an entity live in one table. This \u201cflat\u201d dimensional design minimizes joins. This layout resembles a star with the fact at the centre. Star schemas are <em>simple to understand<\/em>: one dimension equals one table. Star designs also make DAX measures straightforward: filters from slicers flow directly to the fact table through single relationships.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img data-dominant-color=\"9ac8a2\" data-has-transparency=\"false\" style=\"--dominant-color: #9ac8a2;\" loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"1024\" src=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-star-schema-example-1024x1024.webp\" alt=\"Power BI Star Schema Model Layout\" class=\"wp-image-2387 not-transparent\" srcset=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-star-schema-example-1024x1024.webp 1024w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-star-schema-example-300x300.webp 300w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-star-schema-example-150x150.webp 150w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-star-schema-example.webp 1080w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Figure 2: Example of a Star Schema in Power BI where a central fact table connects directly to denormalized dimension tables for optimal performance.<\/figcaption><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Snowflake Schema:<\/strong> A variation where one or more dimension tables are <strong>normalized<\/strong>. That is, a dimension is split into sub tables. For example, instead of one Product table with Category and Subcategory columns, they have separate Category \u2192 Subcategory \u2192 Product tables linked in a chain. The structure \u201cbranches out\u201d more like a snowflake. Snowflaking <strong>reduces data duplication<\/strong>: common attributes like category names live only in one table. However, it <strong>adds complexity<\/strong>: each fact-to-dimension filter must traverse multiple tables. For instance, filtering on a product category now requires a join from <kbd>Fact\u2192Product\u2192Subcategory\u2192Category<\/kbd> rather than directly Fact\u2192Product. This eliminates duplicated attributes but creates extra tables.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image size-full\"><img data-dominant-color=\"91c49f\" data-has-transparency=\"false\" style=\"--dominant-color: #91c49f;\" loading=\"lazy\" decoding=\"async\" width=\"940\" height=\"788\" src=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-snowflake-schema-design.webp\" alt=\"Power BI Snowflake Schema Diagram\" class=\"wp-image-2388 not-transparent\" srcset=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-snowflake-schema-design.webp 940w, https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/power-bi-snowflake-schema-design-300x251.webp 300w\" sizes=\"auto, (max-width: 940px) 100vw, 940px\" \/><figcaption class=\"wp-element-caption\">Figure 3: A Snowflake Schema design showing normalized dimension tables branching out into sub-tables, such as Category and Subcategory.<\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Comparison: Star vs Snowflake in Power BI<\/h2>\n\n\n\n<figure class=\"wp-block-table has-small-font-size\"><table class=\"has-subtle-background-background-color has-background has-fixed-layout\"><thead><tr><th><strong>Aspect<\/strong><\/th><th><strong>Star Schema<\/strong><\/th><th><strong>Snowflake Schema<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>Query Performance<\/strong><\/td><td><strong>Fewer joins, faster queries.<\/strong> VertiPaq compresses star-schema tables very efficiently, and repeated dimension values shrink well. Result: visuals and DAX calculations run very quickly.<\/td><td><strong>More joins, slower queries.<\/strong> Snowflake schemas introduce extra relationship \u201chops\u201d through sub-dimensions, which adds processing overhead. Each additional join can slow down VertiPaq\u2019s in-memory engine. In practice, complex filter propagation through multiple tables degrades performance compared to a star model.<\/td><\/tr><tr><td><strong>DAX Complexity<\/strong><\/td><td><strong>Simpler.<\/strong> With one dimension table per entity, filter contexts flow cleanly. Functions like CALCULATE or time-intelligence behave predictably. It\u2019s easy to define measures because each filter comes from a single table.<\/td><td><strong>More complex.<\/strong> Filters must traverse intermediate tables, making DAX harder to write and debug. Multi-hop relationships can lead to unexpected filter behavior. For example, you need to explicitly bridge relationships or use <kbd>CROSSFILTER\/USERELATIONSHIP<\/kbd> in some cases.<\/td><\/tr><tr><td><strong>Model Size (Memory)<\/strong><\/td><td><strong>Potentially larger.<\/strong> Dimensions are denormalized, so attribute values are stored redundantly, for example category names repeat for each product row. This can increase model size, but VertiPaq\u2019s columnar compression often offsets the redundancy.<\/td><td><strong>Potentially smaller.<\/strong> Normalization eliminates duplicate attribute storage, e.g. one Category name stored once instead of many times, so raw data size can shrink. However, splitting tables can actually increase overhead per table. In other words, many small tables may not compress as well as a few larger ones.<\/td><\/tr><tr><td><strong>Maintenance and Governance<\/strong><\/td><td><strong>Simpler to manage.<\/strong> Each dimension is a single table, so updating attributes, adding a column, fixing data, is straightforward. Hierarchies can be defined within one table. Business users and new developers find a star model easier to understand.<\/td><td><strong>More complex.<\/strong> A logical dimension is spread across several tables. Adding a new attribute may mean modifying multiple tables and relationships. Changes in one subtable e.g. adding a new category must be propagated to related tables.<\/td><\/tr><tr><td><\/td><td><\/td><td><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Real-World Considerations<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preferred Approach:<\/strong> For almost all Power BI projects, star <strong>schema is the starting point<\/strong>. <a href=\"https:\/\/learn.microsoft.com\/en-us\/power-bi\/guidance\/star-schema\">Microsoft<\/a> and Power BI experts consistently recommend flattening normalized structures when loading data into Power BI.<\/li>\n\n\n\n<li><strong>VertiPaq Engine:<\/strong> Always remember that Power BI\u2019s VertiPaq stores data column-wise. It <strong>loads only the needed columns<\/strong> for each query. Star schemas align perfectly with this: common dimension columns (like category or year) have many repeated values, so they compress extremely well, and since there are fewer relationships, filter contexts are applied quickly. Snowflaked dimensions increase column cardinality and add joins, which means VertiPaq has more work.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Best Practices<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start with Star Schema:<\/strong> Design your model with one fact table and clear dimension tables wherever possible. This ensures optimal performance and simplicity.<\/li>\n\n\n\n<li><strong>Use Power Query to Denormalize:<\/strong> If your source has normalized tables, merge them in Power Query to present a star layout to Power BI.<\/li>\n\n\n\n<li><strong>Monitor Query Plans:<\/strong> Tools like <a href=\"https:\/\/daxstudio.org\/\">DAX Studio<\/a> or Power BI\u2019s Performance Analyzer can reveal if extra relationships are costing time. Use these to identify bottlenecks caused by a snowflake design.<\/li>\n\n\n\n<li><strong>Maintain Clear Documentation:<\/strong> Always document the relationships and reasons. Complex models are harder for colleagues to use correctly.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading has-h-4-font-size\">Conclusion<\/h2>\n\n\n\n<p>In summary, Star schemas yield <strong>fast queries, simple DAX, and user-friendly models<\/strong>. Snowflake schemas offer <strong>space savings and normalized data integrity<\/strong> but require more complex modelling and can slow down visuals. Align your model to your scenario: if speed and simplicity dominate, go star; if data conformity and storage are paramount, consider snowflake. In all cases, follow best practices: drop unused columns, enforce correct data types, and prefer filtering by one-to-many relationships. By doing so, you\u2019ll get the most out of VertiPaq, achieve faster refreshes, and write clearer DAX, whether your model is a star, a snowflake, or a hybrid of both.<\/p>\n\n\n\n<p>If you want to build production-ready data models and truly master dimensional design, consider our <a href=\"https:\/\/www.dynamicwebtraining.com.au\/power-bi-training-courses\/power-bi-advanced-course\">advanced Power BI training<\/a> that goes beyond report building and focuses on modelling fundamentals, performance optimization, and real-world case studies.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A Power BI data model or semantic model is the set of tables, relationships, and calculations loaded into Power BI\u2019s in-memory engine. A schema refers to how these tables are organized. It underpins all reports and visuals. A high-quality model delivers fast, reliable analytics; a poor model often causes slow refreshes and incorrect results.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1354],"tags":[],"class_list":["post-2385","post","type-post","status-publish","format-standard","hentry","category-power-bi"],"yoast_head":"<title>Power BI Data Modelling: Star vs Snowflake Schemas<\/title>\n<meta name=\"description\" content=\"View and Share Dynamic Web Training Blog Archives. This is a great source of articles and posts on Computer and IT training, tutorials and insights\" \/>\n<meta name=\"robots\" content=\"index, follow\" \/>\n<meta name=\"googlebot\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<meta name=\"bingbot\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Power BI Data Modelling: Star vs Snowflake Schemas\" \/>\n<meta property=\"og:description\" content=\"Master Power BI data modelling with our guide on Star vs Snowflake schemas. Learn how fact vs dimension tables and normalisation impact speed.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\" \/>\n<meta property=\"og:site_name\" content=\"Dynamic Web Training Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/DynamicWebTraining\/\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/DynamicWebTraining\/\" \/>\n<meta property=\"article:published_time\" content=\"2026-03-02T23:13:59+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-03-02T23:23:58+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-1024x1024.webp\" \/>\n<meta name=\"twitter:card\" content=\"summary\" \/>\n<meta name=\"twitter:creator\" content=\"@dynamicwebtrain\" \/>\n<meta name=\"twitter:site\" content=\"@dynamicwebtrain\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#organization\",\"name\":\"Dynamic Web Training\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/\",\"sameAs\":[\"https:\/\/www.facebook.com\/DynamicWebTraining\/\",\"https:\/\/www.linkedin.com\/company\/dynamic-web-training\",\"https:\/\/twitter.com\/dynamicwebtrain\"],\"logo\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#logo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2016\/02\/logo.png\",\"width\":361,\"height\":109,\"caption\":\"Dynamic Web Training\"},\"image\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#logo\"}},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#website\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/\",\"name\":\"Dynamic Web Training Blog\",\"description\":\"The Ultimate Training Experience.\",\"publisher\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-content\/uploads\/2026\/03\/fact-vs-dimension-table-comparison-1024x1024.webp\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#webpage\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\",\"name\":\"Power BI Data Modelling: Star vs Snowflake Schemas\",\"isPartOf\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#primaryimage\"},\"datePublished\":\"2026-03-02T23:13:59+00:00\",\"dateModified\":\"2026-03-02T23:23:58+00:00\",\"description\":\"Master Power BI data modelling with our guide on Star vs Snowflake schemas. Learn how fact vs dimension tables and normalisation impact speed.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\",\"name\":\"Training Blog\"}},{\"@type\":\"ListItem\",\"position\":2,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/category\/training\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/category\/training\",\"name\":\"Training\"}},{\"@type\":\"ListItem\",\"position\":3,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/category\/training\/power-bi\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/category\/training\/power-bi\",\"name\":\"Power BI\"}},{\"@type\":\"ListItem\",\"position\":4,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\",\"url\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas\",\"name\":\"Power BI Data Modelling: Star vs Snowflake Schemas\"}}]},{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#webpage\"},\"author\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#\/schema\/person\/c94653aed4a6decc8e357af0a1082233\"},\"headline\":\"Power BI Data Modelling: Star vs Snowflake Schemas\",\"datePublished\":\"2026-03-02T23:13:59+00:00\",\"dateModified\":\"2026-03-02T23:23:58+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#webpage\"},\"publisher\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/star-vs-snowflake-schemas#primaryimage\"},\"articleSection\":\"Power BI\",\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#\/schema\/person\/c94653aed4a6decc8e357af0a1082233\",\"name\":\"Dynamic Web Training\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/www.dynamicwebtraining.com.au\/blog\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0a14e92e62ad4eee0843f5cf7da3a00e1df4c9763922d4d20ba3ed2402a6896d?s=96&d=mm&r=g\",\"caption\":\"Dynamic Web Training\"},\"description\":\"Dynamic Web Training is Australia's leading provider of instructor led software training. We offer training courses in Adobe, Web Design, Graphic Design, Photoshop, InDesign, Dreamweaver and many more.\",\"sameAs\":[\"https:\/\/www.facebook.com\/DynamicWebTraining\/\",\"https:\/\/www.linkedin.com\/company\/dynamic-web-training\",\"https:\/\/twitter.com\/dynamicwebtrain\"]}]}<\/script>","_links":{"self":[{"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/posts\/2385","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/comments?post=2385"}],"version-history":[{"count":4,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/posts\/2385\/revisions"}],"predecessor-version":[{"id":2394,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/posts\/2385\/revisions\/2394"}],"wp:attachment":[{"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/media?parent=2385"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/categories?post=2385"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dynamicwebtraining.com.au\/blog\/wp-json\/wp\/v2\/tags?post=2385"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}