Елементи моделі. Будь-який фрагмент предметної області може бути представлений як множина сутностей, між якими існує певна множина зв'язків.
ER-діаграма предметної області представляється множиною сутностей, атрибутів та зв’язків. Елементи кожної з цих множин представляються вузлами графа для яких використовуються спеціальні форми для визначення їхнього виду:
- Множина сутностей представляється прямокутниками.
- Атрибути представляються овалами.
- Зв’язки представляються ромбами.
Приклад На рис.1.1 представлена ER-діаграма, яка зображає базу даних про працівників. Набори сутностей - це Працівник, Посада і Відділ.
Рис. 1.1Діаграма “сутність-зв’язок” для бази даних працівників
Визначення 1 Сутність (entity) це множина реальних або абстрактних об'єктів (людей, подій, станів), що володіють загальними атрибутами. Будь-який об'єкт системи може бути представлений лише однією сутністю, яка повинна бути унікально ідентифікована. При цьому ім'я сутності повинне відображати тип або клас об'єкту, а не його конкретний екземпляр (наприклад, МІСТО, а не ЛЬВІВ).
Визначення 2 Набір сутностей (entity set) – це множина сутностей одного типу (володіють однаковими властивостями). Приклади: всі люди, підприємства, свята тощо. Набори сутностей можуть перетинатися. Наприклад, сутність, що належить до набору ЧОЛОВІКИ, також належить набору ЛЮДИ.
Сутність представляє собою множину атрибутів, які описують властивості всіх членів даного набору сутностей.
Приклад Розглянемо множину співробітників певного відділу. Кожного працівника можна описати за допомогою характеристик табельний номер, прізвище, вік. Тому сутність ПРАЦІВНИК має атрибути ТАБЕЛЬНИЙ_НОМЕР, ПРІЗВИЩЕ, ВІК.Для визначення сутності та її атрибутів використовується позначення виду :
|
|
|
ПРАЦІВНИК (ТАБЕЛЬНИЙ_НОМЕР, ПРІЗВИЩЕ, ВІК).
Визначення 3 Множина значень (область визначення) атрибута називається доменом. Наприклад, для атрибута ВІК домен задається інтервалом цілих чисел більших за нуль, оскільки людей з від’ємним віком не буває.
Визначення 4 Ключ сутності - це один або більше атрибутів які унікально визначають дану сутність. У нашому випадку ключем сутності СПІВРОБІТНИК є атрибут ТАБЕЛЬНИЙ_НОМЕР (якщо всі табельні номери унікальні).
Визначення 5 Зв'язок (relationship) - це асоціація, встановлена між декількома сутностями.
Приклад:
- оскільки кожний співробітник працює у якому-небудь відділі, між сутностями СПІВРОБІТНИК і ВІДДІЛ існує зв'язок "працює в" або ВІДДІЛ-ПРАЦІВНИК;
- оскільки один з працівників відділу є його керівником, то між сутностями СПІВРОБІТНИК і ВІДДІЛ існує зв'язок "керує" або ВІДДІЛ-КЕРІВНИК;
- Зв'язок може мати атрибути. Наприклад, для зв'язку ВІДДІЛ-ПРАЦІВНИК можна задати атрибут СТАЖ_РОБОТИ_У_ВІДДІЛІ.
|
|
|
Визначення 6 Набір зв'язків (relationship set) - це відношення між n (причому n не менше 2) сутностями, кожна з яких відноситься до деякого набору сутностей.
Поняття "зв'язок" і "набір зв'язків" різні (перша є елементом другого), їх, проте, часто вживають для позначення одного і того самого.
У випадку n=2, тобто коли зв'язок об'єднує дві сутності, він називається бінарним. Доведено, що n-арний набір зв'язків (n>2) завжди можна замінити безліччю бінарних, проте перші краще відображають семантику предметної області.
Визначення 7 Кількість сутностей, які можна асоціювати через набір зв'язків з іншим сутностями, називають степінню зв'язку. Є наступні типи зв’язків:
· один до одного Це означає, що в такому зв'язку сутності з однією роллю завжди відповідає не більше однієї сутності з іншою роллю. У прикладі це зв'язок "керує", оскільки у кожному відділі може бути лише один начальник, а співробітник може керувати лише в одному відділі. Даний факт представлений на Рис. 1.2, де прямокутники позначають сутності, а ромб - зв'язок. Оскільки степінь зв'язку для кожної сутності дорівнює 1, то вони з'єднуються однією лінією.
Рис. 1.2Приклад графічної побудови зв’язку один-до-одного
|
|
|
Важливою характеристикою зв'язку є клас належностісутностей які до нього входять. Оскільки у кожному відділі обов'язково повинен бути керівник, то кожній сутності "ВІДДІЛ" неодмінно повинна відповідати сутність "СПІВРОБІТНИК". Проте, не кожний співробітник є керівником відділу, відповідно у даному зв'язку не кожна сутність "СПІВРОБІТНИК" має асоційовану з нею сутність "ВІДДІЛ".
Таким чином, говорять, що сутність "СПІВРОБІТНИК" має обов'язковий клас належності (цей факт є також вказівкою інтервалу кількості можливих входжень сутності у зв'язок, у даному випадку це 1,1), а сутність "ВІДДІЛ" має необов'язковий клас належності (0,1). Тепер даний зв'язок ми можемо описати як 0,1:1,1. Надалі клас належності бінарних зв'язків степені 1 будемо позначати наступним чином:
Рис. 1.3Приклад позначення бінарних зв’язків степені 1
· один до багатьох (1:n). Сутності з однією роллю може відповідати будь-яка кількість сутностей з іншою роллю. Таким є зв'язок ВІДДІЛ-СПІВРОБІТНИК. У кожному відділі може працювати довільна кількість співробітників, але співробітник може працювати лише в одному відділі. Графічно степінь зв'язку n відображається "деревоподібною” лінією, як це зроблено на рис 1.4.
|
|
|
Рис. 1.4Приклад графічної побудови зв’язку один-до-багатьох
Даний рисунок додатково ілюструє той факт, що між двома сутностями може бути визначено декілька наборів зв'язків.
Тут також необхідно враховувати клас належності сутностей. Кожний співробітник повинен працювати у якому-небудь відділі, але не обов’язково кожний відділ (наприклад, щойно сформований) повинен включати хоча б одного співробітника. Тому сутність "ВІДДІЛ" має обов'язковий, а сутність "СПІВРОБІТНИК" необов'язковий класи належності. Степінь зв’язку бінарних зв'язків степені n будемо позначати наступним чином:
Рис. 1.5Приклад позначення бінарних зв’язків степені n
· багато до одного (n:1). Цей зв'язок аналогічний відображенню 1:n. Припустимо, що представлення нами підприємство будує свою діяльність на підставі контрактів, що підприємство, яке ми розглядаємо, будує свою діяльність на основі контрактів, які укладаються із замовниками. Цей факт відображається у моделі "сутність-зв'язок” (Рис.2.5) за допомогою зв'язку КОНТРАКТ-замовник, який об'єднує сутності КОНТРАКТ(НОМЕР, ТЕРМІН_ВИКОНАННЯ, СУМА) і ЗАМОВНИК(НАЗВА, АДРЕСА). Оскільки з одним замовником може бути укладено більше одного контракту, то зв'язок КОНТРАКТ-замовник між цими сутностями матиме степінь n:1.
Рис. 1.6Приклад графічної побудови зв’язку багато-до-одного
У даному випадку, по представлення очевидних міркуваннях (кожний контракт укладений представлення конкретним замовником, а кожний замовник має хоча б один контракт, інакше він не був би таким), кожне представлення має обов'язковий клас приналежності.
· багато до багатьох (n:n). У цьому випадку кожне з асоційованих сутностей може бути представлена будь-якою кількістю екземплярів. Нехай на підприємстві для виконання кожного контракту створюється робоча група, у яку входять співробітники різних відділів. Оскільки кожний співробітник може входити в кілька (у тому числі і в жодну) робочих груп, а кожна група повинна включати не менше одного співробітника, то зв'язок між сутностями СПІВРОБІТНИК і РОБОЧА_ГРУПА має степінь n:n (Рис.1.7.).
·
Рис. 1.7Приклад графічної побудови зв’язку багато -до-багатьох
Визначення 8 Якщо існування сутності x залежить від існування сутності у, то x називається залежною сутністю (інколи сутність x називають "слабкою", а сутність у – “сильною”).
ПрикладРозглянемо зв'язок між раніше описаними сутностями РОБОЧА_ГРУПА і КОНТРАКТ. Робоча група створюється лише після того, як буде підписаний контракт із замовником, і припиняє своє існування по виконанню контракту. Таким чином, сутність РОБОЧА_ГРУПА є залежною від сутності КОНТРАКТ. Залежна сутність позначається подвійним прямокутником, а її зв'язок із сильною сутністю лінією із стрілкою:
Рис. 1.8 Графічна побудова залежної сутності та зв’язок між ними.
Рис. 1.9Приклад графічного представлення залежності сутностей
Категоризація сутності. Сутність може бути розділена і представлена у вигляді двох або більше сутностей-категорій, кожна з яких має загальні атрибути. Розщеплювана на категорії сутність має назву загальної сутності (на проміжних рівнях декомпозиції одна і та сутність може бути як загальною, так і сутністю-категорією).
Для демонстрації декомпозиції сутностей на категорії використовуються діаграми категоризації. Така діаграма містить загальну сутність, дві і більше сутностей-категорій і спеціальний вузол-дискримінатор, який описує способи декомпозиції сутності (див. Рис. 1.10).
Рис. 1.10Діаграма категоризації
Існує 4 можливі типи дискримінаторів (рис.1.11):
1. Повне і обов'язкове входження E/M (exclusive/mandatory) – сутність повинна бути однією і лише однією з випливаючих категорій. Для прикладу на рис. 1.10 це означає, що ВИКЛАДАЧЕМ є ФІЗИК, або ХІМІК, або МАТЕМАТИК.
2. Повне і необов'язкове входження E/O (exclusive/optional) - сутність може бути однією і лише однією з випливаючих категорій. Це означає, що ВИКЛАДАЧЕМ є ФІЗИК, або ХІМІК, або МАТЕМАТИК, або викладач якої-небудь іншої дисципліни (наприклад, ІСТОРИК).
3. Неповне і обов'язкове входження I/M (inclusive/mandatory) - сутність повинна бути принаймні однією з випливаючих категорій. Це передбачає у доповнення до 1) задавати наступну ситуацію: ВИКЛАДАЧЕМ є одночасно і ФІЗИК і ХІМІК.
4. Неповне і необов'язкове входження I/O (inclusive/optional) - сутність може бути принаймні однією з випливаючих категорій. У доповнення до 2) ВИКЛАДАЧЕМ є викладач якої-небудь іншої дисципліни (наприклад, ІСТОРИК).
Рис 1.11 Типи дискримінаторів.
Побудова моделіДуже важливою властивістю моделі "сутність-зв'язок є те, що вона може бути представлена у вигляді графічної схеми. Це значно полегшує аналіз предметної області. Існує декілька варіантів позначення елементів діаграми " сутність -зв'язок, кожний з яких має свої позитивні риси. Ми використовуватимемо певний гібрид нотацій Чена (позначення представлення, зв'язків і атрибутів) і Мартіна (позначення степенів і класу належності зв’язків).
У процесі побудови діаграми можна виділити декілька очевидних етапів:
- Визначення класу належності зв'язків.
- Визначення атрибутів і наборів їх значень (доменів).
- Організація даних у вигляді відношень "сутність-зв'язок.
Як приклад розглянемо діаграму, яка відображає зв'язок даних для підсистеми обліку персоналу підприємства.
Виділяються сутності і зв'язки, які нас цікавлять:
Підприємство складається з відділів, у яких працюють співробітники. Оклад кожного співробітника залежить від посади (інженер, бухгалтер, тощо). Можуть бути суміщення посад, тобто кожний співробітник може мати більше ніж одну посаду (і працювати більше ніж в одному відділі), причому може займати неповну ставку. У той же час, одну і ту ж посаду можуть займати одночасно декілька співробітників. У результаті цих міркувань ми повинні ввести набори сутностей
· ВІДДІЛ(НАЗВА_ВІДДІЛУ)
· СПІВРОБІТНИК(ТАБЕЛЬНИЙ_НОМЕР, ІМ'Я)
· ПОСАДА(ІМ’Я_ПОСАДИ, ОКЛАД)
і набір зв'язків ПРАЦЮЄ_В із атрибутом ставка між ними. Атрибут ставка може приймати значення з інтервалу [0,1] (більше нуля, але менше або дорівнює одиниці), він визначає яку частину посадового окладу отримує даний співробітник.
Рис. 1.12Етап побудови моделі предметної області
Тренарний зв'язок, показаний тут, безумовно несе повнішу інформацію про предметну область. Дійсно, вона однозначно відображає той факт, що оклад співробітника залежить від його посади, відділу, де він працює і ставки. Проте, у цьому випадку виникають деякі проблеми із визначенням степені зв'язку. Хоча, як було сказано, кожний працівник може займати декілька посад, а у штаті кожного відділу існують вакансії із різними посадами, проте клас належності сутності ПОСАДА на наведеному рисунку встановлений у (1,1). Це пояснюється тим, що ПОСАДА асоціюється фактично не з сутностями СПІВРОБІТНИК і ВІДДІЛ, а із зв'язком між ними. Цей факт позначається так, як це зображено на наступній діаграмі:
·
Рис. 1.13 Приклад графічної побудови абстрактної сутності
Тут сутності СПІВРОБІТНИК, ВІДДІЛ і зв'язок ПРАЦЮЄ_В агрегуються у деяку нову абстрактну сутність, яка асоціюється із сутністю ПОСАДА за допомогою зв'язку степені n:1.
· Відобразимо асоціації співробітників, відділів і посад за допомогою бінарних зв'язків (Рис.1.14).
Рис. 1.14 Відображення асоціації співробітників, відділів і посад за допомогою бінарних зв'язків
У цому випадкудля адекватного опису семантики предметної області необхідно ввести ще одне сутність ШТАТНА_ОДИНИЦЯ, яка фактично замінює собою зв'язок ПРАЦЮЄ_В в абстрактній сутності і тому має атрибут ставка.
Перехід від n-арного зв'язку через аггрегацию сутностей до набору бінарних зв'язків можна розглядати як послідовні етапи одного процесу, який приволить до однозначного породження реляційної моделі даних. При побудові діаграми "сутність-зв'язок" можна використовувати будь-який з цих трьох способів представлення даних.
Перерахуємо низку об'єктів, які описані вище і будуть корисними під час моделювання даних вибраного підприємства. Їм відповідають наступні сутності:
o ЗАМОВНИК(ІМ’Я_ ЗАМОВНИКА,АДРЕСА)
o КОНТРАКТ(НОМЕР,ТЕРМІН_ПОЧАТКУ, ТЕРМІН_ЗАВЕРШЕННЯ,СУМА)
o РОБОЧА ГРУПА(ПРОЦЕНТ_ВИНАГОРОДИ)
Атрибут"процент_винагороди" відображає ту частку вартості контракту, яка призначена для оплати праці членів відповідної робочої групи. Зміст решти атрибутів зрозумілий без додаткових пояснень. Зв'язки між перерахованими сутностями також описані вище
Як правило, один із членів робочої групи є керівником по відношенню до інших співробітників, що входять до її складу. Для відображення цього факту необхідно ввести зв'язок "керує" із класои належності 1,1:0,n між сутностями СПІВРОБІТНИК і РОБОЧА_ГРУПА (співробітник може керувати у довільній кількості робочих груп, але кожна робоча група має одного і лише одного керівника).
Розглянемо уважніше інформаційний об'єкт "замовник". На практиці дуже часто виникає необхідність розрізняти національну приналежність юридичних осіб, із якими підприємство вступає у договірні відносини. Це пов’язано із тим, що для зарубіжних фірм необхідно зберігати, наприклад, інформацію про валюту, у якій здійснюються розрахунки, мову, на якій підписана угода тощо. У свою чергу, для українських компаній необхідно мати відомості про їхню форму власності (приватна або державна), оскільки від цього може залежати порядок оподаткування засобів, отриманих за виконання робіт за контрактом.
Таким чином, ми приходимо до висновку, що необхідно ввести ще дві множини, які не перетинаються, ЗАРУБІЖНЕ_ПІДПРИЄМСТВО(ВАЛЮТА, МОВА) і УКРАЇНСЬКЕ_ПІДПРИЄМСТВО(ФОРМА_ВЛАСНОСТІ), об'єднання яких складає повну сутність ЗАМОВНИК. Асоціацію між цими об'єктами називаютьвідношенням наслідуванняабоієрархічним зв'язком,оскільки сутність ЗАРУБІЖНЕ_ПІДПРИЄМСТВОіУКРАЇНСЬКЕ_ПІДПРИЄМСТВОнаслідують атрибути сутностіЗАМОВНИК(ІМ’Я_ ЗАМОВНИКА,АДРЕСА)
ПРАКТИЧНЕ ЗАВДАННЯ
1. Описати предметну область “автостояка” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
2. Описати предметну область “мережа лотків” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
3. Описати предметну область “гуртожиток” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
4. Описати предметну область “ТТУ м. Львова” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
5. Описати предметну область “мережа магазинів Еколан” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
6. Описати предметну область “маркетинговий відділ банку” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
7. Описати предметну область “циклова комісія Засобів зв’язку та оргтехніки” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
8. Описати предметну область “Львівський коледж ДУІКТ” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
9. Описати предметну область “студмістечко” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
10. Описати предметну область “пункт прокату ZMS” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
11. Описати предметну область “автовокзал” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
12. Описати предметну область “послуги та клієнти UARNet” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
13. Описати предметну область “нерухомість Львівського коледжу ДУІКТ” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
14. Описати предметну область “салон КРЕЗ” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
15. Описати предметну область “служба доставки Львівської головпошти” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
16. Описати предметну область “відділення Львівського коледжу ДУІКТ” та побудувати для неї інформаційну модель у вигляді ER- діаграми.
Контрольні запитання
1. Для чого будується ER- діаграма?
2. Дайте визначення компонентів ER – моделі.
3.У чому відмінність сутності від поняття?
4. Які властивості називають ключовими?
5. Якому компоненту ER - діаграми відповідає поняття?
6. Що таке домен і як він описується?
7. Які із перерахованих термінів є синонімами: зв'язок, поняття, атрибут, клас сутностей, сутність, відношення, екземпляр відношення, екземпляр сутності, властивість?
Практична робота №2
Тема:Створення фізичної моделі бази даних
Мета роботи Навчитися створювати фізичну модель бази даних.
Короткі теоретичні відомості
1 Загальний огляд методології фізичного проектування баз даних.Процес реалізації бази даних в зовнішній пам'яті повинен включати основні таблиці, файлову організацію, індекси, що забезпечують ефективний доступ до даних, а також всі відповідні обмеження цілісності і засоби захисту.
Етапи фізичного проектування баз даних.
- Перенесення глобальної логічної моделі даних в середовище цільової СУБД.
- Проектування основних таблиць.
- Розробка способів одержання похідних даних.
- Реалізація обмежень предметної області.
- Проектування фізичного представлення бази даних.
- Вибір файлової структури.
- Визначення індексів.
- Розробка механізмів захисту
Обговорювана нами методологія фізичного проектування баз даних включає шість основних етапів. Концептуальне і логічне проектування охоплює три перші етапи розробки баз даних, а фізичне проектування — етапи 4-9.
4-й етап фізичного проектування включає розробку основних таблиць і реалізацію обмежень. На цьому етапі має бути також прийняте рішення по вибору способів одержання похідних даних.
5-й етап включає вибір файлової організації і індексів для основних відношень. Як правило, СУБД для персональних комп'ютерів мають фіксовану структуру зовнішньої пам'яті. З точки зору користувача організація внутрішньої структури зберігання таблиць має бути абсолютно прозорою — користувач повинен мати можливість діставати доступ до будь-якого відношення і до окремих його рядків без врахування способу зберігання даних. Це означає, що СУБД повинна забезпечувати повну незалежність фізичного зберігання даних від їх логічної організації.
6-й етап включає прийняття рішення про те, як має бути реалізоване кожне призначене для користувача представлення.
7-й етап здійснює проектування засобів захисту, необхідних для запобігання несанкціонованому доступу до даних, включаючи управління доступом до основних відношень.
8-й етап аналізує необхідність зниження рівня вимог нормалізації даних в логічній моделі, що підвищує загальну продуктивність системи.
9-й етап описує спосіб організації контролю операційної системи, що дозволяє виявляти і усувати проблеми продуктивності, які можуть бути вирішені на рівні проекту.
2 Перенесення глобальної логічної моделі даних в середовище цільової СУД (4-й етап).Головним завданням на етапі фізичного проектування баз даних є перетворення відношень, створених на основі логічної моделі даних, в форму, яка може бути реалізована в середовищі СУБД. Перша частина цього процесу передбачає перевірку інформації, зібраної на етапі логічного проектування бази даних і поміщеної в словник даних. Друга частина процесу полягає у використанні цієї інформації для розробки структури основних таблиць.
На етапі 4 розробки баз даних виконуються наступні дії.
- Проектування основних таблиць.
- Розробка способів одержання похідних даних.
- Реалізація обмежень предметної області.
3 Проектування основних таблиць.Приступаючи до фізичного проектування, необхідно проаналізувати і добре засвоїти інформацію про відношення, зібрану на етапі побудови логічної моделі бази даних. Визначення кожної таблиці включає наступні елементи:
- ім'я таблиці;
- список простих полів
- визначення первинного ключа і (якщо такі існують) альтернативних (АК) і зовнішніх (FK) ключів;
- список обчислювальних полів і опис способів їх обчислення;
- визначення вимог цілісності для будь-яких зовнішніх ключів.
Для кожного поля має бути присутня наступна інформація:
- визначення його домена, що включає вказівку типу даних, розмірність внутрішнього представлення атрибуту і необхідні обмеження на допустимі значення;
- значення атрибуту, що набуває за замовчуванням (необов'язково);
- допустимість значення NULL для даного атрибуту.
Рішення про спосіб реалізації основних відношень залежить від типу вибраної СУБД. Підготовлений проект основних відношень має бути детально описаний в супровідній документації з вказівкою причин, по яких був вибраний даний конкретний проект
4 Розробка способів одержання похідних даних. Похідними, або розрахунковими називаються атрибути, значення яких можна визначити з використанням значень інших атрибутів. Наприклад, похідними є всі перераховані нижче атрибути:
- кількість співробітників, що працюють в конкретному відділенні;
- загальна сума щомісячної зарплати всіх співробітників;
- кількість об'єктів нерухомості, що знаходяться під управлінням певного співробітника компанії.
На етапі фізичного проектування бази даних необхідно визначити, чи повинен похідний атрибут зберігатися в базі даних або обчислюватися кожного разу при необхідності. Проектувальник повинен розрахувати наступне:
- додаткові витрати на зберігання похідних даних і підтримку їх узгодженості з реальними даними, на основі яких вони обчислюються;
- витрати на обчислення похідних даних, якщо їх обчислення виконується в міру необхідності.
Додаткові витрати пам'яті для цього нового похідного атрибуту не дуже великі. Значення атрибуту оновлюється кожного разу, коли під управління співробітника компанії передається об'єкт нерухомості або відміняється його призначення для управління якимсь об'єктом. У процесі проектування необхідно забезпечити, щоб ці зміни відбувалися в кожному з вказаних випадків і кількість об'єктів, що враховувалися, залишалася правильним, оскільки це гарантує цілісність бази даних. Якщо запит вказаного типа виконується часто або вважається дуже важливим з точки зору продуктивності, похідний атрибут доцільніше зберігати в базі даних, а не обчислювати при кожному зверненні до його значення. Рішення, що передбачає зберігання похідних атрибутів, є прийнятним і в тому разі, якщо мова запитів цільової СУБД не дозволяє легко реалізувати алгоритм обчислення похідних атрибутів.
Спосіб здобуття похідних даних має бути повністю описаний в документації з вказівкою причин вибору запропонованого проекту.
5 Проектування фізичного представлення бази даних (5 етап).Важливим завданням фізичного проектування бази даних є організація ефективного зберігання даних. Вона включає:
- Продуктивність виконання транзакцій. Цим показником є кількість транзакцій, які можуть бути оброблені за заданий інтервал часу.
- Час відповіді. Характеризує часовий проміжок, необхідний для виконання однієї транзакції. З точки зору користувача бажано зробити час відповіді системи мінімальним.
- Дискова пам'ять. Цим показником є об'єм дискового простору, необхідного для розміщення файлів бази даних. Розробник повинен прагнути мінімізувати об'єм використовуваної дискової пам'яті.
Діапазон вибору можливих типів організації файлів залежить від СУБД, оскільки різні системи підтримують різні набори допустимих структур зберігання інформації. Важливо, щоб розробник фізичного проекту мав повне уявлення про всі типи структур зберігання даних, підтримуваних СУБД, а також про всі особливості використання цих структур в системі.
Для досягнення високої продуктивності системи, розробник фізичного проекту бази даних повинен знати, як взаємодіють між собою і впливають на продуктивність системи чотири основні компоненти апаратних засобів.
- Оперативна пам'ять. Доступ до даних в оперативній пам'яті здійснюється набагато (у десятки або навіть в сотні і тисячі разів) швидше, ніж до даних в зовнішній пам'яті. Якщо в системі не вистачає оперативної пам'яті, то операційна система звільняє частину цієї пам'яті, передаючи окремі сторінки пам'яті деяких процесів на диск. Ці сторінки будуть зчитані з диска, як тільки буде потрібно доступ до них. Така операція називається сторінковим обміном.
- Процесор. Управляє функціонуванням інших апаратних компонентів системи і підтримує призначені для користувача процеси. Найважливішою умовою ефективної роботи цього компонента є запобігання конкуренції за право його використання, що зазвичай супроводжуються переведенням процесів в стан чекання.
- Дисковий ввід-вивід. У будь-якій СУБД процеси збереження і вибірки даних пов'язані з виконанням операцій введення-виводу. Як правило, виробники дискових пристроїв вказують кількість операцій введення-виводу, що рекомендується, в секунду.
- Файли операційної системи мають бути відокремлені від файлів бази даних.
- Основні файли бази даних мають бути відокремлені від індексних файлів.
- Мережа може стати вузьким місцем всієї системи при надмірному зростанні мережевого трафіку або великій кількості мережевих колізій.
Варіанти практичних завдань
1 Описати предметну область “автостояка” та побудувати для неї фізичну модель.
2 Описати предметну область “мережа лотків” та побудувати для неї фізичну модель.
3 Описати предметну область “гуртожиток” та побудувати для неї фізичну модель.
4 Описати предметну область “ТТУ м. Львова” та побудувати для неї фізичну модель.
5 Описати предметну область “мережа магазинів Еколан” та побудувати для неї фізичну модель.
6 Описати предметну область “маркетинговий відділ банку” та побудувати для неї фізичну модель.
7 Описати предметну область “циклова комісія Засобів зв’язку та оргтехніки” та побудувати для неї фізичну модель.
8 Описати предметну область “Львівський коледж ДУІКТ” та побудувати для неї фізичну модель.
9 Описати предметну область “студмістечко” та побудувати для неї фізичну модель.
10 Описати предметну область “пункт прокату ZMS” та побудувати для неї фізичну модель.
11 Описати предметну область “автовокзал” та побудувати для неї фізичну модель.
12 Описати предметну область “послуги та клієнти UARNet” та побудувати для неї фізичну модель.
13 Описати предметну область “нерухомість Львівського коледжу ДУІКТ” та побудувати для неї фізичну модель.
14 Описати предметну область “салон КРЕЗ” та побудувати для неї фізичну модель.
15 Описати предметну область “служба доставки Львівської головпошти” та побудувати для неї фізичну модель.
16 Описати предметну область “відділення Львівського коледжу ДУІКТ” та побудувати для неї фізичну модель.
Зміст звіту
1 Мета роботи.
2 Теоретичний аналіз опрацьованого матеріалу.
3 Відповіді на контрольні запитання.
4 Індивідуальне завдання.
5 Аналіз отриманих результатів і висновки.
6 Список використаної літератури.
Контрольні запитання
1 Які дані називаються похідними
2 Якими елементами характеризується таблиця
3 Які поля називаються обчислювальними
4 У чому полягають відмінності між концептуальним, логічним і фізичним проектуванням баз даних? Чому ці проекти можуть виконуватися різними людьми?
5 Опишіть склад вхідної інформації і результати виконання процедури фізичного проектування бази даних.
6 Яке призначення основних етапів фізичного проектування бази даних?
7 Перерахуйте етапи фізичного проектування баз даних.
Практична робота № 3
Тема: Побудова запитів засобами мови SQL
Мета:Навчитися конструювати запити різних типів на мові SQL: вибирати дані за певними критеріями, перевизначати імена полів, уточнювати поля іменами таблиць.
Теоретичні відомості
MySQL підтримує велику кількість типів полів, які в загальному можна поділити на три категорії – числові типи, типи дата/час і стрічкові. В описах ви знайдете деякі символи, що мають символічне значення. Це M, що означає, що в зазначеному місці стоїть максимальний розмір значення поля, і D, що вказує (для числових типів із плаваючою крапкою) кількість розрядів, що стоять після крапки, тобто довжина дробової частини числа. Квадратні дужки ('[' і ']') вказують на те, що взятий у них параметр не є обов'язковим і може бути пропущений. В цілому, оголошення типу INT([M]) [UNSIGNED] [ZEROFILL] говорить про те, що при оголошенні поля типу INT ви можете (але не повинні) вказати максимальний розмір поля в дужках після слова INT, а також написати (необов’язково) параметри ZEROFILL UNSIGNED
Цілочисельні типи.
TINYINT [(M)] [UNSIGNED] [ZEROFILL]
Це найменший цілочисельний тип. Діапазон значень для знакових –
-128..127 (у випадку беззнакових -UNSIGNED - 0..255)
SMALLINT[(M)] [UNSIGNED] [ZEROFILL]
Це короткий цілий тип. Діапазон значень —32768..32767 і відповідно 0..65535 для беззнакового цілого.
MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]
Це середній цілий тип. Значення можуть бути від - -8388608 до 8388607 і від 0 до 16777215 при вказаному UNSIGNED.
INT[(M)] [UNSIGNED] [ZEROFILL] або
(INTEGER[(M)] [UNSIGNED] [ZEROFILL])
Це звичайний цілий тип. Значення - -2147483648..до 2147483647 і 0..4294967295 для беззнакового цілого.
BIGINT[(M)] [UNSIGNED] [ZEROFILL]
Це довгий цілочисельний тип. Значення лежать у межах від
-9223372036854775808 до 9223372036854775807 і від 0 до 18446744073709551615 для UNSIGNED. Зауважимо, що всі арифметичні дії виконуються за допомогою BIGINT зі знаком, тому не слід користуватися значеннями, більшими, ніж 9223372036854775807.
Дата добавления: 2018-05-13; просмотров: 560; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!