Міністерство освіти і науки України
Національний університет "Львівська політехніка"

“Інфологічне проектування бази даних”
Методичні вказівки до лабораторного заняття з дисципліни
“Бази даних в інформаційно-комп'ютерних технологіях”
для студентів базового напрямку 6.091 “Електронні апарати”
Затверджено на засіданні кафедри ЕЗІКТ
Протокол № ___ від ___ ______ 2006 р.
Львів - 2006
Інфологічне проектування бази даних. Методичні вказівки до лабораторного заняття з дисципліни "Бази даних в інформаційно-комп'ютерних технологіях” для студентів базового напрямку 6.091 “Електронні апарати”/ Укл. Л.К.Гліненко.-Львів; Вид-во Нац. ун-ту "Львівська політехика" , 2006. - 24 с.
Укладач: Л.К.Гліненко, канд. техн. наук, доц.
Відповідальний за випуск – Г.В.Юрчик , канд. техн. наук, доц.
Рецензенти: О.М.Воблий, канд. техн. наук, доц.
І.В.Атаманова, канд. техн. наук, доц.
ІНФОЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
1. Мета роботи
Вивчення задач та основних кроків і практичне виконання етапу інфологічного проектування бази даних.
2. Теоретичні відомості
2.1. Моделі баз даних
Висока продуктивність СУБД дозволяє ефективно експлуатувати дані у тому випадку, якщо структури даних коректні з точки зору даної СУБД та вимог користувача. Тому проектування БД є основним етапом створення БД.
Процес проектування БД спрощується при застосуванні моделей. Моделі являють собою спрощені абстракції реальних подій та умов, які дають змогу досліджувати характеристики логічних об'єктів (сутностей) та відношень, що можуть між ними створюватися. Якщо моделі не будуть логічно вірними та коректними, то отриманий на їх основі проект БД не буде відповідати вимогам ефективності обробки інформації. Ефективна техніка моделювання даних є передумовою створення ефективно спроектованої БД, що, своєю чергою, є передумовою створення ефективних додатків. І навпаки.
Модель бази даних – це сукупність логічних конструкцій, що застосовується для представлення структури даних та відношень між ними всередині БД. Моделі баз даних підрозділяються на дві категорії: концептуальні моделі та моделі реалізації.
Національний інститут стандартизації США виділяє три різних моделі даних у відповідності з рівнями абстракції: концептуальну, зовнішню та внутрішню. Для відбиття проблем реалізації БД, специфічних для обраної СУБД у внутрішній моделі, до цих рівнів абстракції додається ще один – фізичний.
Концептуальна (понятійна) модель відбиває логічну природу представлених даних, представлення про дані з погляду основних користувачів. Тому у концептуальній моделі основна увага приділяється тому, що представлене у БД, а не тому, як воно представлене. Ця модель відбиває семантику даних, тобто основні логічні об'єкти (сутності) моделі даних, та зв'язки між ними, необхідні та достатні для ефективного застосування інформації з точки зору користувача. Концептуальна модель задає структуру даних на рівні “сутність-зв'язок”; відповідно до концептуальних моделей відносять моделі “сутність-зв'язок” (ER-моделі), у яких об'єкт (сутність) задається її атрибутами, та об'єктно-орієнтовані моделі, у яких об'єкт складається з атрибутів та методів. Оскільки створення концептуальної моделі є метою інфологічного етапу проектування БД, то цю модель деколи називають інфологічною. Деколи як окремий етап інфологічного проектування виділяють побудову користувацької моделі, тобто опису вимог до змісту та операцій з даними з точки зору користувачів БД.
Модель реалізації, на відміну від концептуальної, націлена на відбиття способу представлення (синтаксису) даних у БД. Вона відбиває те, яким чином мають бути реалізовані структури даних, щоб отримати уявлення про те, що ми моделюємо, тобто адекватно відбити семантику моделі. До моделей реалізації БД відносять ієрархічну, мережеву, реляційну та об'єктно-орієнтовану моделі. Створення моделі реалізації БД на рівні певного типу та конкретної СУБД, чи логічної моделі, є метою етапу логічного проектування БД, а у випадку ієрархічних та мережевих БД – і фізичного.
Моделі реалізації за рівнем абстракції підрозділяються на внутрішні, зовнішні та фізичні моделі даних. Внутрішня модель є результатом адаптації концептуальної моделі до обраної СУБД. Іншими словами, внутрішня модель є представленням БД “з поляду” СУБД. Внутрішня модель вимагає, щоб проектувальник привів властивості та обмеження концептуальної моделі у відповідність з обраною моделлю реалізації бази даних. Оскільки, на відміну від концептуальної моделі, внутрішня модель залежить від специфічного програмного забезпечення, вона є програмно залежною.
Зовнішня модель базується на внутрішній і відбиває представлення кінцевого користувача про конфігурацію даних, де під кінцевими користувачами розуміють людей, що застосовують та розробляють прикладні програми. Кінцеві користувачі оперують додатками у певних підрозділах організації. У кожному підрозділі є власна специфіка, система обмежень та вимог, і у кожному з них використовується певна підмножина інформаційного середовища підприємства. Відповідно, прикладні програмісти, що працюють у різних підрозділах, розглядають свою підмножину даних окремо від внутрішньої моделі (як зовнішнє стосовно неї), з якої вони були отримані. Тому з точки зору прикладного програміста бажано, щоб спеціалісти з моделювання всю множину вимог та обмежень розбивали на функціональні модулі, які можна досліджувати в межах структури зовнішніх моделей. У кожну зовнішню модель включаються всі необхідні сутності, зв'язки, процеси та обмеження, визначені даним підрозділом. Зовнішня модель є підмножиною внутрішньої. При цьому, хоча представлення (views) ізольовані один від одного, вони сумісно використовують спільну сутність.
Фізична модель діє на найнижчому рівні абстракції, описуючи способи зберігання інформації на носіях, наприклад, жорстких дисках. Фізична модель вимагає визначення як пристрою фізичного зберігання, так і методу фізичного доступу, необхідного для отримання даних з фізичного носія. Очевидно, що фізична модель є як програмно, так і апаратно залежною. Використовувані структури зберігання залежать від пограмного забезпечення (СУБД, операційна система) та від типу носія, що підтримується комп'ютером. Вибір певного методу доступу до даних дає змогу оптимізувати роботу з БД кожного типу, проте реляційна модель в основному орієнтована на логічний рівень представлення і переважно не вимагає такого детального фізичного моделювання, як БД ієрархічного та мережевого типів.
2.2. Інфологічні моделі
Інфологічний етап проектування БД. Мета інфологічного етапу проектування полягає в одержанні семантичних (концептуальних) моделей, що відбивають предметну область і інформаційні потреби користувачів, поняття про предмети, факти і події, якими буде оперувати дана інформаційна система. Як інструмент для побудови семантичних моделей даних та уніфікованого представлення даних, незалежного від реалізуючого його програмного забезпечення, на етапі інфологічного проектування застосовується неформальна модель "сутність-зв'язок" (entity-relationship model, ER - model). Модель "сутність-зв'язок" ґрунтується на опорній семантичній інформації про реальний світ і призначена для логічного представлення даних у контексті їхнього взаємозв'язку з іншими даними. З моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережна, реляційна, об'єктна), тому вона є найбільш загальною.
Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. Модель "сутність-зв'язок" не визначає операцій над даними й обмежується описом тільки їхньої логічної структури.
Основні елементи інфологічних моделей. Основними поняттями ER-моделі є сутність, зв'язок і атрибут. При інфологічному проектуванні бази даних довільний фрагмент предметної області може представляють як множину сутностей, між якими існує деяка множина зв'язків.
Сутність (entity) - це об'єкт, що може бути ідентифікований деяким способом, що відрізняє його від інших об'єктів, це реальний чи уявний об'єкт предметної області, інформація про який повинна зберігатися у базі даних і бути доступною. Приклади: конкретна людина, підприємство, подія і т.д.
Розрізняють такі поняття, як тип (клас) сутності й екземпляр сутності. Набір (тип) сутностей (entity set) - множина сутностей одного типу (тобто сутностей, що мають однакові властивості). Поняття тип сутності відноситься до набору однорідних предметів, подій, осіб, що виступають як єдине ціле. Приклади: усі люди, підприємства, свята і т.д. Набори сутностей не обов'язково повинні бути такими, що не перетинаються. Наприклад, сутність, що належить до набору ЧОЛОВІК, також належить набору ЛЮДИ. Екземпляр сутності відноситься до конкретного об'єкту в наборі. Представлення сутності у діаграмах моделей БД залежить від обраної нотації. У діаграмах ER-моделі сутність представляється у вигляді прямокутника (у нотації Баркера), що містить ім'я сутності. При застосуванні нотацій Чена т