قبل از صحبت درباره پیاده سازی پایگاه داده، بهتر است درباره طراحی منطقی پایگاه داده بخوانیم:

طراحی منطقی پایگاه داده

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

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

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

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

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

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

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

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

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

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

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

پیاده سازی پایگاه داده

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

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

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

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

تحقق طراحی

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

یکی از راه‌های رسیدن به این هدف، نوشتن دستورات SQL DDL مناسب در فایلی است که می‌تواند توسط یک DBMS اجرا شود تا یک رکورد مستقل، یک فایل متنی، از دستورات SQL که پایگاه داده را تعریف می‌کند، وجود داشته باشد. روش دیگر این است که به صورت تعاملی با استفاده از ابزار پایگاه داده مانند SQL Server Management Studio یا Microsoft Access کار کنید. هر مکانیزمی که برای پیاده سازی طرح منطقی استفاده شود، نتیجه این است که یک پایگاه داده با جداول و محدودیت ها تعریف می شود اما هیچ داده ای برای فرآیندهای کاربر نخواهد داشت.

پر کردن پایگاه داده

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

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

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

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

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

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

دستورالعمل برای توسعه نمودار ER

توجه: اینها دستورالعمل های کلی هستند که به ایجاد یک پایه قوی برای طراحی واقعی (مدل منطقی) و پیاده سازی پایگاه داده کمک می کنند.

1. تمام موجودیت های کشف شده در مرحله جمع آوری اطلاعات را مستند کنید.
2. تمام ویژگی های متعلق به هر موجودیت را مستند کنید. کلیدهای کاندید و اصلی را انتخاب کنید. اطمینان حاصل کنید که همه ویژگی‌های غیرکلیدی برای هر موجودیت کاملاً به کلید اصلی وابسته هستند.
3. یک نمودار اولیه ER تهیه کنید و آن را با پرسنل مناسب بررسی کنید. (به یاد داشته باشید که این یک فرآیند تکراری است.)
4. موجودیت های جدید (جدول) برای ویژگی های چند ارزشی و گروه های تکرار شونده ایجاد کنید. این موجودیت های جدید (جدول) را در نمودار ER ادغام کنید. با پرسنل مناسب بررسی کنید.

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

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

توسعه وب

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

full stack development

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