Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Ярцев в. П. Створення та обробка баз даних на пеом

Ярцев в. П. Створення та обробка баз даних на пеом




Сторінка4/20
Дата конвертації10.03.2017
Розмір2.36 Mb.
ТипПротокол
1   2   3   4   5   6   7   8   9   ...   20

3. Проектування баз даних

3.1. Проблеми і етапи проектування баз даних

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



Системний аналіз предметної області і словесний опис інформаційних об'єктів і зв’язків між ними.

Інфологічне проектуванняпобудова інформаційно-логічної (інфологічної) моделі предметної області.

Вибір СУБД.

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

Фізичне проектування – вибір ефективного способу розміщення БД на зовнішніх носіях для забезпечення найбільш ефективної роботи прикладних програм.

Етапи проектування БД наочно зобразити можна у виді схеми на Рис. 3.1. Далі розглянемо коротко сутність кожного з цих етапів.



Рис. 3.1. Етапи проектування БД



3.1.1. Системний аналіз предметної області

Системний аналіз предметної області повинний дозволити скласти докладний словесний опис основних об'єктів даної предметної області, їхніх властивостей і зв'язків між цими об'єктами. При цьому розрізняють такі два підходи до системного аналізу: функціональний і структурний.



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

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

На практиці рекомендується використовувати компромісний варіант, який, з одного боку, орієнтований на конкретні задачі користувачів, а, з іншого боку, враховує прогнозовані потреби нарощування можливостей прикладних програм, які можуть з'явитися у майбутньому.

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


3.1.2. Інфологічне проектування

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

В даний час найбільш розповсюдженим є підхід до інформаційно-логічного проектування, заснований на застосуванні моделі “сутність-зв'язок” (ER-моделі). Уже розроблені і застосовуються на практиці інструментальні засоби, які використовують модель “сутність-зв'язок” (CASE-системи), за допомогою яких автоматизується процес розробки інформаційно-логічної моделі. Нижче ми більш докладно познайомимося з основними положеннями моделі “сутність-зв'язок”.

3.1.3. Вибір СУБД

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



3.1.4. Даталогічне проектування

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

Якщо раніше вже була побудована інфологічна модель, то на даному етапі вона перетворюється в схему відношень реляційної БД. Виконується аналіз коректності схеми відношень. Аналіз цей заснований на застосуванні методу нормальних форм, який дозволяє виявити й усунути небажані залежності між атрибутами у відношеннях, що може привести у майбутньому до низької ефективності робота з БД. Суть цього методу буде розглянута нижче, в окремій лекції.

На цьому ж етапі визначаються правила і процедури забезпечення цілісності БД.



3.1.5. Фізичне проектування


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

3.2. Модель “сутність-зв'язок”

Модель “сутність-зв'язок” є найбільш розповсюдженим у даний час підходом до побудови БД. Її застосування по суті справи стала діючим стандартом при інфологічному проектуванні БД. Загальноприйнятим стало скорочене найменування ER-модель (Essenceсутність, Relation – зв'язок).



ER-модель добре співвідноситься з концепцією об'єктно-орієнтованого проектування і тому використовується в різних програмних засобах автоматизованого проектування систем (у так званих CASE-системах). Найбільш розповсюдженими засобами інфологічного проектування на даний час є, наприклад, програмні системи ERwin, POWER DESIGNER та ін.

Розглянемо коротко базові поняття ER-моделі (багато з них вам покажуться знайомими, тому що вони зв’язані з поняттями реляційної моделі даних).

Поняттям сутність представляється клас однотипних об'єктів. Передбачається, що існує множина екземплярів даної сутності, що представляють реальні об'єкти предметної області. Об'єкт, якому відповідає дана сутність, має свій набір атрибутів – характеристик, що описують властивості даного об'єкта. При цьому набір атрибутів повинний бути таким, щоб можна було розрізняти конкретні екземпляри даної сутності. Графічно сутність прийнято зображувати прямокутником, у верхній частині якого записується ім'я сутності, а нижче перелічуються всі атрибути даної сутності. На Рис. 3.2 показаний приклад зображення сутності “Співробітник”.

Ключовими атрибутами називається такий набір атрибутів, що однозначно ідентифікує кожен екземпляр сутності. Наприклад, для сутності “Співробітник” це може бути атрибут “Табельний номер”. Ключові атрибути виділяються підкресленням чи іншим шрифтом.

Рис. 3.2. Зображення сутності “Співробітник”


Між сутностями завжди встановлюються зв'язки, тому що всі об'єкти реального світу зв'язані між собою. Зв'язкам привласнюються найменування. Наприклад, між сутностями “Студент” і “Викладач” може існувати зв'язок “Читає лекції”. На схемі моделі зв'язки позначаються лініями, що з'єднують значки відповідних сутностей. Наприклад, так, як це показано на Рис. 3.3.

Дипломне

проектування





Читає лекції
Рис. 3.3. Зображення зв'язку між сутностями
Зв'язки між сутностями можуть бути типів “один до одного” (1:1), “один до кількох” (1:М) чи “кілька до кількох” (М:М).

Зв'язок типу “один до одного” (1:1) означає, що один екземпляр першої сутності зв'язаний тільки з одним екземпляром другої сутності.

Зв'язок типу “один до кількох” (1:М) означає, що один екземпляр першої сутності може бути зв'язаний з декількома екземплярами другої сутності, але кожен екземпляр другої сутності - зв'язан тільки з одним екземпляром першої сутності.

Зв'язок типу “кілька до кількох” (М:М) означає, що один екземпляр першої сутності може бути зв'язаний з декількома екземплярами другої сутності і навпаки, кожен екземпляр другої сутності може бути зв'язаний з декількома екземплярами першої сутності.

У розглянутому вище прикладі зв'язок “Читає лекції” є зв'язком типу “один до кількох”, причому першою сутністю тут є “Викладач”, а другою – “Студент”.

У різних CASE-системах використовуються різні способи позначення типів зв'язків. Наприклад, у системі POWER DESIGNER прийнято зв'язок “один до кількох” позначати потрійною лінією з боку “кілька” (приблизно так, як це показано на Рис. 3.3). Між двома сутностями може бути встановлено як завгодно багато зв'язків. Наприклад, між сутностями “Студент” і “Викладач” ще може бути встановлений зв'язок “Дипломне проектування”. Очевидно, що цей зв'язок так само є зв'язком типу “один до кількох” – один викладач може керувати дипломною роботою декількох студентів, але кожен студент може мати тільки одного керівника дипломного проекту. Зв'язки будь-якого типу можуть бути обов'язковими чи необов'язковими. Якщо в даному зв'язку повинен брати участь кожен екземпляр сутності, то зв'язок у даному випадку є обов'язковим, а якщо не кожен екземпляр – то необов'язковим. При цьому зв'язок може бути обов'язковим з однієї сторони і необов'язковим з іншої сторони. Обов'язковий зв'язок на схемі прийнято позначати кружечком, а необов'язковий – перпендикулярною лінією, що перекреслює лінію зв'язку. На Рис. 3.3 зв'язок “Дипломне проектування” з боку студента є обов'язковим, а з боку викладача – необов'язковим. Дійсно, кожен студент-дипломник повинен обов'язково мати керівника дипломного проекту, але не кожен викладач є керівником дипломного проекту.

3.3. Наслідування сутностей

Відповідно до принципів об'єктно-орієнтованого проектування для сутностей уводиться поняття типу і підтипу сутності. Це значить, що для будь-якої сутності ми можемо ввести її підтипи, у яких наслідуються всі атрибути старшої сутності, і ще вводяться додаткові атрибути, за допомогою яких визначаються специфічні властивості для даного підтипу сутності.

Пояснити ідею типів і підтипів можна на такому прикладі. Нехай, мається сутність “Цех”, у якій представлені атрибути, загальні для будь-яких цехів. На підприємстві є багато цехів, що істотно розрізняються по призначенню, складу устаткування і, отже, по атрибутах, за допомогою яких можна описувати їхні характеристики. У цьому випадку доцільно для сутності “Цех” увести підтипи, у яких визначити необхідні специфічні атрибути. Наприклад, підтипами тут можуть бути: “Інструментальний цех”, “Ливарний цех”, “Склад готової продукції” і т.д. На Рис. 3.4 зображено приклад діаграми, що описує підтипи сутності “Цех”.

Сутність, на основі якої будуються підтипи, часто називають супертипом. На діаграмах для зображення зв'язку супертипу з підтипами сутностей використовується вузол-дискримінатор, що зображується у виді півкола, зверненого опуклою стороною до супертипу (як на Рис. 3.4). Множина підтипів повинна бути вичерпною, тобто включати всі можливі варіанти представлення даної сутності в підтипах. Для цього, при необхідності, може вводитися підтип “Інші”. У результаті розробки інформаційно-логічної моделі повинний бути отриманий зв'язний граф, у вузлах якого розташовуються введені сутності, зв'язані необхідними зв'язками. В отриманому графі не повинне бути циклічних зв'язків. Наявність циклічних зв'язків свідчить про некоректність моделі.

У завершення даного розділу розглянемо простий приклад моделі “сутність-зв'язок”. Для прикладу візьмемо учбову БД, у якій необхідно зберігати інформацію про успішність студентів. Нехай у наслідок системного аналізу предметної області були визначені такі сутності: Група, Студент, Предмет, Викладач, Успішність.



Рис. 3.4. Діаграма підтипів сутності “Цех”

Розроблена схема моделі “сутність-зв'язок” може бути такою, що зображена на Рис. 3.5. Пояснимо найбільш важливі елементи й особливості цієї схеми.

Між сутностями “Група” і “Студент” мається зв'язок “Належить”. Зв'язок є обов'язковим і тип зв'язку – “один до кількох”. У кожну групу повинні обов'язково входити більш одного студента. Кожен студент обов'язково входить до складу якої-небудь однієї групи.

У сутності “Успішність” представляються оцінки, отримані студентами на заняттях у різний час. Зв'язок між сутностями “Студент” і “Успішність” має назву “Бере участь на заняттях”. Зв'язок має тип “1:М”, тому що один студент може мати кілька оцінок чи ні однієї. Тому зв'язок є обов'язкової з боку сутності “Успішність” і необов'язкової з боку сутності “Студент”.

Зв'язок між сутностями “Предмет” і “Успішність” може мати назву “Заняття по предметах”. Тип зв'язку – “1:М”. По кожному предмету можуть бути отримані ні однієї чи кілька оцінок, але кожна оцінка завжди відноситься до якого-небудь одного предмету.

Зв'язок між сутностями “Викладач” і “Предмет” має назву “Викладає”. Тип зв'язку можна вважати “1:М” з урахуванням того, що кожен предмет веде тільки один викладач (якщо викладачів два, то основний завжди один). Зв'язок є обов'язковим.

Первинні ключі сутностей виділено напівжирним шрифтом.

Викладач

1   2   3   4   5   6   7   8   9   ...   20



  • 3.1.1. Системний аналіз предметної області
  • 3.1.2. Інфологічне проектування
  • 3.1.3. Вибір СУБД
  • 3.1.4. Даталогічне проектування
  • 3.1.5. Фізичне проектування
  • 3.2. Модель “сутність-звязок”
  • 3.3. Наслідування сутностей
  • Рис. 3.4. Діаграма підтипів сутності “Цех”