Power BI में डेटा मॉडलिंग ट्यूटोरियल

बेहतर प्रदर्शन और ज़रूरत के अनुसार स्केलिंग के लिए अनुकूलित Power BI रिपोर्ट्स बनाते समय अच्छी डेटा मॉडलिंग प्रथाएँ अत्यंत महत्वपूर्ण होती हैं।

यह ट्यूटोरियल Microsoft द्वारा प्रदान किए गए एक सैंपल डेटासेट का उपयोग करता है, जिसे इस लेख में चर्चा की जाने वाली डेटा मॉडलिंग सर्वोत्तम प्रथाओं को दर्शाने के लिए अनुकूलित किया गया है। आप डेटासेट यहाँ से डाउनलोड कर सकते हैं।

डेटा मॉडलिंग क्या है?

डेटा मॉडलिंग वह प्रक्रिया है जिसमें डेटा संरचनाओं के बीच संबंधों के दृश्य निरूपण बनाए जाते हैं, साथ ही उन संरचनाओं में निहित व्यक्तिगत विशेषताओं के बारे में जानकारी भी शामिल होती है।

सामान्य रूप से डेटा मॉडलिंग की बात करें तो सबसे अधिक सुना जाने वाला शब्द है स्टार स्कीमा। यह डेटा वेयरहाउस और रिलेशनल डेटाबेस डिज़ाइन करने का व्यापक रूप से अपनाया गया तरीका है और Power BI में भी यही तरीका अपनाने की सिफारिश की जाती है। 

स्टार स्कीमा उपयोग करने के दो मुख्य लाभ हैं:

• उपयोगिता: स्टार स्कीमा आपके डेटा मॉडल को अधिक साफ़-सुथरा और सुव्यवस्थित बनाता है, और आपकी रिपोर्ट का उपयोग करना आसान हो जाता है।
• प्रदर्शन: स्टार स्कीमा आपकी रिपोर्ट को बहुत बड़े डेटा वॉल्यूम तक आसानी से स्केल करने देता है। DAX मीज़र तेज़ी से कैलकुलेट होते हैं और Power BI रिपोर्ट का रिफ्रेश भी समग्र रूप से तेज़ होता है।

स्टार स्कीमा कैसे काम करता है?

स्टार स्कीमा एक केंद्रीय फैक्ट टेबल से बना होता है, जिससे कई डाइमेंशन टेबल्स शाखाओं की तरह निकलती हैं—दिखने में यह एक सितारे जैसा लगता है। आदर्श रूप से, किसी डेटा मॉडल में केवल एक फैक्ट टेबल रखना अच्छी प्रथा मानी जाती है। हालाँकि, Power BI में एक से अधिक फैक्ट टेबल्स शामिल करना संभव है।

Power BI स्टार स्कीमा। चित्र: लेखक

एक फैक्ट टेबल, सारांशित और एग्रीगेट की जा सकने वाली वैल्यूज़ के साथ-साथ एक या अधिक कीज़ से मिलकर बनी होती है जो डाइमेंशन टेबल्स से जुड़ती हैं। की का उद्देश्य तालिकाओं के बीच कनेक्शन बनाना है। यदि आपके डेटा मॉडल जटिल हैं या डेटा का आयतन बड़ा है, तो यह बेहतर होता है कि कीज़ टेक्स्ट स्ट्रिंग्स के बजाय संख्यात्मक मान हों, क्योंकि इससे मॉडल के प्रदर्शन में सुधार हो सकता है।

फैक्ट टेबल्स बहुत संकरी होनी चाहिए और उनमें यथासंभव कम कॉलम होने चाहिए। ऐसे कोई भी कॉलम जो डेटासेट की विशेषताओं का वर्णन करते हैं, जैसे Product Name या Product Category, उन्हें (यदि डेटा वेयरहाउस में पहले से अलग न हों) फैक्ट टेबल से अलग कर उनकी संबंधित डाइमेंशन टेबल्स में रखा जाना चाहिए। इस प्रक्रिया को डेटा का नॉर्मलाइज़ेशन कहा जाता है और इसका लक्ष्य दोहराव से बचना होता है।

डाइमेंशन टेबल्स डेटासेट की विशेषताओं का वर्णन करती हैं, जहाँ विशेषताओं को तार्किक रूप से अलग-अलग टेबल्स में समूहित किया जाता है ताकि एक ही टेबल फूले न और रिलेशनशिप बनाना कठिन न हो। डाइमेंशन टेबल्स में उन विशेषताओं के लिए अद्वितीय मान होने चाहिए जिनका वे वर्णन कर रही हैं, और उनके कॉलम Power BI रिपोर्ट में डेटा को फ़िल्टर या समूहित करने के लिए ज़िम्मेदार होंगे। 

स्टार स्कीमा का एक विस्तार स्नोफ्लेक स्कीमा है। इस तरीके में, यदि किसी विशेषता की और श्रेणियाँ या उप-श्रेणियाँ हैं, तो डाइमेंशन टेबल्स को और विभाजित किया जाता है। हमारे मामले में, हमारे पास एक Products टेबल है जिसमें Product ID, Product Name और Product Category शामिल हैं। स्नोफ्लेक स्कीमा में यह Products टेबल केवल Product ID और Product Name रखेगी, जबकि Product Category को आगे अलग कर उसकी अपनी टेबल में रखा जाएगा जिसमें Product Category ID और Product Category होंगे।

Power BI स्नोफ्लेक स्कीमा। चित्र: लेखक

हालाँकि, स्नोफ्लेक स्कीमा का उपयोग अनावश्यक रूप से आपके डेटा मॉडल की जटिलता बढ़ा सकता है; ये अतिरिक्त टेबल्स प्रदर्शन घटा सकती हैं और रिलेशनशिप बनाना कठिन और भ्रमित कर सकती हैं।

Power BI में रिलेशनशिप कैसे बनाएँ

Power BI में रिलेशनशिप बनाने के दो तरीके हैं:

1. एक टेबल से एक फ़ील्ड चुनें और जिस दूसरी टेबल के फ़ील्ड से रिलेशनशिप बनानी है, उस पर खींचकर छोड़ दें। 
2. रिबन से Manage Relationships चुनें और “New” चुनें ताकि उसी विंडो का उपयोग करके रिलेशनशिप जोड़ सकें जिसके बारे में हम आगे चर्चा करेंगे (बस यह रिक्त से शुरू होगी)।

डिफ़ॉल्ट रूप से, Power BI टेबल्स के बीच रिलेशनशिप का अनुमान लगाने की कोशिश करेगा; यह हमेशा सही नहीं होता, इसलिए आप सेटिंग्स में इस फ़ीचर को बंद करना चाह सकते हैं या स्वचालित रूप से बनी रिलेशनशिप्स को हटा सकते हैं। रिलेशनशिप संपादित करने के लिए, उनके बीच की कनेक्टिंग लाइन पर राइट-क्लिक करें और “Properties” चुनें। 

इस विंडो में रिलेशनशिप परिभाषित करते समय चुनने के लिए 2 महत्वपूर्ण विकल्प होते हैं: कार्डिनैलिटी और क्रॉस फ़िल्टर दिशा। इन विकल्पों में से प्रत्येक की पसंद का परिणामी रिपोर्ट पर बड़ा प्रभाव हो सकता है, इसलिए सावधानी से चुनें। आइए इन विकल्पों को अलग-अलग समझें।

Power BI में रिलेशनशिप बनाना। चित्र: लेखक

कार्डिनैलिटी

कार्डिनैलिटी के 4 विकल्प हैं: many-to-one, one-to-one, one-to-many, या many-to-many। 

रिलेशनशिप बनाते समय यह सिफारिश की जाती है कि जुड़ने वाला फ़ील्ड कम-से-कम एक टेबल में अद्वितीय मान रखता हो। इससे आप अपने डेटा मॉडल में one-to-many या many-to-one विकल्पों का उपयोग कर सकते हैं। 

हमारे डेटा में, Financials टेबल और Products टेबल के बीच Product ID फ़ील्ड के माध्यम से रिलेशनशिप है। Products टेबल में Product फ़ील्ड के मान अद्वितीय हैं (प्रत्येक उत्पाद केवल एक बार टेबल में आता है)। हालाँकि, Financials टेबल में प्रत्येक उत्पाद तिथि, देश, सेगमेंट आदि के अनुसार कई बार दिखाई दे सकता है।

many-to-many विकल्प सबसे समस्याग्रस्त होता है, और यद्यपि यह जटिल मॉडलों में बहुत उपयोगी हो सकता है, इसे केवल तभी चुनना चाहिए जब आप इस रिलेशनशिप के निहितार्थों को पूरी तरह समझते हों।

यह दिखाने के लिए कि many-to-many रिलेशनशिप कहाँ समस्याएँ पैदा कर सकती हैं, हम डेटा मॉडल में प्रति वर्ष Product Category के अनुसार एक Sales Target टेबल बनाते हैं। हमें बिक्री के आँकड़े और इन लक्ष्यों को एक ही विज़ुअल में साथ-साथ रिपोर्ट करना है। यह Sales Target टेबल और Product टेबल के बीच many-to-many रिलेशनशिप बनाकर हासिल किया जा सकता है। 

Power BI में many-to-many रिलेशनशिप। चित्र: लेखक

निम्नलिखित टेबल विज़ुअल में, हम प्रत्येक प्रोडक्ट कैटेगरी के लिए अपनी बिक्री और लक्ष्य मानों को साथ-साथ देख सकते हैं। 

प्रोडक्ट कैटेगरी, बिक्री, और लक्ष्य राशि। चित्र: लेखक

हालाँकि, यदि हम इस टेबल को Product स्तर पर देखने की कोशिश करें, तो लक्ष्य के मान पूरी तरह गलत होंगे। इसका कारण डेटा में ग्रैन्युलैरिटी का अंतर है; चूँकि बिक्री लक्ष्य केवल प्रोडक्ट कैटेगरी स्तर पर हैं, Power BI इन लक्ष्यों को प्रोडक्ट स्तर पर उचित रूप से प्रदर्शित नहीं कर सकता, और परिणामस्वरूप, लक्ष्यों को बस उस कैटेगरी के प्रत्येक प्रोडक्ट पर डुप्लिकेट कर देता है। यदि आपको पता न हो कि many-to-many रिलेशनशिप का यह परिणाम हो सकता है, तो यह व्यावसायिक रिपोर्टिंग के लिए अत्यंत समस्याग्रस्त हो सकता है।

प्रोडक्ट कैटेगरी, बिक्री, और लक्ष्य राशि। चित्र: लेखक

दिशा-निर्देशन

क्रॉस फ़िल्टर दिशा विकल्प में सिंगल या दोनों दिशाओं में से चुनने का विकल्प होता है। रिलेशनशिप अद्वितीय मानों वाली टेबल से कई मानों वाली टेबल की ओर प्रवाहित होती हैं। हमारे मामले में, रिलेशनशिप Products टेबल से Financials टेबल की ओर प्रवाहित होती है। इसका अर्थ है कि यदि क्रॉस फ़िल्टर दिशा सिंगल पर सेट है, तो Financials टेबल को Products टेबल के product और product category फ़ील्ड्स से फ़िल्टर किया जा सकता है। हालाँकि, Products टेबल को Financials टेबल के product ID फ़ील्ड का उपयोग करके, या अन्य डाइमेंशन टेबल्स में निहित किसी अन्य विशेषता का उपयोग करके फ़िल्टर नहीं किया जा सकता। 

अधिकांश मामलों में सिंगल दिशा की सिफारिश की जाती है। ऐसा इसलिए क्योंकि द्वि-दिशात्मक रिलेशनशिप्स (‘both’ विकल्प) न केवल मॉडल के प्रदर्शन को घटाती हैं, बल्कि डेटा फ़िल्टर करते समय अस्पष्टता भी ला सकती हैं।

हमारे मामले में, Product, Countries और Financials टेबल्स के बीच के रिलेशनशिप्स पर विचार करें। ये दोनों सिंगल-दिशा, one-to-many रिलेशनशिप्स हैं। इसका मतलब है कि रिपोर्ट को देश के अनुसार फ़िल्टर करने से, Product टेबल अपने-आप केवल उस देश के प्रासंगिक प्रोडक्ट्स तक सीमित नहीं होगी। इसे दर्शाने के लिए नीचे दिए गए स्लाइसर देखें। किसी देश (जैसे USA) का चयन करने से Product स्लाइसर केवल उसी देश के प्रासंगिक प्रोडक्ट्स पर समायोजित नहीं होगा। 

Power BI में स्लाइसर। चित्र: लेखक

हालाँकि, Products टेबल और Financials टेबल के बीच रिलेशनशिप को द्वि-दिशात्मक में बदलकर, हम फ़िल्टरिंग को Products टेबल में प्रवाहित होने दे सकते हैं। इस स्थिति में, हम देखते हैं कि Carretera उत्पाद Product स्लाइसर में नहीं दिखता क्योंकि United States of America में उस उत्पाद की कोई बिक्री नहीं है।

Power BI में स्लाइसर। चित्र: लेखक

वैकल्पिक रूप से, द्वि-दिशात्मक रिलेशनशिप्स का उपयोग करने से बचने के लिए, आप स्लाइसर विज़ुअल में ऐसा फ़िल्टर जोड़ सकते हैं जो खाली मान वाली आइटम्स को बाहर कर दे। ध्यान देने योग्य है कि आपको यह उन सभी विज़ुअल्स के लिए करना होगा जो डाइमेंशन टेबल्स के फ़ील्ड्स का उपयोग करते हैं।

Power BI में फ़िल्टर्स और स्लाइसर। चित्र: लेखक

अपने Power BI मॉडल को कैसे अनुकूलित करें

अपने Power BI मॉडल को अनुकूलित करने में सबसे महत्वपूर्ण कारक है—इस ट्यूटोरियल में बताई गई अच्छी डेटा मॉडलिंग प्रथाओं का उपयोग करना। अक्सर एक अच्छा डेटा मॉडल अकेले ही Power BI रिपोर्ट को लाखों और अरबों पंक्तियों तक स्केल करने देता है, जबकि प्रदर्शन का एक अच्छा स्तर बनाए रखता है। 

हालाँकि, अच्छी डेटा मॉडलिंग प्रथाओं का पालन करने के अलावा, आप अपने Power BI मॉडल को अनुकूलित करने के लिए कुछ और काम भी कर सकते हैं, जैसे:

• टाइम इंटेलिजेंस को बंद करना – Power BI में यह फ़ीचर हर बार जब कोई तिथि फ़ील्ड किसी विज़ुअल में जोड़ी जाती है, स्वतः ही दिनांक/समय हायरार्की बनाता है। हर बार जब इन हायरार्की में से एक बनती है, तो यह मूलतः डेटा मॉडल में एक अतिरिक्त टेबल जोड़ती है। जैसा कि आप समझ सकते हैं, इससे Power BI रिपोर्ट काफ़ी फुल सकती है, विज़ुअल्स का रेंडर धीमा हो सकता है और रिफ्रेश समय बढ़ सकता है। इस फ़ीचर को बंद करना और सभी दिनांक/समय हायरार्की के लिए एक समर्पित तिथि टेबल का उपयोग करना बेहतर विचार है।
• केवल वही कॉलम लोड करना जिनकी आपको वास्तव में आवश्यकता है – Power Query एडिटर का उपयोग करके, ऐसे सभी कॉलम हटाना अच्छा विचार है जिनकी आपको आवश्यकता नहीं है या जिन्हें आप अपनी रिपोर्ट में उपयोग नहीं कर रहे हैं। सबसे आम फ़ील्ड्स में से एक जिसे आमतौर पर एहतियातन रखा जाता है, वह है Row ID फ़ील्ड। यह फ़ील्ड आपके डेटासेट के लिए अद्वितीय होती है; उदाहरण के लिए Orders टेबल में प्रत्येक ट्रांज़ैक्शन के लिए एक Order ID। अक्सर यह ID फ़ील्ड टेक्स्ट के रूप में भी संग्रहीत होती है, जो मॉडल को और अधिक फुला देती है। यदि यह ID फ़ील्ड किसी रिलेशनशिप में स्पष्ट रूप से उपयोग नहीं हो रही है, तो आमतौर पर इसे मॉडल में लोड करना आवश्यक नहीं होता।
• केवल आवश्यक पंक्तियाँ लोड करना – इस जाल में न फँसें कि आपको अपना सारा व्यावसायिक डेटा Power BI रिपोर्ट में आयात करना है। विशेषकर यदि आपका व्यवसाय लंबे समय से चल रहा है, तो इसका अर्थ होगा कि आपकी रिपोर्ट में बहुत सारा ऐसा डेटा होगा जिस पर वास्तव में कोई ध्यान नहीं दे रहा। यहाँ कुंजी यह है कि रिपोर्ट के व्यावसायिक उपयोगकर्ताओं से बात करें और ठीक-ठीक जानें कि उन्हें कितना ऐतिहासिक डेटा देखना है। यदि उन्हें पुराना डेटा देखना आवश्यक है, तो आप हर एक ट्रांज़ैक्शन के बजाय उस टेबल का केवल संक्षिप्त/सारांशित संस्करण आयात करने पर विचार कर सकते हैं।