It’s essentially a performance improvement feature that helps better optimize data models. In this scenario, secondary dimensions are outrigger dimensions. Outrigger dimensions sometimes include a reference to another dimension table. Junk dimensions are also created to manage foreign keys made by quickly changing dimensions. Depending on the complexity, a fact table may have one or more junk dimensions. Most often, the values of these attributes fall under simple (yes/no (or) true/false) indicators. They often don’t logically belong to any specific dimension. Junk dimensions form a collection of random transactional codes, text attributes, or flags. You can model these relationships with outrigger dimensions. However, as the invoice number is a standalone attribute with no attributes associated with it, the invoice number can be critical to keeping track of product quantities.ĭimension-to-dimension table joins can reference other dimensions. For example, product IDs come from a product dimension table. We use degenerate dimensions to collect snapshots of a fact table. As it’s derived from a fact table, it doesn’t have its own dimension. Various tables will use the same table across the fact table to create different reports.ĭegenerate dimensions don’t have corresponding dimensions. This approach helps create consistency as we can maintain the same across fact tables. Attributes such as the month, week, day, or even year communicate the same information across any number of facts. A date dimension is an excellent example of a conformed dimension. You can use this dimension in more than a one-star schema or Datamart. They describe different objects and are denormalized because of one-to-many relationships.Įxamples of dimension include the following:Ĭonformed dimensions are the facts that it’s related to. A website dimension consists of the website’s name and URL attributes. For example, a customer’s dimension attributes usually include their first and last name, gender, birth date, occupation, and so on. What Are Dimensions in Data Warehousing?ĭimensions are companions to facts and are attributes of facts like the date of a sale. Non-additive describes the storage of basic units of measurement of business processes-for example, phone calls, orders, and sales. Semi-additive describes what measures can be added to some dimensions but not with others. This is considered a foreign key to the dimension table.Īdditive describes the measures we must add to all dimensions. In this scenario, a composite primary key contains each attribute of a primary key. Facts form foreign key relationships with different dimension tables. You can store this information in fact tables at the lowest level of granularity. The amount sold is a fact measure or a key performance indicator (KPI). These include header numbers, order numbers, ticket numbers, transaction numbers, transaction currency, etc. They both store the exact measure of resources and details about the resource and task.Ī fact in data warehousing describes quantitative transactional data like measurements, metrics, or the values ready for analysis. They inform us about things like the number of resources used for a particular task. In data warehousing, facts and dimensions are standard terms.
0 Comments
Leave a Reply. |