star schema क्या है, और आप कब किसी dimension को snowflake करेंगे?

star schema में एक fact table होती है और उसके चारों तरफ denormalized dimension tables, इसलिए ज्यादातर queries को हर dimension पर एक ही join चाहिए। snowflaking किसी dimension को sub tables में normalize करती है, जिससे storage बचता है और साझा attributes एक जगह आ जाते हैं, लेकिन joins बढ़ जाते हैं। columnar warehouse पर storage सस्ता है और joins duplication से महंगे पड़ते हैं, इसलिए star ही डिफॉल्ट है। किसी dimension को snowflake तब करें जब वह सचमुच बड़ी, hierarchical, या कई marts में साझा हो।

star एक तय grain वाली fact table है जिससे denormalized dimensions लटकी होती हैं, इसलिए analyst हर dimension पर एक join लिखता है और उसे पढ़ने लायक column names मिलते हैं। मैं यही डिफॉल्ट रखता हूं, क्योंकि columnar warehouse पर बीस लाख rows में देश का नाम दोहराना compress होकर लगभग कुछ भी नहीं रह जाता, और छोटी dimension वैसे भी broadcast हो जाती है। snowflaking तब समझ आती है जब dimension सचमुच बड़ी और hierarchical हो, जैसे एक product dimension जिसमें category tree हो और कई marts को वह साझा चाहिए, क्योंकि उस hierarchy को एक जगह रखना उसे पांच जगह दोहराने से बेहतर है। इन दोनों से पहले मैं जो बात उठाऊंगा वह grain है। यह तय करना कि fact table में एक row हर order line की है, न कि हर order की, आगे का सब कुछ तय कर देता है, और यहां गलती होने पर वही क्लासिक double counted revenue बग पैदा होता है। मुझे एक mart इसलिए दोबारा बनाना पड़ा था क्योंकि grain मिला जुला था, और यह किसी भी normalization बहस से कहीं ज्यादा महंगा पड़ता है।