مراحل طراحی و ایجاد پایگاه داده. مراحل توسعه پایگاه داده

مراحل طراحی پایگاه داده

موضوعات:مراحل طراحی پایگاه داده، طراحی پایگاه داده بر اساس مدل رابطه شی

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

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

قبل از ایجاد پایگاه داده، داشتن توضیحاتی در مورد انتخاب شده بسیار مهم است موضوع، ĸᴏᴛᴏᴩᴏᴇ باید اشیاء و فرآیندهای واقعی را پوشش دهد، تمام منابع اطلاعاتی لازم را برای پاسخگویی به درخواست های مورد انتظار کاربر شناسایی کند و نیازهای پردازش داده را تعیین کند.

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

مراحل طراحی و ایجاد پایگاه داده به ترتیب زیر تعیین می شود:

‣‣‣ ساخت یک مدل داده منطقی اطلاعاتی از حوزه موضوعی؛

‣‣‣ تعریف ساختار منطقی یک پایگاه داده رابطه ای.

‣‣‣ ساخت جداول پایگاه داده.

‣‣‣ ایجاد یک طرح داده؛

‣‣‣ وارد کردن داده ها در جداول (ایجاد رکورد).

‣‣‣ توسعه فرم های لازم، درخواست ها، ماکروها، ماژول ها، گزارش ها؛

‣‣‣ توسعه رابط کاربری.

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

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

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

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

قوانین رسمی که برای انتخاب اشیاء اطلاعاتی استفاده می شود را در نظر بگیرید.

‣‣‣ بر اساس شرح حوزه موضوعی، اسناد و ویژگی های آنها را شناسایی کنید تا در پایگاه داده ذخیره شوند.

‣‣‣ تعريف كردن وابستگی های عملکردیبین صفات؛

‣‣‣ همه ویژگی‌های وابسته را انتخاب کنید و برای هر یک از ویژگی‌های کلیدی آن، یعنی آنهایی که به آن‌ها بستگی دارد، نشان دهید.

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

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

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

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

بر اساس پایگاه داده ایجاد شده، پرس و جوها، فرم ها، ماکروها، ماژول ها، گزارش های لازم تشکیل می شود که پردازش مورد نیاز داده های پایگاه داده و ارائه آنها را انجام می دهد.

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

2 طراحی پایگاه داده بر اساس مدل رابطه شی

تعدادی روش برای ایجاد مدل های اطلاعاتی-منطقی وجود دارد. یکی از رایج ترین تکنیک های مدل سازی امروزه استفاده از ERD (Entity-Relationship Diagrams) است. در ادبیات روسی، این نمودارها "شی - رابطه" یا "ماهیت - ارتباط" نامیده می شود. مدل ERD توسط پیتر پینگ شن چن در سال 1976 پیشنهاد شد. تا به امروز، انواع مختلفی از آن توسعه یافته است، اما همه آنها بر اساس نمودارهای گرافیکی ارائه شده توسط چن هستند. نمودارها از تعداد کمی از اجزا ساخته می شوند. به دلیل وضوح ارائه، آنها به طور گسترده در ابزارهای CASE (مهندسی نرم افزار به کمک کامپیوتر) استفاده می شوند.

اصطلاحات و نمادهای استفاده شده را در نظر بگیرید.

وجود، موجودیت- یک شی واقعی یا خیالی که برای حوزه موضوع مورد بررسی ضروری است و اطلاعات مربوط به آن باید ذخیره شود.

هر موجودیت باید یک شناسه منحصر به فرد داشته باشد. هر نمونه از یک موجودیت باید به طور منحصربه‌فرد شناسایی و از سایر نمونه‌های یک نوع معین (موجود) متمایز باشد. هر موجودیت باید دارای برخی ویژگی ها باشد:

‣‣‣ دارای یک نام منحصر به فرد؛ علاوه بر این، همان تعبیر (تعریف موجودیت) همیشه باید برای این نام اعمال شود. و بالعکس: نمی توان یک تعبیر را به نام های مختلف اطلاق کرد، مگر اینکه مستعار باشند;

‣‣‣ یک یا چند ویژگی دارند که یا به یک موجودیت تعلق دارند یا از طریق یک رابطه به ارث می رسند.

‣‣‣ دارای یک یا چند ویژگی است که به طور منحصر به فرد هر نمونه موجود را شناسایی می کند.

یک موجودیت باید مستقل یا وابسته باشد. نشانه یک موجودیت وابسته، وجود صفاتی است که از طریق یک رابطه به ارث می رسد (شکل 1.).

ارتباط- ارتباط نامگذاری شده بین دو نهاد که برای حوزه موضوعی مورد بررسی مهم است. یکی از موجودیت‌های شرکت‌کننده در اتصال مستقل است، مرسوم است که نهاد مادر را فراخوانی می‌کند، دیگری وابسته است، مرسوم است که نهاد فرزند یا فرزند خوانده شود. به عنوان یک قاعده، هر نمونه از موجودیت اصلی با تعداد دلخواه (شامل صفر) نمونه های موجودیت فرزند مرتبط است. هر نمونه موجودیت فرزند دقیقاً با یک نمونه از موجودیت اصلی مرتبط است. ᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ، یک نمونه از موجودیت فرزند تنها در صورتی می تواند وجود داشته باشد که موجودیت والد وجود داشته باشد.

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

‣‣‣ ممکن است فروشنده برای یک یا چند قرارداد پاداش دریافت کند.

‣‣‣ قرارداد باید دقیقاً توسط یک فروشنده آغاز شود.

در نمودار، رابطه با یک قطعه (چند خط) نشان داده شده است. انتهای بخش با کمک نامگذاری های خاص (شکل 2) درجه اتصال را نشان می دهد. در عین حال، ماهیت خط - خط چین یا جامد، نشان دهنده الزام ارتباط است.

صفت- هر ویژگی یک موجودیت که برای حوزه موضوعی مورد بررسی مهم است. در نظر گرفته شده است که واجد شرایط، شناسایی، طبقه بندی، کمی کردن، یا بیان وضعیت یک موجودیت است. یک ویژگی نشان دهنده نوعی از ویژگی ها (خواص) مرتبط با مجموعه ای از اشیاء واقعی یا انتزاعی (افراد، مکان ها، رویدادها، حالت ها، ایده ها، جفت اشیاء و غیره) است (شکل 3). نمونه صفتیک ویژگی خاص از یک نمونه خاص از یک موجودیت است. یک نمونه مشخصه با یک نوع مشخصه (به عنوان مثال، ʼʼColorʼʼ) و مقدار آن (به عنوان مثال، ʼʼlilacʼʼ)، که مقدار ویژگی نامیده می شود، تعریف می شود. در مدل ER، ویژگی ها با موجودیت های خاص مرتبط هستند. هر نمونه موجود باید یک مقدار خاص برای هر یک از ویژگی های خود داشته باشد.

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

ماهیت شناسایی در نمودار روی خط ارتباطی نمایش داده می شود (شکل 4).

هر صفت با یک نام منحصر به فرد مشخص می شود که با یک عبارت اسمی بیان می شود که مشخصه ای را که ویژگی نشان می دهد توصیف می کند. ویژگی ها به صورت لیستی از نام ها در یک بلوک موجودیت مرتبط نمایش داده می شوند که هر ویژگی یک خط جداگانه را اشغال می کند. ویژگی هایی که کلید اصلی را تعریف می کنند در بالای لیست قرار می گیرند و با ʼʼ#ʼʼ مشخص می شوند.

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

امروزه بر اساس رویکرد چن، متدولوژی IDEF1X ایجاد شده است که با در نظر گرفتن الزاماتی مانند سهولت مطالعه و امکان اتوماسیون طراحی شده است. نمودارهای IDEFlX توسط تعدادی از ابزارهای رایج CASE (به عنوان مثال ERwin، Design/IDEF) استفاده می شود.

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

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

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

یک رابطه شناسایی بین یک موجودیت اصلی و یک موجودیت فرزند به عنوان یک خط ثابت نشان داده شده است. روی انجیر 5: #2 - موجودیت وابسته، رابطه 1 - رابطه شناسایی. یک موجودیت فرزند در یک رابطه شناسایی، یک موجودیت وابسته به هویت است. موجودیت اصلی در یک رابطه شناسایی باید هم مستقل و هم وابسته به شناسه باشد (این توسط روابط آن با سایر موجودیت ها مشخص می شود).

خط چین یک رابطه غیر شناسایی را نشان می دهد. روی انجیر 5: شماره 4 یک موجودیت مستقل است، پیوند 2 یک پیوند غیر شناسایی است. یک موجودیت فرزند در یک رابطه غیر شناسایی، اگر موجودیت فرزند در هیچ رابطه شناسایی نیز نباشد، مستقل از شناسه خواهد بود.

یک رابطه را می توان با مشخص کردن درجه یا اصل تعریف کرد (تعداد نمونه های موجودیت فرزند، ĸᴏᴛᴏᴩᴏᴇ ممکن است برای هر نمونه موجودیت والد وجود داشته باشد). در IDEF1X، کاردینالیتی های زیر بیان می شوند:

‣‣‣ هر نمونه موجودیت اصلی می‌تواند صفر، یک یا چند نمونه موجودیت فرزند مرتبط با خود داشته باشد.

‣‣‣ هر نمونه موجودیت اصلی باید حداقل یک نمونه موجودیت فرزند مرتبط با آن داشته باشد.

‣‣‣ هر نمونه موجودیت اصلی باید حداکثر یک نمونه موجودیت فرزند مرتبط با خود داشته باشد.

‣‣‣ هر نمونه موجودیت اصلی با تعداد ثابتی از نمونه های موجودیت فرزند مرتبط است.

قدرت پیوند همانطور که در شکل نشان داده شده است نشان داده شده است. 6 (قدرت پیش فرض - ن).

نتیجه یک مدل اطلاعاتی منطقی است که توسط تعدادی از ابزارهای رایج CASE مانند ERwin، Design / IDEF استفاده می شود. به نوبه خود، فناوری های CASE دارای پتانسیل بالایی در توسعه پایگاه های داده و سیستم های اطلاعاتی هستند، یعنی افزایش بهره وری نیروی کار، بهبود کیفیت محصولات نرم افزاری، حمایت از یک سبک کاری یکپارچه و سازگار.

مراحل طراحی پایگاه داده - مفهوم و انواع. طبقه بندی و ویژگی های دسته "مراحل طراحی پایگاه داده" 2017، 2018.

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

محتوای طراحی پایگاه داده و مراحل

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

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

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

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

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

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

در نهایت، مرحله نهایی طراحی پایگاه داده، طراحی فیزیکی است - مرحله پیوند ساختار منطقی و محیط ذخیره سازی فیزیکی.

بنابراین، مراحل اصلی طراحی در یک فرم دقیق توسط مراحل نشان داده می شود:

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

موارد کلیدی در زیر با جزئیات بیشتر مورد بحث قرار خواهند گرفت.

طراحی اینفولوژیک

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

• شرح انواع شیء،
• محدودیت های یکپارچگی مرتبط با نوع توصیف شده،
• فرآیندهایی که منجر به تکامل حوزه موضوعی - انتقال آن به حالت دیگر می شود.

یک مدل اینفولوژیک را می توان با استفاده از چندین روش و رویکرد ایجاد کرد:

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

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

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

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

لازم است مفاهیم "نمونه موجودیت" (شیئی که با مقادیر خاصی مشخص می شود) و مفهوم "نوع موجودیت" - شیئی که با یک نام مشترک و لیستی از ویژگی ها مشخص می شود ، جدا کنید.

برای هر موجودیت مجزا، صفاتی (مجموعه ای از ویژگی ها) انتخاب می شود که بسته به معیار، می تواند:

• شناسایی (با ارزش منحصر به فردبرای موجودیت هایی از آن نوع، که آنها را کلیدهای بالقوه می کند) یا توصیفی؛
• تک ارزشی یا چند ارزشی (با تعداد مناسب مقادیر برای یک نمونه موجودیت)؛
• پایه (مستقل از سایر ویژگی ها) یا مشتقات (محاسبه شده بر اساس مقادیر سایر ویژگی ها)؛
• ساده (تک جزئی غیرقابل تقسیم) یا ترکیبی (ترکیب از چندین جزء).

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

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

انتخاب سیستم کنترل و نرم افزار پایگاه داده

پیاده سازی عملی سیستم اطلاعاتی به انتخاب سیستم مدیریت پایگاه داده بستگی دارد. مهمترین معیار در فرآیند انتخاب پارامترهای زیر است:

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

اشتباهات در انتخاب DBMS تقریباً به طور قطع نیاز به تنظیم مدل های مفهومی و منطقی را بعداً برمی انگیزد.

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

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

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

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

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

طرحواره های پایگاه داده با استفاده از یکی از دو رویکرد متفاوت تولید می شوند:

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

رویکرد دوم شامل تعریف تعدادی از موجودیت‌های سطح بالا و روابط آن‌ها، و به دنبال آن جزئیات تا سطح مورد نظر است، که برای مثال، مدلی را که بر اساس روش «موجود-رابطه» ایجاد شده است، منعکس می‌کند. با این حال، در عمل، هر دو رویکرد معمولاً با هم ترکیب می شوند.

طراحی پایگاه داده فیزیکی

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

ساخت یک مدل فیزیکی از بسیاری جهات با حل مسائل متناقض همراه است:

1. مشکلات کمینه سازی فضای ذخیره سازی داده ها،
2. اهداف دستیابی به یکپارچگی، امنیت و حداکثر عملکرد.

وظیفه دوم با تکلیف اول در تضاد است زیرا برای مثال:

• برای عملکرد موثر تراکنش ها، باید فضای دیسک را برای اشیاء موقت رزرو کنید.
• برای افزایش سرعت جستجو، باید شاخص هایی ایجاد کنید که تعداد آنها با تعداد ترکیبات ممکن از فیلدهای موجود در جستجو تعیین می شود.
• برای بازیابی داده ها، از پایگاه داده پشتیبان گرفته می شود و گزارشی از تمام تغییرات نگهداری می شود.

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

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

آژانس فدرال آموزش

موسسه آموزشی دولتی آموزش عالی حرفه ای

دانشگاه ایالتی آمور

(GOUVPO "AmSU")

تست

در رشته "سیستم های اطلاعاتی در اقتصاد"

با موضوع: "اصول ساخت و مراحل طراحی پایگاه داده"

مجری

دانش آموز گروه C - 81 N.A. وخمیانینا

سرپرست

دانشیار، Ph.D. D. G. Shevko

بلاگوشچنسک 2010

معرفی

1. اصول ساخت پایگاه داده

2. مفاهیم ساخت پایگاه داده

3. مراحل طراحی پایگاه داده

فهرست کتابشناختی

معرفی

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

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

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

پایگاه داده (DB)- مجموعه ای نامگذاری شده از داده ها که وضعیت اشیا و روابط آنها را در حوزه موضوعی مورد بررسی منعکس می کند.

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

سیستم مدیریت پایگاه داده (DBMS)- مجموعه ای از ابزارهای زبان و نرم افزار طراحی شده برای ایجاد، پر کردن، به روز رسانی و حذف پایگاه های داده.

برنامه هایی که کاربران با آنها با پایگاه داده کار می کنند برنامه کاربردی نامیده می شوند.

1. اصول ساخت پایگاه های داده

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

1. عملکرد بالا (زمان پاسخ کوتاه به یک درخواست).

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

2. به روز رسانی داده ها آسان است.

3. استقلال داده ها.

4. به اشتراک گذاری داده ها بین بسیاری از کاربران.

5. امنیت داده ها - حفاظت از داده ها در برابر نقض عمدی یا غیر عمدی رازداری، تحریف یا تخریب.

6. استاندارد سازی ساخت و بهره برداری از پایگاه داده (در واقع DBMS).

8. رابط کاربری دوستانه.

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

استقلال داده ها- امکان تغییر ساختار منطقی و فیزیکی پایگاه داده بدون تغییر دیدگاه کاربران.

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

امنیت داده هایکپارچگی و حفاظت آنها را شامل می شود.

یکپارچگی داده - مقاومت داده های ذخیره شده در برابر تخریب و تخریب مرتبط با نقص وسایل فنی, خطاهای سیستمو اقدامات اشتباه کاربران

او پیشنهاد می کند:

1. عدم وجود داده های وارد شده نادرست یا دو ورودی یکسان در مورد یک واقعیت.

2. محافظت در برابر خطاها هنگام به روز رسانی پایگاه داده.

3. عدم امکان حذف (یا حذف آبشاری) داده های مربوط به جداول مختلف.

4. عدم تحریف داده ها هنگام کار در حالت چند کاربره و در پایگاه های داده توزیع شده.

5. ایمنی داده ها در صورت خرابی تجهیزات (بازیابی اطلاعات).

یکپارچگی توسط محرک های یکپارچگی ارائه می شود - برنامه های کاربردی ویژه ای که تحت شرایط خاصی کار می کنند. حفاظت از داده ها در برابر دسترسی غیرمجاز شامل محدود کردن دسترسی به داده های محرمانه است و می توان به موارد زیر دست یافت:

1. معرفی یک سیستم رمز عبور.

2. اخذ مجوز از مدیر پایگاه داده (DBA).

4. تشکیل نماها - جداول برگرفته از جداول اصلی و در نظر گرفته شده برای کاربران خاص.

سه رویه آخر به راحتی در زبان پرس و جوی ساختاریافته - SQL که اغلب به آن SQL2 گفته می شود، انجام می شود.

استانداردسازی تداوم نسل‌های DBMS را تضمین می‌کند، تعامل پایگاه‌های داده یک نسل از DBMS را با مدل‌های داده مشابه و متفاوت ساده می‌کند. استانداردسازی (ANSI/SPARC) تا حد زیادی از نظر رابط کاربری DBMS و زبان SQL پیاده سازی شده است. این امکان حل موفقیت آمیز مشکل تعامل انواع مختلف را فراهم کرد DBMS رابطه ایهم با استفاده از زبان SQL و هم با استفاده از برنامه Open DataBase Connection (ODBC). در این مورد، هم محلی و هم دسترسی از راه دوربه داده ها (فناوری مشتری/سرور یا گزینه شبکه).

2. مفهوم ساخت پایگاه داده

دو رویکرد برای ساخت یک پایگاه داده بر اساس دو رویکرد برای ایجاد یک سیستم کنترل خودکار (ACS) وجود دارد.

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

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

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

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

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

3. مراحل طراحی پایگاه داده

طراحی پایگاه داده در چهار مرحله انجام می شود.

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

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

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

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

مراحل طراحی پایگاه داده

فرآیند طراحی شامل مراحل زیر است:

• 1. طراحی اینفولوژیک.
• 2. تعیین الزامات برای محیط عملیاتی که سیستم اطلاعاتی در آن فعالیت خواهد کرد.
• 3. انتخاب سیستم مدیریت پایگاه داده (DBMS) و سایر ابزارهای نرم افزاری.
• 4. طراحی پایگاه داده داده شناسی (منطقی).
• 5. طراحی فیزیکی پایگاه داده.

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

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

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

از آنجایی که دسترسی مشخص شده با استفاده از یک DBMS خاص انجام می شود، مدل ها باید در زبان توصیف داده های این DBMS توضیح داده شوند. چنین توصیفی نامیده می شود مدل داده دیتالوژیکی.

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

مدل اینفولوژیک (اطلاعاتی-منطقی).هدف از مرحله اینفولوژیک طراحی به دست آوردن مدل های معنایی (مفهومی) است که حوزه موضوعی و نیازهای اطلاعاتی کاربران را منعکس می کند. بنابراین به این مرحله مدلسازی معنایی نیز می گویند. مدل‌سازی معنایی مدل‌سازی ساختار داده‌ها بر اساس معنای این داده‌ها است.

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

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

مثال ها.

یک شی " انسان" دارای ویژگی های: قد، نام، تاریخ تولد ...،

یک شی - " تولید - محصول"دارای خواص: کیفیت، تاریخ ساخت، ظاهر ....

ارتباطات متعددی بین اشیا وجود دارد. مثلا:

• · انسانمی خرد، می فروشد، تولید می کند تولید - محصول
• · تولید - محصولایجاد، خرید، فروش انسان.

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

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

هسته شیء سیستم در طول چرخه حیات یک IS ثابت نمی ماند: اشیا ناپدید می شوند و ظاهر می شوند، خواص و روابط آنها تغییر می کند. زنجیره این تغییرات ثابت در زمان نامیده می شود مسیرهای حوزه موضوعی،و کل خواص مشترکمسیر - معناشناسی دامنه

تعدادی از تکنیک های مدل سازی دامنه وجود دارد. یکی از رایج‌ترین تکنیک‌ها در حال حاضر مبتنی بر استفاده از نمودارهای گرافیکی است که شامل تعداد کمی از اجزای ناهمگن ERD (نمودارهای نهادی-رابطه) است. در ادبیات روسی زبان به این نمودارها "شی - رابطه" یا "ماهیت - اتصال" می گویند.

مدل ERD در سال 1976 ارائه شد. پیتر پینگ شنگ چن. متعاقباً، بسیاری از نویسندگان نسخه های خود را از چنین مدل هایی توسعه دادند: نماد مارتین، نماد IDEF1X، نماد بارکر)، اما همه آنها بر اساس نمودارهای گرافیکی ارائه شده توسط چن هستند.

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

در واقع، همه انواع نمودارهای موجودیت-رابطه از یک ایده ناشی می شوند - یک نقاشی همیشه واضح تر است. توضیحات متن. همه این نمودارها از یک نمایش گرافیکی از موجودیت های حوزه موضوعی، ویژگی های آنها (ویژگی ها) و روابط بین موجودیت ها استفاده می کنند.

ما با نمودارهای ER در نماد بارکر آشنا می شویم، زیرا درک ایده های اساسی بسیار آسان است.

مفاهیم اساسی نمودارهای ER.مفاهیم اصلی مدل ER عبارتند از نهاد، رابطه و ویژگی.

برای بیان بیشتر و درک بهتر، نام موجودیت را می توان با مثال هایی همراه کرد. اشیاء خاصاز این نوع

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

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

نمونه هایی از موجودیت ها می توانند کلاس های شی مانند "Supplier"، "Employee"، "Invoice" باشند.

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

تعریف 2. نمونه نهاد نماینده خاص این نهاد است.

به عنوان مثال، نماینده نهاد "کارمند" می تواند "کارمند ایوانف" باشد.

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

تعریف 3. صفت موجودیت یک ویژگی نامگذاری شده برای یک موجودیت است. نام آن باید برای یک نوع موجودیت خاص منحصر به فرد باشد، اما می تواند برای انواع موجودیت های مختلف یکسان باشد (به عنوان مثال، COLOR را می توان برای بسیاری از موجودیت ها تعریف کرد: DOG، CAR، PAINT، و غیره). ویژگی ها برای تعریف اینکه چه اطلاعاتی باید در مورد یک موجودیت جمع آوری شود استفاده می شود. نمونه هایی از ویژگی های یک موجودیت خودرو عبارتند از TYPE، MARK، LICENSE PLATE، COLOR و غیره.

در اینجا نیز بین نوع ویژگی و نمونه تمایز وجود دارد. نوع مشخصه COLOR نمونه ها یا مقادیر زیادی دارد: قرمز، آبی، موزی، شب سفید و غیره، اما به هر نمونه موجودیت فقط یک مقدار مشخصه اختصاص داده می شود.

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

هر ویژگی با نامی ارائه می شود که در موجودیت منحصر به فرد است. نام ویژگی باید به صورت یک اسم مفرد بیان شود (احتمالاً با صفت های مشخص کننده).

نمونه هایی از ویژگی های نهاد "کارمند" می تواند ویژگی هایی مانند "شماره پرسنل"، "نام خانوادگی"، "نام"، "نام پدر"، "مقام شغلی"، "حقوق" و غیره باشد.

ویژگی ها در مستطیلی که موجودیت را تعریف می کند نمایش داده می شوند:

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

توصیفی ویژگی ها نشان دهنده حقایق ذاتی هر نمونه از یک موجودیت است.

اشاره می کند ویژگی‌ها برای نام‌گذاری یا برچسب‌گذاری نمونه‌های موجودیت استفاده می‌شوند.

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

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

به عنوان مثال، برای یک موجودیت برنامهکلید یک ویژگی است شماره پروازیا تنظیم کنید: نقطه عزیمت, زمان خروجو مقصد(به شرطی که یک هواپیما در یک زمان از نقطه ای به نقطه دیگر پرواز کند).

یک موجودیت می تواند چندین کلید مختلف داشته باشد.

ویژگی های کلیدی در نمودار نشان داده شده است:

تعریف 5. ارتباط نوعی ارتباط بین دوموجودیت ها. یک موجودیت می تواند با موجودیت دیگر یا به خودش مرتبط باشد. روابط به یک موجود اجازه می دهد تا موجودیت های دیگر مرتبط با خود را بیابد.

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

به عنوان مثال، روابط بین نهادها را می توان با عبارات زیر بیان کرد - "یک کارمند می تواند چندین فرزند داشته باشد"، "هر کارمند باید دقیقاً در یک بخش ثبت شود".

از نظر گرافیکی، یک رابطه با خطی نشان داده می شود که دو موجودیت را به هم متصل می کند:

هر پیوند دارای دو انتهای و یک یا دو نام است. این نام معمولاً به صورت فعل نامشخص بیان می شود: "داشتن" ، "تعلق" و غیره. هر یک از نام ها به انتهای اتصال آن اشاره دارد. گاهی اسامی به دلیل واضح بودن نوشته نمی شود.

هر پیوند می تواند یکی از موارد زیر را داشته باشد انواع ارتباط :

نوع ارتباط یک به یک به این معنی که یک نمونه از موجودیت اول (سمت چپ) با یک نمونه از موجودیت دوم (راست) مرتبط است. رابطه یک به یک اغلب نشان می دهد که در واقع ما فقط یک موجودیت داریم که به اشتباه به دو قسمت تقسیم شده است.

نوع ارتباط یک به چند به این معنی که یک نمونه از موجودیت اول (سمت چپ) با چندین نمونه از موجودیت دوم (راست) مرتبط است. این رایج ترین نوع اتصال است. موجودیت چپ (در سمت "یک") فراخوانی می شود والدین ، سمت راست (از سمت "بسیار") - شرکت فرعی . (نگاه کنید به شکل تصویر گرافیکیاتصالات)

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

هر اتصال می تواند یکی از این دو را داشته باشد روش های ارتباطی :

مدالیته " شاید ممکن است مرتبط باشدبا یک یا چند نمونه از موجودیت دیگر، شاید مرتبط نباشدنه یک نسخه

مدالیته " باید "به این معنی است که یک نمونه از یک موجودیت واحد باید حداقل با یکی مرتبط باشدنمونه ای از موجودیت دیگر

اتصال ممکن است داشته باشد مدالیته مختلفاز انتهای مختلف

نحو گرافیکی توصیف شده اجازه می دهد قطعانمودارها را با استفاده از طرح عبارت زیر بخوانید:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

هر پیوند را می توان از چپ به راست یا از راست به چپ خواند. به عنوان مثال، پیوند نشان داده شده در شکل 4 در بالا به شرح زیر است:

از چپ به راست: "هر کارمند می تواند چند فرزند داشته باشد."

از راست به چپ: "هر کودک باید دقیقاً متعلق به یک کارمند باشد."

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

که در اول عادی شکل یک نمودار ER ویژگی های تکراری یا گروه هایی از ویژگی ها را حذف می کند. موجودیت های ضمنی "مستدل" به عنوان ویژگی ها شناسایی می شوند.

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

که در سوم عادی فرم، ویژگی هایی که به ویژگی هایی بستگی دارند که در شناسه یکتا (کلید موجودیت) موجود نیستند، حذف می شوند. این صفات اساس یک موجودیت واحد هستند.

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

بازیابی یک طرحواره رابطه ای از یک طرحواره ER:

مرحله 1.هر موجود ساده به یک جدول تبدیل می شود. موجود ساده موجودی است که زیرمجموعه نیست و هیچ گونه فرعی ندارد. نام موجودیت به نام جدول تبدیل می شود.

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

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

مرحله 4روابط چند به یک (و یک به یک) به کلیدهای خارجی تبدیل می شوند. آن ها یک کپی از شناسه منحصر به فرد از انتهای رابطه "یک" ساخته می شود و ستون های مربوطه کلید خارجی را تشکیل می دهند. روابط اختیاری مربوط به ستون هایی است که مقادیر null را مجاز می کند. روابط اجباری - ستون هایی که مقادیر تهی را مجاز نمی دانند.

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

مرحله 6اگر زیرگروه ها در طرح مفهومی وجود داشته باشند، دو روش ممکن است:

• همه زیرگروه ها در یک جدول
• برای هر زیرگروه - یک جدول جداگانه (b)

در روش (الف)، یک جدول برای بیرونی‌ترین سوپرتایپ ایجاد می‌شود و می‌توان نماها را برای زیرگروه‌ها ایجاد کرد. حداقل یک ستون حاوی کد TYPE به جدول اضافه می شود. بخشی از کلید اصلی می شود.

هنگام استفاده از روش (b)، برای هر زیرگروه از سطح اول (برای موارد پایین تر - نمایش ها)، سوپرتایپ با استفاده از نمایش UNION دوباره ایجاد می شود (ستون های رایج از همه جدول های زیرگروه انتخاب می شوند - ستون های supertype).

مرحله 7دو راه برای کار با روابط انحصاری وجود دارد:

• دامنه(های) مشترک
• کلیدهای خارجی صریح (ب)

اگر کلیدهای خارجی باقیمانده همه در یک دامنه باشند، به عنوان مثال. یک قالب مشترک دارند (روش (الف))، دو ستون ایجاد می شود: شناسه رابطه و شناسه نهاد. ستون شناسه پیوند برای تشخیص پیوندهای تحت پوشش قوس خروج استفاده می شود. ستون Entity ID برای ذخیره مقادیر شناسه منحصر به فرد موجودیت در انتهای رابطه مرتبط استفاده می شود.

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

نمونه ای از توسعه یک مدل ER ساده.هنگام توسعه مدل های ER، باید اطلاعات زیر را در مورد حوزه موضوعی به دست آوریم:

• 1. فهرست نهادهای حوزه موضوعی.
• 2. فهرست صفات موجودیت.
• 3. شرح روابط بین موجودیت ها.

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

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

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

• · ذخیره اطلاعات مشتری.
• · چاپ فاکتور برای کالاهای صادر شده.
• · نظارت بر موجودی انبار.

بیایید همه اسامی را در این جملات انتخاب کنیم - اینها نامزدهای بالقوه برای موجودیت ها و ویژگی ها خواهند بود و آنها را تجزیه و تحلیل می کنیم (ما اصطلاحات نامفهوم را با علامت سوال برجسته می کنیم):

• · خریدار
• · صورتحسابیک کاندید واضح برای یک نهاد است.
• · تولید - محصول- یک نامزد واضح برای یک نهاد
• · (؟)موجودی- و به طور کلی شرکت چند انبار دارد؟ اگر چندتایی باشد، نامزد یک موجودیت جدید خواهد بود.
• · (؟)در دسترس بودن محصول- این به احتمال زیاد یک ویژگی است، اما ویژگی کدام موجودیت است؟

بلافاصله یک ارتباط آشکار بین نهادها وجود دارد - "مشتریان می توانند بسیاری از محصولات را بخرند" و "محصولات را می توان به بسیاری از خریداران فروخت." نمودار اول به این صورت است:

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

نهادهای "فاکتور" و "انبار" را در کجا قرار دهیم و آنها را با چه چیزی مرتبط کنیم؟ بیایید از خود بپرسیم که این موجودات چگونه با یکدیگر و با موجودیت های "خریدار" و "محصول" ارتباط دارند؟

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

بنابراین، پس از روشن شدن، نمودار به شکل زیر خواهد بود:

نمایش اطلاعات ویژگی infological

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

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

مجدداً، تمام اسم هایی را که صفات بالقوه خواهند بود، می نویسیم و آنها را تجزیه و تحلیل می کنیم:

• · وجود، موجودیت - یک اصطلاح بلاغی، ما با آن کار نمی کنیم اشخاص حقیقی. ما توجه نمی کنیم
• · نام خریدار
• · نشانی- مشخصه واضح خریدار.
• · اطلاعات دقیق بانکی- مشخصه واضح خریدار.
• · نام محصول
• · (؟) قیمت محصول- به نظر می رسد یکی از ویژگی های محصول است. آیا این مشخصه با قیمت در فاکتور متفاوت است؟
• · واحد- توضیح واضح محصول
• · شماره فاکتور- یک ویژگی منحصر به فرد واضح از بارنامه.
• · تاریخ فاکتور- مشخصه صریح بارنامه.
• · (؟) فهرست کالاها در فاکتور- لیست نمی تواند یک ویژگی باشد. احتمالاً باید این لیست را به یک نهاد جداگانه جدا کنید.
• · (؟) مقدار کالا در فاکتور- این یک ویژگی واضح است، اما مشخصه چیست؟ این فقط یک ویژگی "کالا" نیست، بلکه "کالا در بارنامه" است.
• · (؟) قیمت کالا در فاکتور- باز هم باید بگویم که این فقط باید توصیف کالا نباشد، بلکه باید توصیف کالا در فاکتور باشد. اما قیمت کالا قبلاً در بالا آمده است - آیا همان چیزی است؟
• · مبلغ فاکتور- مشخصه صریح بارنامه. این ویژگی مستقل نیست. مبلغ فاکتور برابر است با مجموع هزینه های کلیه کالاهای درج شده در فاکتور.
• · نام انبار- توضیح واضحی از انبار.

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

با مفهوم در حال ظهور "فهرست کالاها در فاکتور" همه چیز کاملاً واضح است.

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

این نهاد، نهاد «فهرست کالاهای روی فاکتور» خواهد بود. رابطه آن با نهادهای "فاکتور" و "محصول" با عبارات زیر مشخص می شود

- "هر بارنامه باید دارای چندین ورودی از لیست کالاهای موجود در بارنامه باشد"

• - "هر ورودی از لیست کالاها در فاکتور باید دقیقاً در یک فاکتور درج شود"
• - "هر محصول را می توان در چندین ورودی از لیست محصولات در فاکتور گنجانده شود"
• - «هر ورودی از لیست کالا در فاکتور باید دقیقاً با یک کالا مرتبط باشد».

ویژگی های «تعداد کالا در فاکتور» و «قیمت کالا در فاکتور» ویژگی های نهاد «فهرست کالاهای مندرج در فاکتور» هستند.

بیایید همین کار را با اتصالی که موجودیت های "انبار" و "کالا" را به هم متصل می کند، انجام دهیم. معرفی کنیم اضافیموجودیت "کالاهای موجود". ویژگی این نهاد «تعداد کالای موجود در انبار» خواهد بود. بدین ترتیب کالا در هر انباری درج می شود و مقدار آن در هر انبار متفاوت خواهد بود.

اکنون می توانید همه اینها را در نمودار قرار دهید:

مدل‌های ER مفهومی و فیزیکیمثال نمودار ER که در بالا ایجاد شد یک مثال است نمودار مفهومی. این به این معنی است که نمودار را در نظر نمی گیردویژگی های یک DBMS خاص از این نمودار مفهومی می توان ساخت نمودار فیزیکی، که قبلاً ویژگی های DBMS مانند انواع و نام های معتبر فیلدها و جداول، محدودیت های یکپارچگی و غیره را در نظر می گیرد. برای مثال، نسخه فیزیکی نمودار بالا ممکن است به شکل زیر باشد:

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

جداول به دست آمده در 3NF هستند.

نمودارهای موجودیت-رابطه به شما امکان می دهد از بصری استفاده کنید نمادهای گرافیکیبرای مدل سازی موجودیت ها و روابط آنها.

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

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

انواع فرعی و ابرگونه های موجودات. همانطور که در زبان های برنامه نویسی با سیستم های نوع توسعه یافته (به عنوان مثال، در زبان های برنامه نویسی شی گرا)، امکان به ارث بردن یک نوع موجودیت بر اساس یک یا چند سوپرتایپ ارائه می شود.

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

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

مثال: Supertype AIRCRAFT

چگونه قرار است خوانده شود؟ از supertype: AIRCRAFT، که باید یک AIRCRAFT، HELICOPTER، BIRDS، یا هواپیماهای دیگر باشد. از نوع فرعی: هلیکوپتر که متعلق به نوع AIRCRAFT است. از یک زیرگروه که سوپرتایپ هم هست: AEROPLANE که متعلق به نوع AIRCRAFT است و باید GLIDER یا POWER PLANE باشد.

گاهی اوقات داشتن دو یا چند زیرگروه مختلف از یک موجود راحت است. به عنوان مثال، موجودیت PERSON را می توان با توجه به ویژگی های حرفه ای (برنامه نویس، شیرکار و غیره) به زیرگروه هایی تقسیم کرد، یا شاید - بر اساس جنسیت (MAN، WOMAN).

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

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

به معنای معنایی مفهوم دامنه نیز باید توجه داشت: داده ها تنها در صورتی قابل مقایسه در نظر گرفته می شوند که متعلق به یک دامنه باشند. در مثال ما، مقادیر دامنه های "Pass Numbers" و "Group Numbers" از نوع عدد صحیح هستند، اما قابل مقایسه نیستند.

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

مراحل طراحی پایگاه داده

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

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

2. پایگاه داده باید داده های مورد نیاز را در یک زمان معقول ارائه دهد، یعنی. برآورده کردن الزامات عملکرد؛

3. هنگام سازماندهی مجدد حوزه موضوعی، پایگاه داده باید به راحتی گسترش یابد.

4. هنگامی که محیط نرم افزاری و سخت افزاری تغییر می کند، پایگاه داده باید به راحتی تغییر یابد.

5. داده های صحیح بارگذاری شده در پایگاه داده باید درست باقی بمانند (داده ها هنگام وارد شدن باید از نظر صحت بررسی شوند).

مراحل اصلی طراحی را در نظر بگیرید (شکل 3.5):

مرحله اول. برنامه ریزی توسعه پایگاه داده در این مرحله موثرترین راه برای اجرای مراحل برجسته خواهد شد. چرخه زندگیسیستم های.

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

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

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

برنج. 3.5. طرح طراحی پایگاه داده

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

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

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

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

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

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

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

مرحله هشتم. تست و بهینه سازی. مرحله اجباری آزمایش و بهینه سازی برنامه توسعه یافته است.

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

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