Microsoft Word - 13-1-05

Лекція 9. Проектування баз даних

1. Життєвий цикл розробки бази даних

Інформаційна система виконує функції збору та збереження даних, а також обробку та маніпулювання даними. Вона забезпечує структурування даних і управління ними.

Ефективність роботи інформаційної системи залежить від таких складових:

- проекту та реалізації бази даних;

- проекту та реалізації застосувань;

- супроводження інформаційної системи.

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

Інформаційна система має життєвий цикл (Systems Development Life Cicle, SDLC), який складається з таких етапів:

- планування;

- збір і аналіз вимог;

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

- реалізація;

- тестування;

- супроводження.

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

- планування БД;

- аналіз вимог до БД;

- проектування БД (концептуальне, логічне, фізичне);

- розробка застосувань;

- реалізація і завантаження даних;

- тестування;

- експлуатація.

Описание: image1

Рис. 1. Етапи життєвого циклу бази даних

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

1.2. Планування бази даних

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

- аналіз існуючих інформаційних систем;

- доцільність зміни існуючої інформаційної системи;

- обсяг робіт і ресурсів, вартість проекту;

- визначення технічного завдання для проекту бази даних;

- визначення технічних вимог;

- розробка методології збору даних, визначення їх формату;

- визначення необхідної документації;

- визначення послідовності проектування і реалізації застосувань.

1.3. Аналіз вимог до бази даних

На етапі аналізу вимог до бази даних вирішуються такі задачі:

- визначення діапазону дії і границь застосувань БД;

- визначення складу користувачів і областей застосування;

- визначення представлень користувачів, що підтримуються БД.

На цьому етапі також збираються і аналізуються вимоги користувачів:

- опис даних, що застосовуються (вхідні і вихідні документи);

- детальні відомості про транзакції;

- відомості про засоби застосування даних.

На основі всієї цієї інформації складаються специфікації вимог користувачів.

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

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

- системний аналіз предметної області;

- концептуальне проектування;

- логічне проектування;

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

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

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

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

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

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

У загальному випадку існує два підходи до проектування БД: низхідне проектування і висхідне проектування (рис. 2).

Рис. 2. Схема підходів до проектування бази даних

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

Цей підхід рекомендується застосовувати у тих випадках, коли кількість, різноманітність та складність сутностей, зв'язків і транзакцій значна за розмірами. Найбільш поширеними моделями для цього проектування є моделі «сутність - зв'язок» (ER-моделі, Entity-Relationship model).

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

Цей підхід рекомендується застосовувати у тому випадку, якщо розробляється невелика БД з незначною кількістю об'єктів, атрибутів і транзакцій.

Концептуальне проектування полягає в створенні концептуальної моделі, яку відображає концептуальна схема БД. На цьому етапі визначаються об'єкти, зв'язки між об'єктами, атрибути, ключові атрибути.

Логічне проектування полягає в створенні логічної моделі на основі вибраної моделі даних. На цьому етапі необхідно вже знати яка СКБД буде застосовуватися в системі (ієрархічна, мережна, реляційна, об'єктно-орієнтована). Для перевірки вірності логічної моделі застосовується нормалізація. Крім того логічна модель перевіряється на умову забезпечення всіх транзакцій користувачів.

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

5. Розробка застосувань

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

На цьому етапі вирішуються такі задачі:

- проектування транзакцій;

- проектування інтерфейсів користувачів.

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

Інтерфейс користувача – сукупність функціональних компонентів, які забезпечують взаємодію користувача з системою.

6. Реалізація

На етапі реалізації вирішуються такі задачі:

- встановлюється технічне і програмне забезпечення СКБД;

- реалізується проект БД;

- реалізуються прикладні програми;

- реалізуються форми вводу/виводу даних і звіти;

- наповнення БД даними;

- захист БД від несанкціонованого втручання;

- підтримка цілісності БД.

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

7. Тестування

На етапі тестування вирішуються такі задачі:

- перевіряється вірність роботи окремих модулів або функціональних компонентів (альфа-тестування);

- проводяться виміри продуктивності роботи системи, визначаються потреби в ресурсах;

- здійснюється дослідницька експлуатація (бета-тестування), при якій перевіряється відповідність розробленої системи її специфікаціям.

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

8. Експлуатація

На етапі експлуатації вирішуються такі задачі:

- контроль продуктивності роботи системи і в разі потреби підвищення продуктивності (наприклад за рахунок створення додаткових індексів);

- супроводження і модернізація застосувань БД;

- профілактичне обслуговування (резервне копіювання);

- корегуюче обслуговування (відновлення БД);

- призначення прав доступу для нових користувачів;

- ведення статистики доступу до БД для підвищення ефективності роботи системи;

- періодична перевірка безпеки;

- періодичні зведення використання системи.

2. Концептуальне проектування баз даних

2.1. Концептуальні моделі

З концептуального проектування починається створення концептуальної схеми БД, в основі якої лежить концептуальна модель даних. Концептуальна модель представляє загальний погляд на дані. Розрізняють два головних підходи до моделювання даних при концептуальному проектуванні:

- семантичні моделі;

- об'єктні моделі.

Семантичні моделі головну увагу приділяють структурі даних. Найбільш поширеною семантичною моделлю є модель «сутність – зв'язок» (Entity Relationship model, ER-модель). ER-модель складається із сутностей, зв'язків, атрибутів, доменів атрибутів, ключів. Моделювання даних відображає логічну структуру даних, так само, як блок-схеми алгоритмів відображають логічну структуру програми.

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

Зближення цих моделей реалізується в розширеному ER- моделюванні (Extended Entity Relationship model, EER-модель).

2.2. Модель «сутність-зв'язок»

ER-моделювання являє собою низхідний підхід до проектування БД, який починається з визначення найбільш важливих даних, які називаються сутностями (entities), і зв'язків (relationships) між даними, які повинні бути представлені в моделі. Потім в модель заноситься інформація про властивості сутностей і зв'язків, яка називається атрибутами (attributes), а також всі обмеження, які відносяться до сутностей, зв'язків і атрибутів. ER-модель дає графічне представлення логічних об'єктів і їх відношень в структурі БД. Послідовність проведення ER-моделювання показана на рис. 2.1.

Описание: image2

Рис. 2.1. Етапи побудови моделі «сутність - зв'язок»

Вперше поняття ЕR-моделі запровадив П.Чен. Підхід П.Чена дозволив концептуальне моделювання перевести в практичну площину проектування БД. У подальшому діаграми Чена набули розвитку у багатьох інших роботах з ЕR - моделювання. До них належать такі моделі:

- «пташина лапка», розроблена К.М. Бахманом;

- IDEF1X, розроблена Т.Ремеєм;

- на основі UML;

- модель Баркера і багато інших моделей.

Сутності

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

Приклад. Сутність Викладач може мати такі атрибути: Табельний номер, Прізвище, Ім'я, По батькові, Посада, Вчений ступінь.

Набір атрибутів, що однозначно ідентифікує конкретний екземпляр сутності, називають ключовим. У наведеному прикладі для сутності Викладач ключем буде Табельний номер, оскільки для всіх викладачів табельні номери різні. Екземпляром сутності Викладач буде опис конкретного викладача. Загальноприйняте позначення сутності – прямокутник (рис. 2.2).

Рис. 2.2. Представлення сутностей і атрибутів у ER-діаграмах П. Чена і ER-діаграмах «пташина лапка»

Зв'язки

Між сутностями встановлюються зв'язки, які вказують яким чином сутності співвідносяться або взаємодіють між собою. Розрізняють такі зв'язки:

- між двома сутностями (бінарний зв'язок);

- між трьома сутностями (тернарний зв'язок);

- між N сутностями (N-арний зв'язок);

- між однією сутністю (рекурсивний зв'язок).

Найбільш поширеними є бінарні зв'язки. Зв'язок показує яким чином екземпляри сутностей зв'язані між собою. Бінарні зв'язки бувають:

- 1:1 (один до одного);

- 1:М (один до багатьох);

- N:М (багато до багатьох).

На рис. 2.3, 2.4 показані відображення цих зв'язків у різних ЕR-моделях.

Рис. 2.3. Представлення зв'язків між відношеннями на діаграмі Чена:

а –1:1; б – 1:М; в – N:M

Рис. 2.4. Представлення зв'язків між відношеннями на діаграмі «пташина лапка»:

а -1:1; б - 1:М; в – N:М

Атрибути

Атрибути являють собою властивості сутності. Значення кожного атрибута вибирають з відповідної множини значень, яка включає всі потенційні значення, які можуть бути присвоєні атрибуту. Ця множина значень називається доменом.

Приклад. Атрибут Оцінка може приймати чотири значення: 2, 3, 4, 5. Ці значення і складають домен цього атрибута.

Атрибути залежно від складності значень, які вони можуть приймати поділяються на певні категорії (табл. 2.1).

Таблиця 2.1. Типи атрибутів

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

Приклад. Розглянемо сутність Студент (рис. 2.5).

Рис. 2.5. ER-діаграма сутності Студент

Атрибути номер залікової книжки, рік народження є простими.

Атрибути ПІБ і Адреса є складовими. ПІБ може бути поділений на атрибути: прізвище, ім'я, по батькові, а Адреса – на індекс, місто, вулиця, будівля, квартира.

Атрибут Вік є похідним: він обчислюється за значенням атрибута Рік народження (зображається пунктирною лінією).

Атрибут Номер залікової книжки є однозначним: він не може приймати два значення для одного студента.

Атрибут Номер телефону є багатозначним: він може приймати декілька значень для одного студента (зображається подвійною лінією).

Атрибут або набір атрибутів сутності, які застосовуються для ідентифікації екземпляра сутності, називаються потенційним ключем. Сутність може містити декілька потенційних ключів. В прикладі в якості потенційних ключів можуть бути такі атрибути: Номер залікової книжки, Прізвище Ім'я по Батькові.

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

Потужність зв'язків

Потужність зв'язку (кардинальність) відображає певне число екземплярів сутностей, які зв'язані з одним екземпляром зв'язаної сутності. В моделі Чена потужність зв'язку відображається вказівкою відповідних чисел поруч з сутностями у форматі (х, у). Перше число визначає мінімальне значення потужності зв'язку, а друге – його максимальне значення. Потужність вказує на число екземплярів у зв'язаній сутності.

Відомості про максимальне і мінімальне значення потужності зв'язку може застосовуватися у прикладному програмному забезпеченні або за допомогою тригерів; на рівні таблиць СКБД не може оперувати з потужністю зв'язків.

Приклад. Розглянемо зв'язок Група-Студент (рис. 2.6).

Рис. 2.6. Зв'язок і потужність в ER-діаграмах

Потужність (1,30) поруч із сутністю Група вказує, що в групі може займатися від 1 до 30 студентів. Потужність (1,1) поруч із сутністю Студент вказує, що студент може займатися тільки в одній групі (мінімум 1, максимум 1). У моделі «пташина лапка» числовий діапазон значень потужності не відображається в ER-діаграмах.

Сильні і слабкі зв'язки

Якщо сутність може існувати незалежно від інших сутностей, то вона є незалежною від існування. Якщо сутність залежить від існування інших сутностей, то вона є залежною від існування. Наприклад, сутності Студент і Група можуть існувати незалежно одна від одної, а сутність Нагорода студента є залежною від сутності Студент й існувати без неї не може.

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

Ідентифікаційний зв'язок або сильний зв'язок має місце у тому випадку, коли одна зв'язана сутність залежить від існування іншої. На ER-діаграмах «пташина лапка» сильний зв'язок відображається суцільною лінією.

Приклад. Розглянемо зв'язки Група-Студент і Студент-Нагорода (рис. 2.7).

Рис. 2.7 Неідентифікаційний (а) та ідентифікаційний (б) зв'язки

Сутність Студент не залежить від сутності Група, в цьому випадку зв'язок між сутностями відображається штриховою лінією, а атрибут Назва групи в сутності Студент є зовнішнім ключем (Foreign Key, FK).

Сутність Нагорода залежить від сутності Студент, в цьому випадку зв'язок між сутностями відображається суцільною лінією, а атрибут Прізвище студента в сутності Нагорода є частиною первинного ключа (Primary Key, PK) і одночасно зовнішнім ключем (FK).

Контрольні запитання:

1. Розкажіть про життєвий цикл розробки бази даних.

2. Опишіть підходи до проектування бази даних.

3. ER-моделювання як низхідний підхід до проектування БД.

4. Дайте х-ку моделі «сутність-зв'язок».

5. Сутності та зв’язки у процесі розробки бази даних.