ТЕМА. Система управління базами даних.
Архітектура системи бази даних
Інформація дуже різноманітна за змістом та дуже велика за обсягом. Тому
її необхідно структурувати — виділити компоненти та встановити зв’язки
поміж ними. Існує три моделі (рівні) структурування: концептуальна,
логічна (зовнішня) та фізична (внутрішня). На рис. 10.1 відображена
архітектура системи бази даних.
Рис. 10.1. Архітектура системи бази даних
Концептуальна модель. Елементи реального світу, інформація про які
зберігається та використовується, називається об’єктами.
Об’єктом може бути предмет праці, технологічна операція, робітник,
підрозділ, підприємство або поняття, про яке отримані дані. Множина
об’єктів, інформаційний опис котрих використовується в системі, має
назву предметної області системи. Сукупність інформації про цю область
являє собою інформаційний простір предметної області.
Кожний об’єкт предметної області характеризується низкою властивостей.
Ці властивості відображуються за допомогою елементарних одиниць
інформації — атрибутів. Атрибут — це неподільний під час передавання та
зберігання елемент інформаційного простору. З атрибутів будуються всі
інші, більш складні, інформаційні конструкції. Атрибут відображує певну
властивість деяких класів об’єктів. Значення або екземпляр атрибута — це
інформація про дану властивість одного конкретного об’єкта. Клас
об’єктів — це їхня сукупність, яка володіє однаковим набором
властивостей.
Концептуальна модель також визначає зв’язки між об’єктами.
Таким чином, концептуальна модель відображує узагальнене уявлення про
інформацію її кінцевих користувачів.
Існують такі моделі даних: файлові з послідовною та індексно-послідовною
організацією; ієрархічні; мережові та реляційні. Останнім часом найбільш
поширеною моделлю є реляційна.
Внутрішня модель (фізична база даних) являє собою найнижчий рівень бази
даних. Вона складається з різних екземплярів типів даних, які
зберігаються на пристроях зовнішньої пам’яті (наприклад, на дисках).
Зовнішня модель. Як правило, окремого користувача цікавить лише окрема
частина бази даних. Окрім того, користувач не знає, яким чином фізично
зберігаються ці дані. Зовнішня модель — це інформаційний зміст бази
даних у такому вигляді, як її уявляє собі користувач. Для звертання до
бази даних можуть використовуватися як мови програмування, так і
спеціалізовані мови (наприклад, мова запитів SQL).
Таким чином, база даних — це інтегроване сховище взаємопов’язаних даних
конкретної предметної області.
Система управління базами даних (СУБД) — це комплекс програмних засобів,
призначений для інтегрованого зберігання та обробки даних.
За загальне управління системою бази даних відповідає адміністратор бази
даних, котрий виконує такі функції:
визначення інформаційного змісту бази даних;
визначення структури зберігання даних;
взаємодія з користувачами;
забезпечення перевірки достовірності інформації;
визначення повноважень доступу;
визначення методів архівації та поновлення даних;
управління ефективністю функціонування СУБД.
Реляційна модель даних
Реляційна модель даних подає дані у вигляді множини таблиць. Структура
бази даних визначається встановленням зв’язків між таблицями замість
моделювання схеми даних відповідно до способу їхнього фізичного
розташування.
Таблиця являє собою набір рядків та стовпців, де рядки називаються
записами, а стовпчики — полями. Наприклад, таблиця
«Замовники» має такий вигляд:
Таблиця 1
Номер
замовника Прізвище Ім’я Номер
рахунка Адреса
120 Петренко Іван 432568 м. Полтава
123 Ткаченко Тарас 325672 м. Київ …
178 Кулик Тетяна 734589 м. Львів
Для кожної таблиці можна створити декілька індексів. Індекси дозволяють
впорядковувати записи, виконувати швидкий пошук потрібних даних та
встановлювати зв’язки між таблицями. Поля, які використовуються в
індексах, називаються ключами записів. Ключ може бути простим та
складеним. Простий ключ містить ім’я одного поля, а складений може
містити декілька полів. Первинний ключ (Primary key) повинен однозначно
ідентифікувати запис, тобто він може приймати тільки унікальне значення,
наприклад, поле «номер замовника».
База даних може містити декілька таблиць, які пов’язані поміж собою по
ключових полях. Наприклад, база даних «Замовники» крім таблиці
«Замовники» може мати таблицю «Замовлення» (табл. 2), яка містить усі
замовлення, що розміщені окремими замовниками. Замість повторення всієї
інформації замовника в кожному записі таблиці «Замовлення» ця таблиця
може містити єдине поле (номер замовника), яке ідентифікує відповідного
замовника.
Таблиця 2
Номер
замовлення Номер
замовника Дата Код товару Сума,
тис. грн
1234 123 10/03/01 25 123
1235 123 10/03/01 28 165
1238 178 10/03/01 28 154
1237 120 10/03/01 25 345
З табл. 2 бачимо, що замовник з номером 123 (Ткаченко) замовив товари 25
та 28. У табл. 1 первинним ключем є поле «Номер замовника», в табл. 2
первинним ключем є номер замовлення, а поле «номер замовника» в табл. 2
встановлює відношення (зв’язок) між таблицями і являє собою зовнішній
ключ, тому що він посилається на первинний ключ «зовнішньої» таблиці
«Замовники». Такий тип відношення має назву «one-to-many»
(один-до-багатьох), тому що один замовник може розміщати багато
замовлень, але окреме замовлення може бути розміщене тільки одним
замовником. Ще існують відношення «one-to-one» (один-до-одного) та
«many-to-many» (багато-до-багатьох). Відношення «one-to-one» (одному
запису в першій таблиці відповідає один запис
у другій таблиці) у реляційній моделі застосовується дуже рід-
ко, тому що такі дві таблиці можна з’єднати в одну. Відношен-
ня «many-to-many» використовується, якщо одному запису першої таблиці
відповідає декілька записів другої таблиці та одно-
му запису другої таблиці відповідає декілька записів першої
таблиці.
¶
?
A
A
I
I
?
th
– ^ I
I
Z\X
oeeaeUNE1/4®ENNNNNNNNN
d.y ¤ `„a$
y`„-
gd#)…
&
gd’ub
—0-6->-@-J-R-d-iiiiIiiiYkda
Ykdy
Mсутні у стовпчиках НОМЕР ЗАМОВНИКА табл. 1 та табл. 2, вибрані з
основного домену всіх можливих номерів замовника. Декартовим добутком
доменів D1, D2, … , Dn (позначається як D1 ( D2 ( … ( Dn) називається
множина всіх кортежів (V1, V2, … , Vn) довжини n, таких, що V1 належить
D1, V2 належить D2, … , Vn належить Dn, тощо. Наприклад, якщо n=2,
D1={0,1} та D2={r,f}, тоді D1 ( D2 є {(0,r), (0,f), (1,r), (1,f)} .
Відношення — підмножина декартового добутку одного або більше доменів.
Наприклад, {(0,r), (0,f), (1,r), (1,f)} є відношення визначеної раніше
підмножини D1 ( D2. Величина n являє собою ступінь відношення. Так, для
відношення ЗАМОВНИКИ ступінь має значення 5.
Елементи відношення називаються кортежами. Кожний кортеж містить n
компонентів.
Таблицю можна представити як відношення, де кожний кортеж — це рядок, а
кожний стовпчик відповідає одному компоненту. Стовпчики також
називаються атрибутами, але складаються вони з відповідного домену.
Список імен атрибутів відношення зветься схемою відношення. Наприклад,
відношення має назву ЗАМОВНИКИ. Його схема буде мати такий вигляд:
DOMAIN НОМЕР ЗАМОВНИКА NUMERIC (4)
DOMAIN ПРІЗВИЩЕ CHARACTER (20)
DOMAIN ІМ’Я CHARACTER (15)
DOMAIN НОМЕР РАХУНКА NUMERIC (10)
DOMAIN АДРЕСА CHARACTER (50)
RELATION ЗАМОВНИКИ (НОМ DOMAIN НОМЕР ЗАМОВНИКА)
ПРІЗВ DOMAIN ПРІЗВИЩЕ
NAME DOMAIN ІМ’Я
РАХ DOMAIN НОМЕР РАХУНКА
АДР DOMAIN АДРЕСА
Сукупність схем відношень, які використовуються для подання інформації,
називають схемою бази даних.
Таким чином, у табл. 1 зображено відношення ЗАМОВНИКИ ступеня 5, яке
визначено на доменах НОМЕР ЗАМОВНИКА, ПРІЗВИЩЕ, ІМ’Я, НОМЕР РАХУНКА,
АДРЕСА. У табл. 3 показаний декартовий добуток двох множин ЗАМОВНИКИ
(120, 123, 178) та КОД ТОВАРУ (25, 28).
Таблиця 3
Номер замовника Код товару
120 25
120 28
123 25
123 28
178 25
178 28
Для створення запитів у реляційних відношеннях використовується
реляційна алгебра, яка містить такі операції:
З’єднання. З’єднання відношень R1 та R2 є множиною кортежів R3, котрі
належать R1 або R2, або їм обом. Ця операція застосовується тільки до
відношень, які мають однакові стовпчики. Наприклад, відношення R1
містить працівників механічного цеху, а відношення R2 — збирального
цеху. Якщо відношення R3 з’єднання R1 та R2, тоді воно буде містити
працівників з обох цехів.
Різниця. Різницею відношень R1 та R2 є множина кортежів, що належать R1,
але не належать R2. Ця операція теж застосовується тільки до відношень,
які мають однакові стовпчики. Наприклад, відношення R1 містить усіх
працівників, а відношення R2 — тільки працівників механічного цеху.
Відношення R3, якщо воно є різницею відношень R1 та R2, буде містити
всіх працівників, окрім працівників механічного цеху.
Декартовий добуток. Якщо відношення R1 та R2 мають ступінь n1 та n2
відповідно, тоді декартовим добутком R1 ( R2 називається множина
кортежів довжини n1 + n2, перші n1 компонентів яких — це кортежі
відношення R1, а останні n2 — кортежі відношення R2. Фактично ця
операція повертає відношення, кортежі якого — це всі можливі комбінації
рядків початкових таблиць. Якщо кількість кортежів відношення R1 — N, а
відношення R2 — M, тоді результатом операції буде відношення, яке
складається з N*M кортежів.
Проекція. Сутність цієї операції полягає у тому, що з заданого
відношення R вилучаються деякі з його компонентів або (та)
переупорядковуються ті, що залишилися. Наприклад, проекцією відношення
ЗАМОВНИКИ може бути відношення із атрибутами: НОМЕР ЗАМОВНИКА, АДРЕСА.
Перехрестя. Перехрестям двох відношень R1 та R2 називається множина всіх
кортежів t, що належать як R1, так і R2. Відношення R1 та R2 повинні
мати однакову ступінь n та j-й атрибут одного з них повинен бути з того
ж самого домену, що і j-й атрибут другого. Наприклад, відношення R1
містить працівників усього підприємства, а R2 — працівників механічного
цеху. Відношення R3, яке є перехрестям відношень R1 та R2, буде містити
працівників лише механічного цеху.
Селекція. Ця операція повертає відношення R2, котре містить ті самі
атрибути, що і задане відношення R1, та частину кортежів R1. Значення
певних атрибутів цих кортежів відповідають деяким умовам. Наприклад,
однією з можливих рестрикцій відношення ЗАМОВНИКИ може стати відношення
замовників, котрі проживають у Києві та мають ім’я Віктор.
Можна виділити такі переваги реляційної моделі даних:
простота. Запити формулюються у термінах інформаційного змісту без
урахування складних аспектів системної реалізації;
непроцедурні запити. Запити можуть бути сформульовані непроцедурною
мовою, тому що вони не будуються на основі заздалегідь визначеної
структури;
незалежність даних. Під час використання реляційної моделі інтерфейс
користувача не пов’язаний з фізичною структурою даних та доступом до
них;
теоретичне обґрунтування. Під час проектування бази даних застосовуються
методи, які побудовані на нормалізації відношень. Нормалізація — це
структурування даних таким чином, щоб уникнути непотрібного дублювання
даних та забезпечити швидкий шлях пошуку необхідних даних.
Принципи та етапи проектування
бази даних
Проектування бази даних відбувається на основі концептуальних вимог її
кінцевих користувачів. Під час проектування бази даних враховується
таке:
база даних повинна задовольняти актуальним інформаційним потребам;
дані перед включенням до бази даних повинні перевірятися на
достовірність;
доступ до даних повинні мати тільки особи з відповідними повноваженнями;
база даних повинна легко розширятися під час реорганізації та збільшення
обсягів предметної області.
Етапи проектування бази даних:
Визначення мети створення бази даних.
Проектування концептуальної моделі бази даних.
Проектування зовнішніх моделей даних.
Проектування внутрішньої моделі даних.
Оцінка внутрішньої моделі даних.
Реалізація бази даних.
Аналіз ефективності бази даних.
PAGE 1
Зовнішня модель А
Мова
Робоча
область
Мова
Робоча
область
Мова
Робоча
область
Мова
Робоча
область
Користувач А1
Користувач А2
Користувач В1
Користувач В2
Зовнішня модель В
Модель даних
(концептуальна модель)
СУБД
База даних (внутрішня модель)
Нашли опечатку? Выделите и нажмите CTRL+Enter
