New answers tagged

0

If you want to capture historical changes on the three tables you need change hierarchies tables (i.e. [Area], [Region]) into sub-dimensions of the dimension table (i.e. [Location]) by adding an effective_date and expire_date (in the three tables )and you can track changes in dimension and sub-dimension attributes in order to report historical data using ...


0

You are correct. The reason for this is the current situation, in which the transactional database is usually separate from the analytical database, and therefore isn't up to date. While up to date technologies like Data Vault could mean that you would use the same database for transaction and analytics, a situation in which you need to aggregate data from ...


5

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 tweet to a car), DimAuthor and I would probably keep URL and Description as degenerated dimensions. You could potentially add the sentiment of the tweet as ...


2

I suspect the advice is predicated on the likely utility of partitioning a dimension table. In a data warehouse, fact tables are good example of the adage, big data is medium data, plus time. Dimension tables don't have time (not really), and as a rule don't have useful partitioning properties. Yours seems like a good example. Why is Accounts ...


0

First in this case I suggest you to adopt a star schema. the transaction_data table obviously will be you reference to construct your fact table because it contains 'measures' like quantity,sales_value and other numeric attributes , the fact table also will contain substitution-keys of dimensions tables like Time, Product, Customer,demographic, etc.


1

The short answer is no, MySQL does not have that 'feature'. The long answer (and opinion)... Perhaps 1% of tables are partitioned. Perhaps 1% of partitioned tables could use that feature. Now imagine the effort to implement, test, and deploy such an obscure feature. Oracle has had several decades to incorporate little-used features like that. MySQL is ...


0

For date key you might prefer a number. So for April 7th 2016 201604 (Or 20160407 in case of extended requirements) might be best for your date. I don't think that in a DW you need an IDENTITY column for a primary key; After all, you're more aggregating then asking to see a specific value. What I do is make sure the index avoids duplication of values: for ...



Top 50 recent answers are included