5 votes

FK Issue with Fact Table

I see a tweet as an event happening, so I would model it as a new fact table FactTweet. More specifically as a factless fact. The dimensions for FactTweet would be DimDate, DimCar (if you can relate a ...
JeromeFr's user avatar
  • 289
4 votes
Accepted

What is the difference between bridge table and helper table in data warehouse's context?

Bridge tables are the official name according to Dimensional Modeling as defined by the Kimball methodology. Helper tables as far as I know have been used in many (often incorrect) contexts, one of ...
Tom V's user avatar
  • 15.7k
3 votes

Dimensional Modeling of a Loan Approval Process and Fact Grain(s)

Dimensions that are 1-1 with facts are not unheard of. The problem with such dimensions is their size, which won't get any smaller just because you introduce a fact table that's even more detailed. ...
Nickolay's user avatar
  • 172
3 votes

If a DW fact table is not uniquely identified by all dimensions, what problems?

I don't think you will run into a lot of problems when querying your data warehouse except for the one you already stated (cross fact queries) although if you are aware of how your design is done and ...
Tom V's user avatar
  • 15.7k
2 votes

What is the difference between bridge table and helper table in data warehouse's context?

From the definitions I've seen, helper tables and bridge tables are the same thing. "A bridge table sits between a fact table and a dimension table and is used to resolve many-to-many relationships ...
Nate's user avatar
  • 121
2 votes

Problem with Processing Dimensions with Multiple Facts

You need to process D1 and D5 in the same transaction. Then both will complete processing before measure groups are processed. Make sure you mark Transaction=true (the default unless you explicitly ...
GregGalloway's user avatar
  • 1,385
2 votes

Database design to record occurences in tv show

I think given the requirements and that at some point you may want additional information that wasn't listed here, I would go with a fully normalized approach. 3 Tables: Guests, Episodes, ...
Shooter McGavin's user avatar
2 votes
Accepted

How to handle NULL Dates in an "Accumulating fact table"

You say "null should be avoided in a foreign key column," but are these dates really FKs? Most likely, these dates are just attributes of an order, and if the dates are unknown (and the ...
AMtwo's user avatar
  • 16.1k
1 vote

Replace primary key with unique constraint and other clustered index to improve query performance without doubling table size

As mentioned in the comments by LoztInSpace, your primary key doesn't need to also be the clustered index. That is just the default (since most times it makes sense). But in a data warehouse ...
J.D.'s user avatar
  • 37.5k
1 vote

How to deal with fact table data that needs to be version controlled?

As is often the case; a little more googling gave me an answer. Just in case the link ever breaks: So the way the solution works is that the fact table changes are simply treated like SCD type 2 ...
Jossy's user avatar
  • 83
1 vote
Accepted

Type 2 Dimension for a fact measure

Honestly it really just depends on your use cases, but for me I would likely just store all 10 columns in the same table and call it a day (unless they were very unrelated to each other, then I might ...
J.D.'s user avatar
  • 37.5k
1 vote
Accepted

Deciding what values should be used in a data warehouse dimension?

If you have an attribute with the same granularity of the Fact table (i.e.: "TransactionID") and it is usually used to filter one single Fact table, you don't have to create a separate table (aka ...
Evandro's user avatar
  • 868
1 vote
Accepted

SSAS Cube Only Displays Total Values

The Customer dimension is joined to the measure group at a non-key granularity. If the Customer Name attribute isn't related to the attribute you join on then data repeats in reports. You need to do ...
GregGalloway's user avatar
  • 1,385
1 vote

Database design to record occurences in tv show

The following table structure is what I would use. It covers all the information you're indicating you capture, and allows scalability if your shows/episodes grow, without having to make many ...
SQLDevDBA's user avatar
  • 2,254
1 vote

Database design to record occurences in tv show

It is a simple many to many table episodeID guestID The episode table should have a date The guest table should have a sex
paparazzo's user avatar
  • 5,043
1 vote

Should a Fact table contain a column with a single unique value?

If the intention here is to provide a fixed alternate table name (rather than record a source, which may vary), one option would be to implement a non persisted virtual column (calculated column in ...
Paul Holmes's user avatar
1 vote

Should a Fact table contain a column with a single unique value?

What I recommend is that you have a fact_source table: CREATE TABLE fact_source ( fact_source_id INTEGER, -- auto-increment. fact_source_name VARCHAR (50) ); Use your own RDBMS's (you didn't ...
Vérace's user avatar
  • 29.9k
1 vote
Accepted

Database design to record occurences in tv show

This is what I recommend for your requirements
Joe Borysko's user avatar
1 vote

Advice on Measures that have properties on their own

It sounds like you want to put aggregation rules (based on anything, doesn't matter) in the database. Nothing particularly wrong with that, unless you're planning to use it to generate SQL ...
James K. Lowden's user avatar

Only top scored, non community-wiki answers of a minimum length are eligible