بررسی روش تحلیل سیستم [بخش دوم]

مقدمه

در قسمت قبلی، توضیح مناسبی از تحلیل بیان شد و برای یک مسئله ساده، تحلیل و شناسایی موجودیت و شناخت روابط بین موجودیت ها و طراحی پایگاه داده و نرمال سازی انجام شد. آن هم بسیار ساده.
خوب، حالا اگر بخواهیم کمی پیچیده تر رفتار کنیم چطور؟ مثلا پیام به این نحو باشد:
جناب آقای حمید جواهری، گواهی پایان دوره Sql Server 2008 شما با نمره ۹۵ از ۱۰۰ آماده است….
سرکار خانم الهه مقدم، گواهی پایان دوره C# .Net ما با نمره ۸۳ از ۱۰۰ آماده است….
خوب حالا چه می‌کنید؟ کمی سخت شد نه؟ اگر فکر می کنید که در یکی از جداول باید ستون هایی اضافه کنید یا فکر می‌کنید که باید جدولی اضافه کنید، باید بگویم که هم بله و هم خیر. در واقع در اینجا تقریبا ماهیت مسئله کمی تغییر می‌کند.

درست است که شما می توانید با برگرداندن ستون {متن پیام} به جدول شماره ها، هر پیام را به صورت اختصاصی داشته باشید ولی مجبور می شوید که برای هر نفر، پیام را تایپ نمایید. خوب چه کاری بود؟ از اول با تلفن همراه خود به هر کس پیام می دادید. نرم افزار و تحلیل و اینجور چیزها هم نیاز نبود. پس ما باید یک کار سیستمی درست انجام دهیم.
خوب بیایید مرحله به مرحله پیش برویم. کل کار را یکجا تحلیل کردن باعث سردرگمی می شود. حتی اگر کار انجام شود هم احتمال خطا زیاد است. اول از همه اینکه متن پیام ها یک قالب کلی دارد به این نحو:
{(خانم/آقای) (نام شخص)، گواهی پایان دوره (نام دوره) شما با نمره (نمره شخص) از (نمره کل) آماده است……}
خوب اگر چنین قالبی درنظر بگیریم، با جایگزین کردن موارد داخل پرانتز برای هر شخص، پیام مورد نظر آماده می شود. برای قابل فهم شدن متن برای نرم افزار، چنین قالبی نیاز است:
{PersonTitle PersonName، گواهی پایان دوره ClassName شما بانمره PersonScore از TotalScore آماده است…..}
حالا با جایگزین کردن عبارات مناسب به جای PersonTitle و یا PersonName و همچنین ClassName و غیره، متن مورد نظر ساخته می شود. پس تا اینجا ساختار جدول پیام ها تغییر نمی کنند فقط متن ردیف های آن تغییر می کند. البته در عمل و دنیای واقعی، معمولا از کاراکترهای خاص برای جایگزینی استفاده می شود مثلا %PersonTitle% و یا @PersonTitle و یا @$PT#. ولی فعلا اهمیت ندارد. خوب پس برای هر شماره، باید عنوان(آقا خانم) و نام و فامیل و نام دوره و نمره و نمره کل مشخص شود به این نحو:به متن های ردیف های جدول پیام ها دقت نکنید چون برای اختصار چنین نوشته شده اند و ضمنا چپ چین و راست چین آن به هم خورده است که وقتی با عبارات فارسی جایگزین شوند درست می شود. البته گاهی اوقات همین مسائل در نتیجه کار تاثیر منفی می گذارند ولی به هر حال این قسمت ها معمولا مربوط به سَمت برنامه نویسی می شوند و کاری به تحلیل پایگاه داده ندارند. هرچند گاهی اوقات تحلیلگر نرم افزار باید مشکل را حل کند. به هرحال، ما در اینجا قصد برنامه نویسی نداریم و فقط به تحلیل می پردازیم.
خوب بیاییم سروقت جدول شماره ها. شاید بگویید ستون {نام} می تواند به دو ستون {نام} و {نام خانوادگی} شکسته شود. بله ولی این مسئله تاثیری برساختار اصلی نخواهد گذاشت پس به آن نمی پردازیم، شما اگر میخواهید دو ستون بگذارید. بهتر هم هست.
اینها را گفتم که بدانید ما در حال آموزش تحلیل هستیم و قصدمان تمرین دادن به مغز جهت تقویت آن است. پس اگر به برخی موارد نمی پردازیم و روی برخی پافشاری می کنیم، علت دارد.
اگر از تجربه {وضعیت ارسال} استفاده کرده باشید، همان ابتدا می گویید که برای ستون {عنوان}، باید جدولی درست کنید و بجای متن {عنوان}، {کد عنوان} را در جدول شماره ها بیاورید.
حالا به جدول شماره ها دقت کنید. ستون های زیاد در یک جدول در نود و نه درصد مواقع، بیانگر این است که جدول باید به جداول کوچکتر شکسته شود.
از نظر مفهومی هم که نگاه کنیم، نام و شماره مربوط به شخص است و نمره کل دوره و نام دوره مربوط به کلاس یا دوره است و نمره شخص در دوره و بدهی شخص، مربوط به ثبت نام است.
از این هم که بگذریم، شما تحلیلگر هستید، فکر کنید کسی که در دو دوره شرکت کرده است، نام و عنوان و شماره او باید دوبار در جدول بیاید. این درست است؟ اگر کسی در سه دوره ثبت نام کند و وسط دوره شماره او تغییر کرد، باید سه ردیف جدول تغییر کند؟ اگر در ده دوره همزمان شرکت کند و قبل از پایان دوره ها تغییر جنسیت دهد چطور؟? از شوخی که بگذریم، پس از هر پرداختی توسط هر شخص، باید در تمامی ردیف های آن شخص، ستون {بدهی} ویرایش شود. و مشکلاتی از این قبیل.
خوب قرار شد مرحله به مرحله پیش برویم. به نظر می رسد که خوب باشد از موجودیت شخص شروع کنیم. پس اول، موجودیت شخص را مستقل می کنیم.
به این صورت:به تغییرات دقت کنید. اول اینکه چون شماره ها به جدول اشخاص منتقل شد، دیگر نام {جدول شماره ها} مناسب نخواهد بود. پس نام {جدول ارسال} را جایگزین می کنیم. دوم اینکه یک ستون به نام {کد یکتا} به جدول ارسال اضافه شده است. این قاعده در شاید نود و پنج درصد موارد صادق است که هر جدول به یک ستون عددی با مقدار یکتا نیاز دارد. حتی برخی مواقع، به آن پنج درصد دیگر هم به دلایلی، چنین ستونی اضافه می کنیم. البته معمولا چنین ستونی را {شناسه} یا {Id} نامگذاری می کنند.
سایر تغییرات هم مشخص است. جدول جنسیت اشخاص، جدول اشخاص که شامل نام و شماره تلفن شخص است و در ستون {کد جنسیت} با جدول جنسیت اشخاص مرتبط است. و در نهایت، ستون {کد شخص} در جدول ارسال. البته اینکه در جدول ارسال، مقادیر ستون {کد یکتا} با مقادیر ستون {کد شخص} برابر است، اتفاقی می باشد. اگر یک شخص در دو دوره شرکت کند، کد آن شخص دوبار در جدول ارسال خواهد آمد.
خوب، حالا نوبت جدول دوره‌ها است:به نظر نیاز به توضیح خاصی نیست.
حال می رویم به سراغ اینکه چرا نمره اشخاص و بدهی ها در این جدول نیامده است. ببینید، نمره شخص و بدهی، چیزی است که به شخص و دوره مربوط می شود ولی کاری به ارسال پیام ندارد. پس باید جدول واسطی وجود داشته باشد که شخص را به دوره مربوط کند. چیزی مثل ثبت نام:خوب، برای واضح تر شدن قضیه و اینکه وضعیت شخص در دوره مشخص شود، جدول وضعیت شخص در دوره را هم اضافه کردیم. باز هم اینکه مقادیر ستون های {کد یکتا} و {کد شخص} در جدول ثبت نام یکی است، اتفاقی می باشد.

باز به جدول ارسال دقت کنید. وقتی ما {کد شخص} و {کد دوره} را در جدول ثبت نام داریم و {کد ثبت نام} هم در جدول ارسال وجود دارد، چه نیازی هست که ستون های {کد شخص} و {کد دوره} در جدول ارسال وجود داشته باشد؟ بله نیازی نیست پس این دو ستون را حذف می کنیم.
البته دقت داشته باشید که همیشه نمی توان از این قاعده پیروی کرد. ما در اینجا مجوز انجام اینکار را داریم چون ماهیتا اینکار انجام پذیر است. یعنی از نظر مفهومی، درواقع ارسال برای ثبت نامی های دوره انجام می شود. پس اصلا باید همینطور شود:قبل از اینکه به پاسخ سوالاتی برسم که احتمالا در ذهن شما چرخ می خورد، اجازه بدهید کمی محو زیبایی شویم! متوجه شدید چه اتفاقی افتاد؟ جدول شماره ها(در مراحل اولیه تحلیل) را با جدول نهایی ارسال مقایسه کنید.جدول نهایی، بیشتر شامل عدد است، آن هم کد مربوط به جداول دیگر. به این می گویند قدرت رابطه در پایگاه داده های رابطه ای. زیبا نیست؟ پس به این تصویر دقت کنید:
این تصویر، در واقع دیاگرامی از پیاده سازی جداول نهایی در نرم افزار Microsoft Sql Server است.جداول و ستون ها، با واژگان انگلیسی نامگذاری شده اند و خطوط بین جداول، ارتباط بین آنها را نشان می دهد. می بینید، هیچ جدولی جدا نیفتاده است و همه به هم مربوط هستند. البته در دنیای واقعی، گاهی جداولی به صورتی تکی نیاز می شوند(مثل جدول تنظیمات) و گاهی دیاگرام به صورت دو یا چند مجموعه جدول مشاهده می شود. بگذریم به ادامه تحلیل بپردازیم.
شاید با دیدن تصویر به این فکر کنید که از میان این همه جدول و ارتباط که در مسائل بزرگ حتی به صدها جدول ختم می شود، چطور اطلاعات به صورت پیوسته استخراج می شود. این مسئله برمیگردد به موضوعی به نام Structured Query Language که مربوط به بحث دیگری است. ولی شما نگران نباشید! چون Structured Query Language کار خود را درست انجام خواهد داد و اطلاعات مورد نظر ما را از این همه جدول، استخراج خواهد کرد آن هم درست و به سرعت. به شرطی که تحلیل و طراحی جداول به طور صحیح انجام شده باشد.

خوب برویم سراغ سوالات احتمالا پیش آمده. ببینید، این فقط یک تمرین بود. آن هم به صورت مبتدی. به اینکه چرا ستون نام از نام خانوادگی جدا نشد قبلا پاسخ دادم. اینکه در جدول اشخاص، آدرس شخص هم ثبت شود یا تلفن منزل هم ثبت شود، خوب شما به جدولتان ستون های لازم را اضافه کنید. اصلا همین درست است که خودتان تحلیلگر خودتان شوید. اینکه اگر کسی بیشتر از یک شماره موبایل داشت چطور؟ یا مثلا چرا فقط بدهی ثبت می شود آن هم برای هر دوره. اگر بخواهیم مبلغ دوره مشخص شود و پرداختی های اشخاص ثبت شود و بدهی خود به خود حساب شود. حتی حضور و غیاب افراد سر هر کلاس و…
کم کم می شود یک نرم افزار آموزشگاهی کامل. البته فقط قسمت پایگاه داده آن.

نکته مهم اینجاست که من سوالی را طرح کردم و خودم برای آن مسیری تعیین کردم چون فقط قصد آموزش را داشتم. در دنیای واقعی، بخش مهمی از کار، همین نیاز سنجی است. اینکه با کسی که قرار است تحلیل برای او انجام شود، جلسه بگذارید، صحبت کنید و ببینید به چه چیزهایی نیاز دارد. گاهی این شخص خود شمایید یعنی تحلیل را برای مسائل خودتان انجام می دهید. بر خلاف اینکه فکر می کنید، برخی اوقات تحلیل کردن برای خودتان سخت تر است. اینکه هم طراح مسئله باشید هم حلال آن.
به هر حال یک نکته مهم را فراموش نکنید. اینکه اصلا قرار نیست با پیچیدگی، خودتان و سایرین را آزار دهید. مهمترین بخش کار شناخت مسئله است که هرچه در تحلیل با تجربه تر و صد البته قوی تر باشید، شناخت بهتری پیدا می کنید. و گاهی قوی ترین تحلیل، تحلیل نکردن است! بله منظورم از پیچیدگی همین بود. اگر الان از خود من پرسیده شود یکی از بزرگترین اشتباهات تحلیل را در دوران کاری خودم بگویم، پروژه و شرکتی را یادآور می شوم که یکی از علل شکست آن، قوی بودن تحلیل من و همکارم بود. پروژه بیش از حد بزرگ شد. البته منظورم از بیش از حد، به نسبت نیاز مشتریان آن شرکت بود وگرنه تحلیل مشکلی نداشت. فقط با توجه به شرایط، برخی چیزها نباید اضافه می شد. این باعث افزایش هزینه پیاده سازی و آموزش و پشتیبانی پروژه شد. و حتی باعث شد بعضی مشتریان نتوانند از آن استفاده کنند. اگر نمیدانید که بزرگ شده پروژه چرا باعث ایجاد مشکل و یا شکست می شود، فعلا به آن فکر نکنید. فقط این را بدانید که:

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