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

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

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

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

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

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

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

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

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

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

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

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

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

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

با اعمال رویکرد مدلسازی انبار داده ۳NF در مثال رستوران‌مان، جداول را بیشتر از هم تفکیک می‌کنیم. در رویکردهای سنتی مدلسازی، هر جدول به‌شکل انفرادی دارای یک ساختار سلسله‌مراتبی بود؛ اما در ۳NF، این ساختار منظم به‌شکل لینک به جداول دیگر ایجاد می‌شود. 

 بنابراین برخی از ستون‌های جدول تراکنش‌ مانند سفارش‌ها و پرداخت‌ها، به کلیدهای اصلی جداول 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 و بروز مشکل افزونگی داده‌ها 
• به‌وجود آمدن چالش در رسیدگی به تغییرات جداول ابعاد 
• انعطاف کمتر در مقایسه‌ با ۳NF برای انطباق با تغییرات آینده

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

“Snowflake Schema” گونه‌ای از اسکیمای ستاره‌ای در انبار داده است که برای مدیریت ساختارهای داده‌ای پیچیده با درصد زیادی از Normalized طراحی شده است. 

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

اجزای کلیدی رویکرد 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

ساختار طراحی 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، داده‌های بدون ساختار و انواع منابع داده را با حفظ یک‌پارچگی و دقت تاریخی برطرف می‌کند. مانند ۳NF، این رویکرد هم در لایه 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 اغلب سریع‌تر از دیگر مدل‌ها هستند؛ اما به فضا و تجهیزات ذخیره‌سازی بیشتری نیاز دارند.

آنچه در ۷ رویکرد مدلسازی انبار داده خواندیم

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