star-schema

Data Warehousing - Star Schema vs Flat Table

我们两清 提交于 2021-02-17 18:58:45
问题 I'm trying to design a Data Warehouse for a single store of commonly required data ranging from finance systems, project scheduling systems and a myriad of scientific systems. I.e. many different data marts. I have been reading up on Data Warehousing and popular methods such as Star Schemas and Kimball methods etc but one question I cannot find answer to is: Why is it better to design your DW Data Mart as a star schema rather than a single flat table? Surely having no joins between facts and

SCD 1 dimension without surrogate key

旧城冷巷雨未停 提交于 2021-02-11 14:49:12
问题 This reference to Kimball group state that all dimensions should have surrogate keys except some very predictable one like date diemnsion. I have exactly the same case as described at SCD Type 1 Wiki page: Technically, the surrogate key is not necessary, since the row will be unique by the natural key (Supplier_Code). Data are loaded from operational system without surrogate key, while I calculating surrogate key in ETL based on single and unique xxx_code column. SCD Type 1, full load. Are

Star-Schema Design [closed]

别说谁变了你拦得住时间么 提交于 2020-01-09 04:01:05
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 3 years ago . Is a Star-Schema design essential to a data warehouse? Or can you do data warehousing with another design pattern? 回答1: Using star schemas for a data warehouse system gets you several benefits and in most cases it is appropriate to use them for the top layer. You may also

Creating Relationships while avoiding ambiguities

丶灬走出姿态 提交于 2020-01-07 08:21:04
问题 I have a flat table like this, R# Cat SWN CWN CompBy ReqBy Department 1 A 1 1 Team A Team B Department 1 2 A 1 3 Team A Team B Department 1 3 B 1 3 Team A Team B Department 1 4 B 2 3 Team A Team C Department 1 5 B 2 3 Team D Team C Department 2 6 C 2 2 Team D Team C Department 2 R# indicates the RequestNumber, Cat# indicates the Category, SWN indicates the Submitted Week Number, CWN indicates the Completed Week Number, CompBy indicates Completed By, ReqBy Indicates Requested By, Department

Star schema [fact 1:n dimension]…how?

蹲街弑〆低调 提交于 2019-12-30 10:00:47
问题 I am a newcomer to data warehouses and have what I hope is an easy question about building a star schema: If I have a fact table where a fact record naturally has a one-to-many relationship with a single dimension, how can a star schema be modeled to support this? For example: Fact Table: Point of Sale entry (the measurement is DollarAmount) Dimension Table: Promotions (these are sales promotions in effect when a sale was made) The situation is that I want a single Point Of Sale entry to be

How can a multi-valued dimension be expressed in a star-schema given that it has 1-to-many relationship [Dim 1: many Fact]?

送分小仙女□ 提交于 2019-12-25 04:11:58
问题 I am new to Data Warehouse practices and in the context of an academic exercise I would like to create a star-schema using a dataset in a chosen area of interest. So, my classmate and I chose a dataset of car accidents in a country during a year. The problem is that in a lot of cases if not the most, there are more than one cars involved. So if I choose to have incidents of "accidents" as the Fact Table with "Driver", "Car", "Casualties", "Location", "Contitions" etc as Dimentions, how can

Star Schema database for NBA/Basketball statistics

拜拜、爱过 提交于 2019-12-24 19:04:36
问题 I want to design a database of basketball players and their stats. I hear star schema databases are the best for these type of tasks. If I'm not mistaken, star schema has dim and fact tables. I plan to load scores/stats into the fact tables and teams,year, coach, conference, etc in the dim tables. Is this an acceptable approach? Im a noobie at database design so please help if you can or give me your thoughts on my process. Thanks! 来源: https://stackoverflow.com/questions/24524919/star-schema

star schema design - one column dimensions

时光毁灭记忆、已成空白 提交于 2019-12-23 03:19:27
问题 I`m new to data warehousing, but I think my question can be relatively easy answered. I built a star schema, with a dimension table 'product'. This table has a column 'PropertyName' and a column 'PropertyValue'. The dimension therefore looks a little like this: surrogate_key | natural_key (productID) | PropertyName | PropertyValue | ... 1 5 Size 20 ... 2 5 Color red 3 6 Size 20 4 6 Material wood and so on. In my fact table I always use the surrogate keys of the dimensions. Cause of the

Nulls in dimension table for numeric attributes

淺唱寂寞╮ 提交于 2019-12-22 13:58:58
问题 What is the best way to handle missing values in a dimension table? In the case of a textual column, it is easy to write "NA: Missing," but what should be done for numeric columns where it is important to retain the specific values . Note: I do not want a solution that uses banded values (e.g., textual columns for "0-50", "50-100", "NA: Missing"). For instance, a customer dimension may have a year-of-birth. How should missing years of birth be handled? Leave it null? Add in an arbitrary

Star schema, normalized dimensions, denormalized hierarchy level keys

我只是一个虾纸丫 提交于 2019-12-17 23:43:41
问题 Given the following star schema tables. fact, two dimensions, two measures. # geog_abb time_date amount value #1: AL 2013-03-26 55.57 9113.3898 #2: CO 2011-06-28 19.25 9846.6468 #3: MI 2012-05-15 94.87 4762.5398 #4: SC 2013-01-22 29.84 649.7681 #5: ND 2014-12-03 37.05 6419.0224 geography dimension, single hierarchy, 3 levels in hierarchy. # geog_abb geog_name geog_division_name geog_region_name #1: AK Alaska Pacific West #2: AL Alabama East South Central South #3: AR Arkansas West South