انبار داده چیست ؟
در این ویدیو میخواهیم که یک سری توضیحات در مورد انبار داده بدهیم که درک آن از اهمیت بالایی برخوردار است.
برای طراحی یک انبار داده خوب نیاز به آگاهی کامل از چیستی و ویژگی های آن داشته باشیم.
در بحث تئوری در مورد DWH دو نظریه پرداز داریم. یکی رالف کیمبال و دیگری بیل اینمون.
تعاریف این دو تقریبا میتوان گفت برعکس همدیگر هست. یکی از آنها نگاه بالا به پایین و دیگری نگاه پایین به بالا دارد.
تعریف بیل اینمون :
A subject Oriented Integrated , Nonvolatile , Time Variant Collection of Data In Support of Management Decision System.
یک مجموعه موضوع گرا ، یکپارچه ، ماندگار و متغیر با زمان در پشتیبانی از یک سیستم تصمیم یار است.
حال این تعریف را به چند بخش تقسیم کرده و هر بخش را توضیح میدهیم :
موضوع گرایی :
انبار داده ما باید دیدگاه و جنبه هایی را دارا باشد که کسب و کار را به وسیله آنها تحلیل و بررسی میکند.
برای مثال در زمینه فروش یکی از این دیدگاه هایی که داریم ، Product است. یا میتوان Customer را مثال زد.
فرض کنید یک دیتابیس OLTP همانند تصویر پایین داریم :
حالا وقتی میخواهیم انبار داده را طراحی کنیم ، با توجه به OLTP سعی میکنیم هر یک از این جداول را که دارای مفهوم نزدیک به هم هستند ، با هم یکی کنیم. برای مثال مشتری و گروه مشتری مفهوم مشتری را به ما میرسانند و در انبار داده میتوانیم آنها را به عنوان Dim Customer در نظر بگیریم.
در هر بیزینس یک سری اطلاعات هستند که تحلیل بر مبنای آنها صورت میگیرد. یعنی اگر بخواهیم ببینیم که روند کسب و کارمان صعودی است یا نزولی ، باید آنها را بررسی کنیم. مثلا فروش و مرتبطات آن را بررسی میکنیم که اوضاع بیزینس را درک کنیم. این اطلاعات به صورت تراکنشی هستند که در هر دقیقه و ساعت در حال ثبت شدن هستند و به آنها جداول فکت (Fact) اطلاق می شود.
پس این فکت ها هستند که اوضاع ما را نشان میدهند و بر اساس آنها برای آینده تصمیم گیری میکنیم. برای مثال اگر فروش و تعداد فاکتور ها زیاد میشود ، میتوان تحلیل کرد که باید تهیه مواد اولیه و تولید کارخانه را با سرعت بیشتری پیش برد.
در کل میتوان گفت در یک سیستم هوش تجاری ، هدف سنجش تراکنش ها بر مبنای موضوعات(Dimensions) مختلف است.
این شناسایی دایمنشن و فکت ها خیلی مهم هست و بنا بر تجربه این قدرت شناسایی به دست میاید. ولی به صورت تجربی میتوان گفت جداولی که به اطلاعات تجمیعی آنها نیاز داریم مانند Sumیا میانگین ، جدول فکت نام دارد. جداولی که بیشتر توصیف و توضیحات را شامل میشوند ، Dimension های ما هستند و محاسباتی که روی آنها صورت میگیرد در حد Count است.
نرخ تغییرات دیتا در جداول دایمنشن به نسبت فکت خیلی کمتر است.
در طراحی DWH معمولا بیشترین حجم اطلاعات مربوط به جداول فکت است که مدام دیتای آنها در حال افزایش است و معمولا در اسکیل میلیون هستند.
خب تا اینجا بحث موضوع گرایی را بررسی کردیم. بحث بعد یکپارچگی انبار داده هست.
یکپارچگی اطلاعات :
منظور از یکپارچگی اطلاعات ، یکپارچگی داده های تجمیع شده در انبار داده است.
وقتی اطلاعات داخل انبار داده قرار میگیرند یعنی باید از لحاظ فرمت و دیتا تایپ یکسان باشند ، برای مثال در فیلد تاریخ ، باید همه تاریخ ها یا شمسی باشند یا میلادی.
یکپارچگی را از چند جنبه باید بررسی کرد :
– نوع داده یا دیتا تایپ : برای مثال در فیلد تاریخ در یک سری منابع ممکن است تایپ این ستون ، String باشد و در یک سری منابع دیگر ، تایپ تاریخ Date باشد. برای انبار داده باید تصمیم گیری کنیم که دیتاتایپ یا باید رشته ای باشد یا به صورت تاریخ Date.
– فرمت یا ساختار داده : برای این مورد دوباره از فیلد تاریخ مثال میزنیم. در یک سری منابع داده ممکن است فرمت تاریخ به صورت YYYY/MM/DD و در یک سری منابع دیگر به صورت YYYY/DD/MM باشد که برای ورود اطلاعات به انبار داده باید یک نوع از این فرمت ها را انتخاب کرد.
– واحد اندازه گیری و ارزی : ممکن است در برخی سورس ها قیمت ها به صورت ریال و در برخی به صورت دلار باشد. یا برای فیلد اندازه کالا به عنوان مثال از دو نوع واحد اندازه گیری متر و سانتی متر استفاده شده باشد که باید این ها را یکی کنیم.
* این یکپارچگی هنگام انتقال اطلاعات از منابع داده ای به انبار داده در مرحله ETL باید صورت بگیرد.
– مدیریت مقادیر Null یا نامعتبر : برای مثال در فیلد سن عدد ۲۰۰ را داریم ، یا در یک فیلد دیگر مقادیر Null یا Missing Value را داریم. باید با مشورت سایر افراد برای نحوه برخورد با این مقادیر تصمیم گیری کنیم. ممکن است اصلا نیازی به تحلیل اطلاعات آن ستون نباشد برای همین اصلا روی مقادیر آن ستون وقت نمیگذاریم.
– مدیریت داده های پایه یا Master Data : اطلاعات درون موضوعات Dim را پوشش میدهد.
فرض کنید در بیزینسی که داریم هر شعبه به کل کشور میتواند فروش داشته باشد. حال در دیتابیسی که در شعبه تهران داریم ، کد ۳ ، ۵ و ۱ به ترتیب به استان های اصفهان ، کرج و تهران اطلاق شده است. در دیتابیس شعبه اصفهان ، کد ۱ ، ۲ ، ۶ و ۷ را داریم که به ترتیب به اصفهان ، کرج ، اهواز و حومه اهواز اطلاق شده اند.
در انبار داده ای که داریم ، کد ۱ را به تهران و کد ۲ را به اصفهان داده ایم. در نتیجه اینجا من باب این کد ها به مشکل خواهیم خورد. مشکل بعدی این است که در شعبه شیراز کدهای ۲ ، ۱ و ۵ به اصفهان ، کرج و اهواز و حومه اطلاق شده است. یعنی در شعبه شیراز بر خلاف شعبه اصفهان ، اهواز و حومه اهواز یک مقدار در نظر گرفته شده اند.
در انبار داده یک جدول داریم که به هر شعبه یک کد اختصاص داده شده اما در دیتای شعبات ، هر شهری یک کد خاص خودش را دارد و منطبق با جدول انبار داده ما نیست.
برای حل این مشکل باید یک Mapping Table یا جدول نگاشت ایجاد کنیم.
این Mapping Table به صورت زیر خواهد بود و به ما در مرتفع کردن مشکل یک کمک خواهد کرد :
سپس میتوان این جدول نگاشت را با جدول اصلی در انبار داده جوین زد و از اطلاعات صحیح بهره برد.
برای حل مشکل بعدی باید از راه حلی به نام کمیته Master Data استفاده کرد که راه حل فنی برای آن نداریم. برای حل این مشکل کار زیادی نمیتوان کرد و باید به مدیر پروژه صحبت شود که در شعبه اصفهان هم اهواز و حومه اهواز را همانند شعبه شیراز یک مقدار در نظر گرفت ، زیرا در شعبه شیراز نمیتوان درست برآورد کرد که چه میزان سهم اهواز و چه میزان سهم حومه اهواز است و به خطا میخوریم.
باید این موضوع را در نظر داشت که همیشه اطلاعات داخل سیستم BI به صورت صد در صدی نمیتواند منطبق بر اطلاعات دیتاسورس ها باشد ، ولیکن این اطلاعات خیلی زیاد نخواهد بود که در تصمیمات مدیریتی ایجاد بایاس کند.
