دانلود رایگان ترجمه مقاله پایگاه داده منطقی با مدل های مشخص ارتباط نهادی (آی تریپل ای ۲۰۱۲)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

از آنجا که RDS در شکل ۲ توسط قوانین تحول دقیق زیر به دست می آید، پس آن را تحول درون الگوریتمی می نامیم.
با اینحال، برخی ابهامات غالب بر RDS وجود دارد. دلایل برای داشتن کلید ابتدائی (PK)، EmpNo کارکنان بعنوان یک کلید خارجی (FK) در رابطه دپارتمان به خاطر موارد مزبور است: در ابتدا به منظور ارائه ارتباط «مدیران» OUC-ERD، و سپس به منظور اشاره بر کارکنانی است که قرار است دپارتمان را اداره کنند. با اینحال، بطور کلی، این ممکن است برای شخصی غیر از طراح RDS به منظور درک این دلایل سخت باشد.
بطور مشابه، معنای ورود مشخصه «StartDate» در رابطه دپارتمان درک نمی شود. کلمه «مدیران» در ERD در طول تحول حذف می شود و در نتیجه این در RDS شامل نمی شود. این احتمالا باید به ERD رجوع کند و گاهی اوقات حتی به سناریوی دامنه برای یافتن دلیل اشاره دارد. راه حل اسفاده شده در عمل فعلی به منظور حل این ابهامات تغییر نام ویژگی ها با استفاده از پیشوندهای مناسب است. بر این اساس، EmpNo و StartDate در دپارتمان به ترتیب به Mgr_EmpNo و Mgr_StartDate تغییر می یابد. پیشوند «Mgr» کلمه «مدیر» را نشان می دهد. RDS اصلاح شده در شکل ۳ داده شده است.
با اینحال، معتقدیم که این تنظیمات خارج از قوانین است. هر یک از قوانین تحول یا تبدیل ویژگی های نامگذاری مجدد، روش نامگذاری مجدد و چگونگی تصمیم گیری درباره پیشوندها برای نامگذاری مجدد را ارائه نمی کنند. از آنجا که این تنظیمات بیرون از الگوریتم تبدیل قانونی ایجاد می شوند، پس آن را تنظیمات الگوریتم اضافه می-نامیم. این فرایند اضافه الگوریتم از تخصص دامنه طراح، بینش، داوری، و نظر شخصی استفاده می کند.
 تنظیمات الگوریتم اضافی ایجاد شده برای RDS تبدیل شده در شکل ۱٫ ویژگی های «EmpNo» و «StartDate» به «Mgr_EmpNo» و «Mgr_StartDate» نامگذاری مجدد می شود. پیشوند اختصاری «Mgr» حاکی از کلمه «مدیر» است.
تنظمیمات اضافه الگوریتم چندین موضوع را به شرح زیر ایجاد می کند.
a. نامگذاری دوباره مشخصات خارج از الگوریتم،
b. چگونه یک کلمه خاص به منظور استفاده تصمیم گیری می شود تا پیشوندی را برای نامگذاری مجدد ایجاد کند، برای مثال «مدیر» در این مورد،
c. چگونه پیشوند، برای مثال «Mgr» ایجاد می شود.
حتی پس از تنظیمات الگوریتم اضافی، به نظر میرسد برخی از سناریوها هنوز هم مبهم هستند. برای مثال، OUC-ERD نشان می دهد که یک کارمند تنها یک دپارتمان را اداره می کند یا اصلا دپارتمانی را مدیریت نمی-کند، و این باید در RDS در شکل ۳ منعکس شود. با اینحال، این مشخص نیست که آیا کارکنان یک مدیر ذکر شده توسط ویژگی «Mgr_EmpNo» مجددا نامگذاری شده می توانند تنها یک یا چند دپارتمان را اداره کنند یا خیر، به این دلیل که همان Mgr_EmpNo در چند تائی های مختلف تکرار می شوند. این نشان می دهد که برخی از اطلاعات معنای در طول مدت تبدیل از دست رفته است و حتی با فرایند تنظیم الگوریتم اضافی نیز مجددا ایجاد نمی شود.
فرض کنید یک طراحی با دامنه آشنا نیست، دامنه ای همچون OUC-ERD که به منظور طراحی یک RDS داده شده است. احتمالا، طراح تبدیل درون الگوریتم را انجام دهد که با RDS نشان داده شده در شکل ۲ یافته می شود. با اینحال، وی گاهی اوقات ممکن است کل طراحی را بهم بریزد زمانی که ورود می کند تا تنظیمات الگوریتم اضافی را با توجه به نبود دانش دامنه انجام دهد.

۳٫ OC-ERD و تبدیل آن
در OC-ERD نشان داده شده در شکل ۴، رابطه بهینه با یک رابطه اجباری بین دپارتمان و یک یک زیر نوع جدیدا خلق شده به نام «مدیر» کارکنان حل می شود؛ کارمند مبدل به یک زیر نوع می شود.
اکنون نسبت های کاردینالیتی بسیار روشن و آشکار است، و نشان دهنده ی این موضوع هستند که هر «مدیر» بطور قطعی یک «دپارتمان» را «مدیریت می کند» و یک و تنها یک «دپارتمان» در هر زمان معین را «مدیریت می شود».

تبدیل OC-ERD با استفاده از قوانین موجود سه RDS بهینه مجزا را ارائه می کند همانطور که در شکل ۵ داده شده است. انواع مختلف ابهامات در هر RDS ارائه شده است، برای مثال، در شکل ۵(الف)، افزونگی های اطلاعات، عدم توانائی به منظور شناسایی ارتباط زیر نوع سوپر نوع و نهاد یا موجودیت دقیقی که در رابطه FK مشارکت می کند، و فقدان توانائی به منظور شناسایی هدف ارتباط FK و غیره. همچنین شکل ۵(ب) و (ج) حاوی برخی از ابهامات است.

 تبدیل OC-ERD در شکل ۴ با استفاده از قوانین موجود، (الف) ۱– RDS بهینه، (ب) RDS-2 بهینه، mgr یک مشخصه نوع بولی است که حاکی از این است که چندتائی متعلق به آن است، (ج) RDS-3 بهینه
مثال ساده فوق نشان می دهد که قوانین تبدیل موجود برای هر دو OUC-ERDها و OC-ERDها کارائی مناسبی ندارد. در نتیجه، این امر امکانپذیر نیست که یک RDS غیر مستقیم، سرراست و کاملا قابل اعتماد به دست آید که تمامی اطلاعات ارائه شده در هر یک از RDSها را ارائه کند. در نتیجه، این موضوع ضروری است که مجموعه جدید یا تغییر یافته ای از قوانین به منظور تطبیق با OC-ERDها و همچنین OUC-ERDها توسعه یابد.
مشاهده می شود که OC-ERDها پشتیبانی نسبتا بیشتری را برای جبران یا رفع ابهامات در فرایند تبدیل ارائه می کنند. برای مثال، موضوع حل پیشوند «Mgr» برای نام گذاری مجدد ویژگی ها. در مورد OUC-ERD، این کاملا مبتنی بر نظر و تخصص طراح است. با اینحال، در مورد OC-ERD، خود ERD کلمه «مدیر» را بعنوان یک زیر نوع در حال مشارکت در ارتباط مربوط به «مدیران» اشاره می کند، به طوری که کلمه را می توان به منظور فرم دهی یا شکل دهی پسوند اختصاری کرد یا کلمه کامل را می توان بعنوان پسوند به کار برد اگر که مطلوب باشد. وضعیت موجود این انگیزه را به ما می دهد تا یک رویکرد منطقی را برای فرایند نامگذاری مجدد معرفی کنیم که OUC-ERD را به RDS نهایی پیوند می دهد.
الگوریتم جدید ارائه شده که OC-ERDها را تحت پوشش قرار می دهد دارای جنبه های زیر است.
۱٫ یک مجموعه نامگذاری برای مشخصات، روابط و انواع ناهد در OUC-ERD.
۲٫ یک مجموعه جدید از قوانین تحول برای تبدیل OC-ERDها به مدل ارتباطی.
۳٫ قوانین برای نامگذاری مجدد اسامی ویژگی ها در طرح ارتباطی پاسگاه داده.
الگوریتم ارائه شده که دارای چندین مرحله است و همچنین در فرمی جدید یا اتخاذ شده است [۹] در زیر ارائه می شود.

مرحله ۱: نقشه برداری از انواع نهاد منظم
۱٫ برای هر نهاد منظم نوع E در ERID، یک رابطه L را ایجاد کنید که دربرگیرنده ی تمامی ویژگی های E باشد.
۲٫ یکی از ویژگی های کلیدی E را بعنوان کلید اصلی L یعنی PK(L) انتخاب کنید.
۳٫ PK را بعنوان نخستین مشخصه رابطه جدید L در حال تداوم توسط ویژگی های باقیمانده ی E نهاد قراردهی کنید