رویکرد های مدلسازی انبار داده + توصیه هایی برای انتخاب بهترین شیوه

رویکردهای مدلسازی انبار داده در سناریوهای پیچیده حاوی میلیون‌ها داده، نقش مهمی را ایفا می‌کنند. تصور کنید به‌‎عنوان مهندس تجزیه‌ و تحلیل در یک رستوران شلوغ کار می‌کنید؛ مشتریان هر روز میز و غذا رزرو می‌کنند، سفارش می‌دهند و پرداخت را به‌اتمام می‌رسانند. همه این داده‌ها به دیتابیس تراکنش‌های رستوران سرازیر می‌شوند که با جزئیات هر تراکنش همراه هستند؛ درحالی‌که این پایگاه داده برای اجرای عملیات روزانه عالی است، اما برای تجزیه‌وتحلیل داده‌ها، کشف ترندها و بینش‌های رشد دهنده کسب‌ و کار ایده‌ آل نیست. این‌جا همان خلا ارزش‌ آفرینی به‌وجود می‌آید که با انبار داده (Data Warehouse) پر می‌شود. 

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

چالش مدلسازی در انبار داده چیست؟

انبار داده یک دیتابیس جداگانه است که برای ذخیره حجم زیادی از داده‌ های تاریخی، کوئری و تجزیه‌ و تحلیل سریع بهینه شده است. چالش مدلسازی انبار داده برای نظم دادن به Data Warehouse این است که باید داده‌ها را در انبار خود ساختار دهید تا تجزیه‌ و تحلیل به‌ شکل کار آمدی پیش برود؛ در‌ عین‌ حال هم به‌ اندازه کافی انعطاف‌ پذیر باشد تا بتوانید نیاز های درحال‌ تغییر کسب‌ و کارتان را به‌راحتی مدیریت کنید. 

بررسی یک نمونه پایگاه داده برای تراکنش‌ ها

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

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

پایگاه داده تراکنشی از یک ساختار عادی‌ شده (Normalized) استفاده می‌کند که برای پردازش تراکنش‌ها بهینه شده است؛ اما این ساختار آنالیز و گزارش‌ گیری را دشوار تر می‌کند. یک رویکرد مدل‌ سازی انبار داده، داده‌ها را Denormalized کرده و از نو ساختار می‌دهد تا برای تحلیل در لایه Gold بهینه شود؛ درحالی‌که سرعت بخشیدن به فرآیند نوشتن داده‌ها را در لایه Silver را هم ساده می‌کند.

انواع رویکرد های مدلسازی انبار داده

شناخت انواع رویکرد های مدلسازی انبار داده، در زمینه انتخاب بهترین شیوه مدلسازی کمک زیادی به ما می‌کند؛ پس در ادامه این رویکردها را با جزئیات توضیح خواهیم داد.

۱. فرم عادی سوم (۳NF)

“Third Normal Form” یک رویکرد کلاسیک مدلسازی پایگاه داده رابطه‌ای است که افزونگی داده‌ ها را به‌حداقل می‌رساند. در 3NF، هر ستون بدون کلید فقط به کلید اصلی (Primary Key) جدول بستگی دارد.

با اعمال رویکرد مدلسازی انبار داده 3NF در مثال رستوران‌ مان، جداول را بیشتر از هم تفکیک می‌کنیم. در رویکرد های سنتی مدلسازی، هر جدول به‌ شکل انفرادی دارای یک ساختار سلسله‌ مراتبی بود؛ اما در 3NF، این ساختار منظم به‌ شکل لینک به جداول دیگر ایجاد می‌شود؛ بنابراین برخی از ستون‌ های جدول تراکنش‌ مانند سفارش‌ ها و پرداخت‌ ها، به کلیدهای اصلی جداول Metadata اشاره می‌کنند. این جداول هم به جدول‌ های سطح بالاتر خود که آنها هم Metadata هستند، ارجاع می‌دهند.

ما باید تشخیص دهیم که جدول مشتری، حاوی جزئیات آدرس او است؛ این یک ساختار سلسله‌ مراتبی طبیعی و درست است؛ سپس همین ستون‌ها را به جداول کوچک‌ تر تقسیم می‌کنیم. به‌طور معمول از این روش برای یک لایه Presentation/Gold استفاده نمی‌کنیم؛ اما ممکن است برای لایه Silver رویکرد مناسبی باشد. این موضوع زمانی بیشترین اهمیت را پیدا می‌کند که در حال مصرف منابع متعدد هستید. ممکن است هرکدام از این منابع هم به‌شکل بومی، در سطوح مختلف دانه ساختار یافته باشند.

جنبه‌ های مثبت رویکرد ۳NF

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

جنبه‌‌ های منفی رویکرد ۳NF

• ممکن است برای تجزیه‌ و تحلیل به Join های زیادی بین جداول نیاز داشته باشد، که بر عملکرد کوئری‌ ها تاثیر منفی می‌گذارد.
• درک و پیمایش جداول برای کاربران سازمانی پیچیده می‌شود.

۲. طرح‌ واره ستاره کیمبال

“Kimball Star Schema” یک مفهوم Pivotal در انبار داده است که توسط رالف کیمبال (Ralph Kimball)، یک چهره برجسته در حوزه Data Warehouse و هوش تجاری معرفی شده است. این شیوه، بهترین رویکرد مدلسازی انبار داده برای ساده‌ سازی فرآیند ذخیره‌ کردن داده‌ها و افزایش عملکرد کوئری‌ ها است؛ چون ساختار های داده‌ای پیچیده‌ را برای تجزیه‌ و تحلیل‌، قابل‌ مدیریت و در دسترس‌ تر می‌سازد.

اجزای کلیدی رویکرد Kimball Star Schema

• جدول Fact: جدول Fact محور اصلی طرح‌ واره ستاره‌ای است که داده‌ های کمی را در خود نگه می‌دارد؛ مانند ارقام فروش، تعداد تراکنش‌ها و سایر معیارهای قابل اندازه‌ گیری. هر رکورد در جدول Fact مربوط‌ به یک رویداد یا تراکنش خاص است و کلید های خارجی را در بر می‌گیرد. هرکدام از این کلیدها، داده‌ ها را به جداول ابعاد پیوند می‌دهند. به‌طور معمول، این جدول به‌دلیل حجم زیادی از داده‌ هایی که در خود نگه می‌دارد، بزرگ است.
• جداول Dimension: جداول ابعاد جداول جانبی هستند که زمینه را برای داده‌ ها در جدول Fact فراهم می‌کنند. آنها حاوی ویژگی‌ های توصیفی مرتبط‌ با ابعاد کسب‌ و کار مانند دوره‌های زمانی، مکان‌های جغرافیایی، محصولات، مشتریان و کارمندان هستند. به‌طور کلی، جداول ابعاد در مقایسه با جدول Fact، کوچک‌تر و ثابت‌تر هستند. آن‌ها داده‌ها را به‌شکل Denormalized ذخیره می‌کنند تا پرس‌ و جو ها ساده و درک و پیمایش بین آنها راحت‌تر شود.

ساختار و طراحی Kimball Star Schema 

رویکرد “Kimball Star Schema” نام خود را از چیدمانش گرفته است؛ چیدمانی که شبیه یک ستاره است. این چیدمان فقط در یک حالت تغییر می‌کند؛ از Mermaid برای ساختن نمودارهای خود به‌عنوان کد استفاده کنید که شکل آن را در پایین نشان داده‌ایم. 

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

در مثال رستوران ما، یک جدول Fact حاوی سفارش‌ها داریم که درست در مرکز ساختار قرار دارد و از کلیدهای خارجی برای جداول ابعاد مانند مشتریان، تاریخ، محصول و غیره استفاده می‌کند. این رویکرد تا حدی استاندارد تلقی شده و برای لایه Gold یا Presentation در انبار داده، بهترین انتخاب خواهد بود.

جنبه‌ های مثبت رویکرد Kimball Star Schema

• بهینه‌ سازی‌شده برای کوئری‌ نویسی سریع با به‌حداقل رساندن Join ها.
• نمای بصری برای کاربران سازمانی آشنا با فرآیند کسب‌ و کار.
• سادگی جمع‌ آوری و محاسبه داده‌ها. 

جنبه‌ های منفی رویکرد Kimball Star Schema

• Denormalization و بروز مشکل افزونگی داده‌ ها. 
• به‌وجود آمدن چالش در رسیدگی به تغییرات جداول ابعاد. 
• انعطاف کمتر در مقایسه‌ با 3NF برای انطباق با تغییرات آینده.

۳. طرح‌ واره دانه‌ های برف

“Snowflake Schema” گونه‌ای از اسکیمای ستاره‌ای در انبار داده است، که برای مدیریت ساختارهای داده‌ای پیچیده با درصد زیادی از Normalized طراحی شده است. این طرح که به‌دلیل شکل پیچیده و دانه برفی خود نام‌ گذاری شده است، داده‌ها را در چند جدول مرتبط سازماندهی می‌کند. در این حالت، یکپارچگی داده‌ها افزایش یافته و افزونگی کاهش می‌یابد. بااین‌حال، رویکرد Snowflake Schema به قیمت افزایش پیچیدگی در نوشتن کوئری و تاثیرات بالقوه منفی بر عملکرد کلی دیتابیس است؛ به‌ همین‌ دلیل، می‌توانیم آن را به‌عنوان ترکیبی بین Star Schema و 3NF درنظر بگیریم.

اجزای کلیدی رویکرد Snowflake Schema

• جدول Fact: جدول Fact در این رویکرد، به‌عنوان جدول اصلی در طرح دانه‌های برف باقی می‌ماند و حاوی داده‌های کمی مانند فروش، درآمد یا سایر متریک‌ های تجاری است. Snowflake Schema کلید های خارجی جداول ابعاد را نگه می‌دارد که زمینه را برای Fact فراهم می‌کنند. هر رکورد در جدول Fact یک رویداد قابل اندازه‌ گیری را نشان می‌دهد و شامل متریک‌های عددی و کلید های خارجی است که به ابعاد مربوطه وصل می‌شوند.
• جداول ابعاد: برخلاف طرح ستاره، طرح دانه‌های برف جداول ابعاد را بیشتر Normalized می‌کند. هر جدول بُعد را می‌توان به چند جدول مرتبط تقسیم و ساختار نرمال‌ تری را ایجاد کرد. برای مثال، بُعد مشتری ما آدرس را به جدول‌ های کدپستی، شهر و ایالت تقسیم می‌کند که هرکدام به کلید های خارجی وصل هستند. این Normalization افزونگی داده‌ها را کاهش می‌دهد؛ اما به‌ طور هم زمان هم باعث افزایش تعداد Join های مورد نیاز برای پرس‌ و جو ها می‌شود.

جنبه‌ های مثبت رویکرد Snowflake Schema

• افزونگی داده‌ها را در مقایسه با طرح‌واره ستاره‌ای کاهش می‌دهد.
• یک‌پارچگی داده‌ها را با کمک Normalisation اعمال می‌کند.
• نگهداری جداول ابعاد را آسان‌ تر می‌کند.

جنبه‌ های منفی رویکرد Snowflake Schema

• ممکن است در مقایسه با طرح ستاره‌ای به Join های بیشتری نیاز داشته باشد که بر عملکرد کوئری‌ها تاثیر منفی می‌گذارد.
• درک و پیمایش بین جداول و دیتابیس برای کاربران سازمانی دشوار تر از مدل‌ های قبلی است.

۴. یک میز بزرگ (OBT)

“The One-Big-Table” که به‌عنوان میز مسطح یا جدول عریض هم شناخته می‌شود، یک رویکرد ذخیره‌ سازی داده است که در آن همه داده‌ها در یک جدول واحد و Denormalized ادغام می‌شوند. این رویکرد مدلسازی انبار داده با طرح‌ واره‌ های نرمال‌ شده مانند طرح‌ واره‌ های ستاره‌ای و دانه‌های برف تضاد زیادی دارد؛ همچنین ساختار ساده‌ تری را ارائه می‌دهد؛ اما به‌ طور هم‌ زمان هم باعث افزایش افزونگی و مشکلات ضعف عملکردی بالقوه می‌شود که در مواجه‌ با مجموعه داده‌ های بسیار بزرگ رخ می‌دهند.

اجزای کلیدی OBT

• جدول تک: ویژگی اصلی طراحی OBT این است که تمام داده‌های مرتبط در یک جدول جامع ذخیره می‌شوند. این جدول شامل آرایه وسیعی از ستون‌ها است که تمام ویژگی‌ها و معیارهای لازم را برای تجزیه‌ و تحلیل نشان می‌دهد. جدول ممکن است حاوی هزاران ستون باشد که هر ردیف نشان‌دهنده یک رکورد منحصر به‌فرد است که ابعاد و معیارهای متعددی را دربرمی‌گیرد.
• ویژگی‌ها و متریک‌ها: در طراحی OBT، ویژگی‌ها که در جداول ابعاد طرح‌ واره‌ های دیگر هم یافت می‌شوند و معیار ها که در جداول Fact حضور دارند در یک جدول واحد ترکیب می‌شوند؛ به‌عنوان مثال، جزئیات مشتری، اطلاعات محصول و ارقام فروش همگی در یک جدول ذخیره می‌شوند و هر رکورد یک Snapshot فوری و کامل از تراکنش یا رویداد را ارائه می‌دهد.

ساختار طراحی OBT ساده است؛ چون فقط یک جدول دارد که هر ردیف آن شامل تمام نقاط داده لازم است. این ساختار مسطح نیاز به Join را از بین می‌برد و کاربران می‌توانند بدون درک روابط پیچیده جدول، کوئری و بازیابی داده‌ها را انجام دهند. در مثال رستوران، برای هریک از سه رویداد کلیدی رزرو، سفارش و پرداخت یک OBT خواهیم داشت. 

اگر داده‌ های خود را به Power BI یا انواع ابزار های هوش تجاری می‌کشید، نرم‌ افزار انتظار یک مجموعه داده سبک را با رویکرد Star Schema دارد؛ با این‌ حال، اگر داده‌ها را به Tableau می‌کشید، ممکن است رویکرد OBT انتخاب بهتری باشد.  نکته: اگر OBT را انتخاب می‌کنید، باید هر منطق Reusable را در جداول پشتیبانی (Supporting Tables) حفظ کنید؛ چون می‌توانید در دیتابیس خود، بارها و بار ها به این جداول ارجاع دهید.

جنبه‌ های مثبت رویکرد OBT

• عملکرد کوئری‌ها بسیار سریع می‌شود و نیاز به Join از بین می‌رود.
• به‌دلیل قرار گرفتن همه داده‌ها در یک مکان، درک ارتباطات جداول و مدل کلی ساختار ساده می‌شود.
• برای استفاده در زمینه Data Science، یک گزینه است.

جنبه‌ های منفی رویکرد OBT

• افزونگی بالا در داده‌ ها، نیاز به فضای ذخیره‌ سازی قابل‌ توجهی دارد.
• ایجاد تغییرات بدون تغییر کل ساختار جدول دشوار است.
• کوئری‌ هایی با ستون‌ های زیاد می‌توانند برای نوشتن و نگهداری سخت باشند.

۵. Data Vault 2.0

Data Vault 2.0 یک رویکرد مدرن برای مدلسازی انبار داده است که چند هدف کلیدی را دنبال می‌کند: ارائه یک مدل داده مقیاس‌ پذیر، چابک و قابل ممیزی. این رویکرد توسط “Dan Linstedt” توسعه یافت و براساس روش اصلی Data Vault ساخته شده است؛ مدلی که برای پشتیبانی بهتر از محیط‌های داده‌ای پیچیده امروزی، کامل‌ترین قابلیت‌ها را دارد. Data Vault 2.0 نیاز به مدیریت Big Data، داده‌ های بدون ساختار و انواع منابع داده را با حفظ یکپارچگی و دقت تاریخی برطرف می‌کند؛ مانند 3NF، این رویکرد هم در لایه Silver دیتابیس شما قرار می‌گیرد. 

اجزای کلیدی Data Vault 2.0

• هاب‌ ها: هاب‌ها در واقع کلید های منحصربه‌فرد بیزینس را با یک کلید جانشین خاص و Metadata آن، مانند تاریخ بارگذاری و اطلاعات منبع ذخیره می‌کنند. هر هاب یک مفهوم پایه را در بیزینس نشان می‌دهد؛ مانند مشتری، محصول یا سفارش. هاب‌ ها بسیار پایدار هستند و به‌ندرت تغییر می‌کنند؛ همچنین یک نقطه مرجع ثابت برای انبار داده می‌سازند.
• لینک‌ ها: لینک‌ها روابط بین کلید های ذخیره‌شده بیزینس را در هاب‌ها نشان می‌دهند. هر جدول لینک حاوی کلیدهای خارجی به هاب‌ های مربوطه به‌همراه Metadata است. لینک‌ ها نشان‌دهنده تراکنش‌ها،‌ گروه‌ های به‌ هم‌ مرتبط یا سلسله مراتب بین موجودیت‌ها هستند. آن‌ها برای مدل‌سازی روابط چند به‌ چند (Many-to-Many) و تغییرات اعمال‌ شده روی آن‌ها در طول زمان استفاده می‌شوند.
• ماهواره‌ ها: “Satellites” ویژگی‌ها و زمینه‌ های توصیفی را برای کلیدهای بیزینس در هاب‌ها یا روابط بین لینک‌ها ذخیره می‌کنند. آنها شامل Metadata برای ردیابی تغییرات در طول زمان هستند؛ مانند تاریخ بارگذاری و منبع. ماهواره‌ها می‌توانند بدون تاثیرگذاری بر کلید ها و روابط اصلی کسب‌ و کار تکامل یافته و امکان تطبیق را به‌شکل انعطاف‌ پذیر با سیستم‌ های جدید فراهم کنند.

ساختار و طراحی Data Vault 2.0

Data Vault 2.0 با معماری ماژولار طراحی شده که تفکیک ذخیره‌ سازی داده‌ها را با این سه نوع جدول ممکن می‌کند؛ به‌همین‌دلیل، رویکرد Data Vault 2.0 را یک شیوه مقیاس‌ پذیر و منعطف در زمینه مدلسازی انبار داده می‌دانیم. هاب‌ها، لینک‌ها و ماهواره‌ها به گونه‌ای طراحی شده‌اند که به‌صورت تدریجی و موازی بارگذاری شوند. این تقسیم‌ بندی امکان مدیریت کارآمد حجم زیادی از داده‌ها و تغییرات را در طول زمان ساده می‌کند.

جنبه‌‎ های مثبت رویکرد Data Vault 2.0

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

جنبه‌ ‎های منفی رویکرد Data Vault 2.0

• گاهی در طراحی و پیاده‌ سازی دیتابیس پیچیدگی‌ های زیادی را رقم می‌زند.
• در جمع‌ آوری داده‌ها و تجزیه‌ و تحلیل آنها، به جداول و Join های زیادی نیاز دارد.
• در این رویکرد ممکن است نوشتن و درک کوئری‌ها دشوار باشد.

۶. طرح‌ واره فعالیت

“Activity Schema” یک رویکرد ذخیره‌ سازی داده است که توسط احمد السامدیسی (Ahmed Elsamadisi)، برای ثبت سوابق دقیق فعالیت‌ها یا رویداد های بیزینسی به‌شیوه‌ای ساختار یافته و کارآمد طراحی شد. این رویکرد مدلسازی انبار داده بر مستند سازی اقدامات یا تراکنش‌ های انجام‌ شده در یک کسب‌ و کار تمرکز دارد و آن را برای داده‌ های رویداد محور و ثبت جزئیات تراکنش مفید می‌کند. 

Activity Schema در سیستم‌ هایی که نیاز به ردیابی حجم بالایی از رویدادهای Granular دارند، بهترین رویکرد مدلسازی در انبار داده است؛ سیستم‌ ها و پلتفرم‌ هایی مانند فروشگاه‌ های آنلاین، پلتفرم‌های تجارت الکترونیک، سیستم‌ های مالی و برنامه‌های IoT.

اجزای کلیدی Activity Schema

• جدول فعالیت: جدول مرکزی در طرح‌واره فعالیت، همان Activity Table است که هر فعالیت یا رویداد تجاری را ثبت می‌کند. هر ردیف در این جدول، رویداد یا تراکنش واحدی را نشان می‌دهد که جزئیات مربوط‌به اتفاقات، زمان وقوع و سایر زمینه‌های مرتبط را به تصویر می‌کشد. ویژگی‌های جدول Activity به‌عنوان بخشی از استانداردهای متداول دیتابیس تعریف شده است؛ بنابراین پیاده‌سازی آن آسان است.
• جداول ابعاد: پیوست‌ شده به جدول فعالیت که یک جدول ابعاد اختیاری است و زمینه اضافی را برای رویداد های ثبت‌ شده در جدول فعالیت فراهم می‌کند. یک بُعد در این جدول ممکن است شامل جزئیاتی در مورد مشتریان، محصولات، مکان‌ها، زمان و سایر نهادهای مرتبط و وابسته‌به جریان فعالیتی باشد که با آن ارتباط دارد.

در مثال رستوران، ممکن است یک جدول فعالیت مشتری با بُعد مرتبط‌ با مشتری داشته باشیم. جدول Activity فعالیت‌ های مشتری را مانند رزرو، سفارش‌ها و پرداخت‌ های او ردیابی می‌کند. جزئیات این موارد در ستون “feature_json” با یک ستون اختیاری دیگر نگهداری می‌شود. این ستون اختیاری مسئول ذخیره‌سازی  تاثیر درآمد، در صورت پیدا کردن ارتباط با داده‌های جدول است.

جنبه‌‌ های مثبت رویکرد Activity Schema

• طراحی این رویکرد بسیار ساده و شهودی است که به تعداد بسیار کمی جدول نیاز دارد.
• فعالیت‌های اضافی توسط یک موجودیت می‌تواند بدون تغییر طرح‌ واره ثبت شود.
• جداول جدید فقط زمانی ایجاد می‌شوند که موجودیت‌ های جدید نیاز به ردیابی داشته باشند.

جنبه‌‌ های منفی رویکرد Activity Schema

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

۷. مدلسازی موجودیت‌ محور

“Entity-Centric Modelling” یک رویکرد انعطاف‌ پذیر برای مدلسازی انبار داده است که توسط “Maxime Beauchemin”، با تمرکز بر مدل‌ سازی پیرامون موجودیت‌ هایی مانند مشتریان و محصولات ارائه شد. در این رویکرد هر موجودیت، جدول مخصوص به‌خود را می‌گیرد و با کمک json، ردیابی مجموعه‌ای از معیارها را ممکن می‌سازد. رویکرد Entity-Centric به جداول ابعاد اضافی نیاز ندارد؛ چون جداول Entity در پایین‌ ترین Grain موجودیت دیتابیس قرار دارند و می توانند ویژگی‌ های خود را به‌شکل مستقیم در جدول داشته باشند.

در مثال رستوران، ما یک جدول مشتریان با ستون‌هایی برای ویژگی‌ های مشتری، به‌علاوه یک ستون json برای نگهداری معیار های محدود زمانی مانند visit.7d، visit.14d، sale.30d خواهیم داشت.

جنبه‌‌ های مثبت رویکرد Entity-Centric

• انعطاف‌ پذیری و سازگار بالایی با نیازهای درحال‌ تغییر کسب‌ و‌ کارها دارد.
• جداول کمی در این رویکرد می‌سازیم و به‌همین‌دلیل درک بالایی از روابط و جداول این مدل داریم.
• تاریخچه را به‌طور موثری در ستون متریک ثبت می‌کند.

جنبه‌‌ های منفی رویکرد Entity-Centric

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

۵ توصیه برای انتخاب بهترین رویکرد مدلسازی انبار داده

انتخاب روش مدلسازی انبار داده با در نظر گرفتن این هفت رویکرد ممکن می‌شود. در ادامه به بررسی پنج نکته مهم در انتخاب بهترین رویکرد این زمینه می‌پردازیم.

۱. الزامات تحلیلی

باید به چه نوع سوالاتی در تحلیل داده‌های خود پاسخ دهید؟ براساس جوابی که به این سوال‌ها می‌دهید، یک مدل بهینه‌ شده برای الگو های کوئری‌ های دیتابیس خود انتخاب کنید.

۲. حجم داده و مقیاس‌ پذیری

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

۳. سادگی در استفاده

به این فکر کنید که چه‌کسی در انبار داده کوئری‌ می‌نویسد و دیتابیس شما را مدیریت می‌کند؟ برخی از رویکردها برای کاربران غیر فنی گرافیکی‌تر و ساده‌تر هستند.

۴. انعطاف‌ پذیری

ممکن است کسب‌ و کار شما درحال‌ تکامل و گسترش باشد، پس مدلی را انتخاب کنید که بتواند با نیازهای متغیر سازمان و داده‌ های شما سازگار شود.

۵. عملکرد

در انتخاب بهترین رویکرد مدلسازی انبار داده، مبادلات بین سرعت کوئری‌ها و افزونگی داده‌ها را در نظر بگیرید. اغلب مدل‌ های Denormalized اغلب سریع‌تر از دیگر مدل‌ ها هستند؛ اما به فضا و تجهیزات ذخیره‌ سازی بیشتری نیاز دارند.

سخن پایانی

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