Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Логічне проектування бази даних
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Електронні апарати
Кафедра:
Не вказано
Інформація про роботу
Рік:
2005
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Бази даних в інформаційно-комп'ютерних технологіях
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет "Львівська політехніка"
EMBED Word.Picture.6
“Логічне проектування бази даних”
Методичні вказівки до лабораторного заняття з дисципліни
“Бази даних в інформаційно-комп'ютерних технологіях”
для студентів базового напрямку 6.091 “Електронні апарати”
Затверджено на засіданні кафедри ЕЗІКТ
Протокол № ___ від ___ ______ 2006 р.
Львів 2005
Логічне проектування бази даних. Методичні вказівки до лабораторного заняття з дисципліни "Бази даних в інформаційно-комп'ютерних технологіях” для студентів базового напрямку 6.091 “Електронні апарати”/ Укл. Л.К.Гліненко.-Львів; Вид-во Нац. ун-ту "Львівська політехика" , 2006. - 28 с.
Укладач: Л.К.Гліненко, канд. техн. наук, доц.
Відповідальний за випуск – Г.В.Юрчик , канд. техн. наук, доц.
Рецензенти: О.М.Воблий, канд. техн. наук, доц.
І.В.Атаманова, канд. техн. наук, доц.
ЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
1. Мета роботи
Вивчення задач та основних кроків і практичне виконання етапу логічного проектування бази даних та створення логічної моделі спроектованої логічної бази даних засобами Microsoft Visio у відповідності з вимогами наявної СУБД
2. Теоретичні відомості
2.1. Логічне проектування баз даних
Мета логічного етапу проектування - організація даних, виділених на етапі інфологічного проектування у форму, прийняту в обраній СУБД Слід зазначити, що деякі CASE-засоби, зокрема, програмний продукт ErWin та PowerBuilder, застосовують дещо іншу термінологію стосовно різновидів моделей БД та етапів проектування. Зокрема, використовується поняття побудови моделі на логічному і на фізичному рівні, причому при моделюванні на логічному рівні дані представляються так, як виглядають у реальному світі, і можуть називатися так, як вони називаються в реальному світі, наприклад "Постійний клієнт", "Відділ" чи "Прізвище співробітника". Об'єкти моделі, що представляються на логічному рівні, називаються сутностями й атрибутами. Логічна модель даних може бути побудована на основі іншої логічної моделі, наприклад на основі моделі процесів. Логічна модель даних у ErWin є універсальної і ніяк не зв'язана з конкретною реалізацією СУБД, а залежить лише від типу обраної СУБД.
Фізична модель даних, навпроти, залежить від конкретної СУБД, фактично будучи відображенням системного каталогу. У фізичній моделі міститься інформація про всі об'єкти БД. Оскільки стандартів на об'єкти БД не існує (наприклад, немає стандарту на типи даних), фізична модель залежить від конкретної реалізації СУБД. Отже, однієї і тієї ж логічної моделі можуть відповідати кілька різних фізичних моделей. Якщо в логічній моделі не має значення, який конкретно тип даних має атрибут, то у фізичній моделі важливо описати всю інформацію про конкретні фізичні об'єкти - таблицях, колонках, індексах, процедурах і т.д. Поділ моделі даних на логічні і фізичні дозволяє вирішити кілька важливих задач.
. Задачею логічного етапу проектування є відображення об'єктів предметної області в об'єкти використовуваної моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості найкращим (ефективним, зручним і т.д.). З погляду обраної СУБД задача логічного проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те:
з яких відношень (таблиць) повинна складатися база даних;
які атрибути повинні бути в цих відношень;
як забезпечити виконання вимог до реляційної БД;
як позбутися суперечливості та надлишковості даних;
які обмеження повинні бути накладені на атрибути і відносини бази даних, щоб забезпечити її цілісність.
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) стають зовнішніми ключами. Для цього робиться копія унікального ідентифікатора із кінця зв'язку "один" і відповідні стовпці утворюють зовнішній ключ. Необов'язкові зв'язки відповідають стовпцям, що допускають невизначені значення; обов'язкові зв'язки - стовпцям, що не допускають невизначених значень.
У таблицях, побудованих на основі асоціацій, зовнішні ключі використовуються для ідентифікації учасників асоціації, а в таблицях, побудованих на основі характеристик і позначень, - для ідентифікації сутностей, описуваних цими характеристиками і позначеннями. Обмеження, пов'язані з кожним з цих зовнішніх ключів, підлягають окремій специфікації.
Якщо в концептуальній схемі були присутні підтипи, то можливі два способи їх обробки:
а) усі підтипи розташувати в одній таблиці;
б) для кожного підтипу побудувати окрему таблицю.
При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертипу. У таблицю додається принаймні один стовпець, що містить код ТИПУ, і він стає частиною первинного ключа. Для роботи з підтипами можуть створюватися представлення. При використанні методу (б) супертип відтворюється за допомогою конструкції UNION.
2.4. Забезпечення цілісності даних
При обробці даних необхідна гарантія збереження цілісності даних у базі, тому важливим етапом проектування реляційної бази даних є забезпечення цілісності бази даних.
Виділяють три групи правил цілісності:
цілісність по сутностях;
цілісність по посиланнях;
цілісність, обумовлена користувачем.
Забезпечення цілісності бази даних забезпечується завданням обмежень цілісності. Обмеження цілісності - це деяке твердження, що може бути правдивим чи хибним в залежності від стану бази даних. Правила цілісності на різних рівнях наведені у таблиці 1.
За способами реалізації обмеження цілісності поділяються на:
декларативні, виконувані засобами мови SQL;
процедурні, виконувані за допомогою тригерів і збережених процедур.
При виконанні цієї лабораторної роботи в процесі побудови реляційної моделі даних повинні бути забезпечені декларативні обмеження цілісності. Декларативні обмеження цілісності повинні забезпечувати:
завдання первинних ключів для забезпечення цілісності по сутностях;
визначення необхідних зовнішніх ключів для забезпечення цілісності по посиланнях;
завдання невизначених значень і значень за замовчуванням;
контроль функціональних обмежень на значення атрибутів, обумовлених вимогами предметної області;
завдання умов каскадного видалення тощо.
Таблиця 1
Правила цілісності
3. Практична реалізація логічних моделей реляційних баз даних за допомогою Microsoft Visio Professional
3.1. Інструменти Microsoft Visio, що використовуються при роботі з БД
Основним інструментом Microsoft Visio Professional, який підтримує розробку, генерацію та аналіз БД, є шаблон Database Model Diagram.
Він дає змогу розробляти, описувати та аналізувати на логічному рівні графи моделей БД у вигляді, зокрема, ER-діаграм (діаграм “сутність-зв'язок”) для реляційних та об'єктно-реляційних БД, створювати моделі на рівні ключів та повні атрибутивні моделі.
У Microsoft Visio Professional існують 3 основні можливості створення логічних моделей баз даних:
створення діаграм логічної моделі з нуля як документу Microsoft Visio за допомогою шаблонів Database Model Diagram;
виділення і перетягування у Visio схеми даних існуючої БД з наступним її коригуванням або просто дослідженням;
імпортування діаграм логічної моделі БД, створеної в іншій програмі.
Microsoft Visio надає можливість створити логічну моделі БД на рівні:
ER-діаграми (діаграми “сутність-зв'язок”, шаблон “Entity-Relationship”), моделі на рівні ключів та повної атрибутивної моделі для БД реляційного типу;
об'єктно-реляційної діаграми (діаграми “об'єкт-відношення”, шаблон “Entity-Relationship”);
Express_G схеми даних для багаторівневих структур даних в нотації Express (стандарт ISO 10303-11);
ORM-діаграми (Object Role Modeling), тобто моделі БД у вигляді взаємодіючих об'єктів з визначенням ролі кожного з об'єктів (стандарт моделювання даних Object Role Modeling).
Обмеження на маніпулювання даними у моделі можуть задаватися за допомогою тригерів. Крім того, можна сформувати моделі запитів до БЛ.
Для вибору типу БД (реляційна чи об'єктно-реляційна) і типу моделі (ER-діаграмі; ОR-діаграма; ОRМ- чи Express_G схема) необхідно активувати відповідний набір “форм” елементів моделі (сутностей, атрибутів, об'єктів, зв'язків тощо) з їх властивостями, які відрізняються в різних наборах в залежності від обраного типу БД і моделі.
Вибір набору “форм” у Visio еквівалентний вибору типу БД. Він здійснюється клацанням по відповідній команді контекстного меню Database, що розкривається при активованому шаблоні Stencils Database Model Diagram. Для цього меню Файл (File) головної панелі Visio слід обрати команду Stencils (Шаблони) і клацнути по виконати команду Database Model Diagram , клацнувши по відповідній позиції (рис. 2).
3.2. Створення моделі БД інструментами Microsoft Visio
3.2.1. Створення логічної моделі реляційної БД інструментами Microsoft Visio
Створення логічної моделі реляційної БД починається з проектування структури БД на рівні реляційної ER-діаграми. Створення ER-діаграми полягає у табличному представленні основних сутностей користувацької моделі даних, визначенні їх атрибутів та зв'язків між ним з приведеннях цих зв'язків у відповідність з вимогами реляційної БД..
Основним інструментом Microsoft Visio Professional, який підтримує розробку та аналіз БД, є набір шаблон Database. Він дає змогу розробляти, описувати та аналізувати на логічному рівні графи моделей БД у вигляді, зокрема, ER-діаграм (діаграм “сутність-зв'язок”), моделі на рівні ключів та повної атрибутивної моделі для реляційних та об'єктно-реляційних БД. Шаблон Database Model Diagram підтримують табличне представлення сутностей (об'єктів) та їх атрибутів, характерне для розгорнутих варіантів нотацій Мартіна, IDEFIX та Чена, тобто дозволяють створити логічну модель БД. В цьому випадку модель створюється за допомогою шаблону Database Model Diagram. Всі можливості шаблону по створенню моделі БД підтримуватимуться лише у випадку, якщо від початку визначити тип створюваного документу як Модель бази даних (Database Model).
Запуск шаблону Database Model Diagram йде в кілька етапів:
зазначення типу документу Visio як проекту моделі БД.
Для цього в меню Файл (File) головної панелі Visio слід обрати команду New (Створити новий файл) і виконати команду Database, клацнувши по відповідній позиції, або виконати команду вибору типу малюнка (рис. 1). Це рівнозначно вибору типу БД.
Рис. 1. Вибір типу документу при побудові логічної моделі БД (крок 1)
Далі для побудови логічної моделі БД реляційного типу слід обрати тип документу позиції Database Model Diagram (рис. 2).
Рис. 2. Вибір типу документу при побудові логічної моделі БД (крок 2)
виклик шаблону Database Model Diagram.
Це можна зробити після активації типу документу як Database клацанням по позиції Database Model Diagram (рис. 1) або виконавши в меню Файл (File) команду Stencils (Шаблони), підкоманда Database (рис. 3);
Рис. 3. Виклик шаблону Database Model Diagram
вибір типу логічної моделі БД.
3.2.2. Вибір форми представлення діаграми “сутність-зв'язок” логічної моделі реляційної БД при застосуванні шаблону Entity Relationship
В цій роботі розглядається створення логічної моделі БД на основі даних про модельовану систему та раніше створеної інфологічної моделі. Логічна модель реляційного представлення даних БД передбачає представлення сутностей у вигляді реляційних таблиць (відношень) з ідентифікацією елементів таблиць та типів зв'язків (первинна модель БД на рівні сутність-зв'язок), визначення первинних та потенційних ключів і нормалізацію зв'язків з визначенням вторинних ключів (модель на рівні ключів) та ідентифікацію типів даних та встановлення обмежень цілісності (повна атрибутивна модель).
Для цього необхідно створити новий файл БД і відкрити шаблон інструментів Entity Relationship. Після цього на поле діаграми слід перетягнути стільки шаблонів сутностей (Entity), скільки сутностей передбачається у моделі. Якщо не відбувається уточнення моделі даних чи розширення кола користувачів БД, то кількість та назви стрижневих сутностей на логічному рівні збігатимуться з тими ж елементами інфологічної моделі. При застосування цього шаблону сутності, незалежно від обраної нотації, завжди будуть відбиватися у вигляді таблиць (назва таблиці відповідатиме назві сутності, а стовпчики (рядки) таблиці – атрибутом сутності). Оскільки обрано реляційний тип БД.
Інші сутності (асоціативні, характеристичні) слід визначити в ході нормалізації зв'язків.
Представлення зв'язків визначається обраною нотацією.
Шаблон Entity Relationship дозволяє представляти відношення у кількох нотаціях, зокрема, у нотації Чена (relational), у нотації IDEFIX та у нотації „пташина лапа”. Обрання нотації та детальності представлення елементів діаграми здійснюється через діалогове вікно Database Document Options за командою Database → Options → Document (рис. 4).
Рис. 4. Вибір синтаксису логічної моделі БД у Microsoft Visio
При цьому відкриється діалогове вікно Database Document Options, вкладка General (рис. 5).
Рис. 5. Вибір нотації та рівня моделі реалізації БД
Для обрання нотації, в якій представлятимуться сутності і зв'язки, слід в меню Database головної панелі інструментів виконати команду Options → Document, вкладка General і встановити перемикач на одну з двох нотацій: IDEFIX або Relational (нотації Чена або Маріна). Форма представлення відношень виводиться у вікні перегляду.
Нижче групи перемикачів нотацій на вкладці General розташований набір типів імен, що виводиться на сутностях діаграми.
Ми завжди обиратимемо перемикач “Conceptual name”, обрання якого відповідатиме тому, що назва таблиці виводитиметься на екрані як логічна назва сутності, введена у поле Conceptual name вікна Categories при активованій таблиці. По замовчуванню в цьому полі стоїть Entity + номер сутності в порядку перетягування на поле діаграми з шаблону Entity Relationship. У випадку обрання опції Physical name виводитиметься номер сутності (номер таблиці) в порядку перетягування на поле діаграми, що для цілей моделювання незручно.
Conceptual name задає логічне ім'я сутності, не прив'язане до фізичної реалізації БД. При завданні Physical name задаватиметься фізичне ім'я, синтаксис якого буде обмежений можливостями СУБД. Наприклад СУБД Access не дозволяє задавати ім'я Order для сутності, оскільки воно зарезервоване для конкретної процедури; крім того, не бажано застосовувати в назвах дефіс (–) чи пробіл (наприклад, в СУБД Oracle). Аналогічна різниця буде при завданні фізичного і логічного типу даних.
Дані про сутність, що будуть візуалізовані в процесі побудови моделі, визначатимуться встановленням прапорців у вкладці Table цього ж діалогового вікна Database → Options → Document (рис. 6).
Рис. 6. Визначення рівня логічної моделі та форми представлення сутностей (відношень) у логічних моделях реляційних БД
Група прапорців Data Type визначає вибір опису типу даних, яким репрезентований той чи інший атрибут. Вибір прапорця Show portable буде означати виведення біля назви атрибуту логічного типу даних на рівні „дата” (Data), лічильник (Counter), малюнок (Picture) тощо. Вибір прапорця Show physical дозволить виводити біля назви атрибуту назву типу даних у відповідності з підтримуваними SQL, Oracle 8, MS Access стандартами (char 10, integer тощо), що точніше задають тип даних при проектуванні БД.
Вибір прапорця Don’t Show (рекомендовано для першого етапу виконання) лабораторної роботи означатиме, що незалежно від того яка інформація буде введена про тип даних (Data Type) через вікно Categories на полі діаграми вона відображатися не буде.
В групі прапорців Display вкладки Table рекомендовано встановити прапорці проти всіх полів, що відповідатиме виведенню на екран позначок первинного та зовнішнього ключів (primary key, foreign key), та всіх інших атрибутів з графічним структуруванням набору атрибутів та позначенням індексованих атрибутів. Для усвідомлення різниці у представленні можна поміняти значення цих прапорців при побудованій діаграмі і подивитися на отриманий результат.
В наборі перемикачів Order слід обрати перемикач “Primary key at top” (що означає, що перелік атрибутів починається з первинного ключа) і встановити прапорець “Draw seperator line” (атрибут – первинний ключ (позначка РК) відділяється грубою лінією). По замовчанню також встановлюють прапорець “Show” IDEFIX optionality (обов'язковість).
Вибір перемикачів і прапорців на вкладці Relationship цього ж діалогового вікна Database → Options → Document означає остаточний вибір нотації представлення зв'язків (рис. 7).
Рис. 7. Обрання форми представлення зв'язків між відношеннями (таблицями)
В групі прапорців рекомендується встановити прапорці Relationships, Cardinality, Referential integrity для нотації IDEFIX і Чена та Relationship, Cardinality та Referential integrity для нотації „пташина лапа”. В першому випадку напрямок відношення від „дитини” до „батька”, тобто від таблиці, що містить FK, до таблиці, що містить PK. Кардинальність відбивається у позиції Miscellaneous вікна Categories при активованому відношенні (рис. 9) Для нотації Чена окрім цього, відтворюється графічне позначення відношення обраної кардинальності.
Вибір перемикача Display name на позиції Show verb phrase означає виведення на поле діаграми імені зв'язку, тобто дії, що пов'язує залежну чи асоційовану сутність зі стрижневою (прямий зв'язок, при встановленому прапорці Forward text) чи навпаки (зворотний зв'язок при встановленому прапорці Inverse text). Рекомендовано обирати обидва для простих БД і перемикач “Don’t display name” для складних, щоб не затьмарювати модель.
3.2.3. Представлення сутностей у вигляді таблиць
Таблиці, що репрезентують сутності, при побудові ER –моделі БД можна вводити у діаграму моделі, усувати з неї та редагувати, змінюючи властивості сутності.
3.2.3.1. Заповнення та редагування таблиць
Заповнення та редагування таблиць відповідає ідентифікації сутностей та їх атрибутів у моделі БД. Ідентифікація таблиці починається з ідентифікації сутності (її імені), яку одна таблиця репрезентує.
Формально процес ідентифікації сутності та її атрибутів є процесом заповнення таблиці. Він здійснюється через вкладку Categories діалогового вікна Database Properties, яке відкривається після клацання по порожній або редагованій таблиці в нижній частині екрану MS Visio.
Назву сутності слід ввести у поле Conceptual name вікна Definition, яке активується командою Definition у списку Categories. Вона (назва) відтвориться у таблиці на екрані.
Назви та властивості атрибутів відбиваються у стовпцях таблиці і вводяться через поле Column списку Categories вікна Database Properties, активувавши команду Column клацанням по ній (рис. 8).
Рис. 8. Створення повної атрибутивної моделі (ідентифікація атрибутів та типів даних, якими представлені їх значення)
На полі Physical name порожнього рядка, що відкривається, слід встановити курсор і ввести ім’я атрибуту, яке слугуватиме за найменування стовпця. Очевидно, що це ім’я має відповідати обмеженням на найменування полів таблиці.
Далі достатньо натиснути Enter або ↓, і перейти на наступний рядок. Поле (атрибут) буде автоматично добавлено у таблиці. Аналогічний результат буде отриманий при клацанні по клавіші Ctrl.
Ім’я поля (Column) по замовчанню відповідатиме тому, що встановлене у діалоговому вікні Database Modeling Preferences (Database → Modeling → Preferences), тому змінювати його треба вручну, набором з клавіатури у відповідному полі. З комірки у комірку таблиці можна пересуватися за допомогою клавіші Tab.
3.2.3.2. Зазначення типів даних атрибутів
Тип даних для атрибуту визначається у відповідній позиції Data Type у фрагменті таблиці вікна Column, що відповідає даному атрибуту у MS Visio визначає:
тип (характер) даних, які містить поле атрибуту (якими описується атрибут);
типи операцій, які можна здійснювати над цими даними;
інші характеристики атрибуту наприклад, вимоги до збереження.
При введенні типів даних у модель слід обирати ті типи даних, що підтримуються СУБД, в якій буде здійснюватись управління Вашою БД. Більшість сучасних СУБД (Access, Oracle 8, DB 2 тощо) мають SQL сумісні типи даних, проте певні відмінності все ж є. В даній лабораторній роботі слід обирати типи даних, що підтримуються СУБД Access.
Обійти це обмеження можна, користуючись виключно типом даних Portable, тобто логічним типом даних, який застосовується у концептуальних, зовнішніх та внутрішніх моделях, оскільки цей тип даних практично не залежить від СУБД та фізичних способів (носіїв) збереження даних. Фізичний тип даних (Physical) відповідає фізичним моделям і залежить як від СУБД, та й і від фізичних носіїв інформації. За замовчанням встановлюватиметься тип даних (логічний чи фізичний), що відповідатиме тому, що встановлене у діалоговому вікні Database Modeling Preferences (Database → Modeling → Preferences), тому змінювати його треба вручну, набором з клавіатури у відповідному полі. Змінити обраний тип даних, що буде фіксуватися у моделі, можна встановленням перемикач на Physical або Portable Data Type у вікні Database Properties при активованій команді Column.
Дані якими представлений атрибут, можуть бути простими (simple) і складеними (composite). Простий тип даних підтримує одну одиницю (тип) даних заданого типу для кожного атрибуту, складені – кілька. У реляційних моделях у даній лабораторній роботі ми застосовуватимемо лише прості дані.
Поле Data Type вікна Column являє собою поле зі списком, що містить підтримувані типи даних кожної природи. Тип даних можна як обрати зі списку Data Type, як було показано раніше, так і створити самостійно за командою: Database → User Defined Types → Add → введенням у полі діалогового вікна Add New User Defined Type Вашого типу даних з клавіатури (рис. 9). При обранні типу бажано враховувати типи даних, підтримуваних СУБД, в якій передбачається реалізувати БД.
Зокрема, СУБД MS Access підтримує наступні основні типи даних:
Текстовий, Текстовый (Text) — символьні чи числові дані, що не потребують обчислень. Поле даного типу може містити до 255 символів. Розмір текстового поля задається за допомогою властивості Размер поля (FieldSize), у який указується максимальна кількість символів, що можуть бути введені в дане поле. При необхідності ввести рядок більшого розміру, ніж зазначено в даній властивості, треба значення властивості змінити, тому що місце під додаткові символи не резервується. Незалежно від довжини текстового поля воно зберігається в базі даних Access у записі перемінної довжини. Access не займає пам'ять під невикористовувану частину текстового поля в записі, що зменшує загальний розмір бази даних;
Поле MEMO (MEMO) — поле MEMO призначено для введення текстової інформації, по обсязі перевищуючої 255 символів. Таке поле може містити до 65 535 символів. Цей тип даних відрізняється від типу Текстовый (Text) тим, що в таблиці зберігаються не самі дані, а посилання на блоки даних, що зберігаються окремо. За рахунок цього прискорюється обробка таблиць (сортування, пошук і т.п.). Поле типу MEMO не може бути ключовим чи проіндексованим. Поле типу MEMO не рекомендується використовувати, якщо потрібно буде сортувати записи таблиці по даному полю — це буде неможливо. Якщо 255 символів не досить для збереження всіх даних, доведеться розбити текстове поле на два чи три текстових поля;
Числовий, Числовой (Number) — числовий тип застосовується для збереження числових даних, використовуваних у математичних розрахунках. Має багато підтипів. Від вибору підтипу (розміру) даних числового типу залежить точність обчислень. Для встановлення підтипу числових даних служить властивість Размер поля (FieldSize). Дані цього типу можуть міститися в 1, 2, 4, 8 чи 16 байтах. Звичайно за замовчуванням використовується підтип Длинное целое (Longlnteger), який займає 4 байти і являє собою число в межах від -2 147 483 648 до +2 147 483 647. Але, крім цього типу, можна вказати Байт (Byte) — 1 байт (тип даних коротке ціле, Short Integer), Целое (Integer) — 2 байти, Одинарное с плавающей точкой (Single) — 4 байти, Двойное с плавающей точкой (Double) — 8 байти, Десятичное (Decimal) — 12 байтов, Код репликации (Replication ID) — 16 байтів.
Дата/Час, Дата/Время (Date/Time) — тип для представлення дати і часу. Дозволяє вводити дати з 100 по 9999 рік. Розмір поля — 8 байтів. Дати і час зберігаються в спеціальному фіксованому числовому форматі. Дата є цілою частиною значення поля типу Дата/Час, а час — його дробовою частиною. Access надає великий вибір форматів відображення дати і часу, основні з яких наведені нижче.
Таблиця 2
Основні формати відображення дати і часу у MS Access
Спеціальні формати дати і часу визначаються за допомогою символів форматування;
Грошовий, Денежный (Currency) — тип даних, призначений для збереження даних, точність представлення яких коливається від 1 до 4 десяткових знаків. Ціла частина даного типу може містити до 15 десяткових знаків;
Лічильник, Счетчик (AutoNumber) — поле містить 4-байтний унікальний номер, який встановлюється Microsoft Access автоматично для кожного нового запису або випадковим образом, або шляхом збільшення попереднього значення на 1. Значення полів типу лічильника обновляти не можна. Максимальне число записів у таблиці з полем лічильника не повинне перевищувати двох мільярдів;
Логічний, Логический (Yes/No) — логічне поле, що може містити тільки два значення, які інтерпретуються як Так/Ні, Істинне/Хибне, Включене/Виключене Access використовує величину -1 для представлення значення Істинне і величину 0 — для значення Хибне
. Поля логічного типу не можуть бути ключовими, але їх можна індексувати;
Поле об'єкта OLE, Поле объекта OLE (OLE object) — містить посилання на OLE-об'єкт (аркуш Microsoft Excel, документ Microsoft Word, звук, малюнок і т.п.). Обсяг об'єкта обмежується наявним дисковим простором. Тип об'єкта OLE не вказується у властивостях поля об'єкта OLE. Він залежить від додатка, використаного для створення об'єктів OLE, що зберігаються в цьому полі. Пакувальник об'єктів дозволяє упроваджувати файли, створені додатками, що не є серверами об'єктів OLE. Наприклад, він дозволяє впровадити текстові файли як об'єкти в таблиці Access 2002. У поле об'єкта OLE можуть зберігатися довільні дані, у тому числі і дані декількох типів. Це дозволяє обійти основне обмеження реляційних баз даних, стосовно того, щоб у кожному полі зберігалися дані тільки одного типу;
Гіперпосилання, Гиперссылка (Hyperlink) — дає змогу зберігати в поле посилання, за допомогою якого можна посилатися на довільний фрагмент даних усередині файлу чи Web-сторінки на тому ж комп'ютері, у Інтранет чи в Інтернет. Гіперпосилання складається з чотирьох частин: відображуваний текст, адреса (шлях до чи файлу сторінці), додаткова адреса (положення усередині чи файлу сторінки) і текст спливаючої підказки. Кожна частина гіперпосилання може містити до 2048 символів. Поле типу Гіперпосилання не може бути ключовим чи індексованим.
3.2.4. Відображення типів сутностей у діаграмі “сутність-зв'язок” логічної моделі БД
3.2.4.1. Типи сутностей і ієрархія спадкування
Як було зазначено вище, зв'язки визначають, чи є сутність незалежною чи залежною. Розрізняють кілька типів залежних сутностей.
Характеристична - залежна дочірня сутність, що зв'язана тільки з одною батьківською і за змістом зберігає інформацію про характеристики батьківської сутності, наприклад, зв'язок СПІВРОБІТНИК – ХОББІ. Асоціативна - сутність, зв'язана з декількома батьківськими сутностями. Така сутність містить інформацію про зв'язки сутностей. Сутність, що іменує - окремий випадок асоціативної сутності, що не має власних атрибутів (тільки атрибути батьківських сутностей, що мігрували як зовнішній ключ). Категоріальна - дочірня сутність в ієрархії спадкування.
Ієрархія спадкування (чи ієрархія категорій) являє собою особливий тип об'єднання сутностей, що поділяють загальні характеристики. Наприклад, в організації працюють службовці, зайняті повний робітник день (постійні службовці) і сумісники. З їхніх спільних властивостей можна сформувати узагальнену сутність (родовий предок) Співробітник, щоб представити інформацію, спільну для всіх типів службовців. Специфічна для кожного типу інформація може бути розташована в категоріальних сутностях (нащадках) Постійний співробітник і Сумісник.
Звичайно ієрархію спадкування створюють, коли кілька сутностей мають спільні за змістом атрибути, або коли сутності мають спільні за змістом зв'язку (наприклад, якби Постійний співробітник і Сумісник мали б подібний за змістом зв'язок "працює в" із сутністю Організація), або коли це диктується бізнес-правилами. Для кожної категорії можна вказати дискримінатор - атрибут родового предка, що показує, як відрізнити одну категоріальну сутність від іншої (атрибут Тип).
3.2.4.2. Таблиця „предок” і таблиця „нащадок”
Первинна таблиця у відношенні, що утворює зовнішній ключ (FK, Foreign key) називається таблицею предком, або батьківською (“parent table”), а таблиця яка успадковує атрибути, що є первинним ключем первинної таблиці називається таблицею-нащадком (child table), або дочірньою. Атрибути, успадковані таблицею нащадком, слугують для неї за зовнішні ключі (Foreign keys). Зовнішній ключ автоматично встановлюється вторинній таблиці, якщо обидві таблиці містять один і самий атрибут, і в первинній він позначений як первинний ключ (Primary key, PК).
У разі обрання при побудові таблиці нотації IDEFIX таблиці, відтворювані на екрані матимуть форму матриці (прямокутника), а концептуальне ім’я таблиці (назва сутності) відтворюватиметься над прямокутником таблиці. У разі обрання нотації Чена (реляційної) таблиця так само має вигляд прямокутника, але ім’я сутності відтворюється у затіненій ділянці у верхньому рядку таблиці.
3.2.4.3. Залежні та незалежні таблиці у нотації IDEFIX
Незалежними вважаються таблиці серед атрибутів яких немає вторинних (зовнішніх) ключів. На діаграмі вони мають вигляд прямокутників з кутами 90. Тип сутності визначається її зв'язком з іншими сутностями. Ідентифікуючий зв'язок установлюється між незалежною (батьківський кінець зв'язку) і залежною (дочірній кінець зв'язку) сутностями.
Екземпляр залежної сутності визначається тільки через відношення до батьківської сутності, тобто в структурі асоційованої сутності ЗАМОВЛЕННЯ інформація про замовлення не може бути внесена і не має змісту без інформації про клієнта, що його розміщає. При встановленні ідентифікуючого зв'язку атрибути первинного ключа батьківської сутності автоматично переносяться до складу первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності при створенні зв'язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як зовнішній ключ - (FK). В ІDЕFІХ залежні і незалежні сутності розрізняють графічно.
Залежні таблиці містять зовнішні ключі, і графічно (у нотації IDEFIX) відрізняються заокругленістю кутів. Коли малюється ідентифікуюча зв'язок, Visio автоматично перетворить дочірню сутність у залежну. Залежна сутність зображується прямокутником з округленими кутами.
У нотації Чена (табличний варіант) графічно залежні та незалежні сутності не відрізняються одна від одної, але операція міграції атрибутів здійснюється при встановленні зв'язку за допомогою інструменту Relationship.
3.2.5. Представлення зв'язків між сутностями при логічному моделюванні БД на рівні діаграми сутність-зв'язок
Зв'язок є логічним співвідношенням між сутностями. Кожен зв'язок повинен іменуватися дієсловом чи дієслівною фразою (Relationship Verb Phrases). Ім'я зв'язку виражає деяке обмеження чи бізнес-правило і полегшує читання діаграми, наприклад:
* Кожен КЛІЄНТ <розміщує> Замовлення; * Кожне ЗАМОВЛЕННЯ <виконується> СПІВРОБІТНИКОМ
При моделюванні даних виключно на рівні діаграми сутність-зв'язок відношення між сутностями створюють виключно інструментом Connector, оскільки в таблицях-сутностях не визначені ключі. Для створення відношення інструментом Connector достатньо клацнути по ньому на стандартній панелі інструментів. Конектор спочатку затягують у центр таблиці-предка (щоб її контур став червоним), а потім у центр таблиці-нащадка з аналогічним результатом. Ім'я зв'язку вводиться при активації зв'язку у текстове поле, що відкривається.
Для встановлення або редагування властивостей відношення слід його активувати подвійним клацанням, і у вікні Database Properties встановити або змінити відповідні значення властивостей.
Після встановлення зв'язків введенням відповідних позначень слід ідентифікувати зв'язність (тип зв'язку). В подальшому всі зв'язки типу М:N підлягатимуть нормалізації з породженням нових сутностей чи атрибутів.
3.3. Створення логічної моделі на рівні ключів
3.3.1. Ключі: типи та роль у БД
Модель даних, заснована на ключах включає опис усіх сутностей і первинних ключів і призначена для представлення структури даних і ключів, що відповідають предметній області. В такій моделі є змога перевірки забезпечення цілісності за сутностями і за посиланнями.
Первинний ключ (primary key) - це атрибут чи група атрибутів, однозначно ідентифікуючий екземпляр сутності. Атрибути первинного ключа на діаграмі позначаються автоматично після встановлення проти цього атрибуту прапорця РК у вікні властивостей таблиці і розташовуються вище горизонтальної лінії з позначкой РК. Вибір первинного ключа може виявитися непростою задачею, рішення якої може вплинути на ефективність майбутньої ІС. В одній сутності можуть виявитися кілька атрибутів чи наборів атрибутів, що претендують на роль первинного ключа. Такі претенденти називаються потенційними ключами (candidate key). Ключі можуть бути складеними, тобто такими, що містять кілька атрибутів. Складені первинні ключі не вимагають спеціального позначення - це список атрибутів вище горизонтальної лінії.
Для того щоб стати первинним, потенційний ключ повинний задовольняти ряду вимог:
1) унікальність. Два екземпляри не повинні мати однакових значень можливого ключа;
2) компактність. Складний можливий ключ не повинний містити жодного атрибута, видалення якого не призводило б до втрати унікальності.
3.3.2. Створення чи редагування первинного ключа (РК) у таблицях ER-діаграми MS Visio
Якщо РК не обраний встановленням прапорця у відповідному полі під час опису атрибутів, то його можна встановити додатково, активувавши таблицю подвійним клацанням по ній і виконавши команду Database Properties → Cat...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора