Degenerate Dimensions

two facts that relate via degenerate dimension

Hi, I have a order line fact which look like this: Order Line Fact ------------- Order Line Key (SK) Order Line number (DD) Order Number (DD) Some measure (fact) Now some time later I have another fact which would reference the Order Number

Monster Dimensions

My customer list is huge (about 70 millionish). We currently have a 60 million row dimension (CUSTOMER) that holds most of our existing customers, and this existing large DIM is currently performing fine for us. Now my clients want to type 2 two

use of degenerate dimension to physically join two logically related fact tables

I am looking for a sanity check on a design decision. Here is the scenario: The business domain is insurance, specifically life and annuity. I have two fact tables - factPolicyTransaction and factCommissionTransaction. Policy transactions,

many to many relationship between dimension level

I need help to design dimension model. Detail of Dimension are as following: Dimension : Student, School Fact : Grade 1. Class_Year 2. School 3. Area 4. City Analysis Requirement are to drill up /down by above given hierarchy there is : M:1

Joining facts through conforming dimensions

I've seen some overlap in some posts but I don't want to hijack someone elses thread to attempt to get clarification for my scenario. I also didn't want to simply make the title "Joining Fact Tables" because I know the immediate response would b

Sparse dimensions, how to handle?

I've purchased the book "The Microsoft Data Warehouse Toolkit" and have reviewed it in order to build out a data warehouse solution I am currently designing. I am stuck in a spot that I don't seem to find any examples of , or am not abl

How to manage Conformed dimensions

Hi, If I'm implementing data mart by data mart, I build a dimension for the first data mart. After a few months, I realize I can use that dimension for the second data mart as a conformed dimension. But it needs additional columns. How do you manage this

Flexiblity To Add Attributes To A Dimension And Not Process The Whole Cube/s

Hello, We are in the process of designing a DW for Games and have run into a business problem : Business users want to add attributes to a dimension and decide its level in the hierarchy on the fly. The new attributes should be availabe in reports

Supplier Dimension to include Customers & Employees

We are in the process of finalising Dimensions /Facts to be used in Datawarehouse. Already finalised separate dimensions (eg Customer,Supplier,Employee) to handle requirements of Sales,Purchace and Human resourses. During designing Accounts Payable Fact

Cube Processing for Dimension Schema changes

Hi, I had a general question about how cube processing works. If my dimension schema changes (an addition of a property), will I have to do a full reprocess of all cube partitions for which that dimension was member of? Or do I only need to

Dimensions - To Create Based on Type or Role ?

I'm trying to lay down some guidelines for creating new dimensions in an existing shop. I have a mix of dimensions that are type-based and role-based. Type-based are those created because an entity (think Party) has many types (individual,

Linking or Merging Similar dimensions from Different Source Systems

We've got a situation with the DW we're building where we have 2 seperate systems that we are wanting to bring the data together for cross analysis 1) The first system is the main operational system ie a contact management application that records

KPI Goals and Percentages as Dimensions or Store as Facts?

We are using PPS Monitoring for our Dashboards and we are creating our KPIs within PPS and SSAS. Our client would like to create a dimension with these KPI goals and percentages for each goal per department and measures or add to the fact table. Now