Методичні вказівки до лабораторного заняття з дисципліни " Бази даних в інформаційно-комп'ютерних технологіях" для студентів базового напрямку 091 "Електронні апарати"



Скачати 451,71 Kb.
Сторінка1/4
Дата конвертації21.07.2017
Розмір451,71 Kb.
ТипМетодичні вказівки
  1   2   3   4

Міністерство освіти і науки України

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



“Інфологічне проектування бази даних”




Методичні вказівки до лабораторного заняття з дисципліни

Бази даних в інформаційно-комп'ютерних технологіях”

для студентів базового напрямку 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-моделі сутність представляється у вигляді прямокутника (у нотації Баркера), що містить ім'я сутності. При застосуванні нотацій Чена та нотації типу “пташина лапа” застосовується як представлення сутностей у вигляді прямокутників (на етапі інфологічного, чи концептуального проектування), так і табличне представлення сутностей (на етапі логічного проектування у разі обрання реляційного типу бази даних). Сутність фактично задається множиною атрибутів, що описують властивості всіх членів даного набору сутностей і складають кортеж, що задає екземпляр сутності.



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

Множина з одного чи декількох атрибутів, значення яких однозначно визначають кожен екземпляр сутності, називається ідентифікатором (ключем). З визначення атрибуту за П.Ченом ключем сутності є така група атрибутів, що відображення набору сутностей у відповідну групу наборів значень є взаємно однозначним відображенням. Іншими словами, ключ сутності - це один чи більш атрибутів, які унікально визначають дану сутність. Кожен екземпляр сутності повинен мати хоча б один ідентифікатор (ключ). Якщо ідентифікаторів кілька, один з них вибирається як привілейований, чи первинний, інші вважаються потенційними ключами.

Атрибути підрозділяються на прості та складені. Складений (composite) атрибут – це атрибут, який у подальшому можна розділити на кілька додаткових атрибутів. Наприклад, атрибут Адреса можна розділити на атрибути Поштовий_КОД, МІСТО, ВУЛИЦЯ, ДІМ, КВАРТИРА тощо. Простий атрибут такого розділення не допускає.

За кількістю значень, які можуть приймати атрибути, їх підрозділяють на одно- та багатозначні. Однозначні атрибути приймають лише одне значення, наприклад, кожна людина може мати лише один код ДПА. При цьому однозначні атрибути можуть бути складеними, наприклад АДРЕСА_ПРОПИСКИ. Багатозначні атрибути можуть приймати кілька значень, наприклад, людина може закінчити кілька учбових закладів або мати кілька машин різних марок. У моделі Чена багатозначеі атрибути під'єднують до сутності подвійною лінією.

Атрибути можуть класифікуватися за приналежністю до одного з трьох різних типів: описові, вказівні, допоміжні. Описові атрибути представляють факти, внутрішньо притаманні кожному екземпляру сутності. Атрибути, що вказують, (вказівні атрибути) використовуються для присвоєння імені чи позначення екземплярів сутності. Допоміжні атрибути використовуються для зв'язку екземпляра однієї сутності з екземпляром іншої. Нарешті, можуть існувати похідні (derived) атрибути, тобто атрибути, які не треба зберігати у БД, а можна отримати за допомогою певного алгоритму. Наприклад, вік співробітника СПІВРОБІТНИК_ВІК можна отримати як різницю між біжучою датою та датою народження (СПІВРОБІТНИК_ДАТАНАР). У Access цей вираз матиме вигляд INT((DATE()-СПІВРОБІТНИК_ДАТАНАР)/365).

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



Зв'язок (relationship) - це асоціація, установлена між кількома сутностями, яка являє собою абстракцію набору відносин, що систематично виникають між різними видами предметів у реальному світі. Більшість зв'язків відносяться до категорії бінарних і має місце між двома сутностями. У ER-діаграмах ця асоціація є пойменованою і зображеною графічно у вигляді лінії, що поєднує зв'язані сутності.

Серед бінарних зв'язків існують три фундаментальних види зв'язку (типи зв'язності, connectivity): один-до-одного (1:1), один-до-багатьох (1:M), багато-до-багатьох (M:M). Зв'язок один-до-одного (1:1) існує, коли один екземпляр однієї сутності зв'язаний з єдиним екземпляром іншої сутності. Зв'язок один-до-багатьох (1:M) має місце, коли один екземпляр однієї сутності зв'язаний з одним чи більше екземпляром іншої сутності, а кожен екземпляр другої сутності зв'язаний тільки з одним екземпляром першої сутності. Зв'язок багато-до-багатьох (М:N) існує, коли один екземпляр однієї сутності зв'язаний з одним чи більше екземпляром іншої сутності і кожен екземпляр другої сутності зв'язаний з одним чи більше екземпляром першої сутності. Окрім зв'язності, зв'язок характеризується кардинальністю (або степенем чи потужністю зв'язку). Ту кількість сутностей, що може бути асоційована через набір зв'язків з іншою сутністю, називають степенем, або потужністю зв'язку. Цей параметр визначає обов'язковість наявності хоча б одного екземпляру сутності, що приймає участь у зв'язку, а також чисельну кількість цих учасників.

Участь сутності у зв'язку може бути обов'язковою або ні. Участь сутності у зв'язку необов'язкова, якщо один екземпляр сутності не вимагає наявності відповідного екземпляру сутності у окремому зв'язку. Такі зв'язки називаються умовними, або необов'язковими (optional). В умовних зв'язках, на відміну від безумовних, можуть існувати екземпляри сутності, які у зв'язку не приймають участі. Якщо зв'язок умовний по обидва боки, він називається біумовним. Існування необов'язковості (optionality) вказує на те, що для необов'язкової сутності мінімальне значення потужності зв'язку дорівнює 0. Як у діаграмах Чена, так і у діаграмах «пташина лапка», необов'язковий зв'язок показується колом з боку необов'язкової сутності.

Усі зв'язки вимагають описання. Опис повинен містити:



  • ідентифікатор зв'язку;

  • формулювання імен зв'язку з погляду кожної сутності, що бере участь у зв'язку;

  • вид зв'язку (множинність (потужність та зв'язність) і умовність);

  • формулювання того, як зв'язок був формалізований.

Роль сутності в зв'язку - функція, що виконує сутність у даному зв'язку. Наприклад, у зв'язку БАТЬКО-НАЩАДОК сутності ЛЮДИНА можуть мати ролі "батько" і "нащадок". Вказування ролей у моделі "сутність-зв'язок" не є обов'язковим і служить для уточнення семантики зв'язку.

Набір зв'язків (relationship set) - це відношення між n (причому n не менше 2) сутностями, кожна з який відноситься до деякого набору сутностей.

Приклад:

сутності набори сутностей

------------ ----------------

e1 належить E1

e2 належить E2

. . .


en належить En
тоді [e1,e2,...,en] - набір зв'язків R

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

У випадку n=2, тобто коли зв'язок поєднує дві сутності, він називається бінарним. Доведено, що n-арний набір зв'язків (n>2) завжди можна замінити множиною бінарних, однак перші краще відображають семантику предметної області.

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

Усі сутності відносяться до одного з чотирьох класів:



  • стрижневі;

  • асоціативні;

  • характеристичні;

  • такі, що позначають.

Стрижнева сутність (стрижень) являє собою незалежну сутність.

Асоціативна сутність (асоціація) - це сутність, що формалізує зв'язок виду M:N між двома чи більше сутностями чи зв'язок виду 1:1 між екземплярами сутностей.

Характеристична сутність (характеристика) являє собою сутність, що формалізує зв'язок виду 1:M чи 1:1. Єдина мета характеристики в рамках розглянутої предметної області полягає в описі чи уточненні деякої іншої сутності.

Сутність, що позначає (позначення) - це сутність, що також формалізує зв'язок виду 1:M чи 1:1 між двома сутностями, але відрізняється від характеристики тим, що не залежить від сутності, яка позначається.

Якщо сутність залежить від існування одної чи більше інших сутностей, то говорять, що вона залежна від існування (existence-dependent). Наприклад, сутність СПІВРОБІТНИК_ДІТИ у БД СПІВРОБІТНИКИ, що фіксує дітей співробітника для обрахування податків, подарунків тощо, та описується атрибутами кількість та вік, є залежною від сутності СПІВРОБІТНИК. Очевидно, що залежні сутності можуть розглядатися як характеристичні. Якщо ж сутність існує незалежно від існування іншої, то вона є незалежною. Незалежні сутності можуть бути як стрижневими, так і позначальними.

Якщо одна сутність незалежна від існування іншої, то зв'язок між ними називається слабим (weak), або неідентифікуючим (non-identifying). З погляду проектування БД слабі зв'язки мають місце тоді, коли первинний ключ зв'язаної сутності не містить первинних компонентів породжуючої сутності. Сильний (strong), або ідентифікуючий (identifying) зв'язок має місце між зв'язаними сутностями, залежними від існування. З погляду проектування БД сильні зв'язки мають місце тоді, коли первинний ключ зв'язаної сутності містить компоненти первинного ключа породжуючої сутності.

До числа більш складних елементів ER-моделі відносяться підтипи і супертипи сутностей. Сутність може бути розщеплена на два чи більш підтипи, що взаємно виключають один одного, кожний з який має спільні атрибути і/чи зв'язки. Ці спільні атрибути і/чи зв'язки явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути і/чи зв'язки. Сутність, на основі якої визначаються підтипи, називається супертипом. Підтипи повинні утворювати повну множину, тобто будь-який екземпляр супертипу повинен відноситися до деякого підтипу. Аналогічно мовам об'єктно-орієнтованого програмування вводиться можливість успадковування типу сутності, виходячи з одного чи декількох супертипів.

У випадку дуже великої кількості сутностей і зв'язків між ними застосовується менш наочна, ніж мова ER-діаграм, але більш змістовна мова інфологічного моделювання, у якій сутності і зв'язки представляються реченнями вигляду:

СУТНІСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)

ЗВ'ЯЗОК [СУТНІСТЬ S1, СУТНІСТЬ S2, ...] (атрибут 1,..., атрибут n).

2.3. Представлення інфологічних моделей у вигляді ER-діаграм




Поділіться з Вашими друзьями:
  1   2   3   4

Схожі:

Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до самостійної роб оти з дисципліни "Історія зарубіжної літератури" для студентів
Методичні вказівки до самостійної роботи з дисципліни „Історія зарубіжної літератури“ для студентів 1 курсу спеціальності „Переклад”...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до практичних занять І самостійних робіт для студентів 5-го курсу
Методичні вказівки з дисципліни “Риторика” / Укладач І. Р. Жиленко. – Суми: Вид-во СумДУ, 2009. – 42 с
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Навчально-методичні вказівки до вивчення дисципліни
Навчально-методичні вказівки до вивчення дисципліни «Історія економіки та економічних вчень» англійською мовою для студентів напряму...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки та індивідуальні завдання до вивчення дисципліни "Соціологія" для студентів усіх спеціальностей заочної
Робоча програма, методичні вказівки та індивідуальні завдання до вивчення дисципліни „Соціологія” для студентів усіх спеціальностей...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до виконання самостійних робіт для студентів напрямку підготовки
«Дизайн» денної І заочної форм навчання / уклад. В. В. Хижинський – Луцьк : Луцький нту, 2016. – 34 с
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до самостійної роботи з дисципліни "Історія зарубіжної літератури. ХХ століття " для студентів спеціальності 0203 Гуманітарні науки
Методичні вказівки до самостійної роботи з дисципліни “Історія зарубіжної літератури. ХХ століття” для студентів спеціальності 0203...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до проведення практичних занять з дисципліни «Фінанси підприємств»
Методичні вказівки до проведення практичних занять з дисципліни «Фінанси підприємств» для студентів спеціальності 051 «Економіка»,...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки до семінарських занять з дисципліни «Історія економіки та економічної думки»
Методичні вказівки до семінарських занять з дисципліни «Історія економіки та економічної думки» (для студентів галузі знань 0305...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки та індивідуальні завдання до вивчення дисципліни "Українська мова (за професійним спрямуванням)" для студентів усіх спеціальностей
Робоча програма, методичні вказівки та індивідуальні завдання до вивчення дисципліни “Українська мова (за професійним спрямуванням)”...
Методичні вказівки до лабораторного заняття з дисципліни \" Бази даних в інформаційно-комп\Методичні вказівки для роботи студентів розроблені відповідно до робочої програмою дисципліни "Історія української культури" для студентів денної форми
Методичні вказівки для роботи студентів розроблені відповідно до робочої програмою дисципліни “Історія української культури” для...


База даних захищена авторським правом ©biog.in.ua 2019
звернутися до адміністрації

    Головна сторінка