صفحه 83 منبع

7. مروری بر مدل‌سازی منطقی داده

7.1 هدف

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

تکنیک مدل‌سازی منطقی داده:

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

مدل منطقی داده:

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

صفحه 84 منبع

8. مدل‌سازی منطقی داده (LDS/LDM)

مدل‌سازی منطقی داده برای تهیه ساختار منطقی داده و اسناد وابسته استفاده می‌شود. مخفف انگلیسی ساختار منطقی داده LDS (Logical Data Structure) و مخفف مدل منطقی داده LDM (Logical Data Model) است.

8.1 هدف تکنیک

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

مزایا:

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

مدل منطقی داده:

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

8.2 نمادگذاری و مفاهیم

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

صفحه 85 منبع

تعریف 8-1: موجودیت (Entity)

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

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

در نمودار LDS، موجودیت با کادر گوشه‌گرد و نام موجودیت در داخل آن نمایش داده می‌شود.

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

اگر یک شیء واقعی در چند سیستم کاربردی ظاهر شود، هر «نما» نمایش آن موجودیت در یک زیرسیستم خاص است.

تعریف 8-2: نمای موجودیت یا جنبه (Entity Aspect)

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

پاورقی 26: واژه Entity از مفهوم Identity/هویت و امکان تمایز نمونه‌ها ریشه می‌گیرد.

شکل 33. نمونه موجودیت‌های LDS: حساب جاری، مشتری و انتقال وجه.

صفحه 86 منبع

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

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

یک موجودیت می‌تواند هم‌زمان چند نما داشته باشد:

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

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

صفحه 87 منبع

تعریف 8-3: ابرنوع و زیرنوع موجودیت (Supertype/Subtype)

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

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

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

ویژگی‌های زیرنوع‌ها:

• شناسه/کلید مشترک دارند و از دامنه‌های ارزشی یکسان استفاده می‌کنند؛
• مجموعه نمونه‌های زیرنوع‌های متفاوت جدا از هم (Disjoint) است؛
• اجتماع نمونه‌های زیرنوع‌ها باید تمام نمونه‌های ممکن ابرنوع را پوشش دهد.

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

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

شکل 34. نمایش نماهای موجودیت و ساختار ابرنوع/زیرنوع.

صفحه 88 منبع

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

تعریف 8-4: رابطه (Relationship)

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

برای هر سر رابطه باید تعدادپذیری/درجه، اجباری یا اختیاری بودن و عبارت پیوندیِ معنادار مشخص شود.

نمونه: «هر مشتری ممکن است یک یا چند حساب جاری داشته باشد» و از سوی دیگر «هر حساب جاری حتماً به دقیقاً یک مشتری تعلق دارد».

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

صفحه 89 منبع

تعریف 8-5: درجه/کاردینالیتی رابطه

درجه رابطه بیان می‌کند یک نمونه از یک موجودیت با چند نمونه از موجودیت دیگر می‌تواند مرتبط باشد. روابط پایه عبارت‌اند از یک‌به‌یک، یک‌به‌چند و چندبه‌چند. در SSADM علامت «پنجه کلاغی» در سر رابطه معمولاً «یک یا بیشتر/چند» را نشان می‌دهد.

تعریف 8-6: روابط اجباری و اختیاری

اگر هر نمونه موجودیت ناگزیر باید در رابطه شرکت کند، آن سر رابطه اجباری است؛ اگر ممکن است شرکت نکند، اختیاری است. نمادگذاری SSADM این تفاوت را در سرهای رابطه مشخص می‌کند.

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

صفحه 90 منبع

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

قالب پیشنهادی ساخت جمله رابطه:

• «هر» + نام موجودیت فاعل؛
• «ممکن است» یا «حتماً»؛
• عبارت پیوندی؛
• «دقیقاً یک» یا «یک یا چند»؛
• نام موجودیت مفعول.

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

شکل 36. نمونه روابط میان موجودیت اصلی و وابسته: مشتری-حساب جاری و سند-محل نگهداری.

صفحه 91 منبع

گروه روابط انحصاری

اگر شرکت یک نمونه موجودیت در یک رابطه، شرکت همان نمونه در یک یا چند رابطه دیگر را منتفی کند، آن روابط یک گروه متقابلاً انحصاری (XOR) تشکیل می‌دهند. همه روابط گروه باید موجودیت موضوع مشترک و وضعیت اجباری مشابه داشته باشند. هر نمونه موضوع در گروه حداکثر در یک رابطه شرکت می‌کند؛ اگر روابط اجباری باشند دقیقاً در یکی، و اگر اختیاری باشند ممکن است در هیچ‌کدام شرکت نکند.

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

نمونه: هر سند داخلی توسط مدیر آغاز می‌شود یا هر سند خارجی توسط کارمند ثبت می‌شود؛ این دو وضعیت برای یک سند معین هم‌زمان برقرار نیستند.

شکل 37. گروه رابطه انحصاری.

صفحه 92 منبع

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

روابط بازگشتی/بازتابی (Recursive)

دو حالت رایج وجود دارد: سلسله‌مراتبی و شبکه‌ای.

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

حالت شبکه‌ای، رابطه بازگشتی چندبه‌چند است. مثال معروف «فهرست مواد/قطعات» (Bill of Materials - BOMP) است: هر زیرمونتاژ ممکن است از چند زیرمونتاژ دیگر ساخته شود و خود نیز در چند زیرمونتاژ دیگر به کار رود.

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

صفحه 93 منبع

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

تعریف 8-7: موجودیت والد و موجودیت فرزند

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

اصولاً روابط 1:1 و m:n را می‌توان با روابط والد-فرزند 1:m جایگزین کرد؛ مثلاً با معرفی موجودیت رابط یا ادغام موجودیت‌های یک‌به‌یک.

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

صفحه 94 منبع

تعریف 8-8: صفت (Attribute)

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

صفات در فهرست داده مستند می‌شوند و می‌توان خصوصیات مشترک چند صفت را به‌صورت «دامنه مشترک ارزش» تعریف کرد.

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

نمونه مقادیر در متن منبع: F0306111، XXXXX Kft.، 1.012.110، 1993.06.02، 9؛ و برای سند D001/93، 1993.02.21، «در انتظار پاسخ»، «1/115/A».

صفات می‌توانند:

• اجباری باشند: هر نمونه باید مقدار داشته باشد؛
• اختیاری باشند: ممکن است در بخشی یا تمام چرخه عمر نمونه بدون مقدار بمانند.

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

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

صفحه 95 منبع

تعریف 8-9: رابطه انتقال‌پذیر و غیرانتقال‌پذیر

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

مثال: یک حساب جاری در هر لحظه یک مالک دارد، اما اگر شرکت مالک تفکیک شود ممکن است یکی از شرکت‌های جدید حساب را به ارث ببرد؛ در نتیجه پیوند حساب-مشتری از دید مشتری قابل انتقال است.

تعریف 8-10: کلیدها

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

• یک یا چند صفت اجباری؛
• یک یا چند صفت اجباری همراه با شرکت در یک یا چند رابطه اجباری و غیرانتقال‌پذیر؛
• یا صرفاً شرکت در یک یا چند رابطه اجباری و غیرانتقال‌پذیر باشد.

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

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

صفحه 96 منبع

موجودیت‌هایی که والد ندارند «موجودیت مرجع» نامیده می‌شوند و با یک یا چند صفت خودشان شناسایی می‌شوند.

تعریف 8-11: کلید سلسله‌مراتبی

ترکیبی از چند صفت شامل:

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

مثال: در «صورتحساب» و «سطر صورتحساب»، شناسه سطر می‌تواند «شماره صورتحساب + شماره سطر» باشد.

تعریف 8-12: کلید مرکب

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

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

تعریف 8-13: دامنه مشترک ارزش (Common Domain)

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

مثال: «تاریخ ثبت»، «تاریخ کنترل» و «تاریخ بسته‌شدن» می‌توانند عضو دامنه «تاریخ اداری» باشند.

صفحه 97 منبع

برای دامنه «تاریخ اداری» می‌توان قالب «YYYY.MM.DD» و قاعده «نباید روز تعطیل باشد» را تعریف کرد. صفات «وضعیت سند» در زیرنوع‌های سند داخلی و خارجی می‌توانند عضو دامنه مشترک «وضعیت» با مقادیر مجاز «ثبت‌شده»، «کنترل‌شده»، «در انتظار پاسخ»، «بسته» باشند.

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

8.3 محصولات

مدل منطقی داده از اجزای زیر تشکیل می‌شود:

• نمودار ساختار منطقی داده (LDS)، در صورت نیاز با چند زیرنمودار؛
• شرح موجودیت‌ها؛
• شرح روابط؛
• شرح صفات، به‌عنوان بخشی از فهرست داده؛
• شرح دامنه‌های مشترک، به‌عنوان بخشی از فهرست داده.

در طول توسعه سه LDM تهیه می‌شود:

• LDM مروری: نمایش حدود 8 تا 12 موجودیت مهم، بدون شرح‌های وابسته؛
• LDM محیط فعلی: توصیف مصرف و تولید اطلاعات در محیط فعلی با سطح جزئیات متناسب با DFD فیزیکی/منطقی فعلی؛
• LDM سیستم موردنیاز: شرح تفصیلی نیازهای اطلاعاتی سیستم جدید.

صفحه 98 منبع

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

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

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

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

8.5 فرایند مدل‌سازی منطقی داده

فعالیت‌ها:

• کشف واقعیت؛
• شناسایی موجودیت‌ها؛
• شناسایی روابط؛
• رسم LDS.

8.5.1 کشف واقعیت

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

صفحه 99 منبع

8.5.2 شناسایی موجودیت‌ها

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

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

8.5.3 شناسایی روابط

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

صفحه 100 منبع

برای هر رابطه باید پرسید:

• معنی دقیق آن چیست و از هر طرف چگونه خوانده می‌شود؟
• اجباری است یا اختیاری؟
• کاردینالیتی آن یک یا چند است؟
• انتقال‌پذیر است یا غیرانتقال‌پذیر؟
• آیا با رابطه دیگری انحصاری است؟
• آیا فقط در یک بازه زمانی معتبر است؟

8.5.4 رسم LDS

در چیدمان نمودار بهتر است موجودیت‌های وابسته در زیر والدها قرار گیرند و جهت غالب روابط از بالا به پایین باشد. موجودیت‌های مرجع معمولاً بالاتر و موجودیت‌های پرتراکنش پایین‌تر قرار می‌گیرند؛ موجودیت‌های مرکزی که روابط زیادی دارند بهتر است نزدیک مرکز باشند.

با وجود پیچیدگی روابط، اصول کلی عبارت‌اند از:

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

صفحه 101 منبع

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

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

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

8.5.6 نرمال‌سازی

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

8.5.7 کنترل برآوردن نیازمندی‌های کارکردی

LDM باید با DFM مربوط، BAM، فهرست نیازمندی‌ها، رویدادها، پرس‌وجوها و عملکردها سازگار باشد.

8.5.7.1 کنترل در برابر مدل جریان داده

مخازن: در DFM منطقی فعلی و موردنیاز، هر موجودیت باید دقیقاً در یک مخزن اصلی ظاهر شود؛ در غیر این صورت مخزن، موجودیت یا هر دو باید اصلاح شوند.

جریان‌ها: داده‌های ورودی/خروجی فرایندهای مرتبط با مخزن باید با LDM تطبیق داده شوند تا معلوم شود همه عناصر موردنیاز برای ذخیره‌سازی در مدل وجود دارند.

صفحه 102 منبع

فرایندهای ابتدایی: برای هر موجودیت باید دست‌کم یک فرایند ابتدایی وجود داشته باشد که بتواند آن را ایجاد و حذف کند؛ در غیر این صورت DFD ناقص است.

مسیرهای دسترسی: به‌صورت غیرصوری بررسی شود که LDM برای هر فرایند ابتدایی مسیر مناسب دسترسی به موجودیت‌های قابل تغییر یا پرس‌وجو را فراهم می‌کند. این کنترل به شناخت فرایند و روابط نیاز دارد و روش رسمی کاملاً خودکار برای آن وجود ندارد. ناسازگاری‌ها باید رفع شوند.

8.5.7.2 کنترل مدل فعالیت سازمانی

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

8.5.8 حذف روابط زائد

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

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

پاورقی 27: معنای دقیق/سمانتیک روابط باید با دقت بررسی شود.

صفحه 103 منبع

8.5.9 حل روابط چندبه‌چند

در آغاز پروژه ممکن است به دلیل سادگی یا بازتاب شیوه صحبت کاربران، روابط m:n در LDM وجود داشته باشند. این روابط روابط والد-فرزند و مسیرهای دسترسی را پنهان می‌کنند و در SSADM باید تا پایان گام 340 همگی حل شوند.

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

8.5.10 حل روابط یک‌به‌یک

در مدل نهایی هر رابطه باید ساختار والد-فرزند روشن داشته باشد؛ بنابراین رابطه 1:1 یا با ادغام دو موجودیت حذف می‌شود یا به 1:m تبدیل می‌گردد. این نیز تکنیک تحلیل است و می‌تواند موجودیت‌ها و روابط پنهان را آشکار کند. یکی از پرسش‌ها این است که آیا باید تاریخچه یکی از موجودیت‌ها ثبت شود؛ اگر در طول زمان چند نمونه لازم باشد، رابطه به 1:m تبدیل می‌شود.

پاورقی 28: رابطه m:n از نظر ریاضی مانند رابطه‌ای عمومی میان دو مجموعه است؛ رابطه 1:m از سمت فرزند به والد رفتاری شبیه تابع دارد.

شکل 40. نمونه حذف رابطه زائد میان انبار، ناحیه و مشتری.

صفحه 104 منبع

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

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

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

صفحه 105 منبع

9. مروری بر گزینه‌های سازمان‌دهی سیستم (Business System Options - BSO)

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

گزینه‌ها تهیه و انتخاب می‌شوند تا:

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

BSO در ساختار تصمیم‌گیری الگوی پایه توسعه سیستم قرار دارد (شکل 41).

پاورقی 29: Business System Options.

پاورقی 30: [CCTA95]، [CCTA95A]، Reference Manual Part 8: Formulating Options, Business System Options, 8-5—8-19؛ Users Guide Part 5: Decision Structure, Business System Options, 5-5—5-13؛ همچنین [CCAT90].

شکل 41. جایگاه گزینه‌های سازمان‌دهی سیستم در الگوی پایه توسعه سیستم.