بخش های از فصل چهارم

 

مشکلات پیرامون طراحی مدل داده‌ای(Data model) انبار داده

مشکلات اصلی طراحی مدل انبار داده عبارتند از:

  • نوع‌های داده‌ای متفاوت
  • وجود مسیرهای متفاوت برای استفاده از انبار داده
  • وجود ساختارهای متفاوت
  • وجود تکنیکهای چندگانه برای طراحی مدل انبار داده
  • عدم برنامه‌ریزی برای جمع آوری داده ها (Replication)
  • حجم زیاد داده

مدل داده‌ای انبار داده پیچیده‌تر از مدل داده‌ای سیستم‌های کاربردی (OLTP) است.

برخی از تفاوتهای اصلی در میان مدل طراحی داده‌ای انبار داده و طراحی مدل داده‌ای برنامه کاربردی عبارتند از:

وجود نوع‌های متفاوت

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

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

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

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

انبار داده می‌تواند با استفاده از ERD (مدل ارتباط موجودیت‌)یا مدل چند بعدی (DM) طراحی شود ، یا می‌توانند ترکیبی از هر دو نوع باشد برای انتخاب ساختار درست باید با کاربرد هر کدام از آنها و مشخصه‌های طراحی آنها آشنا شوید.

تکنیکهای مدل کردن چندگانه

استفاده از روش ERM برای سیستم‌های OLTP مناسب است، هدف از پیاده‌سازی انبار داده بهینه‌سازی دسترسی برای تحلیل داده‌هاست. به همین دلیل برای انبار داده بایداز مدل طراحی متفاوت استفاده شود.

جمع‌آوری کردن برنامه‌ریزی شده

معمولاً تکرار داده در پایگاه داده‌های OLTP اتفاق نمی‌افتد، تکرار داده‌ها یکی از مزایای محیط انبار داده برای دستیابی به تکرارپذیری بهینه (denormalization) در پایگاه داده انبار داده است

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

حجم زیاد دادن

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

مستند کردن متادیتا (اطلاعات پایه)

مستند کردن مقادیر باید شامل موارد زیر باشد:

  • مستند کردن پردازش‌های طراحی
  • مستند کرد پرداز‌ش‌های پیاده‌سازی
  • ارائه کردن یک نسخه‌ از تغییرات
  • ذخیره کردن بهبودهای که در هر زمان انجام می‌شود.

تعریف متادیتا عبارت است از «داده‌ای که درباره داده توضیح می‌دهد.» متادیتای انبار داده داده‌هایی است که درباره داده انبار داده و پردازش‌هایی که برای ایجاد کردن انبار داده انجام می شود توضیح می‌دهد.

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

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

المان‌های متادیتا کسب و کار

  • نام شاخص‌ (measure)ها
  • ابعاد کسب و کار

خصوصیت‌های بعد

  • داده‌های نمونه
  • تعریف کردن کسب و کار و نقش‌ها

اولین نسخه از متادیتای کسب و کار در طول فاز مدل کردن کسب و کار تهیه می‌شود. هر پردازش کسب و کار که در انبار داده پیاده‌سازی می‌شود باید با خروجی‌های زیر مستند شود:

شاخص (Measure)ها: نام (مانند فروش دلار، واحدهای فروخته شده و …)

بعد کسب و کار (پارامترهای تحلیل): نام ابعاد سطح بالای کسب و کار (مانند محصول، زمان، مشتری و …)

خصوصیت های بعد (attributes): نام خصوصیت ابعاد

داده‌های مثال: یک مثال از داده منبع برای خصوصیت ابعاد یا شاخص (measure)ها

مدل اسکیمای دانه‌برفی

بر طبق گفته کیمبال وقتی که تنوع سطح پائین فیلدهای بعد به جداول جداگانه‌ای منتقل شده و این جدول توسط کلیدهایی با هم مرتبط باشند طراحی می‌تواند دانه‌برفی باشد.

ERD یک مدل دانه‌برفی وسیع‌تر از مدل ستاره‌ای است چون داده ابعاد بیشتر نرمال شده هستند ، پیاده‌سازی  یک مدل دانه‌برفی به معنی ایجاد کردن سلسله مراتب  خارج از بعد است (نرمال کردن داده)

یکی از دلایل اصلی اینکه چرا غالباً مدل ستاره‌ای بجای مدل دانه‌برفی غالباً مورد استفاده قرار می‌گیرد ‌برای استفاده از مزایای بهبود کارایی پرس‌وجوها است.

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

مدل اسکیمای دانه‌برفی

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

یک مدل دانه‌برفی:

  • باعث کاهش کارایی می‌شود چون دارای چندین joins با جداول دیگر است.
  • ساختاری را ارائه می‌دهد که می‌توان تغییر براساس نیازمندی را سریع‌تر پیاده‌سازی ‌کند.
  • بارگذاری داده در جداول نرمال شده کوچکتر در مقایسه با اسکیمای ستاره‌ای که داده‌های آن غیر نرمال است سریعتر است.
  • اجازه می‌دهد که جداول تاریخچه‌ای را برای داده‌های تغییر یافته استفاده کنیم.
  • دارای یک ساختار پیچیده است که تشخیص آن برای ابزارهای پشتیبانی و ابزارهای هوش تجاری سخت‌تر است.

در کنار اسکمیاهای ستاره‌ای و دانه برفی مدل‌های دیگر نیز وجود دارد که می‌تواند مورد استفاده قرار بگیرید.

صورت فلکی: یک مدل صورت فلکی (مدل کهکشانی نیز نامیده می‌شود) شامل مجموعه‌ای از مدل‌های ستاره‌ای است. اگر شما یک fact اصلی و جداول خلاصه‌سازی شده از ابعاد مختلف دارید،مدل صورت فلکی می‌تواند یک طراحی مفید باشد. از طریق این طراحی می‌توانید به ابعاد اجازه دهید که مابین چندین Fact به اشتراک گذاشته شوند.

انواع کلیدهای پایگاه داده

  • کلیدهای اصلی (PKها)
  • کلیدهای خارجی (FKها)
  • کلیدهای ترکیبی (Composit)
  • کلیدهای Surrogate

  • کلید اصلی (PK): یک کلید شامل یک یا چند ستون است که منحصراً یک رکورد در جدول بعد را معرفی می‌کند. یک محدودیت کلید اصلی برای اطمینان از یکتا بودن همه رکوردهای جدول برای آن ستون استفاده می‌شود. وجود ایندکس که جزئی از کلید اصلی است باعث بهبود کارایی می‌شود. انتخاب کلید اصلی یک ملاحظه مهم طراحی مهم است چون یکپارچگی داده را حفظ می‌کند و عدم وجود داده‌های تکراری را در داخل جدول بررسی می‌کند.
  • کلید خارجی: این کلید به یک ‍PK در جدول دیگر اشاده می‌کند. در انبار داده مورد استفاده FKها وقتی است که از اسکیمای ستاره‌ای استفاده می‌کنید.
  • کلید ترکیبی: ترکیب چند کلید PK‌ می‌تواند یک کلید ترکیبی ایجاد کند.

معمولاً کلیدهای ترکیبی در انبار داده استفاده می‌شود.

  • Surrogate key: کلیدی است که توسط سیستم تولید می‌شود: این کلید به تنهایی مفهومی ندارد. بنابراین، شما نمی‌توانید درباره بخشی که کلید به آن مرتبط است مطمئن شوید، اساساً یک عدد با 4 بایت مناسب است. یک مثال از یک کلیدی که توسط سیستم تولید می‌شود مقدارrowId است که توسط اوراکل به ازای هر رکوردی که ثبت می‌شود تولید می‌شود. در محیط‌های انبار داده برای حفظ داده‌های تاریخچه‌ای SK (Surrogate Key) می‌تواند به جای NK (Natrol Key) به منظور جلوگیری از تکرار مقادیر کلید طبیعی استفاده شود (یک مثال از آن در بخش SCD در این درس بحث میشود
  • SK (Surrogate Key) در جدول بعد به عنوان کلید اصلی تعریف می‌شود.

مزایای استفاده کردن از SK

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