Лекція 1 "Базові поняття бд. Моделі бд. Основні функції скбд"
Вид материала | Лекція |
- Дайте визначення баз даних та скбд. Класифікація та функції скбд. Моделі баз даних, 128.53kb.
- Лекція Основи вчення про конституцію, 264.13kb.
- Назва модуля: Теорія ймовірностей та математична статистика. Код модуля, 16.22kb.
- Тема. Функції та їх графіки, 243.69kb.
- 1. Вступ. Основні поняття та методологія до історія розвитку та використання методів, 102.84kb.
- Лекція Психологічні основи управлінських функцій менеджера, 656.03kb.
- Гідропривод основні функції, переваги та недоліки, історія розвитку. Принцип дії гідроприводу., 254.18kb.
- Називається комплекс програмних та мовних засобів, які використовуються для створення, 149.17kb.
- Удк: 339. 9: 378 О. Ю. Красовська, 293.21kb.
- 10. Функції рівнів моделі osi тема 10. Функції рівнів моделі osi, 125.17kb.
Значения NULL и поддержка ссылочной целостности
Значения NULL используются для обозначения факта отсутствия информации. Например: дата рождения человека может быть неизвестна. При этом следует учесть, что значения NULL отличаются от числового значения 0 или символьных пробелов. Значение NULL вообще не является реальным значением. Для данного атрибута может быть разрешено или запрещено содержать значения NULL.
Возможность присутствия в отношении значений NULL приводит к необходимости формирования правила целостности объектов. Целостность объектов – ни один элемент первичного ключа не может содержать значения NULL.
Правило ссылочной целостности также должно быть расширено с учетом возможности присутствия значений NULL.
Возможность присутствия значений NULL приводит к возникновению ряда трудноразрешимых проблем и осуждается некоторыми исследователями (например, К. Дж. Дейтом в книге [1]).
Правила внешних ключей
Для того, чтобы избежать некорректных состояний для каждого внешнего ключа необходимо установить правила, на основании которых СУБД будет действовать при попытке удалить объект ссылки внешнего ключа или обновить потенциальный ключ, на который ссылается внешний ключ. Для каждого из этих случаев можно предусмотреть по меньшей мере две возможности.
При попытке удалить объект ссылки внешнего ключа:
- Ограничить – приостановить операцию удаления, до момента, когда не будет существовать ссылающихся объектов.
- Каскадировать – каскадировать операцию удаления, удалив соответствующие ссылающиеся объекты.
- Ограничить – приостановить операцию удаления, до момента, когда не будет существовать ссылающихся объектов.
- При попытке обновить потенциальный ключ, на который ссылается внешний ключ:
- Ограничить – приостановить операцию обновления, до момента, когда не будет существовать ссылающихся объектов.
- Каскадировать – каскадировать операцию обновления, обновив значение внешнего ключа в соответствующих ссылающихся объектах.
- Ограничить – приостановить операцию обновления, до момента, когда не будет существовать ссылающихся объектов.
При каскадных обновлениях удавлениях и обновлениях следует учесть возможность наличия ссылочных циклов, которые могут привести к усложнению процедуры модификации БД.
Обмеження категорийної й посилальної цілісності повинні підтримуватися СУБД.
- Етапи проектування бази даних
- Концептуальна модель ПО (Інфологічна модель)
Предметна область, семантика предметної області.
Поняття “предметна область” є базисним поняттям в теорії баз даних і тому не має строгого визначення. Щоб з'ясувати його зміст, звернемося до понять “об'єкт” і “предмет”.
Об'єкт – це те, що існує поза нами і незалежно від нашої свідомості, явищ зовнішнього світу і матеріальної дійсності. Об'єкти потенційно мають величезну кількість властивостей і знаходяться в потенційно нескінченному числі взаємозв'язків між собою. Однак серед усієї безлічі властивостей і взаємозв'язків між об'єктами має сенс виділяти лише істотні, важливі з погляду споживача інформації.
Предмет – це об'єкт, що став носієм визначеної сукупності властивостей, входить у різні взаємини та становить інтерес для споживачів інформації. Той самий об'єкт може прийматися різними системами як різні предмети. Таким чином, предмет – це модель реального об'єкта.
Сукупність об'єктів, інформація про які становить інтерес для користувачів, утворює об'єктне ядро предметної області.
Поняття “предметна область” відповідає точці зору споживача інформації на об'єктне ядро, при якій виділяються тільки ті властивості об'єктів і взаємозв'язки між ними, що представляють визначену прагматичну цінність і повинні фіксуватися в базі даних. Таким чином, предметна область являє собою абстрактну картину реальної дійсності, певна частина якої фіксується як модель фрагмента дійсності.
У кожен момент часу предметна область знаходиться в одному зі станів, що характеризується сукупністю об'єктів і їхніх взаємозв'язків. Якщо об'єкти утворять об'єктне ядро, то сукупність взаємозв'язків не відбиває структуру фрагмента дійсності. З часом одні об'єкти зникають, інші з'являються, змінюються властивості і взаємозв'язки. Проте нові стани, що виникають з часом, вважаються станами однієї і тієї ж предметної області. Таким чином, предметну область доцільно розглядати як систему, що переживає свою історію, яка складається з певної послідовності станів.
Після завдання простору станів, можна розглядати в ньому визначені траєкторії чи послідовності станів s0,s1,...,st, у яких знаходиться предметна область у моменти часу 0,1,...,t. Члени такої послідовності не можуть бути зовсім довільними, оскільки стан s звичайно яким-небудь чином пов'язан із попередніми станами s0, s1,...,st-1. Тому предметну область можна визначити як клас усіх дійсно можливих послідовностей станів. Такі послідовності називаються траєкторіями предметної області. Сукупність усіх загальних властивостей траєкторій називається семантикою предметної області.
- Концептуальні засоби описання предметної області
Оскільки об'єктне ядро довільної предметної області потенційно містить нескінченне число об'єктів, що знаходяться в потенційно нескінченній безлічі взаємозв'язків, то стає ясним, що прямий підхід до опису предметної області через опис всіх об'єктів і взаємозв'язків між ними не може дати бажаного результату.
Очевидною альтернативою в цій ситуації є підхід до опису предметної області, що фіксує тільки те загальне, що є незмінним і характеризує ситуацію в будь-який момент часу, чи, говорячи іншими словами, що відбиває семантику предметної області.
Звідси випливає, що необхідні спеціальні засоби опису предметної області, що були б застосовні до будь-якої з областей, досить просто інтерпретувалися в конкретному фрагменті зовнішнього світу й одночасно були точними, структурованими і доступними для огляду (кінцевими).
Пристосованість зазначених засобів для опису будь-якої предметної області означає, що вони зобов'язані бути досить універсальними. Для забезпечення універсальності необхідна висока спільність, абстрактність системи базисних мета визначень і правил породження нових понять, що допускають інтерпретацію в будь-якій предметній області. В зв’язку із своєю абстрактністю засобу опису предметної області називаються концептуальними. Тому в теорії баз даних прийнято говорити про концептуальне чи інфологічне моделювання предметної області. Результатом процесу моделювання є концептуальна або інфологічна модель (схема) предметної області.
Обобщение представлений всех пользователей о данных называется концептуальной моделью (схемой) БД. Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому её еще называют инфологической (информационно-логической) моделью. В модели отсутствуют какие-либо понятия, связанные с ЭВМ, памятью ЭВМ, способами размещения данных в памяти ЭВМ и, по сути, это модель только предметной области.
Побудова концептуальної (інфологічної моделі ПО (ІМПО))
Під інфологічною моделлю розуміють опис предметної галузі, який виконав з використанням спеціальних язикових засобів, що не залежать від використовуваних надалі програмних засобів. До побудови інфологічної моделі необхідно детально вивчити предметну галузь і адекватно відобразити її в моделі.
Інфологічна модель ПО (концептуальна модель ПО) – опис ПО, виконане формальною мовою, незалежному від машини й СУБД.
При побудові ИМПО використовуються наступні поняття:
- Сутність
- Атрибут
- Зв'язок
- Клас приналежності
- Тип зв'язку
ІМПО – опис ПО, виконане без орієнтації на використовувані надалі програмні й технічні засоби.
ІМПО - деяка абстракція ПО. Для відображення в ІМПО відбираються тільки ті фрагменти ПО, які необхідно використовувати при формуванні відповідей на інформаційні потреби користувачів.
Звичайно ІМПО зображують графічно у вигляді діаграми “Об'єкт-Властивість-Відношення”. При аналізі ПО виділяють класи об'єктів.
Клас об'єктів – сукупність об'єктів, що володіють однаковим набором властивостей.
В ІМПО кожний клас об'єктів представлений ім'ям цього класу – граматичний оборот іменника множини. Приклад: “Автомобілі”, “Співробітники”.
Клас об'єктів відображається в ІМПО сутністю. Кожна сутність характеризується переліком властивостей (атрибутів). Екземпляри об'єктів одного класу мають різні значення цих властивостей.
Сутність зображується у вигляді прямокутника. Атрибути сутності записуються за допомогою виносних ліній.
Статичні властивості (атрибути) сутності позначають символом S над стрілкою відповідній властивості. Приклад: Ідентифікаційний код людини постійний, тобто цей атрибут сутності люди статичне.
Динамічні властивості позначають латинською буквою D. Приклад: Ціна на товар міняється, тобто цей атрибут сутності. Товари динамічні.
Одиничні властивості з'єднуються з виносной лінією за допомогою одинарної стрілки. Множинні властивості вказуються подвійною стрілкою (“Постачальники”).
Умовні властивості позначаються штриховою стрілкою, тобто атрибут не обов'язковий для заповнення.
Крім сутностей на ІМПО, відображаються зв'язки між ними. Зв'язок відображається у вигляді ромба, у який уписане ім'я зв'язку.
Кожний зв'язок характеризується ім'ям, типом, клас приналежності й напрямком. Ім'я зв'язку повинне бути дієслівним оборотом.
Приклад: “належить”.
Тип зв'язку характеризує кількість екземплярів об'єкта кожного класу, що беруть участь у зв'язку.
Розрізняють 4 типи зв'язку:
Один до одного (1:1) – кожного запису однієї таблиці відповідає тільки один запис іншої таблиці.
Один до багатьох (1:М) – одного запису головної таблиці можуть відповідати кілька записів підлеглої таблиці.
Багато хто до одного (М:1) – декількох записам головної таблиці може відповідати та сама запис підлеглої таблиці.
Багато хто до багатьох (М:М) – один запис головної таблиці пов'язана з декількома записами підлеглої таблиці, а один запис підлеглої таблиці пов'язана з декількома записами головної таблиці.
Розходження між типами зв'язків “один до багатьох” і “багато хто до одного” залежить від того, яка з таблиць вибирається в якості головної, а яка - у якості підлеглої.
Та сама таблиця може бути головної стосовно однієї таблиці й підлеглої стосовно іншої. Або в однієї головної таблиці може перебувати в підпорядкуванні не одна, а кілька таблиць.
Однак підлегла таблиця не може управлятися двома таблицями, тобто в головної таблиці може бути кілька підлеглих, але в підлеглої таблиці може бути тільки ода головна.
Зв'язок “багато хто до багатьох” (М:М) необхідно розбити на зв'язку “М:1” і “1:М” за допомогою додаткової таблиці.
Клас приналежності визначать обов'язковість входження кожного запису таблиці у зв'язок. Розрізняють обов'язковий і не обов'язковий клас приналежності.
Необов'язковий клас приналежності показує, що допускаються записи таблиці, що не беруть участь у зв'язку.
Обов'язковий клас приналежності показує, що всі записи таблиці беруть участь у зв'язку.
Рис. 1. Схема інфологічної моделі предметної області варіанту 31 ,,Приймальна комісія”, що містить зв'язок М:1
2х1 – розміри прямокутника
1,5х1 – розміри ромба
Прочитайте та законспектуйте основні підходи до вирішення проблеми перетворення інфологічної моделі предметної області в реляційне представлення даних
- Логічна модель бази даних
Перетворення інфологічної моделі в реляційну модель даних
В процесі перетворення перед розробником виникає проблема представлення інфологічної моделі предметної області в термінах моделі даних, яка буде використовуватись для реалізації бази даних, наприклад, реляційної.
Існує три підходи до вирішення проблеми перетворення інфологічної схеми предметної області в реляційне представлення даних:
- перший підхід складається в ручному перетворенні інфологічної моделі предметної області в схему бази даних, яке виконується відповідно до методик, що досить чітко обговорюють всі етапи такого перетворення;
- в другому підході реалізується автоматизована компіляція інфологічної моделі предметної області в схему бази даних, найчастіше реляційну;
- третій підхід – це безпосередня робота з базою даних у семантичній моделі, тобто застосування систем управління базами даних, заснованих на семантичних моделях даних.
Згідно першого та другого підходів в результаті створюється реляційна модель бази даних у третій нормальній формі.
Використовуючи одну із методик, які відповідають першому підходу до перетворення інфологічної моделі даних в реляційну, спираючись на терміни теорії реляційних баз даних можна описати наступну структуру реляційної бази даних, що відповідає створеній інфологічній моделі:
- кожній розглянутій сутності ставиться у відповідність певна таблиця реляційної бази даних. Таким чином, кількість таблиць бази дорівнює сьоми;
- кожен з атрибутів сутностей інфологічної моделі перетворюється в поле відповідної таблиці бази даних, тобто формує стовпець таблиці. Також, згідно теорії реляційних баз даних, в кожну із перетворених таблиць додається поле так званого первинного ключа, вміст якого буде однозначно інтерпретувати кожен запис таблиці;
- для організації зв’язку між таблицями реляційної бази даних у відповідності із розробленими зв’язками між сутностями інфологічної моделі та іхніми типами в деякі таблиці додається поле так званого зовнішнього ключа. Якщо дві сутності інфологічної моделі були пов’язані зв’язком типу “один-до-багатьох”, то в таблицю реляційної бази даних, з боку якої сила зв’язку “багато” додається поле зовнішнього ключа, в якості якого буде виступати первинний ключ іншої таблиці.
- оскільки між сутностями розробленої інфологічної моделі були визначені тільки зв’язки типу “один-до-багатьох”, то потреби у створенні проміжних таблиць згідно застосованої методики не існує.
В даний час на ринку програмного забезпечення з'явилося досить багато універсальних, не прив'язаних до якої-небудь конкретної системи управління, пакетів автоматизованого проектування баз даних, що дозволяють виконувати концептуальне моделювання предметної області. В основі практично всіх систем такого роду лежить та чи інша інтерпретація ER-моделі тобто інфологічної моделі. Такі системи є реалізацією другого з розглянутих вище підходів. Одним з найбільш популярних програмних продуктів у цій області є ERwin компанії Platinum.
- Фізична модель БД (Даталогічна модель БД)
Даталогічне проектування є проектуванням логічної структури бази даних, на нього впливають можливості фізичної організації даних, що надаються конкретною СУБД. Тому знання особливостей фізичної організації даних є корисним при проектуванні логічної структури.
Логічна структура бази даних, а також сама заповнена база даних є відображенням реальної предметної галузі. Тому на вибір рішень самий безпосередній вплив робить специфіка відображуваної предметної галузі, відбита в інфологічній моделі.
Процес проектування бази даних передбачає класифікацію об'єктів предметної галузі, систематизоване подання інформації про об'єкти й зв'язки між ними.
При проектуванні логічної структури бази даних здійснюється перетворення початкової інфологічної моделі в модель даних, яка підтримується конкретною СУБД, і перевірка адекватності отриманої даталогічної моделі відображуваної предметної галузі.
Даталогічна модель БД (фізична модель) – являє собою опис бази даних, виконане в термінах використовуваної СУБД і розробленими обмеженнями цілісності.
Для первинних ключі призначається обмеження UNIQUE, тобто унікальне значення в даній таблиці. Обмеження UNIQUE вимагає обов'язкового заповнення поля таблиці.
Обмеження NOT NULL – поле обов'язково заповнюється.
Назва атрибуту | Ідентифікатор | Тип | Розмір | Обмеження |
Код абітурієнта | AKodAbiturienta | integer | 4 | Unique |
| | | | |
| | | | |
Зауваження
Первинний ключ і зовнішні ключі внести в перші рядки таблиць, усю решту атрибутів описати послідовно. Об’єднати таблиці за допомогою ліній від первинних ключів батьківських до зовнішніх дочірніх таблиць. Якщо таблиця має первинні і зовнішні ключі, то на схемі винести їх в одну лінію (Рис. 8, Додаток Б).
Рис. 8. Приклад ліній зв’язку між сутностями
На основі правил перетворення ІМПО в ДМБД у таблиці внесені зовнішні ключі. У головні таблиці внесені первинні ключі підлеглий таблиць, які в головній таблиці стали зовнішніми ключами.
На схемі ДМБД первинні й зовнішні ключі винести в одну лінію квадратів з позначеннями ПК і ВК.
На основі схеми ДМБД можна створити скрипт бази даних мовою SQL.
Додаток Б
Приклад схеми даталогічної моделі для В30