ЛАБОРАТОРНА РОБОТА

Проектування бд

Мета роботи: набути вміння аналізувати предметну область (ПО) інформаційної системи і на основі аналізу створювати концептуальну, логічну моделі майбутньої бази даних.

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

Основні поняття

Автоматизована інформаційна система (АІС) - це комплекс програмних і технічних засобів, що забезпечують збір, обробку і маніпулювання даними.

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

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

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

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

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

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

Основними конструктивними елементами інфологічних моделей є сутності, зв'язки між ними і їх атрибути (властивості).

Сутність (інформаційний об'єкт) (ІО) - будь-який конкретний (реальний) або абстрактний об'єкт у розглянутій ПО.

Зв'язок - спостережуваний взаємозв'язок (асоціація) між сутностями. Для представлення концептуальної моделі використовують різні методи і моделі, наприклад, модель "сутність" - "атрибут" - "зв'язок" (EAR) описує ПО на концептуальному рівні у вигляді EAR-діаграм. У них сутності позначаються прямокутниками, асоціації (характери об'єднання сутностей) - ромбами або шестикутниками, атрибути - овалами, а зв'язки між ними - ребрами, над якими проставляються типи зв'язків.

Між сутностями можливі чотири типи зв'язків: один - до одного (1 ↔ 1), один - до багатьох (1 ↔ ∞), багато хто - до одного (∞ ↔ 1), багато хто - до багатьох (∞ ↔ ∞).

Зв'язок 1 ↔ 1: у будь-який момент часу кожному примірнику першого ІО відповідає 1 або 0 екземплярів іншого ІО і навпаки.

Зв'язок 1 ↔ ∞: одному примірнику першого ІО відповідає 0,1,2, ... примірників іншого і навпаки, кожному екземпляру другого ІО відповідає 0 або 1 екземпляр першого ІО. Аналогічно визначається тип зв'язку ∞ ↔ 1.

Зв'язок ∞ ↔ ∞: одному примірнику першого ІО відповідає 0,1,2, ... примірників іншого ІО і навпаки.

Приклади: 1. Студент 1 ↔ 1 Сесія: кожен студент має певний набір екзаменаційних оцінок в сесію. Мається на увазі ІО Сесія як набір оцінок за поточний семестр.

2. Стипендія 1 ↔ ∞ Студент: вигляд (і сума) стипендії може багаторазово повторюватися для різних студентів за результатами сесії.

3. Студент ∞ ↔ ∞ Викладач: один студент навчається у багатьох викладачів і навпаки, один викладач навчає багатьох студентів.

Концептуальна модель застосовується для структурування ПО з урахуванням інформаційних інтересів користувачів ІС, вона не залежить ні від програмних, ні від технічних рішень.

Розглянемо приклад: проектування БД ІС "Бухгалтерський облік на підприємстві". Фрагмент концептуальної моделі, відповідної підсистемі "Розрахунки з контрагентами" 1 у вигляді EAR-діаграм "сутність" - "атрибут" - "зв'язок", представлений на рис. 1. У результаті аналізу ПО виділено чотири ІО (План рахунків, Контрагенти, Валюти, Журнал господарських операцій (ЖГО)), їх властивості та зв'язки.

Визначимо зв'язки між сутностями:

Назва зв’язку	Тип	Зв'язок між сутностями
Реєстрація операції	1 ↔ ∞	Контрагенти, ЖГО
Віднесення операції на рахунок	1 ↔ ∞	План рахунків, ЖГО
Валютний облік (грошове вираження)	1 ↔ ∞	Валюти, ЖГО

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

Рис. 1. Фрагмент концептуальної моделі ПО

“Бухгалтерський облік на підприємстві”

ЕТАП ЛОГІЧНОГО ПРОЕКТУВАННЯ

Основним завданням логічного проектування є розробка логічної схеми (моделі), орієнтованої на обрану систему управління базами даних (СКБД).

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

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

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

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

Процес логічного проектування складається з наступних дій:

- Вибір конкретної СУБД;

- Відображення концептуальної схеми на логічну схему, отримання логічної МД, відповідної зовнішньому рівнем архітектури будь-якої автоматизованої ІС;

- Вибір ключів;

- Опис мови запитів.

При відображенні концептуальної МД ПО на реляційну МД кожен прямокутник схеми (рис. 1) - інформаційний об'єкт перетворюється в таблицю (відношення). Теорія конструювання реляційних БД розроблена доктором Є.Ф. Коддом в 1968 р. Сформульовані ним 13 правил повністю реалізовані в реляційній СУБД MS Access. Ним же введені основні поняття реляційної БД, якими є: "тип даних", "домен", "атрибут", "кортеж", "первинний ключ", "відношення".

Поняття "тип даних" в реляційній МД цілком адекватно поняттю типу даних в мовах програмування.

Розглянемо відношення "План рахунків" (мал. 2).

Рис. 2. Відношення "План рахунків"

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

Схема відношення - це іменоване безліч пар (ім'я атрибута, ім'я домену). Ступінь або "арності" схеми відносини - потужність цієї множини. Ступінь відносини "План рахунків" дорівнює 5.

Кортеж, відповідний даній схемі відносини, - це множина пар (ім'я атрибута, значення), яке містить одне входження кожного імені атрибута, що належить схемою відносини, а "значення" - допустиме значення домену даного атрибуту.

Відношення – це безліч кортежів, відповідних однією схемою.

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

Доктор Є.Ф. Коддом ввів поняття реляційної алгебри (РА) і реляційного числення (РІ).

РА - сукупність безлічі відносин і безлічі операцій над ними. З точки зору обробки інформації РА є процедурним мовою обробки реляційних таблиць, що забезпечує покрокове рішення завдань. РІ - непроцедурна мова, що дозволяє формулювати, що потрібно зробити, а не як. Наприклад, в РІ запит створюється шляхом визначення таблиці (бланка) запиту за один крок. Є.Ф. Коддом показав, що поняття РА і РІ логічно еквівалентні, що надзвичайно важливо. Це означає, що будь-який запит, який можна сформулювати за допомогою РІ, також можна сформулювати, користуючись РА, і навпаки.