مراحل بهینهسازی جداول Fact و Dimension از ورود دادهها به انبار داده (Data Warehouse) شامل موارد زیر میباشد:
شناسایی نیازهای کسب و کار:
مرحله اول در بهینهسازی جداول Fact و Dimension از، شناسایی نیازهای کسب و کار سازمان و نوع دادههایی که باید تحلیل شوند میباشد. شناسایی نوع کوئری هایی که باید در برابر انبار داده (Data Warehouse) انجام شوند، فرکانس این کوئری ها، و انتظارات عملکردی برای کوئری ها، بسیار مهم هستند. این اطلاعات به شما در طراحی قالب انبار داده (Data Warehouse) کمک خواهند کرد.
ابتدا با صحبت با عاملان و شناسایی نوع کوئری هایی که باید بر روی دیتا ورهاوس اجرا شود، مانند “پرفروشترین محصولات بر اساس دسته بندی” و “روند فروش در طول زمان”، نیازهای کسب و کار را تعیین میکنیم. همچنین، انتظارات عملکردی KPI برای این کوئری ها را مشخص میکنیم، مانند زمان پاسخ دهی کمتر از ۵ ثانیه.
طراحی قالب انبار داده : (Data Modeling)
مدل سازی داده شامل تعریف ساختار جداول واقعیت و Dimension است که انبار داده شما را تشکیل می دهد. هدف از مدل سازی داده ها ایجاد طرح واره ای است که به طور دقیق فرآیندهای تجاری و داده های مورد نیاز سازمان را نشان دهد. جدول Factشامل اندازهها (دادههای عددی) میباشد و جداول Dimensionاز شامل صفات (دادههای توصیفی) میباشد که برای اندازهها مفهوم را ارائه میدهد.
یک مثال از جدول Fact و Dimension باهم بررسی کنیم :
جدول Fact فروش شامل داده های معاملاتی مربوط به فروش است، مانند تاریخ فروش، محصول فروخته شده، مقدار فروخته شده، قیمت هر واحد و کل درآمد ایجاد شده. کلید اصلی این جدول یک کلید ترکیبی است که از تاریخ فروش و شناسه محصول تشکیل شده است.
[table id=1 /]
جدول Dimension محصولات حاوی اطلاعاتی در مورد محصولات فروخته شده مانند نام محصول، توضیحات محصول، دسته بندی محصول و قیمت محصول است. کلید اصلی این جدول شناسه محصول است.
[table id=2 /]
جدول Dimension مشتریان حاوی اطلاعاتی در مورد مشتریانی است که خرید کرده اند، مانند نام، آدرس، شماره تلفن و آدرس ایمیل آنها. کلید اصلی این جدول شناسه مشتری است.
[table id=3 /]
با تعریف ساختار جداول Fact و Dimension به این شکل، میتوانید یک انبار داده را ایجاد کنید که به درستی فرآیندهای کسب و کار و الزامات داده سازمان را نشان میدهد. این کار، به شما کمک میکند تا با ارائه اطلاعات دقیق و بهروز، تصمیمات بهتری درباره کسب و کار خود بگیرید.
مدل دادهای که در مرحله مدلسازی داده ایجاد شده است، به شما اجازه میدهد تا دادههای خود را به صورت منظم و سازماندهی شده در اختیار داشته باشید. با استفاده از این دادهها، میتوانید تصمیمات بهتری را درباره کسب و کار خود بگیرید.
برای مثال، با تحلیل دادههای موجود در جداول واقعیت و Dimension، میتوانید به سوالاتی مانند اینها پاسخ دهید:
- کدام محصولات پرفروشترین هستند؟
- در چه مناطق فروش بیشتری رخ میدهد؟
- آیا قیمت محصولات بر روی فروش تأثیر دارد؟
- آیا مشتریان با کمترین تبلیغات به شما رجوع میکنند؟
- آیا تغییرات در قیمتها به شما کمک میکند تا فروش را افزایش دهید؟
با پاسخ دادن به این سوالات، میتوانید تصمیمات بهتری را درباره برنامهریزی تولید، بازاریابی، تأمین مالی و مدیریت منابع انسانی بگیرید.
علاوه بر این، میتوانید از دادههای موجود در انبار داده برای پیشبینی رفتار مشتریان در آینده استفاده کنید و بر این اساس، برنامهریزی بهتری برای تبلیغات و فروش داشته باشید. همچنین، میتوانید با مقایسه عملکرد خود در طول زمان، بهبودهای لازم را به برنامههای خود اعمال کنید.
برای بررسی صحت طراحی جداول Fact و Dimension در انبار دادهی خود، میتوانید به موارد زیر توجه کنید:
- صحت روابط بین جداول: باید اطمینان حاصل کنید که روابط بین جداول واقعیت و جداول Dimension درست است و کلیدهای خارجی در جداول واقعیت به درستی به کلیدهای اصلی جداول Dimension پیوند شدهاند.
- صحت ساختار جداول: باید از صحت ساختار جداول اطمینان حاصل کنید، مانند صحت نوع دادهها، اندازهگیریها، و جلوگیری از ایجاد تکراریها در جداول.
- صحت مقادیر: باید اطمینان حاصل کنید که مقادیر جداول واقعیت و جداول Dimension دقیق و معتبر هستند و بدون اشکال درج شدهاند.
- صحت پوشش زمانی: باید اطمینان حاصل کنید که جداول واقعیت و جداول Dimension شما پوشش زمانی کامل را دارند و تمام دادههای مورد نیاز در زمان مورد نیاز در دسترس هستند.
- صحت موارد منطقی: باید اطمینان حاصل کنید که طراحی شما صحیح است و موارد منطقی مانند اعتبارسنجی دادهها، محدودیتهای ارجاع، محدودیتهای یکتایی و … رعایت شدهاند.
در کل، برای اطمینان حاصل کردن از درستی طراحی جداول Fact و جداول Dimension، میتوانید از ابزارهایی مانند موارد آزمایشی (Unit Test) و ابزارهای کنترل کیفیت داده (Data Quality Control) استفاده کنید. همچنین، میتوانید با مشاوره اساتید مجرب در این زمینه، از نکات و توصیههای آنها بهره ببرید.
انتخاب نوع داده مناسب: (Data Type)
انتخاب نوع داده مناسب برای هر ستون در جدول Factو Dimension بسیار مهم است. این کار به منظور بهینهسازی ذخیره و پردازش دادهها صورت میگیرد. به عنوان مثال، اگر یک ستون تنها شامل مقادیر صحیح باشد، بهتر است از نوع داده صحیح به جای نوع داده رشتهای استفاده شود. این کار میتواند به کاهش نیاز به فضای ذخیره و بهبود عملکرد کوئری ها کمک کند.
در انتخاب نوع داده برای هر ستون در جداول Fact و Dimension، باید به نیازهای دادهها و نوع محاسباتی که بر روی آنها انجام میشود توجه کرد. این انتخاب میتواند تاثیر مستقیم بر عملکرد دیتابیس و کارایی کوئری ها داشته باشد.
برای مثال، در جدول Fact حاوی اطلاعات فروش، ستون فروش را میتوان با دو نوع داده decimal و float مشخص کرد. اگر ما از داده decimal استفاده کنیم، دقت محاسبات بالاتر خواهد بود و محاسبات دقیقتری برای مقدار فروش ارائه خواهد کرد. اما اگر از داده float استفاده کنیم، حجم داده کمتر خواهد بود و عملکرد کوئری ها بهبود خواهد یافت.
همچنین، در جدول Dimension حاوی اطلاعات محصولات، ستون نام محصول را میتوان با دو نوع داده varchar و nvarchar مشخص کرد. اگر محصولات با نامهای فارسی و یا کاراکترهای خاص دیگری داشته باشیم، از داده nvarchar برای این ستون استفاده میکنیم تا از پشتیبانی از کاراکترهای چندبایتی پشتیبانی کنیم. در غیر این صورت، از داده varchar برای این ستون استفاده میکنیم تا اندازه داده کوچکتر و عملکرد کوئری ها بهتر باشد.
در نهایت، برای انتخاب نوع داده مناسب برای هر ستون، باید به نیازهای کسب و کار و نیازهای کوئری هایی که بر روی دادهها اجرا میشوند توجه کرد و این انتخاب را بر اساس بهترین توازن میان دقت محاسبات، حجم داده و عملکرد کوئری ها انجام داد.
بهینهسازی بارگیری داده (Data Loading):
بارگیری داده به جداول Factو Dimension میتواند با استفاده از تکنیکهایی از جمله پارتیشنبندی، ایجاد Index و Clustering بهینهسازی شود.
پارتیشنبندی:
شامل تقسیم جداول به بخشهای کوچکتر و قابل مدیریتتر است که با کاهش مقدار دادههایی که باید اسکن شوند، بهبود عملکرد کوئری ها را به ارمغان میآورد. پارتیشن بندی در دیتابیس به معنای تقسیم جدول به بخشهای کوچکتر بر اساس یک یا چند ستون است. این روش بهینهسازی عملکرد کوئریها و کاهش زمان پاسخگویی در دیتابیس میباشد.
یک مثال عملی از پارتیشن بندی، تقسیم جدول Fact فروش به بخشهای کوچکتر بر اساس منطقه جغرافیایی میباشد. فرض کنید که جدول Fact فروش یک شرکت حاوی اطلاعات فروش در کل کشور است. برای بهینهسازی عملکرد کوئری ها و کاهش زمان پاسخگویی، میتوانیم جدول را بر اساس منطقه جغرافیایی مشتریان به بخشهای کوچکتر تقسیم کنیم. به عنوان مثال، میتوانیم جدول Fact را به بخشهای استانی تقسیم کرده و هر بخش جدول فاکت را در یک جدول جدید ذخیره کنیم.
این روش به ما امکان میدهد که کوئریهای مربوط به فروش در یک استان را بر روی جدول Fact مربوط به آن استان اجرا کنیم، بدون اینکه بر روی دادههای دیگر تاثیر بگذاریم. همچنین، اضافه کردن دادههای جدید به دیتابیس سریعتر و بهتر انجام میشود، زیرا میتوانیم فقط دادههای جدید را به جدول Fact استانی اضافه کنیم، بدون اینکه بر روی دادههای قدیمی تاثیر بگذاریم.
بنابراین، پارتیشن بندی برای تقسیم جدول Fact فروش به بخشهای کوچکتر بر اساس منطقه جغرافیایی، یک روش موثر برای بهینهسازی عملکرد کوئریها و کاهش زمان پاسخگویی در دیتابیس است.
توجه داشته باشید که پارتیشن بندی برای تمام جداول دیتابیس مناسب نیست و باید بر اساس نیازهای خاص هر جدول و نوع دادههای موجود در آن، تصمیم گیری شود.
استفاده از پارتیشن بندی برای جداولی با حجم بزرگ و یا برای جداولی که برای آنها کوئریهای سنگین و پیچیده وجود دارد، بهینهسازی عملکرد دیتابیس را بهبود میبخشد. اما برای جداول کوچک با حجم کم و یا جداولی که برای آنها کوئریهای ساده و کمی وجود دارد، پارتیشن بندی ممکن است بهینهسازی مفیدی نباشد و حتی باعث افزایش هزینههای مربوط به نگهداری دیتابیس شود.
به علاوه، پارتیشن بندی برای تمام جداول دیتابیس به دلیل اینکه برای تقسیم جدول به بخشهای کوچکتر نیاز به منابع سخت افزاری و نرمافزاری دارد، ممکن است باعث افزایش هزینههای مربوط به نگهداری دیتابیس شود. بنابراین، بهتر است پارتیشن بندی برای جداولی که نیاز به بهینهسازی دارند، انجام شود و در موارد دیگر از آن استفاده نشود.
بنابراین، برای استفاده از پارتیشن بندی در دیتابیس باید به نیازهای خاص هر جدول و نوع دادههای موجود در آن توجه شود و تصمیم گیری برای پارتیشن بندی بر اساس این نیازها انجام شود.
Indexing :
ایجاد ایندکس شامل ایجاد ایندکس روی ستونهایی است که در کوئری ها بکار میروند و میتواند با ارائه دسترسی سریعتر به داده، عملکرد کوئری ها را بهبود ببخشد. برای ایجاد یک ایندکس در دیتابیس، باید یک یا چند ستون انتخاب شود که بر اساس آنها ایندکس ساخته میشود.
یک مثال عملی از ایجاد ایندکس برای بهبود عملکرد کوئری ها، ایجاد یک ایندکس برای جستجوی سریع مشتریان بر اساس شماره تلفن آنها است. فرض کنید که در جدول مشتریان دیتابیس، ستون شماره تلفن به طور مکرر در کوئری ها استفاده میشود. با ایجاد یک ایندکس برای این ستون، میتوان زمان پاسخگویی به کوئری های جستجوی مشتریان را به مراتب کاهش داد.
برای ایجاد ایندکس برای ستون شماره تلفن، میتوان از دستور زیر در دیتابیس MySQL استفاده کرد:
CREATE INDEX phone_number_index ON customers (phone_number);
این دستور یک ایندکس با نام phone_number_index برای جدول customers و بر اساس ستون phone_number ایجاد میکند. با ایجاد این ایندکس، جستجوی مشتریان بر اساس شماره تلفن آنها به طور چشمگیری سریعتر انجام میشود.
بنابراین، ایجاد ایندکس برای ستونهایی که در کوئریها بسیار استفاده میشوند، میتواند به بهبود عملکرد دیتابیس کمک کند و زمان پاسخگویی به کوئریها را به مراتب کاهش دهد.
کلاسترینگ :
شامل سازماندهی فیزیکی دادهها در جداول به گونهای است که احتمالاً دادههای مرتبط در نزدیکی هم بر روی دیسک ذخیره شوند که باعث بهبود عملکرد کوئریها میشود. کلاسترینگ در دیتابیس به معنای تقسیم جدول به چندین گروه بر اساس یک یا چند ستون است. در کلاسترینگ، ردیفهای جدول که بر اساس مقدار ستونهای مشخصی با یکدیگر مشابه هستند، با هم گروهبندی شده و در یک کلاستر (گروه) قرار میگیرند.
یک مثال عملی از کلاسترینگ، تقسیم جدول فاکت فروش به چندین گروه بر اساس منطقه جغرافیایی میباشد. فرض کنید که جدول فاکت فروش یک شرکت حاوی اطلاعات فروش در کل کشور است. برای کلاسترینگ، میتوانیم جدول را بر اساس منطقه جغرافیایی مشتریان به چندین گروه تقسیم کنیم. به عنوان مثال، میتوانیم ردیفهایی که مربوط به فروش در شمال کشور هستند را در یک کلاستر جداگانه قرار دهیم و ردیفهای مربوط به فروش در جنوب کشور را در کلاستر دیگری قرار دهیم.
با استفاده از کلاسترینگ، کوئری های مربوط به فروش در یک منطقه خاص در کمترین زمان ممکن پاسخ داده میشود و بهبود عملکرد دیتابیس را بهبود میبخشد. همچنین، کلاسترینگ میتواند به ما امکان دهد که دادههای مربوط به هر کلاستر را در یک فضای فیزیکی جداگانه قرار دهیم، که میتواند به بهبود عملکرد دیتابیس کمک کند.
بنابراین، کلاسترینگ برای تقسیم جدول به چندین گروه بر اساس مقدار ستونهای مشخصی، یک روش مفید برای بهبود عملکرد کوئری ها و کاهش زمان پاسخگویی در دیتابیس است
کلاسترینگ در تمام دیتابیسها قابل اجرا نیست و تنها در برخی از دیتابیسها پشتیبانی میشود. مثلاً در دیتابیس MySQL، کلاسترینگ با استفاده از موتورهای ذخیرهسازی InnoDB و NDB Cluster قابل اجرا است، اما در دیتابیس SQLite این قابلیت وجود ندارد.
علاوه بر این، برای اجرای کلاسترینگ در دیتابیس، باید دادهها بر اساس یک یا چند ستون تقسیم شوند. در برخی از دیتابیسها، این عملیات به صورت پیش فرض پشتیبانی نمیشود و باید از روشهای دیگری مانند پارتیشن بندی
فشرده سازی : (Compression)
روشهای فشردهسازی میتوانند برای کاهش میزان فضای ذخیره سازی مورد نیاز برای جداول واقعیت و ابعاد استفاده شوند. به عنوان مثال، میتوانید از فشردهسازی سطح ستون برای فشرده سازی دادههای موجود در جدول واقعیت و یا از فشردهسازی سطح صفحه برای فشرده سازی دادههای موجود در جدول ابعاد استفاده کنید.
با استفاده از فشردهسازی، میتوانید از فضای دیسک آزاد شده استفاده کنید و عملکرد کوئریهای خود را بهبود بخشید.
در این راستا، چندین روش فشردهسازی موجود است که بسته به نوع دادهای که در حال ذخیرهسازی است و سیستم ذخیرهسازی استفاده شده، میتوانید از آنها استفاده کنید.
یکی از رویکردهای متداول، استفاده از فشردهسازی سطح ستون Column-level compression است که دادههای موجود در ستونهای جدول واقعیت را فشرده میکند. در این روش، دادههای موجود در ستونهای جدول واقعیت فشرده میشوند. این روش برای ستونهایی که دارای دادههای تکراری یا تکراری هستند، کارآمد است. برای مثال، فشرده سازی ستون تاریخ، که تاریخهای مشابهی در ستون وجود دارد، میتواند فضای ذخیرهسازی را کاهش دهد.
رویکرد دیگر، استفاده از فشردهسازی سطح صفحه Page-level compression است که صفحات کاملی از دادهها در جدول ابعاد را فشرده میکند. این روش برای جداولی که دارای تعداد بالای ستون یا درصد بالای خالی بودن سلولها هستند، مفید است. در این روش، یک لغتنامه برای دادههای موجود در جدول ایجاد میشود و دادهها با استفاده از این لغتنامه فشرده میشوند. برای مثال، اگر یک جدول شامل کشورها با نامهای کامل آنها باشد، میتوان با استفاده از یک لغتنامه کوچکتر، نام کشورها را به فرم کوتاهتری فشرده کرد.
روشهای دیگری مانند فشردهسازی مبتنی بر فرهنگ لغت Dictionary-based compression، رمزگذاری دوطرفه، رمزگذاری رانلنگ و رمزگذاری دلتا نیز ممکن است استفاده شوند.
- Run-length encoding: در این روش، دادههایی که دارای الگوهای تکراری هستند، فشرده میشوند. برای مثال، اگر یک جدول شامل دادههای مربوط به یک سیگنال صوتی باشد، میتوان با استفاده از رمزگذاری رانلنگ، دادههای مربوط به دورههای صدایی تکراری را فشرده کرد.
- Delta encoding: در این روش، فقط تغییرات اعمال شده به دادهها در جدول ذخیره میشوند. برای مثال، اگر یک جدول شامل اطلاعات مربوط به موقعیت جغرافیایی باشد، میتوان با استفاده از رمزگذاری دلتا، فقط تغییرات موقعیت جغرافیایی را ذخیره کرد.
هر یک از این روشها نقاط قوت و ضعف خود را دارند و بهترین روش بسته به نیازهای خاص انبار داده شما متفاوت است.
البته باید توجه داشت که هر چند فشردهسازی میتواند در کاهش میزان فضای ذخیره سازی کمک کند، اما ممکن است بر عملکرد کوئریهای شما تأثیر بگذارد. دادههای فشرده شده ممکن است برای بازگشت به حالت اولیه زمان بیشتری را از طریق باز فشردهسازی بردارند و کوئریها ممکن است نیاز به پردازش اضافی برای کار با دادههای فشرده شده داشته باشند. به همین دلیل، لازم است که بهبود عملکرد کوئریها را با تأثیر فشردهسازی بر کارایی کلی سیستم دقیقاً متعادل کنید.
بهینهسازی عملکرد کوئری:
عملکرد کوئری را میتوان با استفاده از تکنیکهایی از جمله بهینهسازی کوئری، حافظه نهان و تنظیم کوئری بهینهسازی کرد. بهینهسازی کوئری شامل بهینهسازی کوئریهای SQL است که در برابر انبار داده (Data Warehouse)اجرا میشوند و با کاهش مقدار دادههایی که باید اسکن شوند و استفاده بهینه از ایندکسها، عملکرد کوئریها را بهبود میبخشد. حافظه نهان شامل ذخیره دادههایی است که به طور مکرر دسترسی دارند و باعث بهبود عملکرد کوئریها میشود. تنظیم کوئری بهینهسازی شامل تحلیل کوئریها و ایجاد تغییرات برای بهبود عملکرد آنها، مانند نوشتن مجدد کوئریها یا ایجاد ایندکس جدید است.
نمای تحقق یافته : (Materialized View)
یک Materialized View ، یک شیء پایگاه دادهای است که حاوی نتایج یک کوئریی پیشفرض است. بر خلاف یک نمایش معمولی که فقط یک کوئریی SQL را ذخیره میکند و هر بار که نمایش دسترسی پیدا کند، آن را اجرا میکند، یک Materialized Viewنتایج کوئری را در یک ساختار شبیه جدول ذخیره میکند، که باعث افزایش سرعت دسترسی به دادهها میشود.
Materialized View اغلب در برنامههای انبار داده و هوش تجاری برای بهبود عملکرد کوئری استفاده میشود. با پیشفرض محاسبات نتایج کوئریهای پیچیده و ذخیره آنها در یک نمایش مواد، کاربران میتوانند به جای دسترسی به جداول اصلی، به صورت سریعتری به دادهها دسترسی پیدا کنند.
Materialized View میتواند به صورت دورهای بروزرسانی شود تا اطمینان حاصل شود که دادهها بهروز باشند. روشهای مختلفی برای بروزرسانی Materialized Viewوجود دارد که شامل بروزرسانی کامل با دوباره محاسبه کوئری و ذخیره مجدد نتایج، یا بروزرسانی به صورت تدریجی با بهروزرسانی فقط بخشهایی از Materialized Viewکه از زمان بروزرسانی قبلی تغییر کردهاند، میشود.
یکی از مزایای اصلی نمایش مواد، بهبود قابل توجه عملکرد کوئری است، به خصوص برای کوئریهای پیچیده که شامل Join و aggregation هستند. با پیشفرض نتایج این کوئریها، کاربران میتوانند از هزینه اجرای آنها برای هر بار دسترسی به دادهها جلوگیری کنند، که در برنامههایی که نیاز به دسترسی به دادههای زمان واقعی یا نزدیک به زمان واقعی دارند، بسیار مهم است.
با این حال، Materialized View همچنین محدودیتهایی دارد. به دلیل ذخیره نتایج پیشفرض، میتواند حجم قابل توجهی از فضای دیسک را اشغال کند، به خصوص اگر به صورت دورهای بهروزرسانی شود یا حاوی حجم زیادی از داده باشد. به علاوه، بروزرسانی Materialized View ممکن است زمانبر باشد و ممکن است بر عملکرد کوئریهای دیگر که در همان زمان اجرا میشوند، تأثیر بگذارد.
در کل، Materialized View میتواند یک ابزار قدرتمند برای بهبود عملکرد کوئری در برنامههای انبار داده و هوش تجاری باشد. با این حال، باید با دقت و با توجه به تأثیر آن بر عملکرد کلی سیستم و مصرف منابع، از آن استفاده شود.
فرض کنید یک پایگاه داده دارید که داده های فروش را برای یک شرکت خرده فروشی بزرگ ذخیره می کند. شما جدولی به نام «فروش» دارید که شامل جزئیات هر تراکنش، از جمله تاریخ، محصول فروخته شده، فروشگاهی که فروش در آن انجام شده و مبلغ فروش را در خود دارد.
شما می خواهید بتوانید به سرعت به سوالاتی مانند “کل درآمد هر فروشگاه در ماه گذشته چقدر بوده” پاسخ دهید؟ برای انجام این کار، ممکن است یک پرس و جو بنویسید که جدول فروش را با جدول فروشگاه ها بپیوندد و نتایج را بر اساس فروشگاه و ماه گروه بندی کند:
SELECT stores.name, DATE_TRUNC(‘month’, sales.date) AS month, SUM(sales.amount) AS revenue
FROM sales
JOIN stores ON sales.store_id = stores.id
WHERE sales.date >= DATE_TRUNC(‘month’, CURRENT_DATE) – INTERVAL ‘1 month’
GROUP BY stores.name, month;
این کوئری نسبتاً پیچیده است و شامل یک پیوستن و یک تجمیع است. بسته به اندازه جدول فروش و تعداد فروشگاهها، هر بار که به دادهها نیاز دارید، ممکن است زمان زیادی طول بکشد.
برای سرعت بخشیدن به این پرس و جو، می توانید یک نمای مادی ایجاد کنید که نتایج این کوئری را از قبل محاسبه کرده و آنها را در یک ساختار جدول مانند ذخیره کند. Materialized View به طور منظم به روز می شود تا اطمینان حاصل شود که داده ها به روز هستند. سپس، هنگامی که نیاز دارید به سؤالی مانند «کل درآمد هر فروشگاه در ماه گذشته چقدر بوده است؟» پاسخ دهید، میتوانید بهجای اجرای کوئری پیچیده هر بار، به سادگی Materialized View را جستجو کنید.
در اینجا نمونه ای از نحوه ایجاد نمای مادی بر اساس کوئری بالا آورده شده است:
CREATE MATERIALIZED VIEW monthly_revenue_by_store AS
SELECT stores.name, DATE_TRUNC(‘month’, sales.date) AS month, SUM(sales.amount) AS revenue
FROM sales
JOIN stores ON sales.store_id = stores.id
GROUP BY stores.name, month;
سپس می توانید نمای مادی شده را به طور منظم با استفاده از دستوری مانند این بازخوانی کنید:
REFRESH MATERIALIZED VIEW monthly_revenue_by_store;
به طور کلی، این Materialized View به طور قابل توجهی عملکرد جستجوهایی را که شامل محاسبه درآمد ماهانه توسط فروشگاه است، با پیش محاسبه نتایج و ذخیره آنها در یک ساختار جدول مانند برای دسترسی سریعتر، بهبود می بخشد.
نتیجه :
به طور کلی، بهینهسازی جداول Fact و Dimension از در انبار داده (Data Warehouse)، نیازمند توجه دقیق به نیازهای کسب و کار، طراحی قالب، نوع داده، بارگیری داده، و عملکرد کوئری میباشد. با دنبال کردن این مراحل، میتوانید اطمینان حاصل کنید که انبار داده (Data Warehouse)شما بهینه، موثر و قابل پشتیبانی از نیازهای کسب و کار سازمان خواهد بود.