تحلیل و مدل‌سازی رابطه‌ای داده در SSADM | SSADM

تحلیل و مدل‌سازی رابطه‌ای داده در SSADM

توسط admin | گروه مهندسی نرم افزار | 1405/05/20

نظرات 0

تحلیل و مدل‌سازی رابطه‌ای داده در SSADM

بازه صفحات منبع: 135 تا 151
زبان منبع: مجاری
روش: SSADM
اعتبار ترجمه: ترجمه با کمک هوش مصنوعی

صفحه 135 منبع

13. مروری بر تحلیل رابطه‌ای داده

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

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

13.1 هدف

هدف تحلیل رابطه‌ای داده این است که:

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

پاورقی 32: [CCTA95] و [CCTA95A]، Reference Manual Part 4: Modelling Data، صفحات 4-53 تا 4-82؛ Users Guide Part 2: Specification (Conceptual Model)، بخش Relational Data Analysis، صفحات 3-29 تا 3-57؛ همچنین [CCAT90].

شکل 49 ـ جایگاه تحلیل رابطه‌ای داده در الگوی پایه توسعه سیستم.

تصویر مرجع صفحه 135 سند اصلیتصویر کامل صفحه 135 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 135 سند اصلی.

صفحه 136 منبع

13. مروری بر تحلیل رابطه‌ای داده

13.2 خلاصه کاربرد تکنیک در یک پروژه SSADM

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

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

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

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

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

اصول تحلیل رابطه‌ای داده را می‌توان در تمام طول پروژه، به‌شکل غیررسمی، برای توسعه مدل منطقی داده به کار برد.

تصویر مرجع صفحه 136 سند اصلیتصویر کامل صفحه 136 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 136 سند اصلی.

صفحه 137 منبع

14. مدل‌سازی رابطه‌ای داده

14.1 تحلیل رابطه‌ای داده

در جریان تحلیل رابطه‌ای داده، یک محصول نهایی مستقل SSADM تولید نمی‌شود. یکی از نتایج، کاربرگ‌های تحلیل داده و نتیجه دیگر، مدل منطقی داده‌ای است که ممکن است اصلاح شده باشد.

14.1.1 مفاهیم

14.1.1.1 روابط

تعریف 14-1 ـ رابطه (Relation)

رابطه یک جدول دوبعدی است که از تعدادی سطر و ستون تشکیل می‌شود. هر ستون یک ویژگی (Attribute) رابطه را نشان می‌دهد و هر سطر یک نمونه مشخص از رابطه و مقادیر ویژگی‌های آن را نمایش می‌دهد.

مفهوم رابطه در عمل معادل مفهوم موجودیت است. برای اینکه یک جدول «رابطه» نامیده شود باید ویژگی‌های زیر را داشته باشد:

  • هیچ دو سطری کاملاً یکسان نباشند؛
  • ترتیب سطرها اهمیتی نداشته باشد؛
  • ترتیب ستون‌ها اهمیتی نداشته باشد؛
  • هر ستون نام یکتایی داشته باشد.

نمونه رابطه «شخص»:

شماره شخصی | نام شخص | وضعیت تأهل | تعداد افراد تحت تکفل

16607121213 | Kovács János | متأهل | 2

27001122334 | Kiss Adél | مجرد | 0

13406255543 | Szabó Benedek | متأهل | 1

16702121112 | Kovács János | مجرد | 0

در شکل، سطر، ستون، نام ویژگی‌ها و ویژگی کلید اصلی مشخص شده‌اند.

شکل 50 ـ نمونه یک رابطه.

تصویر مرجع صفحه 137 سند اصلیتصویر کامل صفحه 137 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 137 سند اصلی.

صفحه 138 منبع

14. مدل‌سازی رابطه‌ای داده

برای اینکه یک رابطه «نرمال‌شده» و در فرم نرمال اول (1NF) باشد، یک ویژگی دیگر نیز لازم است:

  • هر ویژگی باید اتمی/ابتدایی باشد.

هیچ دو سطری یکسان نیستند

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

ترتیب سطرها اهمیتی ندارد

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

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

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

هر ستون نام یکتایی دارد

نام ستون‌ها برای شناسایی عناصر داده استفاده می‌شود؛ بنابراین هر ستون باید نام یکتا داشته باشد. اگر دو ستون از یک دامنه مقدار باشند، مثلاً «شماره حساب»، برای هرکدام باید نام نقش تعیین شود تا ابهامی باقی نماند. برای انتقال وجه درون یک بانک می‌توان دو نقش «حساب بدهکار» و «حساب بستانکار» را به کار برد و ستون‌ها را «شماره حساب بدهکار» و «شماره حساب بستانکار» نامید.

هر ویژگی اتمی است

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

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

نرمال‌سازی بیشتر، وابستگی‌های تابعی میان ویژگی‌های رابطه را بررسی می‌کند.

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

تصویر مرجع صفحه 138 سند اصلیتصویر کامل صفحه 138 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 138 سند اصلی.

صفحه 139 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.1.2 دامنه‌های مقدار

تعریف 14-2 ـ دامنه مقدار (Domain)

دامنه مقدار مجموعه مقادیر ممکنی است که یک ویژگی می‌تواند بپذیرد.

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

نمونه رابطه نرمال‌نشده «فاکتور»:

شماره فاکتور | محصول | مقدار | قیمت

1122/9 | P00112 | 100 | 100000

| P00211 | 10 | 12000

| P11122 | 1000| 23000

0911/9 | P00112 | 1 | 100000

| P00222 | 3 | 21000

| P11000 | 12 | 24000

در نمونه، گروه تکرارشونده و کلید اصلی مشخص شده‌اند.

شکل 51 ـ نمونه رابطه نرمال‌نشده.

نمونه رابطه نرمال‌شده:

شماره فاکتور | شناسه محصول | مقدار | قیمت

1122/93 | P001123 | 100 | 100000

1122/93 | P002111 | 10 | 12000

1122/93 | P111222 | 1000 | 23000

0911/93 | P001123 | 1 | 100000

0911/93 | P002221 | 3 | 21000

0911/93 | P110002 | 12 | 24000

شکل 52 ـ نمونه رابطه نرمال‌شده.

تصویر مرجع صفحه 139 سند اصلیتصویر کامل صفحه 139 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 139 سند اصلی.

صفحه 140 منبع

14. مدل‌سازی رابطه‌ای داده

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

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

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

14.1.1.3 کلید اصلی و کلیدهای نامزد

تعریف 14-3 ـ کلید اصلی

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

تعریف 14-4 ـ کلید نامزد (Candidate Key)

هر مجموعه حداقلی از ویژگی‌ها که بتواند به‌عنوان شناسه یکتای سطر استفاده شود «کلید نامزد» نامیده می‌شود.

«حداقلی» یعنی در مجموعه ویژگی‌های کلید نامزد هیچ زیرمجموعه‌ای وجود ندارد که خود نیز کلید نامزد باشد.

تعریف 14-5 ـ کلید ساده

اگر یک کلید نامزد فقط از یک ویژگی تشکیل شده باشد، کلید ساده نامیده می‌شود.

تعریف 14-6 ـ کلید مرکب

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

تعریف 14-7 ـ کلید سلسله‌مراتبی

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

کلید سلسله‌مراتبی اغلب برای شناسایی یکتای اعضای یک گروه تکرارشونده استفاده می‌شود؛ در این حالت جزء تعیین‌شونده غالباً تولیدشده یا مصنوعی است، مثلاً شماره ترتیبی رکورد داخل گروه تکرارشونده، و ممکن است مستقل از آن معنای کسب‌وکاری نداشته باشد.

تصویر مرجع صفحه 140 سند اصلیتصویر کامل صفحه 140 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 140 سند اصلی.

صفحه 141 منبع

14. مدل‌سازی رابطه‌ای داده

از میان کلیدهای نامزد باید یکی به‌عنوان شناسه یکتای رابطه انتخاب شود. این کلید نامزد «کلید اصلی» نامیده می‌شود. معمولاً بهتر است کوتاه‌ترین کلید انتخاب شود. زمانی که کلید نامزد طبیعی مناسبی وجود ندارد، اغلب یک کلید مصنوعی معرفی می‌شود تا از کلیدهای اصلی بسیار طولانی که کلید طبیعی یا مفهومی‌اند اجتناب شود.

14.1.1.4 کلیدهای خارجی

تعریف 14-8 ـ کلید خارجی/بیگانه (Foreign Key)

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

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

14.1.1.5 نرمال‌سازی

نرمال‌سازی فرایندی است که طی آن ویژگی‌ها در روابط بهینه گروه‌بندی می‌شوند.

برای رسیدن به فرم نرمال سوم (3NF)، عناصر داده با فعالیت‌های زیر تحلیل می‌شوند:

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

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

پاورقی 33: این فرایند از کار دکتر Edgar Codd سرچشمه می‌گیرد. او سه مرحله نرمال‌سازی، یعنی فرم نرمال اول، دوم و سوم (1NF، 2NF و 3NF) را تفکیک کرد. بعدها تعریف اصلی 3NF دقیق‌تر شد و گاهی با عنوان Boyce/Codd Normal Form یا BCNF از آن یاد می‌شود.

تصویر مرجع صفحه 141 سند اصلیتصویر کامل صفحه 141 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 141 سند اصلی.

صفحه 142 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.1.6 وابستگی‌های تابعی

تعریف 14-9 ـ وابستگی تابعی

ویژگی Y از رابطه R «به‌طور تابعی» به ویژگی دیگری X از همان رابطه وابسته است اگر و تنها اگر برای هر مقدار X دقیقاً یک مقدار Y ممکن باشد. به بیان دیگر، با دانستن مقدار X می‌توان مقدار Y را تعیین کرد. بنابراین عبارت‌های «X به‌طور تابعی Y را تعیین می‌کند» و «Y به‌طور تابعی به X وابسته است» یک معنا دارند.

برای یافتن وابستگی‌های تابعی مفید است بررسی شود آیا یک عنصر داده مقدار عنصر داده دیگری را تعیین می‌کند یا خیر.

برای اینکه تحلیلگر بتواند ویژگی‌ها را در روابط/موجودیت‌های بهینه گروه‌بندی کند، باید وابستگی‌های میان داده‌ها را درک کند. این روابط به‌طور رسمی «وابستگی تابعی» نامیده می‌شوند. شناسایی آن‌ها نیازمند دسترسی دقیق به دانش کاربران درباره داده‌هاست؛ بنابراین مفاهیم وابستگی و نرمال‌سازی ذاتاً معناشناختی‌اند.

تعریف وابستگی را می‌توان به گروه ویژگی‌ها نیز گسترش داد؛ یعنی یک ویژگی رابطه می‌تواند به مقادیر یک گروه از ویژگی‌ها وابسته باشد.

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

مفهوم «وابستگی تابعی کامل» بسط دیگری است. اگر X یک گروه ویژگی باشد، Y به‌طور کامل به X وابسته است زمانی که به X وابسته باشد ولی به هیچ زیرمجموعه‌ای از X وابسته نباشد. در تحلیل رابطه‌ای داده، دستیابی به وابستگی کامل از طریق شناسایی و حذف وابستگی‌های جزئی انجام می‌شود.

هر ویژگی یا گروه ویژگی که ویژگی دیگری کاملاً به آن وابسته باشد «تعیین‌کننده» (Determinant) نامیده می‌شود.

پاورقی 34: این تعریف با تعریف تابع ریاضی متناظر است: یک تابع برای هر مقدار حوزه تعریف دقیقاً یک مقدار در مجموعه مقادیر دارد. در این قیاس، رابطه نقش تابع را دارد و کلید، عنصری از حوزه است که رابطه برای هر ویژگی مقدار یکتای متناظر را تعیین می‌کند. این تعریف مانع نمی‌شود که برای کلیدهای متفاوت، یک ویژگی مقدار یکسانی داشته باشد؛ جلوگیری از آن شرط قوی‌تری است که متناظر با تابع یک‌به‌یک/دوسویی است.

14.1.2 شرح کوتاه تکنیک

تحلیل رابطه‌ای داده در SSADM، مدل‌سازی منطقی داده را تکمیل و کنترل می‌کند. با نگاه‌کردن به داده‌های سیستم از دیدگاهی دوم و کاملاً متفاوت، کیفیت طراحی نهایی سیستم افزایش می‌یابد.

تصویر مرجع صفحه 142 سند اصلیتصویر کامل صفحه 142 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 142 سند اصلی.

صفحه 143 منبع

14. مدل‌سازی رابطه‌ای داده

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

فرایند چنین است:

  • گروه‌های تکرارشونده را با تجزیه گروه‌های داده حذف کنید؛
  • وابستگی‌های میان عناصر داده را بررسی کنید؛
  • وابستگی‌های جزئی را با تجزیه گروه‌ها حذف کنید؛
  • وابستگی‌های غیرکلیدی را با تجزیه گروه‌ها حذف کنید؛
  • نتایج را عقلانی‌سازی کنید.

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

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

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

تحلیل رابطه‌ای داده را می‌توان در نقاط مختلف روش‌شناسی و هر جا که مدل منطقی داده ساخته می‌شود، مانند گام‌های 140 و 320، به کار برد؛ اما به‌صورت رسمی باید در گام 340 و بر اساس ساختارهای IOS تولیدشده در تعریف عملکرد اجرا شود. در اینجا ساختارهای IOS بر حسب پیچیدگی، شاخص‌های حجمی یا فراوانی و اهمیت انتخاب می‌شوند.

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

پاورقی 35: برای شرح تفصیلی‌تر بنگرید به [Quittner93]، Quittner Pál، «Adatbáziskezelés a gyakorlatban»، Akadémiai Kiadó، Budapest، 1993، ISBN 963 05 6587 0؛ و [Halassy94]، Halassy Béla، «Az adatbázis tervezés alapjai és titkai»، IDG kft.، Budapest، 1994.

تصویر مرجع صفحه 143 سند اصلیتصویر کامل صفحه 143 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 143 سند اصلی.

صفحه 144 منبع

14. مدل‌سازی رابطه‌ای داده

در ارتباط با تعریف عملکرد، تحلیل رابطه‌ای داده برای کنترل انطباق مدل منطقی داده با عملکردها به کار می‌رود؛ این کار از طریق بررسی ورودی‌ها و خروجی‌های منطقی عملکردها ـ ساختارهای IOS و شرح آن‌ها ـ و استفاده از دانش کاربران درباره داده‌ها انجام می‌شود.

در کاربرد عمومی تحلیل رابطه‌ای داده، بعضی عناصر داده را می‌توان نادیده گرفت. در محیط فیزیکی رایانه از جمله:

  • نشانگرهای سرریز؛
  • شمارنده‌های بایت در فیلدها و رکوردهای با طول متغیر؛
  • نشانگر پایان فیلد در فیلدهای با طول متغیر؛
  • اشاره‌گرها (Pointers)؛
  • علامت‌های چاپ در رکوردهای فایل‌های چاپی.

در تحلیل فرم‌ها و گزارش‌ها می‌توان این موارد را کنار گذاشت:

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

14.1.3 محصولات

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

14.1.4 تولید فرم نرمال سوم

14.1.4.1 اصول کلی و مرور

برای تولید 3NF باید مراحل زیر انجام شوند:

a. داده‌های نرمال‌نشده را دریافت و آن‌ها را به‌صورت روابط نرمال‌نشده نمایش دهید؛

b. فرم نرمال اول را ایجاد کنید: گروه‌های تکرارشونده را حذف کنید و کلیدهای اصلی سطح بالاتر را به روابطی که از تجزیه ایجاد شده‌اند بیفزایید؛

c. وابستگی‌ها را درک کنید؛

d. فرم نرمال دوم را ایجاد کنید: ویژگی‌های زائد را از کلید اصلی حذف کنید و وابستگی به بخشی از کلید را با تجزیه روابط حذف نمایید؛

e. فرم نرمال سوم را ایجاد کنید: کنترل کنید که همه وابستگی‌ها به کلیدهای نامزد مربوط باشند و هر وابستگی به تعیین‌کننده غیرکلید نامزد را با تجزیه روابط حذف کنید؛

f. نتایج را عقلانی‌سازی کنید: امکان ادغام روابط دارای کلید اصلی یا کلید نامزد یکسان را بررسی و همه روابط زائد را حذف کنید. رابطه‌ای زائد است که ویژگی‌هایش در رابطه دیگری نیز وجود داشته باشد.

در فرایند نرمال‌سازی هیچ بخشی از اطلاعات اصلی از بین نمی‌رود. با استفاده از روابط 3NF حاصل و عملگر رابطه‌ای «Join» می‌توان روابط نرمال‌نشده اولیه را دوباره ایجاد کرد.

تصویر مرجع صفحه 144 سند اصلیتصویر کامل صفحه 144 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 144 سند اصلی.

صفحه 145 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.4.2 نمایش داده‌های نرمال‌نشده

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

14.1.4.3 عقلانی‌سازی نتایج

در این مرحله باید امکان ادغام روابطی که کلید اصلی یا کلید نامزد یکسان دارند بررسی و روابط زائد ـ روابطی که همان عناصر داده را در بر دارند ـ حذف شوند. ترتیب ویژگی‌ها در داخل رابطه اهمیتی ندارد. روابط باقی‌مانده باید نام‌های معنادار بگیرند؛ معمولاً نام موجودیت‌های مدل منطقی داده مناسب است.

تصویر مرجع صفحه 145 سند اصلیتصویر کامل صفحه 145 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 145 سند اصلی.

صفحه 146 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.5 نمایش روابط 3NF به‌صورت LDM

روابط نرمال‌شده و مدل منطقی داده دو رویکرد متفاوت برای مدل‌کردن یک اطلاعات یکسان‌اند. موجودیت‌های مدل منطقی داده با روابط 3NF متناظرند و روابط میان موجودیت‌ها با تطابق کلید نامزد و کلید خارجی در 3NF متناظر هستند.

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

معمولاً می‌توان فرض کرد ویژگی‌های هم‌نام به یک دامنه تعلق دارند و از نظر معنا نیز مرتبط‌اند، ولی گاهی ویژگی‌های مرتبط با نام‌های متفاوت ظاهر می‌شوند و تشخیص رابطه را دشوار می‌کنند.

با تبدیل روابط 3NF ایجادشده و نام‌گذاری‌شده به قالب و نمادگذاری مدل منطقی داده، می‌توان اعتبار مدل منطقی داده سیستم موردنیاز را کنترل کرد؛ یعنی مدل‌های جزئی حاصل از 3NF با مدل منطقی داده موردنیاز مقایسه شوند.

برای ساخت مدل منطقی داده از روابط 3NF، قواعد زیر به کار می‌روند:

1. برای هر رابطه یک نوع موجودیت ایجاد کنید؛

2. بخش تعیین‌کننده کلیدهای سلسله‌مراتبی را به‌عنوان کلید خارجی مشخص کنید؛

3. کنترل کنید هر رابطه دارای کلید مرکب یک موجودیت والد متناظر داشته باشد؛

4. روابط دارای کلید مرکب را به زیرموجودیت تبدیل کنید؛

5. روابط دارای کلید خارجی را زیرموجودیت قرار دهید.

قاعده 1 ـ برای هر رابطه یک نوع موجودیت ایجاد کنید

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

قاعده 2 ـ بخش تعیین‌کننده کلید سلسله‌مراتبی را به‌عنوان کلید خارجی علامت بزنید

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

پاورقی 36: این روش در هر وضعیتی قابل استفاده است که لازم باشد نمودار مدل منطقی داده از جدول‌های موجود یا از پایگاه داده یک DBMS رابطه‌ای بازسازی شود.

تصویر مرجع صفحه 146 سند اصلیتصویر کامل صفحه 146 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 146 سند اصلی.

صفحه 147 منبع

14. مدل‌سازی رابطه‌ای داده

قاعده 3 ـ کنترل کنید هر رابطه دارای کلید مرکب، موجودیت والد داشته باشد

بررسی کنید هر عنصر از همه کلیدهای مرکب، به‌صورت کلید ساده یا سلسله‌مراتبی در رابطه دیگری نیز ظاهر شود. اگر عنصری بخشی از کلید مرکب است ولی شناسه مستقل هیچ گروه داده‌ای نیست:

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

قاعده 4 ـ روابط دارای کلید مرکب را زیرموجودیت قرار دهید

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

قاعده 5 ـ روابط دارای کلید خارجی زیرموجودیت می‌شوند

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

14.1.6 مقایسه مدل‌های رابطه‌ای داده با مدل منطقی داده

14.1.6.1 نام ویژگی‌های متناظر

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

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

شکل 53 ـ روش تعیین زیرموجودیت‌ها و روابط.

تصویر مرجع صفحه 147 سند اصلیتصویر کامل صفحه 147 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 147 سند اصلی.

صفحه 148 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.6.2 نام‌گذاری روابط

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

در آغاز مرحله 3، هنگام ایجاد مدل داده موردنیاز، نیز می‌توان از تحلیل رابطه‌ای داده برای کنترل نرمال‌بودن مدل منطقی داده استفاده کرد. در این حالت روابط از موجودیت‌های مدل داده ایجاد شده‌اند؛ بنابراین نام روابط مهم و موجودیت‌ها یکسان است.

در مرحله 3 و گام 340، «تأیید مدل داده موردنیاز»، تحلیلگر راه مستقیمی برای شناسایی روابط حاصل به‌عنوان انواع موجودیت ندارد. یک راه ممکن این است که عناصر داده مهم رابطه با ویژگی‌های متناظر در انواع موجودیت تطبیق داده شوند.

14.1.6.3 انطباق مجموعه ویژگی‌ها

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

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

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

14.1.6.4 روش کار

در مرحله 1 و آغاز مرحله 3، مدل‌های رابطه‌ای جزئی را می‌توان برای ایجاد یا تکمیل مدل منطقی داده به کار برد.

در گام 340، که تحلیل رابطه‌ای داده برای کنترل نهایی اعتبار مدل منطقی داده به کار می‌رود، فعالیت‌های اصلی زیر انجام می‌شوند:

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

صفحه 149 منبع

14. مدل‌سازی رابطه‌ای داده

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

14.1.7 فرم/کاربرگ

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

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

14.1.8.1 تبدیل به فرم نرمال اول

نخستین مرحله تولید روابط 3NF، تبدیل داده‌های نرمال‌نشده به فرم نرمال از طریق استخراج گروه‌های تکرارشونده عناصر داده است؛ این گروه‌ها ممکن است در نمایش متنی با تورفتگی یا با شماره سطح بزرگ‌تر از 1 مشخص شده باشند.

گروه تکرارشونده عبارت است از: یک عنصر داده یا گروهی از عناصر داده که برای یک مقدار کلید اصلی رابطه می‌تواند چند مقدار/رخداد داشته باشد.

فرم حاصل «فرم نرمال اول» (1NF) نامیده می‌شود. ساختارهای IOS احتمالاً از ابتدا در 1NF هستند.

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

تصویر مرجع صفحه 149 سند اصلیتصویر کامل صفحه 149 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 149 سند اصلی.

صفحه 150 منبع

14. مدل‌سازی رابطه‌ای داده

14.1.8.2 درک وابستگی‌ها

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

14.1.8.3 تبدیل به فرم نرمال دوم

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

حذف ویژگی‌های زائد از کلید

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

حذف ویژگی‌هایی که کاملاً به کلید وابسته نیستند

برای هر ویژگی غیرکلیدی رابطه این پرسش مطرح شود:

«آیا این عنصر داده به کل کلید وابسته است یا فقط به بخشی از آن؟»

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

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

در این فعالیت باید وابستگی به تعیین‌کننده‌هایی که کلید نامزد نیستند حذف شود؛ یعنی تعیین‌کننده‌های غیرکلید نامزد شناسایی شوند:

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

برای تعیین ویژگی‌های تعیین‌کننده غیرکلید نامزد، باید روابط وابستگی میان ترکیب‌های ممکن ویژگی‌ها در همه روابط بررسی شوند.

شناسایی وابستگی‌های غیرکلید نامزد

پرسش‌های زیر مطرح می‌شوند:

«آیا ویژگی A یا گروه ویژگی A تعیین‌کننده ویژگی B است؟» یعنی «برای یک مقدار مشخص A فقط یک مقدار ممکن B وجود دارد؟»

اگر پاسخ مثبت است، پرسیده می‌شود:

«آیا A یک کلید نامزد است؟»

تصویر مرجع صفحه 150 سند اصلیتصویر کامل صفحه 150 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 150 سند اصلی.

صفحه 151 منبع

14. مدل‌سازی رابطه‌ای داده

تجزیه روابطی که در 3NF نیستند

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

در میان روابط 3NF حاصل ممکن است روابط یکسان وجود داشته باشند؛ یعنی روابطی که طی مراحل مختلف نرمال‌سازی عناصر داده متفاوتی به آن‌ها منتقل شده ولی کلید اصلی یکسانی دارند. این روابط باید در مرحله عقلانی‌سازی با یکدیگر ادغام شوند.

تصویر مرجع صفحه 151 سند اصلیتصویر کامل صفحه 151 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 151 سند اصلی.

امتیاز کاربران به این مقاله

☆☆☆☆☆

0 نفر امتیاز داده اند. میانگین: 0.0 از 5

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

0 / 500

اطلاعات تماس

  • آدرس:اصفهان-خیابان ام کلثوم غربی - بعد خیابان تخم چی - بیست متر بعد از پیتزا ننه شب - کوچه تعمیر گاه سمار زغالی - پلاک 354 - درب مشکی - طبقه هفتم
  • آدرس ایمیل:najafzade@gmail.com
  • وب سایت:http://www.a00b.com/
  • تلفن ثابت:(+98)9131253620
  • تلفن همراه:09131253620