Міністерство освіти І науки україни

Вид материала

Документы

Содержание Концептуальне моделювання предметної області Обґрунтовування вибору СУБД Логічне проектування бази даних

Подобный материал:

• Міністерство освіти І науки України Департамент міжнародного співробітництва та європейської, 39kb.
• Міністерство освіти І науки україни міністерство економіки україни міністерство фінансів, 18.39kb.
• Міністерство освіти І науки україни донецький обласний центр туризму та краєзнавства, 189.44kb.
• Міністерство освіти І науки україни, 335.34kb.
• Міністерство освіти І науки україни, 283.15kb.
• Міністерство освіти І науки, молоді та спорту україни, 59.16kb.
• Міністерство освіти І науки україни, 32.42kb.
• Міністерство освіти І науки, молоді та спорту України, 61.58kb.
• Міністерство освіти І науки україни положенн я про організацію фізичного виховання, 306.47kb.
• Міністерство освіти І науки україни інститут інноваційних технологій І змісту освіти, 43.77kb.

Концептуальне моделювання предметної області

Проектування бази даних полягає в побудові комплексу взаємозв'язаних моделей даних.

Концептуальне моделювання дозволяє врахувати логічне уявлення структури даних у базі даних. Вірно розроблена модель бази даних має підтримувати усі явлення користувачів. Концептуальне моделювання є основою подальшого проектування бази даних та додатку для ії обробці.

Розробка концептуальної моделі предметної області є найважливішим етапом проектування бази даних є, не орієнтованим на конкретну СУБД. Концептуальна модель предметної області будується першою та полягає у структуризації наочної області : об'єкти реального миру піддаються класифікації, фіксується сукупність тих, що підлягають відображенню в БД об'єктів. Для кожного об'єкту фіксується сукупність властивостей, за допомогою яких описуватимуться конкретні екземпляри об'єкту, і відносини (взаємозв'язки) з іншими об'єктами. Потім вирішуються питання про те, яка інформація про об'єкти повинна бути представлена в БД і як її представити за допомогою даних.

Таким чином на цьому етапі проектування треба:

1. визначити перелік типів сутностей, інформація про які зберігатиметься у базі даних;
   
2. на підставі опису предметної області визначити зв’язки між сутностями створюваної бази даних, навести їх опис;
   
3. визначити тип зв’язків та обмеження участі їх членів;
   
4. визначити попередній перелік атрибутів та зв’язати їх з конкретними типами сутностей;
   
5. визначити первинні та потенційні ключі для кожного об'єкту бази даних;
   
6. побудувати ER – діаграму,
   
7. вилучити зайві зв’язки.
   

Приклад

Предметна область «Деканат»

На підставі аналізу предметної області можна виділити сутності, інформація про які зберігається у базі даних

Сутність Студент

Сутність Викладач

Сутність Дисципліна

Існування цих сутностей не залежить від існування інших сутностей, тому ці сутності є базовими.

Сутність Сесія є асоціативною, тому що вона поєдную всі базові сутності.

На підставі опису предметної області визначається зв’язок між сутностями Сесія та Дисципліна: на сесії з кожної Дисципліни здається тільки один іспит, но кожен іспит складається багато разів. Тому зв’язок між сутностями Сесія та Дисципліна М:1. При цьому іспит складається ні з кожної дисципліни, тому цей зв’язок є необов’язковий.

………………………………….

Таким чином, на підставі аналізу зв’язків між сутностями можна скласти концептуальну модель предметної області, яка подана на рис. ХХ.

1. Обґрунтовування вибору СУБД

Важливим етапом розробки інформаційної системи є вибір СУБД.

Для обробки даних розробленої бази даних необхідно розробити додаток у середовищі конкретної СУБД. Для розробки додатку можна вибрати одну з сучасних СУБД. Але цей вибір слід обґрунтувати. Треба докладно описати, з яких міркувань обрана саме ця СУБД.

При виконанні вибору можуть бути враховані наступні критерії:

1. функціональні можливості СУБД при рішення поставленої задачі;
   
2. об’їм баз даних, які може обробляти вибрана СУБД;
   
3. наявність засобів проектування додатків;
   
4. підтримка сучасних мов програмування;
   
5. операційна система, у середовищі якої може використовуватись обрана СУБД; то що.
   

Треба вибрати 2-3 сучасні СУБД, дати їх скорочену характеристику та провести їх порівняльний аналіз. На підставі цього аналізу зробити вибір.

До розробки додатку пропонується використовувати СУБД Access ХХ, яка э простою у використанні та наочною при проектуванні, достатньо потужною для забезпечення всіх етапів проектування додатку. Але студент за власним бажанням може використати будь яку іншу сучасну СУБД та створити у Ії середовищі додаток.

2. Логічне проектування бази даних

Логічне проектування бази даних – це процес перетворення концептуальної моделі в логічну модель з урахуванням особливостей обраної СУБД.

Основним завданням логічного проектування є розробка логічної схеми, орієнтованої на вибрану СУБД. Оскільки переважна більшість сучасних СУБД - реляційні, то і концептуальну модель БД слід відображати на реляційну модель.

У основі реляційної моделі використовується поняття “відносини”, яке використовується для уявлення набору екземплярів об'єкту (сутність) та відносин (зв'язків) між об'єктами.

Відношення представляється як певним чином організована таблиця.

Для відображення інформаційної структури ПО на логічну схему реляційної БД слід визначити:

• скільки таблиць і які повинна включати БД;
  
• які ступінь (кількість стовпців) і склад кожної таблиці;
  
• які атрибути (поля) використовуються як ключі;
  
• як встановлюються зв'язки між різними таблицями:
  

1. використання в різних таблицях одного і того ж ключа
   
2. використання ключа однієї таблиці як атрибут (поля) в записі іншої таблиці (зовнішні ключі)
   
3. створення спеціальних таблиць, що пов'язують сутності згідно з ER- діаграмою;
   

• як забезпечити повноту, несуперечність і узгодженість інформації, що зберігається в БД.
  

Для зменшення надмірності інформації і виключення аномалій виконується нормалізація.

Визначення змісту кожної таблиці зі зазначення типу даних та обмеження на значення для кожного атрибуту рекомендується навести у таблиці.

На підставі проведеного вище проектування необхідно:

1. при наявності складних зв’язків у ER – діаграмі (зв’язки типу М:М) перетворити їх на зв’язки типу 1:М та 1:1, для чого ввести додаткові асоціативні сутності;
   
2. перетворити ER – діаграму у відношення, визначити необхідну кількість відношень, яка дорівнює кількості сутностей на ER – діаграмі;
   
3. для кожного відношення визначити всі атрибути;
   
4. для кожного атрибуту таблиці визначити вимоги до підтримки цілісності даних: визначити обов’язковість наявності даних (припустимість значення NULL);
   
5. встановити обмеження для доменів атрибутів;
   
6. визначити тип даних для кожного атрибуту відношення;
   
7. результати аналізу навести у таблиці, яка створюється для кожній сутності.
   

Зміст таблиці наведений нижче.

Відношення	Атрибут	Тип даних	Припустиме значення	Обов’язковість	Примітка

8. визначити наявні функціональні залежності між атрибутами відношень;
   
9. провести аналіз відповідності створених відношень 3НФ та НФБК. обґрунтувати отримані результати;
   
10. при необхідності провести приведення відношень до НФБК.