Dimensional modeling in Microsoft Fabric

Warehouse: Dimension tables

Article • 04/06/2025

Applies to: ✅ SQL analytics endpoint and Warehouse in Microsoft Fabric

７ Note

This article forms part of the Dimensional modeling in Microsoft Fabric Data Warehouse
series of articles. This series focuses on guidance and design best practices related to
dimensional modeling in Microsoft Fabric Warehouse.

This article provides you with guidance and best practices for designing dimension tables in a
dimensional model. It provides practical guidance for Warehouse in Microsoft Fabric, which is an
experience that supports many T-SQL capabilities, like creating tables and managing data in
tables. So, you're in complete control of creating your dimensional model tables and loading
them with data.

７ Note

In this article, the term data warehouse refers to an enterprise data warehouse, which delivers
comprehensive integration of critical data across the organization. In contrast, the standalone
term warehouse refers to a Fabric Warehouse, which is a software as a service (SaaS)
relational database offering that you can use to implement a data warehouse. For clarity, in
this article the latter is mentioned as Fabric Warehouse.

 Tip

If you're inexperienced with dimensional modeling, consider this series of articles your first
step. It isn't intended to provide a complete discussion on dimensional modeling design. For
more information, refer directly to widely adopted published content, like The Data
Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph
Kimball, and others.

In a dimensional model, a dimension table describes an entity relevant to your business and
analytics requirements. Broadly, dimension tables represent the things that you model. Things
could be products, people, places, or any other concept, including date and time. To easily identify
dimension tables, you typically prefix their names with d_ or Dim_ .

Dimension table structure

To describe the structure of a dimension table, consider the following example of a salesperson
dimension table named d_Salesperson . This example applies good design practices. Each of the
groups of columns is described in the following sections.

SQL

CREATE TABLE d_Salesperson

(
--Surrogate key
Salesperson_SK INT NOT NULL,

--Natural key(s)
EmployeeID VARCHAR(20) NOT NULL,

--Dimension attributes
FirstName VARCHAR(20) NOT NULL,
<...>

--Foreign key(s) to other dimensions

SalesRegion_FK INT NOT NULL,
<...>

--Historical tracking attributes (SCD type 2)

RecChangeDate_FK INT NOT NULL,
RecValidFromKey INT NOT NULL,
RecValidToKey INT NOT NULL,
RecReason VARCHAR(15) NOT NULL,
RecIsCurrent BIT NOT NULL,

--Audit attributes
AuditMissing BIT NOT NULL,
AuditIsInferred BIT NOT NULL,
AuditCreatedDate DATE NOT NULL,
AuditCreatedBy VARCHAR(15) NOT NULL,
AuditLastModifiedDate DATE NOT NULL,
AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Surrogate key
The sample dimension table has a surrogate key, which is named Salesperson_SK . A surrogate key
is a single-column unique identifier that's generated and stored in the dimension table. It's a
primary key column used to relate to other tables in the dimensional model.

Surrogate keys strive to insulate the data warehouse from changes in source data. They also
deliver many other benefits, allowing you to:

Consolidate multiple data sources (avoiding clash of duplicate identifiers).

Consolidate multi-column natural keys into a more efficient, single-column key.
Track dimension history with a slowly changing dimension (SCD) type 2.
Limit fact table width for storage optimization (by selecting the smallest possible integer
data type).

A surrogate key column is a recommended practice, even when a natural key (described next)
seems an acceptable candidate. You should also avoid giving meaning to the key values (except
for date and time dimension keys, as described later).

Natural keys
The sample dimension table also has a natural key, which is named EmployeeID . A natural key is
the key stored in the source system. It allows relating the dimension data to its source system,
which is typically done by an Extract, Load, and Transform (ETL) process to load the dimension
table. Sometimes a natural key is called a business key, and its values might be meaningful to
business users.

Sometimes dimensions don't have a natural key. That could be the case for your date dimension
or lookup dimensions, or when you generate dimension data by normalizing a flat file.

Dimension attributes
A sample dimension table also has dimension attributes, like the FirstName column. Dimension
attributes provide context to the numeric data stored in related fact tables. They're typically text
columns that are used in analytic queries to filter and group (slice and dice), but not to be
aggregated themselves. Some dimension tables contain few attributes, while others contain many
attributes (as many as it takes to support the query requirements of the dimensional model).

 Tip
 A good way to determine which dimensions and attributes you need is to find the right
people and ask the right questions. Specifically, stay alert for the mention of the word by. For
example, when someone says they need to analyze sales by salesperson, by month, and by
product category, they're telling you that they need dimensions that have those attributes.

If you plan to create a Direct Lake semantic model, you should include all possible columns
required for filtering and grouping as dimension attributes. That's because Direct Lake semantic
models don't support calculated columns.

Foreign keys
The sample dimension table also has a foreign key, which is named SalesRegion_FK . Other
dimension tables can reference a foreign key, and their presence in a dimension table is a special
case. It indicates that the table is related to another dimension table, meaning that it might form
part of a snowflake dimension or it's related to an outrigger dimension.

Fabric Warehouse supports foreign key constraints but they can't be enforced. Therefore, it's
important that your ETL process tests for integrity between related tables when data is loaded.

It's still a good idea to create foreign keys. One good reason to create unenforced foreign keys is
to allow modeling tools, like Power BI Desktop, to automatically detect and create relationships
between tables in the semantic model.

Historical tracking attributes

The sample dimension table also has various historical tracking attributes. Historical tracking
attributes are optional based on your need to track specific changes as they occur in the source
system. They allow storing values to support the primary role of a data warehouse, which is to
describe the past accurately. Specifically, these attributes store historical context as the ETL
process loads new or changed data into the dimension.

For more information, see Manage historical change later in this article.

Audit attributes
The sample dimension table also has various audit attributes. Audit attributes are optional but
recommended. They allow you to track when and how dimension records were created or
modified, and they can include diagnostic or troubleshooting information raised during ETL
processes. For example, you'll want to track who (or what process) updated a row, and when.
Audit attributes can also help diagnose a challenging problem, like when an ETL process stops
unexpectedly. They can also flag dimension members as errors or inferred members.

Dimension table size

Often, the most useful and versatile dimensions in a dimensional model are big, wide dimensions.
They're big in terms of rows (in excess of millions) and wide in terms of the number of dimension
attributes (potentially hundreds). Size isn't so important (although you should design and
optimize for the smallest possible size). What matters is that the dimension supports the required
filtering, grouping, and accurate historical analysis of fact data.

Big dimensions might be sourced from multiple source systems. In this case, dimension
processing needs to combine, merge, deduplicate, and standardize the data; and assign surrogate
keys.

By comparison, some dimensions are tiny. They might represent lookup tables that contain only
several records and attributes. Often these small dimensions store category values related to
transactions in fact tables, and they're implemented as dimensions with surrogate keys to relate
to the fact records.

 Tip

When you have many small dimensions, consider consolidating them into a junk dimension.

Dimension design concepts

This section describes various dimension design concepts.

Denormalization vs. normalization

It's almost always the case that dimension tables should be denormalized. While normalization is
the term used to describe data that's stored in a way that reduces repetitious data,
denormalization is the term used to define where precomputed redundant data exists. Redundant
data exists typically due to the storage of hierarchies (discussed later), meaning that hierarchies
are flattened. For example, a product dimension could store subcategory (and its related
attributes) and category (and its related attributes).
Because dimensions are generally small (when compared to fact tables), the cost of storing
redundant data is almost always outweighed by the improved query performance and usability.

Snowflake dimensions
One exception to denormalization is to design a snowflake dimension. A snowflake dimension is
normalized, and it stores the dimension data across several related tables.

The following diagram depicts a snowflake dimension that comprises three related dimension
tables: Product , Subcategory , and Category .

Consider implementing a snowflake dimension when:

The dimension is extremely large and storage costs outweigh the need for high query
performance. (However, periodically reassess that this still remains the case.)
 You need keys to relate the dimension to higher-grain facts. For example, the sales fact table
stores rows at product level, but the sales target fact table stores rows at subcategory level.
You need to track historical changes at higher levels of granularity.

７ Note

Bear in mind that a hierarchy in a Power BI semantic model can only be based on columns
from a single semantic model table. Therefore, a snowflake dimension should deliver a
denormalized result by using a view that joins the snowflake tables together.

Hierarchies
Commonly, dimension columns produce hierarchies. Hierarchies enable exploring data at distinct
levels of summarization. For example, the initial view of a matrix visual might show yearly sales,
and the report consumer can choose to drill down to reveal quarterly and monthly sales.

There are three ways to store a hierarchy in a dimension. You can use:

Columns from a single, denormalized dimension.

A snowflake dimension, which comprises multiple related tables.
A parent-child (self-referencing) relationship in a dimension.

Hierarchies can be balanced or unbalanced. It's also important to understand that some
hierarchies are ragged.

Balanced hierarchies
Balanced hierarchies are the most common type of hierarchy. A balanced hierarchy has the same
number of levels. A common example of a balanced hierarchy is a calendar hierarchy in a date
dimension that comprises levels for year, quarter, month, and date.

The following diagram depicts a balanced hierarchy of sales regions. It comprises two levels,
which are sales region group and sales region.
Levels of a balanced hierarchy are either based on columns from a single, denormalized
dimension, or from tables that form a snowflake dimension. When based on a single,
denormalized dimension, the columns that represent the higher levels contain redundant data.

For balanced hierarchies, facts always relate to a single level of the hierarchy, which is typically the
lowest level. That way, the facts can be aggregated (rolled up) to the highest level of the
hierarchy. Facts can relate to any level, which is determined by the grain of the fact table. For
example, the sales fact table might be stored at date level, while the sales target fact table might
be stored at quarter level.

Unbalanced hierarchies
Unbalanced hierarchies are a less common type of hierarchy. An unbalanced hierarchy has levels
based on a parent-child relationship. For this reason, the number of levels in an unbalanced
hierarchy is determined by the dimension rows, and not specific dimension table columns.

A common example of an unbalanced hierarchy is an employee hierarchy where each row in an

employee dimension relates to a reporting manager row in the same table. In this case, any
employee can be a manager with reporting employees. Naturally, some branches of the hierarchy
will have more levels than others.

The following diagram depicts an unbalanced hierarchy. It comprises four levels, and each
member in the hierarchy is a salesperson. Salespeople have a different number of ancestors in the
hierarchy according to who they report to.
Other common examples of unbalanced hierarchies include bill of materials, company ownership
models, and general ledger.

For unbalanced hierarchies, facts always relate to the dimension grain. For example, sales facts
relate to different salespeople, who have different reporting structures. The dimension table
would have a surrogate key (named Salesperson_SK ) and a ReportsTo_Salesperson_FK foreign key
column, which references the primary key column. Each salesperson without anyone to manage
isn't necessarily at the lowest level of any branch of the hierarchy. When they're not at the lowest
level, a salesperson might sell products and have reporting salespeople who also sell products. So,
the rollup of fact data must consider the individual salesperson and all their descendants.

Querying parent-child hierarchies can be complex and slow, especially for large dimensions. While
the source system might store relationships as parent-child, we recommend that you naturalize
the hierarchy. In this instance, naturalize means to transform and store the hierarchy levels in the
dimension as columns.

 Tip

If you choose not to naturalize the hierarchy, you can still create a hierarchy based on a
parent-child relationship in a Power BI semantic model. However, this approach isn't
recommended for large dimensions. For more information, see Understanding functions for
parent-child hierarchies in DAX.

Ragged hierarchies
Sometimes a hierarchy is ragged because the parent of a member in the hierarchy exists at a level
that's not immediately above it. In these cases, missing level values repeat the value of the parent.

Consider an example of a balanced geography hierarchy. A ragged hierarchy exists when a

country/region has no states or provinces. For example, New Zealand has neither states nor
provinces. So, when you insert the New Zealand row, you should also store the country/region
value in the StateProvince column.

The following diagram depicts a ragged hierarchy of geographical regions.

Manage historical change
When necessary, historical change can be managed by implementing a slowly changing dimension
(SCD). An SCD maintains historical context as new, or changed data, is loaded into it.

Here are the most common SCD types.

Type 1: Overwrite the existing dimension member.

Type 2: Insert a new time-based versioned dimension member.
Type 3: Track limited history with attributes.

It's possible that a dimension could support both SCD type 1 and SCD type 2 changes.
SCD type 3 isn't commonly used, in part due to the fact that it's difficult to use in a semantic
model. Consider carefully whether an SCD type 2 approach would be a better fit.

 Tip

If you anticipate a rapidly changing dimension, which is a dimension that has an attribute that
changes frequently, consider adding that attribute to the fact table instead. If the attribute is
numeric, like the product price, you can add it as a measure in the fact table. If the attribute
is a text value, you can create a dimension based on all text values and add its dimension key
to the fact table.

SCD type 1
SCD type 1 changes overwrite the existing dimension row because there's no need to keep track
of changes. This SCD type can also be used to correct errors. It's a common type of SCD, and it
should be used for most changing attributes, like customer name, email address, and others.

The following diagram depicts the before and after state of a salesperson dimension member
where their phone number has changed.

This SCD type doesn't preserve historical perspective because the existing row is updated. That
means SCD type 1 changes can result in different higher-level aggregations. For example, if a
salesperson is assigned to a different sales region, an SCD type 1 change would overwrite the
dimension row. The rollup of salespeople historic sales results to region would then produce a
different outcome because it now uses the new current sales region. It's as if that salesperson was
always assigned to the new sales region.

SCD type 2
SCD type 2 changes result in new rows that represent a time-based version of a dimension
member. There's always a current version row, and it reflects the state of the dimension member
in the source system. Historical tracking attributes in the dimension table store values that allow
identifying the current version (current flag is TRUE ) and its validity time period. A surrogate key is
required because there will be duplicate natural keys when multiple versions are stored.

It's a common type of SCD, but it should be reserved for attributes that must preserve historical
perspective.

For example, if a salesperson is assigned to a different sales region, an SCD type 2 change
involves an update operation and an insert operation.

1. The update operation overwrites the current version to set the historical tracking attributes.
Specifically, the end validity column is set to the ETL processing date (or a suitable
timestamp in the source system) and the current flag is set to FALSE .
2. The insert operation adds a new, current version, setting the start validity column to the end
validity column value (used to update the prior version) and the current flag to TRUE .

It's important to understand that the granularity of related fact tables isn't at the salesperson
level, but rather the salesperson version level. The rollup of their historic sales results to region will
produce correct results but there will be two (or more) salesperson member versions to analyze.

The following diagram depicts the before and after state of a salesperson dimension member
where their sales region has changed. Because the organization wants to analyze salespeople
effort by the region they're assigned to, it triggers an SCD type 2 change.
  Tip

When a dimension table supports SCD type 2 changes, you should include a label attribute
that describes the member and the version. Consider an example when the salesperson Lynn
Tsoflias from Adventure Works changes assignment from the Australian sales region to the
United Kingdom sales region. The label attribute for the first version could read "Lynn Tsoflias
(Australia)" and the label attribute for the new, current version could read "Lynn Tsoflias
(United Kingdom)." If helpful, you might include the validity dates in the label too.

You should balance the need for historic accuracy versus usability and efficiency. Try to avoid
having too many SCD type 2 changes on a dimension table because it can result in an
overwhelming number of versions that might make it difficult for analysts to comprehend.

Also, too many versions could indicate that a changing attribute might be better stored in
the fact table. Extending the earlier example, if sales region changes were frequent, the sales
region could be stored as a dimension key in the fact table rather than implementing an SCD
type 2.

Consider the following SCD type 2 historical tracking attributes.

SQL

CREATE TABLE d_Salesperson

(
<...>
 --Historical tracking attributes (SCD type 2)
RecChangeDate_FK INT NOT NULL,
RecValidFromKey INT NOT NULL,
RecValidToKey INT NOT NULL,
RecReason VARCHAR(15) NOT NULL,
RecIsCurrent BIT NOT NULL,

<...>
);

Here are the purposes of the historical tracking attributes.

The RecChangeDate_FK column stores the date when the change came into effect. It allows
you to query when changes took place.
The RecValidFromKey and RecValidToKey columns store the effective dates of validity for the
row. Consider storing the earliest date found in the date dimension for RecValidFromKey to
represent the initial version, and storing 01/01/9999 for the RecValidToKey of the current
versions.
The RecReason column is optional. It allows documenting the reason why the version was
inserted. It could encode which attributes changed, or it could be a code from the source
system that states a particular business reason.
The RecIsCurrent column makes it possible to retrieve current versions only. It's used when
the ETL process looks up dimension keys when loading fact tables.

７ Note

Some source systems don't store historical changes, so it's important that the dimension is
processed regularly to detect changes and implement new versions. That way, you can detect
changes shortly after they occur, and their validity dates will be accurate.

SCD type 3
SCD type 3 changes track limited history with attributes. This approach can be useful when there's
a need to record the last change, or a number of the latest changes.

This SCD type preserves limited historical perspective. It might be useful when only the initial and
current values should be stored. In this instance, interim changes wouldn't be required.
For example, if a salesperson is assigned to a different sales region, an SCD type 3 change
overwrites the dimension row. A column that specifically stores the previous sales region is set as
the previous sales region, and the new sales region is set as the current sales region.

The following diagram depicts the before and after state of a salesperson dimension member
where their sales region has changed. Because the organization wants to determine any previous
sales region assignment, it triggers an SCD type 3 change.

Special dimension members

You might insert rows into a dimension that represent missing, unknown, N/A, or error states. For
example, you might use the following surrogate key values.

ﾉ Expand table

Key value Purpose

0 Missing (not available in the source system)

-1 Unknown (lookup failure during a fact table load)

-2 N/A (not applicable)

-3 Error
Calendar and time
Almost without exception, fact tables store measures at specific points in time. To support analysis
by date (and possibly time), there must be calendar (date and time) dimensions.

It's uncommon that a source system would have calendar dimension data, so it must be
generated in the data warehouse. Typically, it's generated once, and if it's a calendar dimension,
it's extended with future dates when needed.

Date dimension
The date (or calendar) dimension is the most common dimension used for analysis. It stores one
row per date, and it supports the common requirement to filter or group by specific periods of
dates, like years, quarters, or months.

） Important

A date dimension shouldn't include a grain that extends to time of day. If time of day analysis
is required, you should have both a date dimension and a time dimension (described next).
Fact tables that store time of day facts should have two foreign keys, one to each of these
dimensions.

The natural key of the date dimension should use the date data type. The surrogate key should
store the date by using YYYYMMDD format and the int data type. This accepted practice should be
the only exception (alongside the time dimension) when the surrogate key value has meaning and
is human readable. Storing YYYYMMDD as an int data type is not only efficient and sorted
numerically, but it also conforms to the unambiguous International Standards Organization (ISO)
8601 date format.

Here are some common attributes to include in a date dimension.

Year , Quarter , Month , Day

QuarterNumberInYear , MonthNumberInYear – which might be required to sort text labels.

FiscalYear , FiscalQuarter – some corporate accounting schedules start mid-year, so that

the start/end of the calendar year and the fiscal year are different.
FiscalQuarterNumberInYear , FiscalMonthNumberInYear – which might be required to sort text

labels.
 WeekOfYear – there are multiple ways to label the week of year, including an ISO standard

that has either 52 or 53 weeks.

IsHoliday , HolidayText – if your organization operates in multiple geographies, you should

maintain multiple sets of holiday lists that each geography observes as a separate dimension
or naturalized in multiple attributes in the date dimension. Adding a HolidayText attribute
could help identify holidays for reporting.
IsWeekday – similarly, in some geographies, the standard work week isn't Monday to Friday.

For example, the work week is Sunday to Thursday in many Middle Eastern regions, while
other regions employ a four-day or six-day work week.
LastDayOfMonth

RelativeYearOffset , RelativeQuarterOffset , RelativeMonthOffset , RelativeDayOffset –

which might be required to support relative date filtering (for example, previous month).
Current periods use an offset of zero (0); previous periods store offsets of -1, -2, -3...; future
periods store offsets of 1, 2, 3....

As with any dimension, what's important is that it contains attributes that support the known
filtering, grouping, and hierarchy requirements. There might also be attributes that store
translations of labels into other languages.

When the dimension is used to relate to higher-grain facts, the fact table can use the first date of
the date period. For example, a sales target fact table that stores quarterly salespeople targets
would store the first date of the quarter in the date dimension. An alternative approach is to
create key columns in the date table. For example, a quarter key could store the quarter key by
using YYYYQ format and the smallint data type.

The dimension should be populated with the known range of dates used by all fact tables. It
should also include future dates when the data warehouse stores facts about targets, budgets, or
forecasts. As with other dimensions, you might include rows that represent missing, unknown,
N/A, or error situations.

 Tip

Search the internet for "date dimension generator" to find scripts and spreadsheets that
generate date data.

Typically, at the beginning of the next year, the ETL process should extend the date dimension
rows to a specific number of years ahead. When the dimension includes relative offset attributes,
the ETL process must be run daily to update offset attribute values based on the current date
(today).

Time dimension
Sometimes, facts need to be stored at a point in time (as in time of day). In this case, create a time
(or clock) dimension. It could have a grain of minutes (24 x 60 = 1,440 rows) or even seconds (24 x
60 x 60 = 86,400 rows). Other possible grains include half hour or hour.

The natural key of a time dimension should use the time data type. The surrogate key could use
an appropriate format and store values that have meaning and are human readable, for example,
by using the HHMM or HHMMSS format.

Here are some common attributes to include in a time dimension.

Hour , HalfHour , QuarterHour , Minute

Time period labels (morning, afternoon, evening, night)

Work shift names
Peak or off-peak flags

Conformed dimensions
Some dimensions might be conformed dimensions. Conformed dimensions relate to many fact
tables, and so they're shared by multiple stars in a dimensional model. They deliver consistency
and can help you to reduce ongoing development and maintenance.

For example, it's typical that fact tables store at least one date dimension key (because activity is
almost always recorded by date and/or time). For that reason, a date dimension is a common
conformed dimension. You should therefore ensure that your date dimension includes attributes
relevant for the analysis of all fact tables.

The following diagram shows the Sales fact table and the Inventory fact table. Each fact table
relates to the Date dimension and Product dimension, which are conformed dimensions.
As another example, your employee and users could be the same set of people. In this case, it
might make sense to combine the attributes of each entity to produce one conformed dimension.

Role-playing dimensions
When a dimension is referenced multiple times in a fact table, it's known as a role-playing
dimension.

For example, when a sales fact table has order date, ship date, and delivery date dimension keys,
the date dimension relates in three ways. Each way represents a distinct role, yet there's only one
physical date dimension.

The following diagram depicts a Flight fact table. The Airport dimension is a role-playing
dimension because it's related twice to the fact table as the Departure Airport dimension and the
Arrival Airport dimension.
Junk dimensions
A junk dimension is useful when there are many independent dimensions, especially when they
comprise a few attributes (perhaps one), and when these attributes have low cardinality (few
values). The objective of a junk dimension is to consolidate many small dimensions into a single
dimension. This design approach can reduce the number of dimensions, and decrease the number
of fact table keys and thus fact table storage size. They also help to reduce Data pane clutter
because they present fewer tables to users.

A junk dimension table typically stores the Cartesian product of all dimension attribute values,
with a surrogate key attribute.
Good candidates include flags and indicators, order status, and customer demographic states
(gender, age group, and others).

The following diagram depicts a junk dimension named Sales Status that combines order status
values and delivery status values.

Degenerate dimensions
A degenerate dimension can occur when the dimension is at the same grain as the related facts. A
common example of a degenerate dimension is a sales order number dimension that relates to a
sales fact table. Typically, the invoice number is a single, non-hierarchical attribute in the fact
table. So, it's an accepted practice not to copy this data to create a separate dimension table.

The following diagram depicts a Sales Order dimension that's a degenerate dimension based on
the SalesOrderNumber column in a sales fact table. This dimension is implemented as a view that
retrieves the distinct sales order number values.
  Tip

It's possible to create a view in a Fabric Warehouse that presents the degenerate dimension
as a dimension for querying purposes.

From a Power BI semantic modeling perspective, a degenerate dimension can be created as a

separate table by using Power Query. That way, the semantic model conforms to the best practice
that fields used to filter or group are sourced from dimension tables, and fields used to
summarize facts are sourced from fact tables.

Outrigger dimensions
When a dimension table relates to other dimension tables, it's known as an outrigger dimension.
An outrigger dimension can help to conform and reuse definitions in the dimensional model.

For example, you could create a geography dimension that stores geographic locations for every
postal code. That dimension could then be referenced by your customer dimension and
salesperson dimension, which would store the surrogate key of the geography dimension. That
way, customers and salespeople could then be analyzed by using consistent geographic locations.

The following diagram depicts a Geography dimension that's an outrigger dimension. It doesn't
relate directly to the Sales fact table. Instead, it's related indirectly via the Customer dimension
and the Salesperson dimension.

Consider that the date dimension can be used as an outrigger dimension when other dimension
table attributes store dates. For example, the birth date in a customer dimension could be stored
by using the surrogate key of the date dimension table.

Multivalued dimensions
When a dimension attribute must store multiple values, you need to design a multivalued
dimension. You implement a multivalued dimension by creating a bridge table (sometimes called a
join table). A bridge table stores a many-to-many relationship between entities.

For example, consider there's a salesperson dimension, and that each salesperson is assigned to
one or possibly more sales regions. In this case, it makes sense to create a sales region dimension.
That dimension stores each sales region only once. A separate table, known as the bridge table,
stores a row for each salesperson and sales region relationship. Physically, there's a one-to-many
relationship from the salesperson dimension to the bridge table, and another one-to-many
relationship from the sales region dimension to the bridge table. Logically, there's a many-to-
many relationship between salespeople and sales regions.

In the following diagram, the Account dimension table relates to the Transaction fact table.
Because customers can have multiple accounts and accounts can have multiple customers, the
Customer dimension table is related via the Customer Account bridge table.

Related content
In the next article in this series, learn about guidance and design best practices for fact tables.