انبار داده (دیتاورهاوس – Data Warehouse) چیست؟

انبار داده (Data Warehouse) یک پایگاه داده رابطه ای (Relational Database) است که برای هدف پرس و جو و تحلیل طراحی شده است و با پایگاه داده (Database) که مدیریت ثبت و  پردازش تراکنش های کسب و کار است، کاملا متفاوت است.

انبار داده شامل داده های تاریخی (Historical) است که از داده های تراکنشی (Transactional) مشتق می شود اما می تواند منابع داده ای دیگر را نیز شامل شود. انبار داده تحلیل را از تراکنش جدا می کند و به سازمان اجازه می دهد که منابع مختلف داده ای را با یکدیگر تلفیق و یکپارچه کند. به علاوه انبار داده شامل عملیات استخراج (Extract)، تبدیل(Transform) و بارگذاری داده (Load) است که به اختصار به آن ETL گفته می شود که طی این فرآیند جمع آوری، پاکسازی و انتقال داده از پایگاه داده به انبار داده صورت می گیرد.

یک انبار داده باید 4 ویژگی اصلی را داشته باشد:

موضوع گرا (Subject-Oriented)

انبار داده برای درک و تحلیل داده های کسب و کار طراحی می شود. به طور مثال برای درک و تحلیل داده های فروش باید انبار داده ای طراحی شود که در آن داده ها بر فروش تمرکز دارند که این انبار داده می تواند به سوالاتی از قبیل مهترین مشتری من در سال گذشته چه کسی بوده است؟ پاسخ دهد. این قابلیت که انبار داده بر اساس یک موضوع طراحی شود باعث می شود که آن را موضوع گرا کند. البته باید توجه داشت در برخی از رویکرد ها انبار داده از چندین Data Mart تشکیل می شود. به طور مثال یک انبار داده می تواند از دیتا مارت های فروش، منابع انسانی و … تشکیل شود که می توان گفت هر دیتا مارت دارای موضوع مشخص می باشد.

یکپارچه (Integrated)

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

غیر فرار (Non-Volatile)

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

متغیر با زمان (Time-Variant)

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

تفاوت های پایگاه داده و انبار داده

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

یکی از مهمترین و اصلی ترین تفاوت های پایگاه داده و انبار داده در درجه نرمال سازی آن ها است. در حالی که پایگاه داده تا حد امکان نرمال طراحی می شود، تا برای عملیات Insert، Update و Delete و همچنین اطمینان از ثبات داده (consistency) بهینه باشند، انبار داده تا جای ممکن به صورت دی نرمال طراحی می شود تا برای هدف پرس و جو، گزارش گیری و تحلیل، بهینه باشد. در واقع پایگاه داده نرمال طراحی می شود تا از تکرار (Duplication) جلوگیری شود، فضای ذخیره سازی کاهش یابد و عملکرد بهینه شود و همچنین از ثبات داده در پایگاه داده اطمینان حاصل شود. همان طور که در تصویر قابل مشاهده است در پایگاه داده جداول مربوط به کالا به صورت نرمال طراحی شده است و برای گروه کالا، زیر گروه کالا و کالا، 3 جدول مجزا در نظر گرفته شده است در حالی که در انبار داده می توان جداول را به صورت دی نرمال و در قالب یک جدول طراحی نمود.

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

تفاوت طراحی انبار داده با رویکرد Star و Snow Flake

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

طراحی Star

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

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

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

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

طراحی Snow Flake

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

رویکردهای بالا به پایین و پایین به بالا در طراحی انبار داده

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

رویکرد طراحی بالا به پایین

این رویکرد در طراحی انبار داده توسط آقای بیل اینمون (Bill Inmon) مطرح شده است. در این رویکرد ابتدا یک انبار داده جامع و کامل طراحی می شود. در واقع در این رویکرد داده از منابع داده ای مختلف استخراج، پاکسازی و در بالاترین سطح ریز دانگی در یک انبار داده جامع ذخیره می شود. سپس از دل این انبار داده Data Mart های کوچک برای هر بخش سازمان خارج می شود و می تواند متناسب با نیاز آن بخش سفارشی سازی و پاکسازی گردد. این رویکرد ثبات و یکپارچگی را تضمین می کند چرا که Data Mart ها از یک انبار داده آماده و پردازش شده استخراج می شوند در مقابل این رویکرد هزینه و زمان بالایی را طلب می کند و نیازمند افراد با توانایی و تجربه بالا می باشد.

رویکرد طراحی پایین به بالا

این رویکرد توسط آقای رالف کیمبل (Ralph Kimball) معرفی شده است. در واقع در این رویکرد Data Mart های کوچک متناسب با نیاز هر بخش سازمان (فروش، منابع انسانی و …) طراحی می شود و سپس انبار داده جامع سازمان از تجمیع این Data Mart ها به وجود می آید. در این رویکرد داده های مرتبط به بخش خاصی از سازمان از منابع داده ای استخراج و در Data Mart ها بارگذاری می شوند و مجموعه ی این Data Mart ها انبار داده سازمان را به وجود می آورند. از مزایای این رویکرد می توان به پیاده سازی سریع این رویکرد اشاره کرد. همچنین این رویکرد برای توسعه مناسب تر است. چرا که با ایجاد نیاز جدید Data Mart مربوط به آن ایجاد و در نهایت در انبار داده سازمان تجمیع می شود. در مقابل نگهداری دشوار تر و امکان ایجاد تکرار و موازی کاری وجود دارد.

برای آشنایی با ابزار های مربوط به ساخت انبار داده می توانید مطالب مربوط به ابزارهای Oracle BI و Microsoft BI را مطالعه نمایید.