مفهوم انبار داده ذخیره سازی فیزیکی و مجازی داده ها

مفهوم انبار داده

"انبار داده" مجموعه ای خاص، محدود به زمان و تغییرناپذیر از داده ها برای پشتیبانی از فرآیند تصمیم گیری مدیریت است.

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

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

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

چرا به ایجاد انبارهای داده نیاز دارید - به هر حال، آنها حاوی اطلاعات آشکارا اضافی هستند که قبلاً در پایگاه داده یا فایل های سیستم عامل وجود دارد؟ تجزیه و تحلیل مستقیم داده های سیستم عامل غیرممکن یا بسیار دشوار است. این به دلایل مختلفی از جمله تکه تکه شدن داده ها و ذخیره آن در فرمت های مختلف DBMS است. اما حتی اگر یک شرکت تمام داده های خود را در یک سرور پایگاه داده مرکزی ذخیره کند، یک تحلیلگر تقریباً به طور قطع ساختار پیچیده و گاهی گیج کننده آنها را درک نخواهد کرد.

بنابراین، هدف مخزن ارائه "مواد خام" برای تجزیه و تحلیل در یک مکان و در یک ساختار ساده و قابل درک است.

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

یک مخزن لزوماً به معنای انباشت غول پیکر داده نیست - نکته اصلی این است که برای تجزیه و تحلیل راحت است.

مفهوم انبار داده

نویسنده مفهوم انبارهای داده ( پایگاه داده تحلیلی) B. Inmon است که انبارهای داده را اینگونه تعریف کرده است: «مجموعه‌های تاریخی خاص، یکپارچه، تغییرناپذیر و تغییرناپذیر از داده‌هایی که برای اهداف پشتیبانی مدیریت سازمان‌دهی شده‌اند» که برای عمل کردن به عنوان «منبع واحد و تنها حقیقت» طراحی شده‌اند، و به مدیران و تحلیلگران ارائه می‌کنند. اطلاعات قابل اعتماد لازم برای تجزیه و تحلیل عملیاتی و تصمیم گیری. نمودار انبار داده را می توان به صورت زیر نشان داد:

اجرای فیزیکی این طرح می تواند بسیار متنوع باشد. بیایید گزینه اول را در نظر بگیریم - یک انبار داده مجازی، این سیستمی است که دسترسی به یک سیستم ضبط معمولی را فراهم می کند که کار با یک انبار داده را شبیه سازی می کند. ذخیره سازی مجازی را می توان به دو صورت سازماندهی کرد. می توانید یک سری "نما" در پایگاه داده ایجاد کنید یا استفاده کنید وسایل خاصدسترسی به پایگاه داده (به عنوان مثال، محصولات کلاس OLAP دسکتاپ).

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

ساخت یک انبار داده کامل سازمانی معمولاً در یک معماری سه لایه انجام می شود. در سطح اول منابع داده های مختلفی وجود دارد - سیستم های ضبط داخلی، سیستم های کمکی، منابع خارجی (داده ها خبرگزاری ها، شاخص های کلان اقتصادی). سطح دوم شامل یک مخزن مرکزی است که در آن اطلاعات همه منابع از سطح اول جریان دارد و احتمالاً یک انبار داده عملیاتی که حاوی داده های تاریخی نیست و دو عملکرد اصلی را انجام می دهد.

مفهوم انبارهای داده مبتنی بر دو ایده اساسی است:

1) ادغام داده های تفصیلی قبلاً جدا شده در یک انبار داده واحد، هماهنگی آنها و احتمالاً تجمیع:

· آرشیوهای تاریخی

· داده های ODS سنتی.

· داده ها از منابع خارجی.

2) جداسازی مجموعه داده های مورد استفاده برای پردازش عملیاتی و مجموعه داده های مورد استفاده برای حل مسائل تجزیه و تحلیل.

هدف از مفهوم انبار داده، روشن کردن الزامات داده های قرار داده شده در پایگاه داده هدف انبار داده (جدول 1)، تعیین اصول کلی و مراحل ساخت آن، منابع اصلی داده ها، ارائه توصیه هایی برای حل است. مشکلات احتمالی که در حین تخلیه، تمیز کردن، هماهنگی، حمل و نقل و بارگیری آنها در پایگاه داده هدف ایجاد می شود.

جدول 1. الزامات اساسی برای داده ها در انبار داده.

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

موضوع مفهوم انبار داده، خود داده است. پس از اینکه یک سیستم پردازش داده سنتی (DPS) پیاده سازی شد و شروع به کار کرد، دقیقاً به همان شی مستقل دنیای واقعی تبدیل می شود. فرایند ساخت. و داده ها که یکی از محصولات نهایی چنین تولیدی است، دقیقاً همان ویژگی ها و ویژگی های هر محصول صنعتی را دارد: ماندگاری، محل نگهداری، سازگاری با داده های سایر صنایع (DOD)، ارزش بازار، قابلیت حمل و نقل، کامل بودن، قابلیت نگهداری. ، و غیره.

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

برای درک صحیحاین مفهوم مستلزم روشن شدن نکات اساسی زیر است:

· مفهوم انبار داده مفهومی از تجزیه و تحلیل داده ها نیست، بلکه مفهوم آماده سازی داده ها برای تجزیه و تحلیل است.

· مفهوم انبارهای داده، معماری سیستم تحلیلی هدف را از پیش تعیین نمی کند. در مورد اینکه چه فرآیندهایی باید در سیستم اجرا شوند صحبت می کند، اما نه اینکه دقیقاً کجا و چگونه این فرآیندها باید اجرا شوند.

· مفهوم انبارهای داده نه تنها شامل یک نمای منطقی واحد از داده های یک سازمان، بلکه اجرای یک منبع داده یکپارچه واحد است.

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

بدون پشتیبانی از زمان شناسی (در دسترس بودن داده های تاریخی)، نمی توان در مورد حل مشکلات پیش بینی و تحلیل روند صحبت کرد. اما بحرانی ترین و دردناک ترین مسائل مربوط به تطبیق داده ها است.

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

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

اطلاعات مربوطه.

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

بیایید به عناصر اصلی مفهوم انبار داده نگاه کنیم.

استخراج داده ها از سیستم عامل ها

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

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

نیاز به یکپارچه سازی داده ها از چندین سیستم OLTP

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

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

هدف خیلی ها سیستم های ذخیره سازی داده هایک مرور سال به سال از فعالیت ها است. به عنوان مثال، می توانید فروش سه ماهه اول سال جاری را با فروش سه ماهه اول سال های گذشته مقایسه کنید. زمان در HD یک ویژگی اساسی است پرس و جوهای متقابل. به عنوان مثال، یک تحلیلگر ممکن است سعی کند تأثیر یک کمپین بازاریابی جدید را که در طول انجام می شود، ارزیابی کند دوره های خاص، نگاهی به فروش در دوره های مشابه. توانایی ایجاد و درک همبستگی بین فعالیت‌های بخش‌های مختلف در یک سازمان اغلب به عنوان یکی از مهم‌ترین استدلال‌ها برای مزایای سیستم های ذخیره سازی داده ها.

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

تفاوت بین پردازش تراکنشی و تحلیلی

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

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

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

داده ها در سیستم های انبار داده بدون تغییر باقی می مانند

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

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

به دیگران مثال خوبممکن است بتوان در انبار داده یک عکس فوری از داده ها در حال تغییر دائم در مقاطع زمانی خاص قرار داد. ماژول کنترل موجودی در یک سیستم OLTP می تواند موجودی را تقریباً در هر تراکنش تغییر دهد. ورود همه این تغییرات به انبار داده غیرممکن است. شما می توانید تعیین کنید که چنین عکس فوری از وضعیت موجودی باید هر هفته یا روزانه به انبار داده وارد شود، همانطور که برای تجزیه و تحلیل در یک سازمان خاص پذیرفته می شود. داده های چنین عکس فوری، البته، تغییرناپذیر است.

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

داده ها در یک انبار داده برای مدت زمان قابل توجهی طولانی تر از سیستم های OLTP ذخیره می شوند

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

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

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

می توانید انتخاب کنید دلایل زیربرای جداسازی داده ها سیستم های ذخیره سازی داده هاو سیستم های پردازش داده های عملیاتی(شکل 1.5).

• تفاوت در الزامات هدف و سیستم های OLTP.
• نیاز به جمع آوری داده ها در انبار داده از منابع مختلف اطلاعاتی، یعنی. اگر داده ها در خود سیستم OLTP تولید شوند، برای سیستم های ذخیره سازی داده هادر بیشتر موارد، داده ها به صورت خارجی تولید می شوند.
• داده های وارد شده به انبار داده در اکثر موارد بدون تغییر باقی می مانند.
• داده ها در انبار داده برای مدت طولانی ذخیره می شوند.

برنج. 1.5.

تبدیل منطقی داده های سیستم های OLTP و مدل سازی داده ها

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

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

فرآیند مدل‌سازی داده‌ها باید داده‌ها را در انبار داده به شکلی مستقل از آن ساختار دهد مدل رابطه ایداده های سیستمی که این داده ها را تامین می کند. همانطور که در زیر نشان داده خواهد شد، مدل انبار داده احتمالاً نسبت به مدل سیستم OLTP - منبع داده - نرمال کمتری خواهد داشت.

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

مدل داده های DW باید به گونه ای توسعه یافته و ساختار یافته باشد که بتوان داده های برنامه های مختلف را اضافه کرد. در بیشتر موارد، یک پروژه انبار داده نمی تواند شامل داده هایی از همه برنامه های تجاری ممکن یک سازمان باشد. به طور معمول، حجم داده ها در یک انبار داده طبق اصل افزایشی افزایش می یابد: داده ها از سیستم های OLTP استخراج می شوند و در بخش های خاصی به انبار داده اضافه می شوند. آنها با ذخیره داده های مهم شروع می کنند، سپس به طور سیستماتیک حجم آنها را در صورت نیاز افزایش می دهند.

مدل انبار داده با ساختار کسب و کار سازگار است

بعد نکته مهماین است که مدل انبار داده منطقی برای ساختار کسب و کار (متمرکز بر حوزه موضوعی) پیکربندی شده است، و نه برای تجمیع مدل های منطقی برنامه های خاص. موجودیت ها (اشیاء) پشتیبانی شده در انبار داده مشابه نهادهای تجاری (اشیاء) هستند - مانند مشتریان، محصولات (محصولات)، سفارش ها و توزیع کنندگان. در بخش‌های خاص یک سازمان، ممکن است دید بسیار محدودی از نهادهای تجاری سازمان مانند مشتریان وجود داشته باشد. بنابراین، تیم خدمات وام در یک بانک ممکن است فقط در مورد یک یا چند وام صادر شده چیزی در مورد یک مشتری بدانند. بخش دیگری از همان بانک ممکن است در مورد مشتری مشابه در زمینه اطلاعات داشته باشد حساب سپرده. ارائه داده های مشتری در انبار داده بسیار بالاتر از ارائه مشابه یک بخش بانکی خاص است. مشتری در HD نماینده مشتری بانک در تمام روابطش با بانک است. از نقطه نظر نظریه رابطه، مجموعه اساسی وابستگی های تابعی پشتیبانی شده در پایگاه داده تغییر می کند.

انبار داده باید بر اساس ویژگی های موجودیت های تجاری (موضوع محور) ساخته شود و داده های مربوط به این نهادها را از منابع مختلف جمع آوری کند. ساختار داده هر منبع داده واحدی احتمالاً برای DW ناکافی است. در مورد ساختار داده کاربرد خاصتحت تأثیر عواملی مانند:

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

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

تبدیل اطلاعاتی که وضعیت اشیاء را در یک سیستم OLTP توصیف می کند

نکته مهم بعدی این است که قبل از قرار دادن داده در انبار داده باید تبدیل شود. اکثر داده های یک سیستم OLTP یا سایر منابع خارجی را نمی توان در انبار داده پشتیبانی کرد. بسیاری از ویژگی های شی در یک سیستم OLTP بسیار پویا و دائما در حال تغییر هستند. بسیاری از این ویژگی ها در انبار داده بارگذاری نمی شوند، در حالی که سایر ویژگی ها در زمان ثابت هستند و در انبار داده بارگذاری می شوند. انبار داده به هیچ وجه نباید حاوی اطلاعاتی درباره اشیایی باشد که پویا هستند و دائماً در حال تغییر هستند.

برای درک اینکه معنای از دست دادن اطلاعات در توصیف چیست وضعیت فعلییک مثال از یک سیستم مدیریت سفارش را در نظر بگیرید که وضعیت موجودی را هنگام تکمیل سفارش ردیابی می کند. ابتدا اجازه دهید به موجودیت "Order" در یک سیستم OLTP نگاه کنیم. یک سفارش ممکن است قبل از تکمیل و رسیدن، از وضعیت ها یا وضعیت های مختلفی عبور کند وضعیت تکمیل شده. وضعیت سفارش ممکن است نشان دهنده آماده بودن آن برای تکمیل، اینکه سفارش در حال تکمیل است، برای بازبینی، آماده ارسال و غیره است. یک سفارش خاص می تواند از بسیاری از حالت ها عبور کند که در وضعیت سفارش منعکس شده و توسط فرآیندهای تجاری که برای آن اعمال شده اند تعیین می شود. تقریباً غیرممکن است که تمام ویژگی های چنین شیء را به انبار داده منتقل کنید. سیستم ذخیره سازی داده هااحتمالاً باید فقط یک عکس فوری نهایی از یک شی مانند یک سفارش داشته باشد. بنابراین، شی "Order" باید تبدیل شود تا در انبار داده قرار گیرد. سپس انبار داده می تواند اطلاعات بسیاری از اشیاء از نوع "سفارش" را جمع آوری کند و شی انبار داده نهایی - "Order" را بسازد.

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

این رویکرد می تواند برای بخش بسیار زیادی از داده ها در سیستم های OLTP اعمال شود. به نوبه خود، چنین تصمیمی مستلزم تعدادی از وظایف مربوط به انتخاب دوره زمانی، حجم داده های جمع آوری شده و غیره خواهد بود. بنابراین، بیشتر داده های مربوط به وضعیت اشیاء در سیستم OLTP را نمی توان مستقیماً به انبار داده منتقل کرد. آنها باید در سطح منطقی تبدیل شوند.

غیر عادی سازی مدل داده

نکته بعدی در طراحی انبارهای داده رابطه ای این است که تصمیم بگیرید که رعایت اصول تئوری رابطه در انبار داده چقدر مهم است، یعنی: اجازه دادن به غیرعادی سازی مدل، به ویژه افزایش عملکرد پرس و جو. قبل از اینکه عادی سازی مدل داده را در زمینه انبار داده در نظر بگیریم، اجازه دهید به اختصار نکات اصلی نظریه پایگاه داده رابطه ای را یادآوری کنیم. فرآیند عادی سازی. E.F. کاد در اواخر دهه 1960 در حالی که در مرکز تحقیقات IBM کار می کرد، نظریه پایگاه داده رابطه ای را توسعه داد. امروزه اکثر پلتفرم های پایگاه داده محبوب به طور کامل از این مدل پیروی می کنند. مدل پایگاه داده رابطه ای مجموعه ای از جداول دو بعدی است که از سطرها و ستون ها تشکیل شده است. در اصطلاحات مدل رابطه ای، این جداول، سطرها و ستون ها را به ترتیب روابط یا موجودیت ها، تاپل ها، ویژگی ها و دامنه ها می نامند. این مدل کلیدهای منحصر به فرد (Keys) را برای همه جداول شناسایی می کند و روابط بین جداول را از طریق مقادیر ویژگی (کلید) توصیف می کند.

عادی سازی فرآیند مدل سازی یک پایگاه داده رابطه ای است که در آن روابط یا جداول شکسته می شوند تا زمانی که تمام ویژگی های یک رابطه به طور کامل توسط کلید اصلی آن مشخص شود. اکثر طراحان سعی می کنند تا قبل از اینکه به دلایلی از حالت عادی خارج شوند، به شکل عادی سوم (3NF) بر روی همه روابط دست یابند. سه مرحله متوالی عادی سازی پایگاه داده رابطه ای به طور خلاصه در زیر توضیح داده شده است.

• اولین فرم نرمال 1NF (1NF). اگر یک رابطه یک موجودیت واحد را توصیف کند و حاوی آرایه‌ها یا گروه‌هایی از مقادیر تکرار شونده به عنوان ویژگی نباشد، به اولین شکل عادی گفته می‌شود. به عنوان مثال، یک جدول سفارشات که شامل موارد سفارش است در اولین شکل عادی نخواهد بود زیرا دارای ویژگی های تکراری برای هر مورد سفارش است.
• فرم معمولی دوم 2NF (2NF). آنها می گویند که رابطه برقرار است فرم معمولی دوم، اگر در اولین شکل نرمال باشد و تمام ویژگی های غیر کلیدی از نظر عملکرد کاملاً به آن وابسته باشند کلید اصلی رابطه.
• فرم سوم عادی 3NF (3NF). آنها می گویند که رابطه برقرار است فرم سوم عادی، اگر در آن باشد فرم معمولی دومو صفات غیر کلیدی آن کاملاً مستقل از یکدیگر هستند.

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

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

روابط ایستا در داده های تاریخی

غیر عادی سازی است فرآیند مهمدر مدل سازی HD: رابطه بین ویژگی ها برای داده های تاریخی تغییر نمی کند. به عنوان مثال، در سیستم های OLTP، ممکن است یک محصول در این ماه بخشی از محصول دیگری در گروه "الف" و در ماه آینده بخشی از محصولی در گروه "ب" باشد. در یک مدل داده نرمال شده، برای نمایش این واقعیت، لازم است که ویژگی "گروه محصول" را در رابطه "محصول" (موجود) لحاظ کنیم، اما نه در رابطه "سفارش" (موجود)، که سفارشات این محصول را ایجاد می کند. . فقط شناسه محصول در موجودیت "سفارش" گنجانده شده است. تئوری رابطه مستلزم پیوستن بین جداول سفارش و محصول برای تعریف گروه محصول و سایر ویژگی های آن محصول است. این حقیقت ( وابستگی عملکردی) برای انبار داده مهم نیست، زیرا داده های ذخیره شده مربوط به سفارشات از قبل تکمیل شده است، یعنی. تعلق محصول به گروه قبلاً ثابت شده است (در واقع، وابستگی عملکردی مشخص شده پشتیبانی نمی شود). حتی اگر کالا تعلق داشته باشد گروه های مختلفدر زمان های مختلف، رابطه بین گروه محصول و محصول هر سفارش فردی ثابت است. بنابراین، این غیرعادی سازی برای ذخیره سازی داده ها نیست. در این حالت، وابستگی عملکردی سیستم OLTP در انبار داده استفاده نمی شود.

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

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

تبدیل فیزیکی داده های برنامه کاربردی منبع

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

شرایط و نام ها ویژگی های موجودیت، مورد استفاده در سیستم های OLTP، در فرآیند تبدیل داده ها برای انبار داده ها به جهانی تبدیل می شوند. شرایط استانداردبرای این حوزه کسب و کار اتخاذ شده است. برنامه‌ها ممکن است به دلایل مختلف از اختصارات یا اصطلاحات غیرقابل درک استفاده کنند. پلت فرم سخت‌افزار و نرم‌افزار ممکن است طول و قالب نام‌ها را محدود کند و برنامه‌های تجاری ممکن است از اصطلاحات رایج در دامنه‌ها استفاده کنند. در یک انبار داده، لازم است از اصطلاحات تجاری استاندارد استفاده شود که به خودی خود برای اکثر کاربران قابل درک باشد.

شناسه مشتری (خریدار) در یک سیستم OLTP را می توان «خرید»، «شناسه_خرید» یا «خرید_نه» نامید. علاوه بر این، کاربردهای مختلف چنین سیستم‌هایی ممکن است از نام‌های (مترادف) متفاوتی هنگام ارجاع به ویژگی موجودیت یکسان استفاده کنند. طراح DW یک اصطلاح تجاری استاندارد ساده مانند "شناسه مشتری" را انتخاب می کند. پس اسامی ویژگی های موجودیتسیستم های تامین باید برای استفاده در HD یکپارچه شوند.

زیرسیستم‌های مختلف سیستم‌های OLTP و منابع داده خارجی ممکن است از تعاریف متفاوتی از دامنه‌های ویژگی در فیزیکی استفاده کنند. سطح ارائه داده ها. بنابراین، یک ویژگی از نوع "شناسه محصول" در یک سیستم دارای طول 12 کاراکتر و در دیگری - 18 کاراکتر است. از سوی دیگر، برخی از سیستم‌های موجود ممکن است محدودیت‌هایی در تعریف طول نام ویژگی‌ها و مجموعه ضعیفی از انواع برای تعریف دامنه داشته باشند، در حالی که برخی دیگر ممکن است چنین محدودیتی نداشته باشند و ممکن است انتخاب گسترده‌ای از انواع ویژگی‌ها را ارائه دهند.

هنگام تعریف ویژگی‌ها در یک مدل انبار داده فیزیکی، لازم است از چنین طول‌ها و انواع داده‌ای در تعریف دامنه ویژگی استفاده شود که امکان در نظر گرفتن الزامات حوزه موضوعی و قابلیت‌های سیستم‌های منبع داده را فراهم کند. تعریف استانداردهای دامنه برای انبار داده یکی از وظایف مهم طراحان انبار داده است. قوانین تبدیل دامنه های ویژگی سیستم های منبع داده به دامنه های ویژگی DW باید در فراداده DW ثبت شود.

تمام ویژگی ها در انبار داده باید به طور مداوم از مقادیر از پیش تعریف شده استفاده کنند. برنامه های مختلف ممکن است قراردادهای متفاوتی برای مقادیر مشخصه از پیش تعریف شده داشته باشند. این مقادیر از پیش تعریف شده شامل مقادیر پیش‌فرض، مقادیری که جایگزین مقادیر تهی می‌شوند و غیره هستند. به عنوان مثال، جنسیت در سیستم های مختلفمی تواند معانی مختلفی داشته باشد: در برخی از آنها مقادیر نمادین "M" و "F" و در برخی دیگر - مقادیر دیجیتال 0 و 1 هستند. مثال ناخوشایندتر زمانی است که از یک مقدار داده در یک برنامه استفاده می شود. برای چندین هدف، یعنی صفت در واقع معانی متعددی را نشان می دهد. به عنوان مثال، هنگامی که در ویژگی "نوع روش اندازه گیری" دو رقم اول نشان دهنده روش اندازه گیری و دو رقم دوم نشان دهنده روش کنترل فیزیکی اندازه گیری است. چنین مقادیر متفاوتی باید قبل از بارگیری در انبار داده به مقدار از پیش تعریف شده پذیرفته شده در انبار داده تبدیل شوند.

در برخی از سیستم های منبع داده، مقادیر ممکن است گم شده باشند (مشکل مقادیر از دست رفته، "داده های از دست رفته") یا تبدیل برای آنها قابل انجام نباشد ("داده های خراب" - داده هایی که تبدیل برای آنها قابل انجام نیست). مهم است که در طول فرآیند تبدیل، چنین داده هایی در انبار داده مقادیری به خود بگیرند که به کاربران اجازه می دهد آن را به درستی تفسیر کنند. به برخی از ویژگی‌ها می‌توان به سادگی یک مقدار پیش‌فرض معقول در صورت عدم وجود مقادیر یا تضاد تبدیل، و سایر ویژگی‌ها را می‌توان مقادیری از مقادیر سایر ویژگی‌ها نسبت داد. برای مثال، فرض کنید در موجودیت «Order» مقدار ویژگی واحد محصول وجود ندارد. این مقدار را می توان از ویژگی مربوط به موجودیت Item این سیستم منبع بدست آورد. برخی از ویژگی ها زمانی که مقادیر آنها از بین رفته باشد، مقادیر پیش فرض مناسبی ندارند. برای چنین مقادیر گمشده، انبار داده نیز باید یک مقدار پیش فرض را تعریف کند، به عنوان مثال، به عنوان یک مقدار تهی.

تفاوت های اصلی در استفاده از داده ها در

تمایل به ترکیب قابلیت های سیستم های OLTP و سیستم های تجزیه و تحلیل در یک معماری DSS منجر به ظهور این مفهوم شد. ایکسranولبه دنبالدآnماایکس (HD).

مفهوم ذخیره سازی داده ها به نوعی توسط متخصصان حوزه فناوری اطلاعات مورد بحث قرار گرفته است.

سیستم های پیوند برای مدت زمان طولانی. اولین مقالات اختصاص یافته به HD ظاهر شد

در سال 1988، نویسندگان آنها B. Devlin و P. Murphy بودند. در سال 1992، دبلیو اینمون این مفهوم را به تفصیل در مونوگراف خود "ساخت انبار داده"، ویرایش دوم - گروه انتشارات QED، 1996 توضیح داد.

مفهوم ذخیره سازی داده ها بر اساس ایده جداسازی داده هایی است که برای آن استفاده می شود

پردازش عملیاتی و برای حل مشکلات تجزیه و تحلیل. این امکان استفاده از ساختارهای داده ای را فراهم می کند که الزامات ذخیره سازی را برای استفاده در سیستم های OLTP و سیستم های تجزیه و تحلیل برآورده می کند. این جداسازی به شما این امکان را می‌دهد که هم ساختار داده‌های ذخیره‌سازی عملیاتی (پایگاه‌های اطلاعاتی آنلاین، فایل‌ها، صفحات گسترده و غیره) را برای انجام عملیات ورودی، اصلاح، حذف و جستجو و هم ساختار داده‌ای که برای تجزیه و تحلیل (برای انجام پرس و جوهای تحلیلی) استفاده می‌شود، بهینه کنید. در DSS این دو نوع داده به ترتیب نامیده می شوند O پ ه آر آ تی و V n س متر و و با تی O ساعت n و به آ متر و د آ ننی ایکس (OID) و ایکسآرآهیچ کداملوschهمتردآNNسایکس.

اینمون در کار خود تعریف زیر را از سی دی ارائه کرد.

ایکس ra هیچ کدام ل و sch ه د آ n n س ایکس - موضوع محور، یکپارچه،

مجموعه ای تغییرناپذیر و تاریخی از داده ها که برای اهداف پشتیبانی تصمیم سازماندهی شده است.

بیایید ویژگی های HD را با جزئیات بیشتری در نظر بگیریم.

پآرواحدهامترهتیnاوهریهnتیآچیمن.این تفاوت اساسی بین HD و OID است.

OID های مختلف ممکن است حاوی داده هایی باشد که یک حوزه موضوعی مشابه را از دیدگاه های مختلف توصیف می کند (به عنوان مثال، از نقطه نظر حسابداری، حسابداری انبار، بخش برنامه ریزی و غیره). تصمیمی که تنها بر اساس یک دیدگاه گرفته می شود ممکن است ناکارآمد یا حتی نادرست باشد. انبارهای داده به شما این امکان را می دهند که اطلاعاتی را که منعکس کننده دیدگاه های مختلف در یک حوزه موضوعی است، ادغام کنید.

سوژه گرایی همچنین به شما این امکان را می دهد که فقط آن دسته از داده ها را در انبار داده ذخیره کنید

برای تجزیه و تحلیل آنها مورد نیاز است (به عنوان مثال، برای تجزیه و تحلیل، ذخیره اطلاعات در مورد تعداد اسناد خرید و فروش فایده ای ندارد، در حالی که محتوای آنها - مقدار، قیمت کالاهای فروخته شده - ضروری است). این به طور قابل توجهی هزینه های رسانه ذخیره سازی را کاهش می دهد و امنیت دسترسی به داده ها را افزایش می دهد.

وnتیهگرمآچیمن. OID ها، به عنوان یک قاعده، در زمان های مختلف توسط چندین تیم با ابزارهای خاص خود توسعه می یابند. این منجر به این واقعیت می شود که داده های منعکس کننده یک شیء دنیای واقعی در سیستم های مختلف آن را به طور متفاوتی توصیف می کنند. ادغام اجباری داده ها در یک انبار داده به ما امکان می دهد این مشکل را با آوردن داده ها به یک فرمت یکپارچه حل کنیم. توسطddeآروبهآایکسآرOnاوهgii. داده های موجود در OID برای انجام عملیات روی آن در زمان فعلی ضروری هستند. بنابراین، ممکن است محدودیت زمانی نداشته باشند. برای تجزیه و تحلیل داده ها، اغلب مهم است که بتوانیم زمان بندی تغییرات در شاخص های دامنه را ردیابی کنیم. بنابراین، تمام داده های ذخیره شده در انبار داده باید با فواصل زمانی متوالی مطابقت داشته باشند. نهوzmهnمنهماهباتیب. الزامات OID محدودیت های زمانی را اعمال می کند

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

هنگام پیاده سازی مفهوم ذخیره سازی داده ها در DSS، داده های OID های مختلف در یک حافظه واحد کپی می شوند. داده‌های جمع‌آوری‌شده در یک قالب واحد آورده شده، هماهنگ و خلاصه می‌شوند. درخواست‌های تحلیلی به انبار داده ارسال می‌شوند (شکل 1).

چنین مدلی به ناچار منجر به تکرار اطلاعات در OID و انبار داده می شود.

با این حال، اینمون در کار خود استدلال می کند که افزونگی داده های ذخیره شده در

DSS از 1% تجاوز نمی کند! این را می توان با دلایل زیر توضیح داد.

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

اطلاعات در OID معمولاً ماهیت عملیاتی دارند و داده ها از دست می روند

مربوطه حذف می شوند. برعکس، انبار داده، اطلاعات تاریخی را ذخیره می کند. از این منظر، تکرار محتویات انبار داده با داده های OID بسیار ناچیز به نظر می رسد. انبار داده اطلاعات کلی را که در OID موجود نیست ذخیره می کند.

در حین بارگیری در انبار داده، داده ها پاک می شوند (اطلاعات غیر ضروری حذف می شوند) و

پس از چنین پردازشی حجم بسیار کمتری را اشغال می کنند.

زیر سیستم ورودی (OLTP)

P o d s i s t e m

پرس و جوهای تحلیلی

P o d s i s t e m

O p e r a t o

زیر سیستم ورودی (OLTP)

و تحلیل

آروبادرnOبه7. ساختار DSS با ذخیره سازی فیزیکی داده ها

افزونگی اطلاعات را می توان با استفاده از یک انبار داده مجازی به صفر رساند. در این مورد، برخلاف انبار داده کلاسیک (فیزیکی)، داده‌های OID در یک ذخیره‌سازی واحد کپی نمی‌شوند. آنها به طور مستقیم هنگام اجرای پرس و جوهای تحلیلی در RAM رایانه استخراج، تبدیل و ادغام می شوند. در واقع چنین درخواست هایی مستقیماً به OID ارسال می شوند (شکل 2). مزایای اصلی ذخیره سازی مجازی عبارتند از:

به حداقل رساندن مقدار حافظه اشغال شده توسط اطلاعات روی رسانه؛ کار با داده های فعلی، داده های دقیق.

زیر سیستم ورودی (OLTP)

زیر سیستم ورودی (OLTP)

زیر سیستم های ورودی

زیر سیستم ذخیره سازی اطلاعات

پرس و جوهای تحلیلی

زیر سیستم های تجزیه و تحلیل (OLAP،

O p e r a t o

مجازی

آر و با در n O به 8. ساختار S PP R s v i r t u a l n m H D

با این حال، این رویکرد دارای معایب بسیاری است.

زمان پردازش درخواست ها به یک سیستم ذخیره سازی مجازی به طور قابل توجهی بیشتر از زمان مربوطه است

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

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

اجرای پرس و جوهای تحلیلی پیچیده در OID به منابع کامپیوتری قابل توجهی نیاز دارد. این منجر به کاهش عملکرد سیستم های OLTP می شود که غیرقابل قبول است، زیرا زمان اجرای عملیات در چنین سیستم هایی اغلب بسیار بحرانی است.

OID های مختلف ممکن است از فرمت ها و رمزگذاری های مختلف داده پشتیبانی کنند. غالبا

ممکن است چندین پاسخ ممکن برای یک سوال وجود داشته باشد. این ممکن است به دلیل:

عدم همگام سازی لحظه های به روز رسانی داده ها در OID های مختلف. تفاوت در توصیف اشیاء و رویدادهای یکسان در حوزه موضوعی؛ خطاهای ورودی؛ از دست دادن قطعات آرشیو و غیره

در این مورد، ممکن است هدف - تشکیل یک دیدگاه منسجم واحد از شی مدیریت - محقق نشود.

نقطه ضعف اصلی ذخیره سازی مجازی کاربردی بودن آن است

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

با وجود مزایای ذخیره سازی فیزیکی نسبت به ذخیره سازی مجازی، ضروری است

اعتراف کنید که اجرای آن یک فرآیند نسبتاً کار فشرده است.

بیایید به مشکلات اصلی ایجاد یک انبار داده نگاه کنیم:

نیاز به ادغام داده ها از منابع ناهمگن در

محیط محدود؛

نیاز به ذخیره سازی و پردازش کارآمد حجم بسیار زیادی از اطلاعات؛ نیاز به دایرکتوری های ابرداده چند سطحی؛ در باره

افزایش الزامات برای امنیت داده ها بیایید این مشکلات را با جزئیات بیشتری بررسی کنیم.

به تفصیل

نهدر بارهایکسOدوماهباتیبکه درتیهگرمآچیودآNNسوساعتnهOدnOآرOدnسوباتیOساعتبریدگی کوچکovVآرآبا- و غیرهغذالهNNآخباآرغذا. انبارهای داده برای ادغام داده‌هایی ایجاد می‌شوند که می‌توانند از OIDهای ناهمگن که به صورت فیزیکی در رایانه‌های مختلف قرار دارند به دست آیند: پایگاه‌های داده، آرشیوهای الکترونیکی، کاتالوگ‌های الکترونیکی عمومی و تجاری، کتاب‌های مرجع، مجموعه‌های آماری. هنگام ایجاد یک انبار داده، باید مشکل ساختن سیستمی را حل کرد که با ابزارها و راه حل های نرم افزاری ناهمگن عمل کند. هنگام انتخاب ابزار برای پیاده سازی ذخیره سازی داده ها، باید عوامل زیادی را در نظر بگیرید، از جمله میزان سازگاری اجزای مختلف نرم افزار، سهولت توسعه و استفاده از آنها، بازده عملیاتی و غیره.

توسطتیآرهبnOباتیبVاوهffهبهتیوVnاهمایکسآرآnههیچ کدامووOبآریا چیز دیگرتیبههOچیnببیشتربwوایکسدر بارهъهحرکتکه درfOآرمادرtsوو. خاصیت تغییر ناپذیری HD به معنای انباشت اطلاعات در آن در مدت زمان طولانی است که باید با افزایش مداوم حجم حافظه دیسک پشتیبانی شود. تمرکز بر اجرای پرس و جوهای تحلیلی و غیر عادی سازی داده ها منجر به افزایش غیرخطی در مقدار حافظه اشغال شده توسط انبار داده با افزایش حجم داده ها می شود. تحقیقات انجام شده بر روی مجموعه تست TPC-D نشان داده است که پایگاه داده های 100 گیگابایتی به 4.87 برابر حافظه مورد نیاز برای ذخیره داده های مفید نیاز دارند.

نهدر بارهایکسOدوماهباتیمترnOجیOUآرovnهبیرونباو غیرهآووساعتبریدگی کوچکov mهتیآدآNNسایکس. برای سیستم های تجزیه و تحلیل، وجود ابرداده های توسعه یافته (داده های مربوط به داده ها) و ابزارهای ارائه آن به کاربران نهایی یکی از شروط اصلی برای اجرای موفقیت آمیز انبارهای داده است. فراداده برای درک ساختار اطلاعات در مورد کاربران DSS ضروری است. که بر اساس آن تصمیم گرفته می شود. به عنوان مثال، قبل از اینکه یک مدیر شرکتی سوال خود را از سیستم بپرسد، باید بداند که چه اطلاعاتی در دسترس است، چقدر مرتبط است، آیا می توان به آن اعتماد کرد، چه مدت ممکن است طول بکشد تا یک پاسخ ایجاد شود و غیره. هنگام ایجاد پایگاه داده، باید مشکلات ذخیره سازی و ارائه راحت متادیتا به کاربران را حل کرد.

پوویwههیچ کدامهتیآرهبوواهیچ کدامهفتمبهبهzoپآباnOباتیودآNNسایکس. جمع آوری شده و با هم

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

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

کاهش هزینه ایجاد انبار داده را می توان با ایجاد یک انباره ساده به دست آورد

گزینه - data mart (Data Mart).

که در و تی آر که در آ د آ n ما ایکس (که درD) - این یک نسخه ساده شده از HD است که فقط شامل موضوع است -

داده های ترکیبی

VD تا حد امکان به کاربر نهایی نزدیک است و حاوی داده است

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

شناسه های مستقل (شکل 3) اغلب به صورت تاریخی در سازمان ها ظاهر می شوند و در سازمان های بزرگ با تعداد زیادی واحد مستقل یافت می شوند که مشکلات تحلیلی خود را حل می کنند.

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

زیر سیستم ورودی (OLTP)

زیر سیستم ورودی (OLTP)

زیر سیستم ذخیره سازی اطلاعات

پرس و جوهای تحلیلی

پرس و جوهای تحلیلی

زیر سیستم های تجزیه و تحلیل (OLAP،

P o d s i s t e m

O p e r a t o

زیر سیستم ورودی (OLTP)

و تحلیل

آروبادرnOبه9. ساختار DSS با شناسه های مستقل

معایب وسایل نقلیه هوایی خودران عبارتند از:

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

از این رو فقدان یک تصویر یکپارچه.

اخیراً ایده ترکیب HD و VD در

یک سیستم در این مورد، DW به عنوان تنها منبع داده های یکپارچه برای همه VD ها استفاده می شود (شکل 4).

انبار داده یک منبع متمرکز اطلاعات برای کل حوزه موضوعی است و دامنه های داده زیرمجموعه ای از داده ها از مخزن هستند.

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

مزایای این رویکرد عبارتند از:

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

زیر سیستم ورودی (OLTP)

زیر سیستم ذخیره سازی اطلاعات

پرس و جوهای تحلیلی

P o d s i s t e m

O p e r a t o

زیر سیستم ورودی (OLTP)

زیر سیستم ورودی (OLTP)

A n a l i t i c h es k e

پرس و جوهای HD

VD

و تحلیل

زیر سیستم های تجزیه و تحلیل (OLAP،

آروبادرnOبه10. ساختار DSS با HD و VD

معایب عبارتند از:

افزونگی (داده ها هم در انبار داده و هم در انبار داده ذخیره می شوند)؛ هزینه های اضافی برای توسعه DSS با HD و VD.

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

DSS با HD فیزیکی (کلاسیک) (شکل 1 را ببینید). DSS با حافظه مجازی (شکل 2 را ببینید). DSS با VD (شکل 3 را ببینید). DSS با CD فیزیکی و با VD (شکل 4).

در مورد معماری هایی با ذخیره سازی فیزیکی و/یا ذخیره سازی، باید به آن توجه شود

مسائل مربوط به سازماندهی (معماری) انبار داده و انتقال داده ها از OID به انبار داده.

طبق تحقیقات Forrester، اکثر شرکت های بزرگ با آن روبرو هستند مشکل بعدی: انباشته می شوند مقدار زیادیاطلاعاتی که هرگز استفاده نمی شود تقریباً در هر سازمانی، در واقع سیستم‌های معاملاتی زیادی وجود دارند که به سمت پردازش سریع داده‌ها (هر کدام برای یک کلاس خاص از وظایف) هدایت می‌شوند و به طور مداوم تعداد زیادی را پر می‌کنند. پایگاه داده. علاوه بر این، شرکت ها اغلب دارای مقادیر عظیمی از اطلاعات ذخیره شده در به اصطلاح هستند. سیستم های میراثی همه این داده ها در شبکه ها توزیع می شوند کامپیوترهای شخصی، در مین فریم ها، ایستگاه های کاری و سرورها ذخیره می شوند. بنابراین، اطلاعات وجود دارد، اما پراکنده، ناسازگار، بدون ساختار، اغلب اضافی و همیشه قابل اعتماد نیست. بنابراین، در بیشتر سازمان‌ها، هنوز نمی‌توان از این داده‌ها برای اتخاذ تصمیمات تجاری حیاتی استفاده کرد. مفهوم انبار داده با هدف حل این تناقض است.

بیل اینمون، مبدع این مفهوم، در مقاله کلاسیک خود «انبار داده چیست» (D2K Incorporated،  1996) انبارهای داده را به عنوان «مجموعه‌ای از داده‌های دامنه گرا، یکپارچه، تغییرناپذیر، نگهداری شده تاریخی که به منظور پشتیبانی از مدیریت سازماندهی شده‌اند، تعریف می‌کند. " او مخازن را به عنوان "منبع یگانه و تنها حقیقت"، "مرکز جهان" سیستم های پشتیبانی تصمیم (DSS) می داند. او می‌نویسد: «از انبارهای داده، اطلاعات به بخش‌های مختلف جریان می‌یابد که مطابق با تنظیمات DSS مشخص شده فیلتر می‌شوند. این پایگاه های اطلاعاتی جداگانه تصمیم گیری نامیده می شوند پنجره های مغازهداده ها."

مفهوم انبارهای داده بر اساس ایده ترکیب داده های شرکتی پراکنده در سیستم های پردازش داده های عملیاتی، آرشیوهای تاریخی و سایر منابع خارجی است. این منابع ممکن است حاوی داده‌هایی باشند که مستقیماً در ODS استفاده نمی‌شوند، اما برای DSS حیاتی هستند: چارچوب قانونی(از جمله پیش بینی های مالیاتی)، برنامه های توسعهصنایع، داده های آماری، فهرست های الکترونیکی. همانطور که تمرین نشان می دهد، تصمیمی که فقط بر اساس داده های داخلی گرفته می شود اغلب نادرست است.

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

مقایسه مشخصات داده ها در سیستم های اطلاعاتیجهت گیری پردازش داده های عملیاتی و تحلیلی

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

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

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

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

مدل های تحلیل داده ها

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

1. تجزیه و تحلیل استاتیک(DSS). مفهوم DSS (سیستم های پشتیبانی تصمیم) در واقع به عنوان DSS ترجمه می شود. تا همین اواخر، این تنها مفهوم تحلیلی بود. نتیجه کار چنین سیستم‌هایی گزارش‌های چند صفحه‌ای به‌شدت تنظیم‌شده بود، که تولید آن‌ها به پرسش‌های طولانی نیاز داشت که حجم عظیمی از داده را پردازش می‌کرد. چنین درخواست هایی ممکن است چندین ساعت، گاهی ده ها ساعت یا حتی روزها طول بکشد.

2. تجزیه و تحلیل داده های آنلاین (OLAP). نویسنده مفهوم OLAP (On-Line Analytical Processing) دکتر E. Codd است که در سال 1993 12 الزام اساسی برای ابزارهای پیاده سازی OLAP را فرموله کرد. تفاوت اساسیاین مدل از DSS استاتیک سنتی یک نمایش مفهومی از داده ها در قالب یک مکعب چند بعدی است. در همان زمان، E. Codd کاستی های بالقوه رویکرد رابطه ای را در سیستم های متمرکز بر تجزیه و تحلیل داده ها نشان داد. هدف از ایجاد این مفهوم، امکان اساسی ارائه ابزار تولید، پردازش و اجرای پرس و جوهای تحلیلی موقت با حداقل زمان پاسخگویی به کاربر نهایی بود. نیاز به ظهور این مفهوم جدید با این واقعیت از پیش تعیین شده بود که اغلب پس از دریافت یک گزارش استاندارد با استفاده از ابزارهای DSS، تحلیلگر سؤال جدیدی داشت یا متوجه می شد که خود سؤال به درستی فرمول بندی شده است. در نتیجه دوباره مجبور شد برای مدت طولانیمنتظر بمانید تا نتیجه بعدی را دریافت کنید تا احتمالاً به تکرار بعدی این فرآیند برگردید.

مقایسه ویژگی های تحلیل استاتیکی و دینامیکی

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

امروزه، جهت OLAP شاید امیدوارکننده ترین راه حل برای حل مشکلات مدیریت تحلیلی باشد. با استفاده از سرویس گزارش OLAP ایجاد شده ویژه، 12 الزامی که در ابتدا توسط دکتر کاد فرموله شده بود، تا حدی بازنگری شده و به طور قابل توجهی تکمیل شدند، چه اساسی و چه اساسی. ویژگی های خاص، مانند انتخاب و پردازش داده های از دست رفته و غیره. اما هنوز هسته اصلی مفهوم OLAP است. نمایش چند بعدیداده ها در سطح مفهومی

دیتا مارت

بر اساس تعریف کلاسیک، دیتا مارت زیرمجموعه ای از انبار داده است که مشخصات یک بخش (ابژه تجاری) را منعکس می کند و ارائه می کند. بهره وری بیشتر. بنابراین، ویترین پیوندی است که در آن یک خاص است سیستم تحلیلیبرای حل مشکلات شما با این وجود، این امکان وجود دارد که حوزه خاصی از فعالیت یک شرکت عملاً با سایرین ارتباط نداشته باشد و می توان یک بازار داده مربوطه را به طور مستقل و بدون اشاره به یک مرکز ذخیره سازی شرکتی ایجاد کرد. سپس ویترین فروشگاه با داده های مستقیم از سیستم های پردازش تراکنش عملیاتی پر می شود. این گونه دیتا مارت ها مستقل نامیده می شوند، برخلاف دیتا مارت های کلاسیک که به انبار داده وابسته هستند و از آن دوباره پر می شوند.

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

بنابراین چه چیزی منطقی است: یک مخزن واحد، مارت های داده مستقل، یک مخزن با مارت های وابسته، یا گزینه های دیگر؟ هیچ پاسخی جهانی برای سؤال نیاز به استفاده از یک یا گزینه دیگر وجود ندارد. در هر مورد بهترین گزینهتوسط الزامات تجاری، شدت درخواست ها، معماری شبکه، سرعت پاسخگویی مورد نیاز و سایر شرایط تعیین می شود.

فناوری برای پیاده سازی انبارهای داده

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

1. تعیین نیازهای کاربران نهایی و ایجاد مدلی از سوالات تجاری که نیاز به پاسخ دارند.

2. داده ها را از منابع شرکتی و خارجی که انبار داده یا بازار داده را تغذیه می کنند، شناسایی کنید.

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

4. تعریف رویه هایی برای تبدیل، تمیز کردن و یکپارچه سازی منطقی داده های منبع قبل از قرار دادن آنها در انبار یا دیتا مارت و همچنین تنظیم اجرای این رویه ها که انبار داده را به روز می کند.

5. ایجاد ابرداده توصیف کننده منابع و روش های تبدیل داده ها و منطق انبار داده ها. مخزن ابرداده باید شامل تعاریف داده، قوانین تجاری و منطق دقیق برای مدل سازی توسعه سیستم های تحلیلی باشد.

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

7. ساخت مخزن داده مارتس که شامل زیرمجموعه های داده های انبار و داده های از پیش تجمیع شده خواهد بود. برخی از ابرداده ها نحوه تبدیل، تجمیع و ذخیره سازی داده های انبار خام را در data marts توضیح می دهند.

8. نصب ابزارهای OLAP، سیستم های کاربردی، سرورهای وب و همه ابزار لازمو برنامه های سرورلازم برای دسترسی به داده ها، تجزیه و تحلیل و گزارش.

9. نصب نرم افزار مشتری بر روی ایستگاه های کاری کاربر نهایی نرم افزار(کلاینت "ضخیم") یا مرورگرهایی که از فرمت های استاندارد داده و اپلت های جاوا و همچنین الحاقات لازمپلاگین (کلینت نازک) برای دسترسی کاربر به داده ها.

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

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

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