خانه / آموزش Microsoft BI / درس نهم – مدل رابطه ای

درس نهم – مدل رابطه ای

مدل رابطه ای Relational Model :

تا اینجا انبار داده و مدل های طراحی را بررسی کردیم و نحوه کار آن ها را دیدیم.

اکنون مدل های رابطه ای را میخواهیم بررسی کنیم. زیرا انبار داده طراحی شده از طریق بانک اطلاعاتی Sql Server یا اوراکل پیاده سازی میشوند که این بانک های اطلاعاتی Relational یا رابطه ای هستند.

حال مدل رابطه ای یعنی چی؟

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

اتفاقی که اینجا میوفتد افزونگی اطلاعات Data Redundancy است و یکی از معایب این سیستم این هست که اگر اطلاعات تغییر کند ، باید به سه واحد بالا اعلام کند تا تغییرات در اطلاعاتش ثبت شود و اگر بروزرسانی اطلاعات بخوبی انجام نشود , در این شرایط ناسازگاری اطلاعات  Data Inconsistency به وجود میاید.

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

دیگر این مشکل را نخواهیم داشت که در سه جا تغییر اطلاعات را ثبت کنیم و فقط تغییر را در جدول دانشجو انجام میدهیم.

RDBMS

 

در مدل رابطه ای ابتدا موجودیت ها (Entity) ها را تعیین میکنیم.

موجودیت Entity : هر آن چیزی که میخواهیم در موردش اطلاعات داشته باشیم.

در سیستم دانشجویی موجودیت های ما می شود : ترم ها ، دروس ، اساتید و دانشجویان.

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

مدل اول ، ارتباط یک به یک یا One to One :

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

One to One

 

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

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

مدل دوم ، ارتباط یک به چند یا One to Many :

ارتباط یک به چند ارتباط مدنظرمان است و باید سعی کنیم روابط بین جداول Fact و Dimension به این صورت باشند.

فرض کنید هر کتاب را یک ناشر چاپ می کند اما از طرفی ، یک ناشر می تواند N کتاب را چاپ کرده باشد.

One to Many

 

یا برای مثال اگر دو جدول DimProduct و FactSales را در نظر بگیریم ، هر کالا میتواند چند بار فروخته شده باشد و چند رکورد در جدول فروش داشته باشد.

 

مدل سوم ، ارتباط چند به چند یا Many to Many :

این نوع رابطه اصلا پیاده سازی نمی شود و باید آن را تبدیل کنیم به روابط یک به چند.

برای مثال در یک جدول ارتباط نوازنده های موسیقی را داریم و در جدول دیگری ، اطلاعات آهنگ ها را داریم.

یک نوازنده میتواند N تا آهنگ را درست کرده باشد و از طرفی یک آهنگ میتواند توسط N نوازنده ایجاد شده باشد.


برای تبدیل این نوع رابطه به One to Many باید چه کار کرد؟ ( سوال مصاحبه فنی ! )

باید از جدولی به نام Bridge Table یا جدول واسط استفاده کنیم. در این مثال ، در این جدول واسط ، فقط کد نوازنده و کد آهنگ را قرار میدهیم و جدول های دیگرمان را به صورت یک به چند به این جدول متصل میکنیم.

Many to Many

 

۳ قانون در طراحی جداول یا موجودیت هایمان در Sql Server باید رعایت کنیم:

– هر موجودیتی باید یک ویژگی منحصر به فرد داشته باشد که بتوان آن را از سایر نمونه های آن موجودیت تفکیک کنیم.

برای مثال از نام مشتری  نمیتوان به عنوان این ویژگی منحصر به فرد استفاده کرد زیر اسامی تکرار میشوند و باید از کد ملی استفاده کنیم.

– اگر موجودیت ما ویژگی یکتا نداشت ، باید خودمان برایش ایجاد کنیم مثلا به صورت Auto Increment به آنها کد های یونیک اطلاق کنیم.

– تنها اطلاعاتی را ذخیره کنید که مستقیما به آن موجودیت مربوط می شود.

فرض کنید یک جدول فروش با اطلاعات  کد مشتری ، کد کالا ، تعداد فروش ، ریال فروش ، سن و محل سکونت مشتری را داریم.

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

* به کد مشتری در در جدول مشتریان ، Primary Key و در جدول فروش ، Foreign Key اطلاق می شود.

درباره‌ی علیرضا حسن نژاد

همچنین ببینید

Deploy کردن Tabular Data Model

درس بیست و نهم – Deploy کردن Tabular Data Model

Deploy کردن Tabular Data Model فرض کنید طراحی دیتا مدل به اتمام رسید. حال میخواهیم …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

معادله امنیتی (فقط عدد بنویسید) *