فرآیند توسعه پایگاه داده

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

چرخه عمر توسعه نرم افزار – آبشار

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

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

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

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

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

 

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

چرخه حیات پایگاه داده

می‌توانیم از چرخه آبشار به‌عنوان پایه‌ای برای مدلی از توسعه پایگاه داده استفاده کنیم که سه فرض را در بر می‌گیرد:

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

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

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

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

جمع آوری ملزومات

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

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

نیاز به داده

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

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

تحلیل و بررسی

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

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

سپس مدل داده مفهومی یک نمایش رسمی از چه داده هایی است که یک پایگاه داده باید داشته باشد و محدودیت هایی که داده ها باید رعایت کنند. این باید با عباراتی بیان شود که مستقل از نحوه اجرای مدل باشد. در نتیجه، تجزیه و تحلیل بر روی سؤالات “چه چیزی لازم است؟” تمرکز می کند. نه “چگونه به دست می آید؟”

ادامه این مقاله را در لینک زیر بخوانید:

طراحی و پیاده سازی پایگاه داده

لینکهای مفید:

آنچه باید درباره توسعه پایگاه داده بدانید

توسعه وب

ساخت اپلیکیشن دسکتاپ

full stack development

گروه خودروسازی سایپا