جلسه نهم - 19/08/93 - شناسایی تغییرات در جداول پایه OLTP

جلسه نهم – 19/08/93

شناسایی تغییرات در جداول پایه OLTP

شناسایی تغییرات داده

• در جداول Dimension

  • تعداد سطر (حجم اطلاعات) کم است

  • نیاز به نگهداری تاریخچه دارد

• در جداول Fact

  • تعداد سطر (حجم اطلاعات) زیاد است

  • نیاز به نگهداری تاریخچه ندارد

برای به روزرسانی جداول Dimension از جداول متناظر در سیستم OLTP از SCD  و برای به روزرسانی جداول Fact  از روش CDC استفاده می شود.

SCD  - Slowly Changing Dimension: مجموعه روش­هایی برای مدیریت تغییرات داده در جداول پایه ابعاد است.

انواع SCD:

1. Type 0 : عدم اعمال تغییرات

   • کاربرد در سیستم مالی کدینگ حسابها و استفاده در کل شعبه هاست. بنابراین اگر در شعبه شرح کل تغییر کرد نسبت به آن بی تفاوت هستیم.

2. Type 1 : اعمال مستقیم تغییر

   • کاربرد در سیستم مالی کدینگ حسابها و استفاده در کل شعبه هاست. بنابراین اگر در شعبه شرح کل تغییر کرد نسبت به آن بی تفاوت هستیم.

   • مزیت: سادگی

   • عیب: نداشتن تاریخچه

   • مثال : نماینده فروش با اطلاعات   شناسه شخص/نام/محل کار      اطلاعات قدیمی:  100/ Ali/ تهران    اطلاعات جدید 100/Ali/ اصفهان

3. Type 2 : ایجاد سطر جدید

   • اعمال مستقیم تغییر

   • مزیت: نگهداری تاریخچه / جمع بندی آسان برروی ویژگی تاریخچه

   • عیب: به دلیل وجود شناسه های مختلف، انجام جمع بندی برروی ویژگی های فاقد تاریخچه دشوار است.

   • مثال: اطلاعات قدیمی  100/Ali/ تهران       اطلاعات جدید: 101/Ali/اصفهان

   • در این روش می توان برای آخرین اطلاعات معتبر فیلد اطلاعاتی به عنوان وضعیت:فعال/غیرفعال  نگهداری کرد.

4. Type 3 : ایجاد ستون جدید

   • مثال:  نگهداری اطلاعات در قالب روبرو    شناسه شخص/نام/محل کار قدیم / محل کار جدید        100/Ali/تهران/اصفهان

   • مزیت: حفظ یک رکورد مشترک برای رکورد مورد نظر

   • عیب: اگر تغییرات زیاد باشد، نیاز به تغییر مداوم طراحی است

5. Type 4 : نگهداری تاریخچه در جداول جداگانه

   • در جدول اصلی آخرین وضعیت نگهداری می­شود – در جدول تاریخچه، تغییرات

   • عیب: عدم امکان پیاده سازی در ساختار چندبعدی

   • مثال:  اطلاعات اصلی:   100/Ali/اصفهان    

جدول تاریخچه:

شناسه جدول	شناسه شخص	نام	محل کار	تاریخ پایان اعتبار
1	100	Ali	تهران	01/01/93
2	100	Ali	اصفهان	NULL

1. Type 6 : ترکیبی از راه حل های 1+2+3 می باشد به آن روش Kimball یا Hybrid هم گفته می شود.

   • تعاریف

     • SK: Surrogate Key (کلید جانشین): کلیدی است که محل اتصال FACT و Dimension بوده و در انبار داده تولید می­شود. برای تولید این کلید می­توان از مقادیر auto increment استفاده نمود.

     • Natural Key: کلید رکورد اطلاعاتی در سیستم OLTP  می­باشد

     • Non-historical Attributes:مانند نام شخص است که نیازی به نگهداری تاریخچه آن نیست

     • Historical Attributes: مانند نام شهر است که نیاز به نگهداری تاریخچه آن هست

     • Historical Attributes – Current: این فیلد اختیاری بوده و نشان گر آخرین مقدار معتبر است

     • Start/End Date:نشانگر طیف زمانی یا اعتبار جاری رکورد اطلاعاتی است. بجای تاریخ می­توان از فعال/غیرفعال یا موارد مشابه استفاده نمود.

SK	Natural Key	Non-historical Attributes	Historical Attributes	Historical Attributes – Current	Start Date	End Date
1	100	Ali	تهران	تهران	01/01/80	01/01/90
2	100	Ali	اصفهان	تهران	01/01/90	01/01/92
3	100	Ali	شیراز	تهران	01/01/92	null

• مزایا:

  • به دلیل وجود SK های متفاوت انجام جمع بندی برروی هریک از وضعیت­های تاریخچه به راحتی امکان پذیر است.

  • به دلیل وجود Natural Key یکسان انجام جمع بندی بدون درنظر گرفتن وضعیت های تاریخچه امکان پذیر است.

  • وجود ستون Historical Attributes – Current کمک می­کند که آخرین وضعیت ویژگی مورد نظر را در اختیار داشته باشیم.

معرفی کامپوننت SCD در محیط Data Flow Task  (DFT)

این کامپوننت کلیه داده های جدول مبدا و مقصد را در حافظه DFT بارگزاری می نماید و داده های دو جدول را براساس Natural Key به هم Join نموده و تغییرات ستون­ها را شناسایی می­نماید. تغییرات هریک از ستون ها به یکی از سه روش زیر قابل مدیریت است:

• Fixed Attribute -> Type 0

• Changing Attribute -> Type 1

• Historical Attribute -> Type 2

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

مثال:

جدول مبدا:

• Title : Fixed Attribute

• Firstname : Changing Attribute

• Lastname : Historical Attribute

جدول مقصد:

• SK

• Natural Key

• Title

• Firstname

• Lastname

• LastNameCurrent

• StartDate

• EndDate

• IsCurrent

• Inferred *

گام صفر: ایجاد یک Source اطلاعاتی و اشاره به جدول مبدا

گام اول: تعیین Business Key – که در اینجا Natural Key است.

گام دوم: تعیین اینکه هریک از فیلدهای اطلاعاتی جدول مبدا از چه نوعی است و پس از آن تعیین ویژگی های هر نوع برای فیلد مذکور

• Fixed: درصورت دیدن تغییرات از این نوع از تغییر در مقصد اجتناب می شود / بنابراین درصورت تغییر فیلد Title مقدار آن در جدول مقصد تغییر نخواهد کرد.

• Changing: تغییر برروی فیلد رکورد متناظر انجام می­شود / بنابراین درصورت تغییر فیلد FirstName مقدار جدید عینا جایگزین مقدار جدول مقصد می شود.

  • Changing Attributes …: در صورت فعال شدن این گزینه، تغییر شناسایی شده (فیلد) برروی تمام سطرها به Business Key یکسان اعمال خواهد شد.

• Historical Attributes: باید ستونی (هایی) برای معرفی سطر جاری تعیین شوند.

تنظیمات Inferred Member

اگر در هنگام بارگزاری جداول FACT به رکوردهایی برخورد کنیم که کد آنها در جدول بعد وجود نداشته باشد، برای جلوگیری از بروز خطا در بارگزاری می­توان طی فرایند این کدها را در جدول بعد مورد نظر ثبت نمود و از SK آنها برای بارگذاری جدول FACT استفاده کرد. پس از اتمام بارگزاری سطرهایی درجدول بعد خواهیم داشت که تنها مقدار SK و Natural Key آنها پرشده است. این سطرها که Inferred Member نامیده می­شوند باید در بارگزاری بعدی جدول بعد شناسایی شده و مقادیر خالی آنها پر شود.

OLE DB Command Component: این کامپوننت به ازای هرسطر از جریان داده یک گزاره SQL را برروی یک انبار داده (DB) مقصد اجرا می نماید. بنابراین همانند CURSOR در TSQL بوده و همانند آن کند است. یکی از دلیلی که استفاده از سازوکار SCD صرفا برای جداول با تعداد رکورد کم توصیه می شود نیز همین است.