جلسه 2 – 14/07/93 - مراحل تولید یک پروژه BI

جلسه دوم – 14/07/93

مراحل تولید یک پروژه BI

·         تحلیل

·         طراحی

·         پیاده سازی

·         نگهداری و بهبود

آشنایی با چند اصطلاح در طراحی

·         Dimension – بعد : همان موضوعات تحلیل یک پروژه BI هستند که باید در فاز تحلیل به درستی شناسایی شوند.

مثال در فروش: مشتری، کالا، منطقه، زمان

·         Attribute – ویژگی : مفاهیم داخل هر موضوع تحلیل هستند.

مثال: در بعد زمان : سال، فصل، .... در بعد مکان: استان، شهر، .....

·         Member – عضو: مقادیر موجود در هر ویژگی از بعد را عضو می­نامند.

مثال: در بعد زمان، ویژگی فصل، عضو: بهار، تابستان

·         Hierarchy – سلسله مراتب: یک ساختار درختی که بین مفاهیم مختلف یک بعد ارتباط برقرار می­کند.

مثال: در زمان  سال-فصل-ماه-روز

·         FACT: مجموعه تراکنش های سیستم را تشکیل می­دهد. معمولا هر FACT در برگیرنده مقادیر اندازه­گیری متعددی است که در یک سیستم BI می­خواهیم این مقادیر را با استفاده از موضوعات تحلیل (Dimension ها) مورد تحلیل و بررسی قرار می­دهیم.

مثال: در حوزه فروش: مجموعه تراکنش­های فروش، دریافتی های فروش

·         Measure: مقادیر عددی قابل سنجش در هر مجموعه تراکنش را گویند. به طور مثال در جدول FACT فروش؛ مبلغ فروش، مالیات از این نوع هستند. Measure همیشه عددی است و دریکی از دسته های زیر قرار می­گیرد:

o        Additive – جمع پذیر : مثل مبلغ فروش

o        Semi-Additive – نیمه جمع پذیر: مثل رکوردهای موجودی حساب اشخاص که جمع عمودی آن در هر مقطع نشان دهنده میزان موجودی در آن زمان می­باشد ولی جمع افقی آن بی معنا بوده و در مورد این مثال برای دانستن موجودی هرشخص باید عدد آخر را مورد نظر قرار داد.

o        Non-Additive – جمع ناپذیر: مثل ستون­ شماره فاکتور

·         Cube – مکعب: یک ساختار چندبعدی برای نگهداری داده است که در این ساختار موضوعات تحلیل (Dimension ها) محورهای مکعب را تشکیل می­دهند و مجموعه تراکنش­ها (FACT)  بدنه مکعب را می­سازد.

مثال: فروش شهر تهران برای محصول A در بهار 93

*توجه: منظور از مکعب فقط 3 بعد نیست، در این مکعب می تواند چندین وجه داشت.

مدل های طراحی : بیان کننده چگونگی ارتباط جداول FACT و DIM با یکدیگر است.

-          Star - ستاره­ای: هر FACT به طور مستقیم توسط ابعادش نگاه می­شود. این مدل بالاترین کارایی را دارد.

-          Snowflake – دانه برفی: هر FACT به طور غیر مستقیم بعدی نگاه شود. اگر طراحی به شکل زیر باشد ولی از بعد غیرمستقیم استفاده نشود، طراحی همان ستاره ای است.

-         Constellation – صورت فلکی، کهکشانی: در این مدل FACT ها می­توانند DIM مشترک داشته باشند از طرف دیگری تحلیل یک FACT از طریق DIM ، FACT دیگر باشد (غیرمستقیم).

بنابراین اگر در این وضعیت FACT توسط  DIMغیرمستقیم تفسیر نشود این مدل صورت فلکی نخواهد بود.

مثال این مدل : زمانی که فروش و خرید FACT جداگانه دارند و بخواهیم خرید و فروش را در بعد زمان کنار هم مورد بررسی قرار دهیم.

 

ابزار پیاده سازی SSDT:  یک نسخه (Instance) از VS است که برای کار با سرویس های حوزه BI کاربرد دارد. (SSIS، SSRS، SSAS). در ویرایش های قدیمی SQL Server نام آن BIDS  ( BI Data Studio) بوده است.

توجه: این ابزار تنها هنگام نصب SQL Server قابل نصب است.

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

1.      ساخت DS   (Data Source): در واقع DS عنصر واسط میان DWH و CUBE است و موجودیت های داخلی DWH را برای CUBE قابل روئیت می­کند.

·         ساخت Connection String  برای اتصال به انبار داده

·         تنظیم Impersonation user: در این مرحله کاربری که واکشی داده ها از انبار داده رابطه­ای با دسترسی آن انجام می­شود معرفی می­گردد. این کاربر باید روی DWH دسترسی READ داشته باشد.

توجه: حالت Inherit: ارث بری از دسترسی کاربر تولید کننده Connection Strring  است. سه حالت اول در دسترسی کاربر، از نوع ویندوزی هستند.

2.       ساخت DSV   (Data Source View): یک تصویر از طراحی انجام شده در انبار داده رابطه­ای را ارائه می­دهد تا بتوان از اشیاء موجود در طراحی­های بعدی نظیر Dimension و Cube  استفاده کرد.

·         انتخاب DS ساخته شده

·         انتخاب اشیاء مورد نظر (Table - View) : انتخاب FACT و DIM ها در این مرحله انجام می­شود

·         تعیین نام

امکانات محیط DSV:

·         : Explore Dataنمایش اطلاعات هر جدول یا view

·         Named Calculation: ایجاد ستون های محاسباتی

·         Named Query: امکان ساخت جداول دلخواه (یا نوشتن Query های دلخواه)

·         Logical Primary Key: امکان تعریف یک کلید منطقی

·         Relationship: امکان برقراری ارتباط بین اشیاء DSV، امکان برقراری ارتباط بین عناصر چند DSV وجود دارد

·         امکان ساخت دیاگرام

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

توجه: مفهوم Factless Fact به جدول FACT ی اطلاق می­شود که دارای measure ی نیست. مثال جدول FACT دومی است که در بالا به آن اشاره شد. در اینگونه جداول فقط measure همان COUNT رکوردها است.

چند مورد در خصوص محیط SSDT بخش DSV:

·         تعریف ستونهای محاسباتی یا تعریف Query های جدید در این محیط یا در سمت DWH یا CUBE بسته به سلیقه طراحی است. بدیهی است درصورتیکه که آوردن این عناصر اطلاعاتی در بخش DSV موجب کندی سرعت در فراخوانی اطلاعات خواهد شد.

·         یکی از مواردیکه طراح ناچار به تعیین ستون­های محاسباتی یا .. می­شود، نقص در طراحی DWH است.

·         امکان تغییر یا درج PK روی جداول در این محیط مقدور نیست. درصورتیکه بخواهیم PK یک جدول در این محیط را عوض کنیم، کافی است تا ابتدا آن جدول را به Named Query تغییر موجودیت داده و پس از آن اقدام به انجام تغییرات مورد نظر نماییم. درصورت پشیمانی و نیاز به برگشت جدول به حالت قبل UNDO نداشته، اما کافی است تا دوباره جدول مذکور از فهرست عناصر DS انتخاب شود.

·         برای طراحی دیاگرام هم می­توان از عناصر DS انتخاب کرد و هم از عناصر DSV. که در حالت دوم تمام عناصری که در DSV تعریف شده اند قابل دسترس خواهند بود.