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

“Логічне проектування бази даних”
Методичні вказівки до лабораторного заняття з дисципліни
“Бази даних в інформаційно-комп'ютерних технологіях”
для студентів базового напрямку 6.091 “Електронні апарати”
Затверджено на засіданні кафедри ЕЗІКТ
Протокол № ___ від ___ ______ 2006 р.
Львів 2005
Логічне проектування бази даних. Методичні вказівки до лабораторного заняття з дисципліни "Бази даних в інформаційно-комп'ютерних технологіях” для студентів базового напрямку 6.091 “Електронні апарати”/ Укл. Л.К.Гліненко.-Львів; Вид-во Нац. ун-ту "Львівська політехика" , 2006. - 28 с.
Укладач: Л.К.Гліненко, канд. техн. наук, доц.
Відповідальний за випуск – Г.В.Юрчик , канд. техн. наук, доц.
Рецензенти: О.М.Воблий, канд. техн. наук, доц.
І.В.Атаманова, канд. техн. наук, доц.
ЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
1. Мета роботи
Вивчення задач та основних кроків і практичне виконання етапу логічного проектування бази даних та створення логічної моделі спроектованої логічної бази даних засобами Microsoft Visio у відповідності з вимогами наявної СУБД
2. Теоретичні відомості
2.1. Логічне проектування баз даних
Мета логічного етапу проектування - організація даних, виділених на етапі інфологічного проектування у форму, прийняту в обраній СУБД. Задачею логічного етапу проектування є відображення об'єктів предметної області в об'єкти використовуваної моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості найкращим (ефективним, зручним і т.д.). З погляду обраної СУБД задача логічного проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те:
з яких відношень (таблиць) повинна складатися база даних;
які атрибути повинні бути в цих відношень;
як забезпечити виконання вимог до реляційної БД;
як позбутися суперечливості та надлишковості даних;
які обмеження повинні бути накладені на атрибути і відносини бази даних, щоб забезпечити її цілісність.
2.2. Рівні логічної моделі реляційної БД
Розрізняють три рівні логічної моделі для БД реляційного типу, що відрізняються по глибині представлення інформації про дані:
діаграма сутність-зв'язок (Entity Relationship Diagram, ERD);
модель даних, заснований на ключах (Key Based model, KB);
повна атрибутивна модель (Fully Attributed model, FA).
Діаграма сутність-зв'язок являє собою модель даних верхнього рівня. Вона містить сутності і взаємозв'язки, що відбивають основні бізнес-правила предметної області. Така діаграма не занадто деталізована, у неї включаються основні сутності і зв'язки між ними, що задовольняють основним вимогам, пропонованим до ІС. Сутності представляються у вигляді таблиць, чи, як їх інакше називають, відношень, що містять назву сутності на логічному рівні та перелік імен доменів (атрибутів), що ідентифікують сутність. Діаграма сутність-зв'язок може включати зв'язки багато до багатьох і не включати опис ключів. Як правило, ERD використовується для презентацій і обговорення структури даних з експертами предметної області.
Модель даних, заснована на ключах, - більш докладне представлення даних. Вона включає опис усіх сутностей і первинних ключів і призначена для представлення структури даних і ключів, що відповідають предметній області. В такій моделі є змога перевірки забезпечення цілісності за сутностями і за посиланнями.
Повна атрибутивна модель - найбільш детальне представлення структури даних. Вона представляє дані в третій або вищих нормальних формах і включає всі сутності, атрибути і зв'язки.
Основні компоненти ER-діаграми - це сутності, атрибути і зв'язки. Кожна сутність є множиною подібних індивідуальних об'єктів, називаних екземплярами. Кожен екземпляр індивідуальний і повинен відрізнятися від всіх інших екземплярів. Атрибут виражає певну властивість об'єкта. З погляду реляційної БД сутності відповідає таблиця, екземпляру сутності - рядок у таблиці, а атрибуту - стовпець таблиці.
Побудова моделі даних передбачає визначення сутностей і атрибутів, тобто необхідно визначити, яка інформація буде зберігатися в конкретній сутності чи атрибуті. Сутність можна визначити як об'єкт, подію чи концепцію, інформація про які повинна зберігатися. Сутності повинні мати найменування з чітким змістовним значенням, іменуватися іменником в однині, не носити "технічних" найменувань і бути досить важливими для того, щоб їх моделювати. Іменування сутності в однині полегшує надалі читання моделі. Фактично ім'я сутності дається по імені її екземпляра. Прикладом може бути сутність Замовник (але не Замовники!) з атрибутами Номер замовника, Прізвище замовника й Адреса замовника. На рівні логічної моделі їй може відповідати таблиця Customer (Замовник) з колонками Customer_number (Замовник_Номер), Customer_name (Замовник_Ім'я) і Customer_address (Замовник_Адреса).
Для внесення сутності в модель при розробці її в Microsoft Visio, як і в багатьох інших CASE-засобах, необхідно "активувати" форму сутності на панелі шаблону Entity Relationship та перетягнути її на ті місце на діаграмі, де необхідно розташувати нову сутність. Клацнувши правою кнопкою миші по сутності і вибравши зі спливаючого меню пункт Set Entity Name, можна викликати діалог Custom Properties, у якому визначаються ім'я, тип і визначення (опис) сутності. Кожна сутність може бути цілком визначена за допомогою текстового опису у вкладці Dеfіnе. Вкладка Dеfіnе використовується для уведення визначення сутності. Ці визначення корисні як на логічному рівні, оскільки дозволяють зрозуміти, що це за об'єкт, так і на фізичному рівні, оскільки їх можна експортувати як частину схеми і використовувати в реальної БД (CREATE COMMENT on entity_name).
Вимоги до обраного набору відношень і складу їхніх атрибутів повинні задовольняти наступним умовам:
відношення повинні відрізнятися мінімальною надмірністю атрибутів;
обрані для відношення первинні ключі повинні бути мінімальними;
між атрибутами не повинне бути небажаних функціональних залежностей;
вибір відношень і атрибутів повинен забезпечувати мінімальне дублювання даних;
не повинно бути труднощів при виконанні операцій включення, видалення і модифікації даних;
час виконання запитів на вибірку даних повинен задовольняти пропонованим вимогам;
перебудова набору відношень при введенні нових типів повинна бути мінімальною та по можливості автоматичною.
Задоволення відзначених вимог забезпечується апаратом нормалізації відношень. Нормалізація відносин - це покроковий оборотний процес композиції чи декомпозиції вихідних відносин у відносини, що мають кращі властивості при включенні, зміні і видаленні даних, призначення їм ключів за визначеними правилами нормалізації і виявлення всіх можливих функціональних залежностей.
2.3. Одержання реляційної схеми бази даних з ER-діаграми
Процес одержання реляційної схеми бази даних з ER-діаграми містить наступні кроки.
Кожна проста сутність перетворюється у відношення. Проста сутність - сутність, що не є підтипом і не має підтипів. Ім'я сутності стає іменем відношення.
Кожен багатозначний атрибут породжує або набір багатозначних атрибутів, або нову сутність, складену з компонентів багатозначного атрибуту. При цьому ця сутність може бути асоційованою, зв'язуючи дві нові сутності, одна з яких часто є незалежною, друга – залежною. З вихідною сутністю нова сутність зв'язується зв'язком 1:М.
Кожен однозначний атрибут стає стовпцем з тим же іменем; може вибиратися більш точний формат виходячи з можливостей СУБД. Стовпці, що відповідають необов'язковим атрибутам, можуть містити невизначені значення; стовпці, що відповідають обов'язковим атрибутам, - не можуть.
Компоненти унікального ідентифікатора сутності перетворюються в первинний ключ відношення. Якщо є кілька можливих унікальних ідентифікаторів, вибирається найбільш використовуваний.
Зв'язки M:1 (і 1:1) стають зовнішніми ключами. Для цього робиться копія унікального ідентифікатора із кінця зв'язку "один" і відповідні стовпці утворюють зовнішній ключ. Необов'язкові зв'язки відповідають стовпцям, що допускають невизначені значення; обов'язкові зв'язки - стовпцям, що не допускають невизначених значень.
У таблицях, побудованих на основі асоціацій, зовнішні ключі використовуються для ідентифікації учасників асоціації, а в таблицях, побудованих на основі характеристик і позначень, - для ідентифікації сутностей, описуваних цими характеристиками і позначеннями. Обмеження, пов'язані з кожним з цих зовнішніх ключів, підлягають окремій специфікації.
Якщо в концептуальній схемі були присутні підтипи, то можливі два способи їх обробки:
а) усі підтипи розташувати в одній таблиці;
б) для кожного підтипу побудувати окрему таблицю.
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертипу. У таблицю додається принаймні один стовпець, що містить код ТИПУ, і він стає частиною первинного ключа. Для роботи з підтипами можуть створюватися представлення. При використанні методу (б) супертип відтворюєтьс