به‌منظور انجام عملیات خاصی توسط query موردنظر، نمایه‌ای پیش تعریف شده (Generate prepopulated views) را بر روی داده‌ها در یک یا چند ذخیره‌گاه داده (data store) ایجاد کنید، زمانی که داده‌ها به بهترین شکل برای انجام عملیات query موردنیاز فرمت نشده باشند. این کار می‌تواند به انجام پرس‌وجوی کارآمد و استخراج بهینه از داده‌ها و بهبود عملکرد برنامه کمک کند.
هنگام ذخیره داده‌ها اولویت برای توسعه‌دهندگان و مدیران داده‌ها (data administrators) اغلب بر نحوه ذخیره داده‌ها متمرکز است و نه نحوه خواندن آنها. فرمت ذخیره‌سازی انتخاب شده معمولاً با فرمت داده‌ها، الزامات مدیریتی در سایز داده‌ها و یکپارچگی و نوع ذخیره‌شدن آنها، ارتباط نزدیکی دارد. به‌عنوان‌مثال، هنگام استفاده از ذخیره‌سازی اسناد NoSQL، داده‌ها اغلب به‌صورت دنباله‌ای از مجموعه‌ها نشان داده می‌شوند که هر کدام شامل تمام اطلاعات مربوط به آن موجودیت است. به‌هرحال، این گزینه می‌تواند تأثیر منفی بر کوئری‌ها داشته باشد. هنگامی که یک کوئری فقط به زیرمجموعه‌ای از داده‌ها و در برخی موجودیت‌ها نیاز دارد، مانند خلاصه‌ای از سفارش‌ها برای چندین مشتری بدون دانستن تمام جزئیات سفارش، آنگاه باید تمام داده‌ها را برای موجودیت‌های مربوطه استخراج کند تا اطلاعات موردنیاز را به دست آورد.
برای پشتیبانی از کوئری به شیوه مناسب یک راه‌حل متداول این است که؛ دیدگاهی تولید شود که داده‌ها را در فرمت مناسب با مجموعه نتیجه‌های موردنیاز، امکان‌پذیر کند. الگوی Materialized View تولید نماهای ازپیش‌ساخته شده (generating prepopulated views) داده‌ها را در محیط‌هایی توصیف می‌کند که داده‌های مبدأ در فرمت مناسب برای query نیستند، جایی که ایجاد یک کوئری مناسب دشوار است یا جایی که کارایی کوئری‌ها به دلیل ماهیت داده‌ها یا ذخیره‌سازهای آنها بسیار ضعیف است. این materialized viewها که فقط حاوی داده‌های موردنیاز یک کوئری هستند که به برنامه‌ها و اپلیکیشن‌ها فرصت این را می‌دهد تا به‌سرعت اطلاعات موردنیاز خود را به دست آورند. علاوه بر پیوستن به جدول‌ها (joining tables) یا ترکیب موجودیت‌های داده‌ها، materialized view می‌توانند شامل مقادیر محاسبه‌شده از ستون‌ها یا آیتم‌های داده‌ای باشد و نتیجه ترکیب این مقادیر یا اجرای تبدیل‌ها بر روی اقلام داده و مقادیر مشخص‌شده به‌عنوان بخشی از فرایند کوئری باشند. یک materialized view حتی می‌تواند تنها برای یک کوئری بهینه شود. یک نکته کلیدی این است که یک materialized view و داده‌های موجود در آن کاملاً یکبار مصرف است زیرا می‌توان آن را به طور کامل از منابع ذخیره‌گاه داده‌ها را بازسازی کرد. materialized view هرگز مستقیماً توسط یک برنامه به‌روزرسانی نمی‌شود و بنابراین یک cache یا حافظه موقت خاص است. هنگامی که source data برای نما (view) تغییر می‌کند، view باید برای گنجاندن اطلاعات جدید به‌روز شود. می‌توانید این کار را به طور خودکار یا زمانی که سیستم تغییری در داده‌های اصلی تشخیص دهد، برنامه‌ریزی کنید. در برخی موارد ممکن است لازم باشد که view را به‌صورت دستی بازسازی کنید. شکل زیر نمونه‌ای از نحوه استفاده از الگوی materialized view شده را نشان می‌دهد.
هنگام تصمیم‌گیری در مورد نحوه اجرای این الگو به نکات زیر توجه کنید: چگونه و چه زمانی نما(view) به‌روزرسانی می‌شود. در حالت ایده‌آل، در پاسخ به رویدادی که نشان‌دهنده تغییر در داده‌های منبع (source data) است، تولید می‌شود، به‌هرحال اگر داده‌های منبع به‌سرعت تغییر کنند، می‌تواند منجر به سربار بیش از حد شود. روش دیگر، استفاده از یک تسک زمان‌بندی‌شده (scheduled) است و همین‌طور یک تحریک (trigger) خارجی یا یک اقدام دستی برای بازسازی view را در نظر بگیرید. در برخی از سیستم‌ها، مانند زمانی که از الگوی Event Sourcing pattern استفاده می‌شود تا ذخیره‌ای از رویدادهایی که داده‌ها را تغییر داده‌اند را نگهداری کند، استفاده از materialized view ضروری هستند. از پیش یکپارچهسازی نماها با بررسی همه رویدادها برای تعیین وضعیت فعلی برنامه ممکن است تنها راه برای به‌دست‌آوردن اطلاعات از event store باشد. اگر از Event Sourcing استفاده نمی‌کنید، باید در نظر بگیرید که آیا یک materialized view مفید است یا خیر. materialized view به طور خاص برای یک یا تعداد کمی از کوئری‌ها تنظیم می‌شوند. اگر کوئری‌های زیادی استفاده شود، materialized view می‌تواند منجر به نیازهای ظرفیت ذخیره‌سازی غیرقابل‌قبول و هزینه ذخیره‌سازی شود. هنگام ایجاد نما و در صورت بروز این اتفاق در یک زمان‌بندی(schedule) یا در حین به‌روزرسانی نما، حتماً تأثیر آن را بر روی پایداری داده‌ها(data consistency) را در نظر بگیرید. اگر داده‌های منبع در نقطه‌ای که نما تولید می‌شود در حال تغییر باشد، کپی داده‌ها در نما کاملاً با داده‌های اصلی یکپارچه و سازگار نخواهد بود. حتماً محل ذخیره نما را در نظر بگیرید. لازم نیست نما در همان ذخیره‌گاه یا پارتیشن داده اصلی قرار گیرد. حتی می‌تواند زیرمجموعه‌ای از چند پارتیشن مختلف باشد. در صورت مفقودشدن یک نما(view)، می‌توان آن نما را بازسازی کرد. به همین دلیل، اگر view گذرا باشد و فقط برای بهبود عملکرد query با انعکاس وضعیت فعلی داده‌ها یا بهبود مقیاس‌پذیری استفاده شود، می‌توان آن را در حافظه cache یا در مکانی کمتر قابل‌اطمینان ذخیره کرد.
هنگام تعریف materialized view، مقادیر را به کمک راه‌حل‌هایی مثل افزودن آیتم‌های داده یا ستون‌ها به آن بر اساس توان محاسباتی یا تبدیل آیتم داده‌های موجود یا به کمک مقادیر ارسال شده در query یا ترکیبی از این مقادیر در صورت نیاز، به حداکثر برسانید.
در جایی که سازوکار ذخیره‌سازی پشتیبانی می‌شود، پیشنهاد می‌شود index کردن materialized view را برای افزایش بیشتر کارایی برنامه در نظر بگیرید. اکثر پایگاه‌های داده رابطه‌ای از رویش index کردن برای viewها پشتیبانی می‌کنند، مانند راه‌حل‌های کلان‌داده (big data) مبتنی بر Apache Hadoop.
این الگو زمانی مفید است که:
* ایجاد materialized views بر روی داده‌هایی که اجرای query به‌صورت مستقیم روی آنها دشوار است یا در جایی که queryها باید بسیار پیچیده باشند تا داده‌هایی را که به‌صورت عادی، نیمه‌ساختاریافته یا بدون ساختار ذخیره می‌شوند، استخراج کنند.
* ایجاد viewهای موقتی که می‌تواند عملکرد query را به طور چشمگیری بهبود بخشد که می‌تواند مستقیماً به‌عنوان source views یا objectهای انتقال داده برای رابط کاربری، گزارش‌دهی یا نمایش عمل کند.
* پشتیبانی از حالت‌های گاهی متصل یا گاهی اتصال قطع شده که در آن اتصال به data store همیشه در دسترس نیست. در این مورد می‌توان نما را به‌صورت محلی(locally) ذخیره کرد.
* ساده‌سازی کوئری‌ها و نمایش داده‌ها برای آزمایش به شیوه‌ای که نیازی به دانش فرمت داده‌های منبع ندارد. برای مثال، با پیوستن جداول مختلف در یک یا چند پایگاه‌داده یا یک یا چند دامنه در NoSQL، و سپس فرمت‌بندی داده‌ها برای استفاده نهایی آنها.
* ارائه دسترسی به زیرمجموعه‌های خاصی از داده‌های منبع که به دلایل امنیتی یا حفظ حریم خصوصی، عموماً نباید در دسترس باشند؛ ولی قابل‌تغییر باشند یا به طور کامل در معرض دید کاربران قرار نگیرند.
* پل زدن data storeهای داده مختلف، برای استفاده از قابلیت‌های فردی آنها. به‌عنوان‌مثال، استفاده از یک cloud store که برای نوشتن به‌عنوان ذخیره داده مرجع کارآمد است و یک پایگاه‌داده رابطه‌ای که query و خواندن داده به‌صورت مناسب و خوبی را برای نگهداری materialized viewها ارائه می‌دهد.
* هنگام استفاده از میکروسرویس‌ها توصیه می‌شود که ارتباط سرویس‌ها به‌صورت loosely coupled باشد و این شامل ارتباط با data storage نیز می‌شود؛ بنابراین، materialized viewها می‌توانند به شما در یکپارچهسازی داده‌های سرویس موردنظر کمک کنند. اگر materialized view در معماری میکروسرویس‌ها یا سناریوی خاص شما مناسب نیستند، بهتر است مرزهای کاملاً مشخص شده‌ای داشته باشید که با طراحی domain driven design (DDD) تراز باشد و داده‌های آنها را در صورت درخواست جمع‌آوری کنید.
این الگو در شرایط زیر مفید نیست: * داده‌های منبع (source data) ساده و آسان برای انواع query باشد.
* داده‌های منبع خیلی سریع تغییر می‌کنند یا می‌توان بدون استفاده از viewها به آنها دسترسی داشت. در این موارد، باید از سربار پردازش ایجاد viewها اجتناب کنید.
* یکپارچگی و پایداری (Consistency) اولویت بالایی دارد. viewها ممکن است همیشه با داده‌های اصلی مطابقت کامل نداشته باشند.
شکل زیر نمونه‌ای از استفاده از الگوی Materialized View برای تولید خلاصه‌ای از یک سناریو مربوط به فروش را نشان می‌دهد. داده‌های موجود در جداول Order، OrderItem و Customer در پارتیشن‌های جداگانه در یک حساب ذخیره‌سازی Azure ترکیب می‌شوند تا یک view حاوی کل ارزش فروش برای هر محصول در دسته Electronics، همراه با شمارش تعداد مشتریانی که هر موردی را خرید کرده‌اند، ایجاد کنند.
ایجاد این materialized view نیاز به queryهای پیچیده دارد. بااین‌حال، با نمایش نتیجه query به‌عنوان یک materialized view، کاربران می‌توانند به‌راحتی نتایج را به دست آورند و مستقیماً از آنها استفاده کنند یا آنها را در query دیگری بگنجانند. این نما احتمالاً در یک سیستم گزارش‌دهی یا داشبورد استفاده می‌شود و می‌تواند به‌صورت برنامه‌ریزی‌شده مانند هفتگی به‌روزرسانی شود.
اگرچه این مثال از Azure table storage استفاده می‌کند؛ اما بسیاری از سیستم‌‌های مدیریت پایگاه‌داده رابطه‌ای نیز پشتیبانی native را برای materialized views ارائه می‌کنند.
* Data Consistency Primer اطلاعات خلاصه در یک materialized view باید به‌گونه‌ای نگهداری شود که مقادیر داده‌های اساسی را منعکس کند. با تغییر مقادیر داده‌ها، ممکن است به‌روزرسانی خلاصه داده‌ها در زمان واقعی عملی نباشد، و در عوض باید یک رویکرد در یکپارچگی تدریجی(eventually consistent) را اتخاذ کنید. این مورد مسائل مربوط به حفظ ثبات در داده‌های توزیع شده را بیان می‌کند و مزایا و معاوضه‌های مدل‌های یکپارچگی مختلف را شرح می‌دهد.
الگوهای زیر نیز ممکن است هنگام اجرای این الگو مرتبط باشند: * الگوی Command and Query Responsibility Segregation (CQRS) pattern را برای به‌روزرسانی اطلاعات در materialized view با پاسخ‌دادن به رویدادهایی که هنگام تغییر مقادیر داده‌های اساسی رخ می‌دهند، استفاده کنید.
* الگوی Event Sourcing pattern در ارتباط با الگوی CQRS برای حفظ اطلاعات در یک materialized view استفاده کنید. هنگامی که مقادیر داده‌ای که یک materialized view بر اساس آن است، تغییر می‌کند، سیستم می‌تواند رویدادهایی را که این تغییرات را توصیف می‌کنند، افزایش دهد و آنها را در یک فروشگاه رویداد ذخیره کند.
* الگوی Index Table pattern. داده‌ها در materialized view معمولاً توسط یک کلید اصلی سازمان‌دهی می‌شوند، اما پرس‌وجوها (query) ممکن است نیاز به بازیابی اطلاعات از این viewها با بررسی داده‌ها در فیلدهای دیگر داشته باشند. در نتیجه باید برای ایجاد ایندکس‌‌های ثانویه روی datasetهایی که برای ذخیره‌سازی داده‌ها از ایندکس‌‌های ثانویه native پشتیبانی نمی‌کنند، استفاده کنید.