مدل سازی داده: آماده سازی داده در Power BI

آماده سازی داده، یکی از مهمترین گام های ابتدایی ایجاد داشبورد در Power BI است. در واقع می توان گفت آماده سازی داده سنگ بنای ایجاد یک سیستم هوش تجاری است. در این مطلب خواهید آموخت که چرا آماده سازی داده ضرورت دارد و همچنین با نکات ساده و پر اهمیت ایجاد یک مدل داده در Power BI آشنا خواهید شد. لازم به ذکر است این مطلب برای همه ابزارهای هوش تجاری صدق می کند.

چرا آماده سازی داده ضرورت دارد؟

همه شما با مدل داده هایی مانند تصویر زیر روبرو بوده اید. پایگاه داده تراکنشی با تعداد زیادی جدول و رابطه که حتی رصد کردن آن ها کاری طاقت فرسا به نظر می رسد. اصولا این نوع طراحی برای عملیات CRUD (Create, Retrieve, Update, Delete Rows) طراحی می شوند. به همین دلیل پایگاه داده تراکنشی به منظور کاهش افزونگی و تکرار داده (redundancy) و همچنین افزایش یکپارچگی و ثبات داده (Consistency)، به صورت نرمال (Normalized) طراحی می شود. به طور مثال برای گروه کالا یک جدول جداگانه به نام Category در نظر گرفته می شود، که این جدول با کلید (CategoryID) به جدول Product وصل می شود.

حال با این نوع طراحی هنگامی که یک Category تغییر یابد، تنها کافیست ردیف مربوط به همان Category تغییر یابد. در حالی که اگر 2 جدول در هم ادغام میشد باید تمام ردیف های مربوط به آن Category تغییر می یافت.

کتاب ها و مطالب زیادی در مورد طراحی پایگاه داده و نرمال سازی وجود دارد. در این مطلب قصد آموزش طراحی پایگاه داده را نداریم، بلکه می خواهیم بگوییم از این نوع طراحی در سیستم های هوش تجاری خود داری کنید. مدل نرمال برای طراحی پایگاه داده عملیاتی بسیار عالی عمل می کند، اما برای سیستم های هوش تجاری مناسب نیست.

دلایل بسیاری برای مناسب نبودن این نوع طراحی در سیستم های هوش تجاری وجود دارد که به 2 تا از مهمترین دلایل آن اشاره می کنیم.

1- فهم این نوع از مدل برای کاربر نهایی بسیار سخت و دشوار است.

2- تعداد زیاد جدول و رابطه، سیستم را کند و غیر کارا می کند.

هیچ کاربری نمی خواهد ساعت ها برای دیدن یک گزارش وقت صرف کند. گزارش ها باید بسیار چابک و سریع باشند. همچنین درک این نوع از مدل برای کاربران پایگاه داده نیز آسان نمی باشد. حال شما فرض کنید کاربران شما افرادی هستند که احتمالا دانش بالایی در زمینه فناوری اطلاعات ندارند. آن ها احتمالا علاقه ای به صرف وقت برای فهمیدن چنین مدل پیچیده ای ندارند، در نتیجه باید مدل تا حد امکان ساده شود. مدلی با کمترین تعداد جدول و روابط. مهمترین وظیفه یک توسعه دهنده سیستم هوش تجاری تبدیل مدل نرمال به مدلی غیر نرمال است که تصویر آن را مشاهده می کنید.

این مدل در مقایسه با مدل قبل بسیار سریع تر و البته قابل فهم تر است. همان طور که در مدل مشاهده می کنید یک جدول اطلاعات فروش را ذخیره کرده (Fact_Sales) و جداول دیگر اطلاعاتی که هر تراکنش فروش را شرح می دهند. (چه کالایی؟ در کدام فروشگاه؟ در چه تاریخی؟ به فروش رسیده است.)

در این نوع مدل جدول Fact در میانه و جداول Dimension در اطراف آن قرار گرفته اند. هر جدول Dimension تنها یک رابطه با جدول Fact برقرار کرده است. این نوع مدل بهترین نوع مدل سازی در سیستم های هوش تجاری به شمار می رود که از آن به عنوان مدل ستاره ای (Star Schema) یاد می شود. تبدیل مدل نرمال به مدل ستاره ای یکی از مهمترین وظایف یک توسعه دهنده سیستم های هوش تجاری به شمار می رود.

طراحی مدل ستاره ای

برای طراحی مدل ستاره ای اکیدا توصیه می شود که در هر لحظه تنها روی یک سیستم تمرکز کنید. به طور مثال تنها بر روی سیستم فروش تمرکز کرده و سپس نیازمندی های تحلیل برای آن را استخراج کنید. تمرکز هم زمان بر روی همه سیستم ها (Sales, CRM, Logistic) شما را با صدها جدول و رابطه روبرو می کند که فقط پیچیدگی بیشتر را برای شما به همراه خواهد داشت.

جدول FACT

جداول FACT جداولی هستند که معمولا عدد و ارقام را در خود نگهداری می کنند. اعدادی که محاسبات تحلیلی بر روی آن ها صورت می پذیرد. به طور مثال میزان فروش، تعداد فروش، تخفیفات، تعداد برگشتی از فروش، هزینه و از این قبیل اطلاعات در جدول FACT ذخیره می شود. اطلاعاتی که قابل تجمیع در ابعاد مختلف می باشند. در تصویر زیر نمونه ای از یک Fact که اطلاعات فروش در آن ذخیره شده است را مشاهده می نمایید.

جدول Dimension

معمولا هر گونه اطلاعات توصیفی در جدول Dimension ذخیره می شود. مثلا اطلاعات مشتریان از قبیل نام، سن، محل زندگی، شغل مشتری و هر گونه اطلاعات مربوط به مشتری در جدول Dimension مشتری (Dim_Customer)ذخیره می شود. همین طور تمام اطلاعات مربوط به نام کالا، وزن کالا و هر نوع اطلاعات مربوط به کالا در جدول Dimension کالا (Dim_Customer) ذخیره می شود. لازم به ذکر است جدول Dimension تاریخ (Dim_Date) یکی از مهمترین جداولی است که در پیاده سازی هوش تجاری حتما و حتما وجود دارد. یک نمونه از جدول Dimension مربوط به مشتری را در تصویر زیر مشاهده می نمایید.

هر جدول Dimension باید شامل یک کلید باشد. این کلید باید از نوع عددی (Numeric & int) در نظر گرفته شود. بدیهی است که با توجه به تعریف کلید این ستون باید دارای مقادیر منحصر به فرد باشد. در واقع این کلید به عنوان کلید اصلی (Primary Key) جدول Dimension و کلید خارجی (Foreign Key) جدول Fact در نظر گرفته می شود و دو جدول از طریق این 2 کلید با یکدیگر رابطه برقرار می کنند. لازم به ذکر است که به طور مثال CustomerKey به عنوان کلید اصلی در جدول Dim_Customer دارای مقادیر منحصر به فرد است اما به عنوان کلید خارجی در جدول Fact_Sales دارای مقادیر تکراری است.

ستونی که به عنوان کلید اصلی جدول Dimension در نظر رفته می شود، حتی الامکان نباید کلید اصلی منبع اصلی باشد. در واقع بهتر است کلید اصلی را در مرحله آماده سازی داده تولید کنیم.  این کلید اصلی که ممکن است با منبع داده تفاوت کند به عنوان Surrogate Key شناخته می شود. دلایل زیادی وجود دارد که ما را به استفاده از Surrogate Key ترغیب می کند.

ممکن است کلید اصلی در سیستم مبدا به صورت عددی نباشد و رشته ای (متنی) باشد. بدانید که نوع عددی (int) بهترین نوع داده برای ستون های Surrogate Key هستند چرا که این مقادیر باید در Fact استفاده شوند. Fact ها معمولا بزرگترین جداول در مدل هستند و کم حجم نگه داشتن آن در عملکرد بسیار اهمیت دارد. یکی از پایه ای ترین کارهایی که می توان برای کاهش سایز این جداول انجام داد جلوگیری از به کار بردن کلید های رشته ای برای Surrogate Key می باشد. لذا سعی کنید برای این کلید نوع عددی را به کار گیرید.

همچنین در مورد پیاده سازی Slowly Changing Dimension کلید Surrogate Key اهمیت به سزایی دارد. SCD زمانی به کار گرفته می شود که رصد تغییرات برای ما اهمیت دارد.

فرض کنید مشتری با مدرک لیسانس کتاب مردی در تبعید ابدی را از فروشگاه ما خریداری کرده است. چند سال بعد همان مشتری که موفق به اخذ مدرک فوق لیسانس شده است کتاب جز از کل را از ما خریداری می کند. ابتدا به شیوه معمول عمل کنیم و مدرک تحصیلی مشتری را از لیسانس به فوق لیسانس تغییر دهیم. مدیریت از ما می خواهد گزارشی تهیه کنیم و اعلام کنیم افراد فوق لیسانس به چه کتاب هایی علاقه دارند؟ ما در گزارش خود اعلام می کنیم افراد با مدرک فوق لیسانس به کتاب مردی در تبعید ابدی و جز از کل علاقه مندند. اما آیا این گزارش صحیح است؟

خیر! افراد فوق لیسانس به کتاب جز از کل علاقه مندند. ولی چون ما در Dimension مدرک تحصیلی فرد را از لیسانس به فوق لیسانس تغییر داده ایم همه خرید های گذشته او نیز با مدرک فوق لیسانس ثبت می شوند. لذا باید برای تصحیح گزارش از مفهومی تحت عنوان SCD استفاده کنیم. با پیاده سازی SCD تاریخچه تغییرات ستون هایی از Dimension که برای ما مهم هستند نگهداری می شود. در واقع ریزدانگی Dimension از مشتری به ورژنی از مشتری تغییر پیدا می کند. به این ترتیب با هر بر تغییر در مدرک تحصیلی فرد یک رکورد جدید برای آن فرد در Dimension درج می گردد. در واقع خرید های قبلی با مدرک تحصیلی قبلی و خرید های جدید با مدرک تحصیلی فعلی او ذخیره می شوند.

Surrogate Key به عنوان کلید اصلی جدول Dimension و کلید خارجی جدول Fact استفاده شده و دو جدول به این طریق با یکدیگر ارتباط برقرار می کنند.

همه Dimension ها به همین طریق ساخته و با جدول Fact ارتباط برقرار می کنند. DimProduct و DimDate به عنوان Dimension های کالا و تاریخ نیز از طریق کلید های خود با Fact_Sales ارتباط برقرار می کنند. اگر به شمای کلی مدل توجه کنید متوجه خواهید شد چرا به این نوع مدل سازی مدل ستاره ای گفته می شود. ویژگی این نوع مدل این است که Dimension ها به Fact متصل هستند اما خود Dimension ها با یکدیگر ارتباطی ندارند.

نکات مدل سازی

برخی از نکات هستند که در طراحی مدل ستاره ای باید مد نظر قرار دهید. نکات ساده ای که نادیده گرفتن آن ها شما را وسوسه می کند. نکاتی که اگر از ابتدا آن ها را رعایت نکنید روزی باید وقت بسیار زیادی جهت اصلاح آن ها صرف کنید.

جداول Dimension را مانند آنچه در پایگاه داده هستند در مدل خود بارگذاری نکنید.

جداول می توانند با یکدیگر Join شوند و جداول Flat را به وجود آورند.  این کار باعث فهم راحت تر و سرعت بیشتر می شود. پس سعی کنید جداول با موضوعات یکسان را با یکدیگر Join کنید (مخصوصا Dimension ها). هر جدول باید اطلاعات یک موجودیت باشد. به طور مثال اگر شهر ویژگی از مشتری است می توانید جدول آن را با جدول مشتری ادغام کنید.

جداول Fact را با هم ادغام نکنید.

جداول Fact بزرگترین جداول شما هستند. ادغام کردن آن ها باعث بزرگتر شدن آن ها می شود. آن ها را با Dimension ها از طریق روابط متصل کنید.

نام ستون ها را با دقت انتخاب کنید.

نام ستون های موجود در پایگاه داده را به نام های با معنی تغییر دهید. اگر ستون هایی مانند Cus_ID و مانند این ها را دارید به اسمی مشخص و قابل فهم در مدل خود تبدیل کنید. بدانید که کاربر نهایی احتمالا با اسامی موجود در پایگاه داده آشنایی ندارد.

نوع داده را در صورت نیاز به نوع مناسب تغییر دهید.

بعضی از انواع داده مانند Decimal باعث مصرف بالاتر مموری و CPU می شوند. در صورت وجود این نوع از داده مطمئن شوید واقعا به آن ها نیاز دارید. نوع داده را چک کنید و مناسب ترین نوع را برای هر ستون انتخاب کنید.

جداولی را که نیاز ندارید بارگذاری نکنید.

از بارگذاری جداول و ستون هایی که نیاز ندارید اکیدا خودداری کنید. عدم بارگذاری جداول و ستون ها در RAM باعث بهبود عملکرد مدل می شود.

جمع بندی

مدل سازی از جمله مباحث بسیار مهمی است که از سوی کاربران ابزارهای هوش تجاری به خصوص ابزارهای Self-Service BI نادیده گرفته می شود. توجه به نکات ساده مدل سازی باعث بهبود در عملکرد و سرعت مدل شما خواهد شد و پیچیدگی محاسبات را در آینده کم خواهد کرد. ممکن است بگویید که من می توانم بدون توجه به این نکات سیستم هوش تجاری پیاده سازی کنم اما افت سرعت و عملکرد باعث خواهد شد در آینده نیاز به صرف وقت و انرژی برای اصلاح مدل خود داشته باشید. پس از همین ابتدا مدل خود را بهینه طراحی کنید.

همچنین می توانید مطالب زیر را مطالعه کنید: