- •4 Концептуальне інфологічне проектування бази даних
- •5 Розроблення інтерфейсу
- •6 Фізичне проектування бд
- •2 Опис та постановка задачі
- •2.1 Приклад. Постановка задачі.
- •6 Розроблення інтерфейсу
- •9 Оформлення додатків
- •Список рекомендованої літератури
- •1 Проектування та реалізація бази даних інформаційної системи. Основні етапи
- •1. Опис та постановка задачі;
- •2. Формулювання та аналіз вимог до бази даних:
- •3 Концептуальне інфологічне проектування бази даних
- •4 Проектування реалізації бази даних
- •3 Формулювання та аналіз вимог до бази даних
- •3.1 Приклад. Формулювання та аналіз вимог до бази даних Передпроектний аналіз проблемної сфери. Збирання інформації про використання даних
- •Зведення зібраної інформації до вигляду, зручного для проектування
- •Формулювання вимог до бд.
- •4 Концептуальне інфологічне проектування бази даних
- •4.1 Приклад. Концептуальне інфологічне проектування бази даних
- •Результат об'єднання першого та другого локальних подань моделі даних
- •Глобальна er- діаграма.
- •Вимоги до технічного забезпечення.
- •Вимоги до пз.
- •5 Проектування реалізації бази даних
- •5.1 Приклад. Проектування реалізації бази даних Даталогічна складна мережна модель даних.
- •Даталогічна проста мережна модель даних.
- •Нормалізація даних
- •6 Розроблення інтерфейсу
- •6.1 Приклад. Розроблення інтерфейсу
- •7 Фізичне проектування бд
- •7.1 Приклад. Фізичне проектування бд
- •8 Реалізація бази даних засобами ms access
- •8.1 Приклад. Реалізація бази даних засобами ms Access
- •Інтерфейс додатку.
- •Керівництво по використанню іс.
- •9 Оформлення додатків
- •9.1 Приклад. Оформлення додатків Додаток а.
- •Додаток б.
- •10 Індивідуальні завдання
- •Список рекомендованої літератури
4 Концептуальне інфологічне проектування бази даних
Концептуальна модель даних відображає об’єкти та їх взаємозв’язки, при цьому не вказуються способи їх фізичного зберігання.
Основна задача концептуального проектування складається в одержанні логічної моделі БД в термінах об’єктів проблемної сфери і зв’язків між ними, яка не залежить від конкретної СУБД і узагальнює інформаційні вимоги користувачів ІС.
Правила проектування локальних інформаційних структур (ER-діаграм):
1) тип сутності – це набір об’єктів проблемної сфери однотипних в тому розумінні, що вони описуються однаковими атрибутами. У локальній задачі не рекомендується виділяти більш ніж 7 типів сутностей. Графічно тип сутності зображається у вигляді іменованого прямокутника (називний відмінок, одиничне число).
2) кожний тип сутностей має ідентифікатори. Графічно атрибути типів сутностей зображається у вигляді іменованих овалів, що зв’язуються з прямокутником ненапрямними зв’язками. Первинний атрибут на діаграмі підкреслюється.
3) зв’язок між типами сутностей відображає фактичну або можливу взаємодію між ними, також динаміку взаємодії між екземплярами сутностей. Графічно цей зв’язок зображається у вигляді іменованого ромба з обов’язковим визначенням типу зв’язку (1:1, 1:М, М:М).
4) При типі зв’язку М:М можуть бути дані перетину, тобто дані, що належать з’єднаним типам сутностей. Такі дані називаються атрибутами зв’язку.
Проектування глобальної інфологічної моделі даних – проектування глобальної ER-діаграми – складається з інтеграції локальних ER-діаграм.
4.1 Приклад. Концептуальне інфологічне проектування бази даних
ER- діаграма першого локального подання.
У першому поданні моделі даних виділяються такі типи сутностей: "Тендерний комітет" і "Товар" з атрибутами, показаними на рисунку 4.1.
Рисунок 4.1 - ER-діаграма першого локального подання моделі даних
Перше локальне подання моделі даних стосується тендерного комітету, котрий проводить засідання, де вирішується питання про закупівлю необхідного товару, робіт, послуг.
Атрибутами, що ідентифікують екземпляри цих сутностей, є номер тендеру та код товару. Решта атрибутів указаних сутностей має описовий характер.
Зв'язок між зазначеними типами сутностей має назву "Замовлення". Тип асоціації цього зв'язку 1:1. У зв'язку є власні атрибути (дані перетину), які одночасно належать типам сутностей "Тендерний комітет" і "Товар".
ER- діаграма другого локального подання моделі даних
Друге локальне подання моделі даних стосується кур’єрської служби, що передає запрошення до участі у тендері фірмам-постачальникам, які пропонують свій товар і умови. Тут виділяються типи сутностей "Постачальник" і "Товар" з атрибутами, показаними на рисунку 4.2.
Зв'язки між типами сутностей має назву „Пропозиція”. Тип сутності "Постачальник" включає не всіх постачальників, а тільки тих, котрі приймають участь у даному тердері, тобто мають пропозицію необхідного товару, тип сутності 1:М. ER-діаграму другого локального подання моделі даних зображено на рисунку 4.2.
Товар
Постачальник
Рисунок 4.2 - ER-діаграма другого локального подання моделі даних
ER- діаграма третього локального подання моделі даних
Третє локальне подання моделі даних стосується тендерного комітету, який аналізує надіслані пропозиції та визначає переможця. Тут до сутностей і зв'язків першого та другого подання моделі даних додають нові, пов'язані з визначенням переможця. Тип сутності "Переможець" включає не всіх учасників тендеру, а постачальника, з яким тендерний комітет згоден складати договір про закупівлю. Тут зв’язок між типами сутностей „Товар” та „Переможець” має назву „Обрана пропозиція” (1:1). ER-діаграму третього локального подання моделі даних показано на рисунку 4.3.
Товар
Переможець
Рисунок 4.3 - ER-діаграма-третього локального подання моделі даних
