fact-table | 易学教程

Difference between Fact table and Dimension table?

阅读更多关于 Difference between Fact table and Dimension table?

问题 When reading a book for business objects, I came across the term- fact table and dimension table. I am trying to understand what is the different between Dimension table and Fact table? I read couple of articles on the internet but I was not able to understand clearly.. Any simple example will help me to understand better? 回答1: This is to answer the part: I was trying to understand whether dimension tables can be fact table as well or not? The short answer (INMO) is No.That is because the 2

Design logical model of Datawarehouse, Fact Tables and Dimensions Table

阅读更多关于 Design logical model of Datawarehouse, Fact Tables and Dimensions Table

问题 Hi i'm newbie in Datawarehousing,For homework ask me realize the logical design, physical and implementation.How would you model this in a Data Warehouse: i wish design the Data Warehouse which give the answers of statistics relating to a baseball league For players in offensive: •How many times has a batter to bat. •How many runs scored is. •How many hits,doubles hit and triples hits. •How many homeruns did. •many RBI. •many base on balls in Defensive: ▪ How many outs, double play takes ▪

Why primary key is (not) required on fact table in dimensional modelling?

阅读更多关于 Why primary key is (not) required on fact table in dimensional modelling?

问题 I have heard a few references that pk is not required on fact table. I believe every single table should have a pk. How could a person understand a row in a fact table if there is no pk and 10+ foreign keys. 回答1: Primary Key is there ... but Enforcing the primary key constraint in database level is not required. If you think about this, technically a unique key or primary key is a key that uniquely defines the characteristics of each row. And it can be composed of more than one attributes of

One or multiple fact tables?

阅读更多关于 One or multiple fact tables?

问题 I am trying to build a data mart. I have lot of dimensions, and couple of measures - facts. Every measure is connected to all dimensions in term of business. There is the standard approach that there will be one big fact table with all measures. But I have an idea: What If I have separate fact tables for each measure? What it will do with database performance, solution extensibility etc? EDIT::: there will be huge solution based on olap cubes in really complex corporate environment. So the

How to create history fact table?

阅读更多关于 How to create history fact table?

问题 I have some entities in my Data Warehouse: Person - with attributes personId, dateFrom, dateTo, and others those can be changed, e.g. last name, birth date and so on - slowly changing dimension Document - documentId, number, type Address - addressId, city, street, house, flat The relations between (Person and Document) is One-To-Many and (Person and Address) is Many-To-Many. My target is to create history fact table that can answer us following questions: What persons with what documents

Why primary key is (not) required on fact table in dimensional modelling?

阅读更多关于 Why primary key is (not) required on fact table in dimensional modelling?

I have heard a few references that pk is not required on fact table. I believe every single table should have a pk. How could a person understand a row in a fact table if there is no pk and 10+ foreign keys. Primary Key is there ... but Enforcing the primary key constraint in database level is not required. If you think about this, technically a unique key or primary key is a key that uniquely defines the characteristics of each row. And it can be composed of more than one attributes of that entity. Now in the case of a Fact table, foreign keys flowing-in from the other dimension tables

Warehouse: Store (and count) non-fact records?

阅读更多关于 Warehouse: Store (and count) non-fact records?

How to store records that don't contain any fact? For example, let's say that a shop wants to count how many people have entered inside a store (and that they take info on every person that goes inside the shop). In warehouse, I guess there would be dimension table "Person" with different attributes, but how would fact table look like? Would it contain only foreign keys? As you described it, that would be just a fact table. Actually, there is name for this -- factless fact table ; fact table without any measures. It is quite common for recoding events. Essentially anything that records: who,

Design of a data warehouse with more than one fact tables

阅读更多关于 Design of a data warehouse with more than one fact tables

问题 I'm new to data warehousing. First, I want to precise than my copy of The Data Warehouse Toolkit is on it's way to my mailbox (snail mail :P). But I'm already studying all this stuff with what I find on the net. What I don't find on the net, however, is what to do when you seems to have more than one fact in a DW. In my case (insurance), I have refunds that occur on a non regular basis. One client can have none for 3 months and then ten in the same months. On the other hands, I have

Warehouse: Store (and count) non-fact records?

阅读更多关于 Warehouse: Store (and count) non-fact records?

问题 How to store records that don't contain any fact? For example, let's say that a shop wants to count how many people have entered inside a store (and that they take info on every person that goes inside the shop). In warehouse, I guess there would be dimension table "Person" with different attributes, but how would fact table look like? Would it contain only foreign keys? 回答1: As you described it, that would be just a fact table. Actually, there is name for this -- factless fact table ; fact