Апаратне забезпечення систем управління базами даних

В залежності від вимог поставленої задачі, конкретної СУБД і ОС апаратні

засоби можуть змінюватися від одного ПК або мейнфрейму до мережі багатьох

комп'ютерів. СУБД потребує певної мінімальної конфігурації апаратних засобів,

але для хорошої продуктивності системи цього може не вистарчити. Програмне забезпечення СУБД

Включає в себе ПЗ:

• самої СУБД;

• прикладних програм;

• ОС;

• мережеве.

Програми в основному створюються на мовах 3-го (C, Fortran, Pascal і т.д.)

і 4-го покоління (SQL і т.д.), оператори яких вбудовуються в програми мовими

3-го покоління. Мови 4-го покоління можуть підвищити продуктивність

системи і зручність для обслуговування програм. СУБД складаються з декількох

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

надає базові служби, а СУБД представляє собою надбудову над ними.

Основні програмні компоненти середовища СУБД:

• процесор запитів: перетворює запити в послідовність низькорівневих

інструкцій для контролера бази даних;

• контролер бази даних: взаємодіє з запущеними користувачами

прикладними програмами і запитами (приймає запити; перевіряє зовнішні

і концептуальні схеми для визначення концептуальних записів, які

задовольняють вимоги запиту; потім викликає контролер файлів для

виконання запиту, який поступив);

• контролер файлів: маніпулює файлами, які призначені для зберігання

даних, і відповідає за розподіл доступного дискового простору; створює і

підтримує список структур і індексів, які визначені у внутрішній схемі (у

випадку використання хешованих файлів, викликає функцію хешування

для генерації адрес і запитів); не управляє фізичним вводом і виводом,

лише передає команди відповідним методам доступу, які зчитують дані в

системні буфери або записують їх звідти на диск;

• препроцесор мови DML: перетворює вбудовані в прикладні програми

DML-оператори в виклики стандартних функцій базової мови (для

генерації відповідного коду препроцесору мови DML повинен

взаємодіяти з процесором запитів);

• компілятор мови DDL: перетворює DDL-команди в набір таблиць, які

містять метадані, після чого таблиці зберігаються в системному каталозі,

а керуюча інформація - в заголовках файлів з даними;

• контролер словника: керує доступом до системного каталогу і забезпечує

роботу з ним (системний каталог доступний більшості компонентів

СУБД).

 

 

Реляційна модель даних

В деяких випадках при ієрархічному і мережному представлені зростання

бази даних може привести до порушення логічної організації даних. Такі

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

Недоліки ієрархічної і мережної моделей привели до появи нової, реляційної моделі даних, створеної Коддом у 1970 році .Реляційна модель була спробою спростити структуру бази даних. У ній були відсутні явні покажчики на предків і нащадків, а всі дані були представлені у виді простих таблиць, розбитих на рядки і стовпці.

Реляційною називається база даних, у якій усі дані, доступні користувачу,

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

У реляційної базі даних інформація організована у виді таблиць,

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

Двохвимірні таблиць в математиці отримали назву відношення .

У кожного стовпця в таблиці є своє ім'я, що звичайно служить заголовком

стовпця. Усі стовпці в одній таблиці повинні мати унікальні імена, однак

дозволяється привласнювати однакові імена стовпцям, розташованим в різних таблицях.

Стовпці таблиці упорядковані зліва направо, і їхній порядок визначається

при формуванні таблиці. У будь-якій таблиці завжди є як мінімум один

стовпець.

Як правило, не вказується максимально допустиме число стовпців у

таблиці, однак майже у всіх комерційних СКБД ця межа існує і , як правило, складає приблизно 255 стовпців.

На відміну від стовпців, рядки таблиці не мають визначеного порядку. Це

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

Рядки таблиці утворюють данні різного формату і різного типу, тобто

можна стверджувати, що рядки таблиці є кортежами.

У таблиці може міститися будь-як кількість рядків. Цілком припустиме

існування таблиці з нульовою кількістю рядків. Така таблиця називається

порожньою. Порожня таблиця зберігає структуру, визначену її стовпцями,

просто в ній не містяться дані. Стандарти реляційних баз даних не накладають обмежень на кількість рядків у таблиці, і в багатьох СКБД розмір таблиць обмежений лише вільним дисковим простором комп'ютера. Як правило, в сучасних реляційних БД допускається збереження символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральных" даних (дата, час, часовий інтервал).

Найменша одиниця даних реляційної моделі - це окреме атомарне

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

Опис кожного відношення складається з імені відношення (підмет), за

яким в круглих дужках перечисляться список атрибутів(присудок). Цей опис називають інтенсіоналом або схемою відношення. Під описом слідує деяке заповнення кортежів відношення, яке називають екстенсіоналом. Відношення називаються еквівалентними, якщо вони відрізняються тільки порядком чергування атрибутів.

Кодд у 1985 році сформулював 12 правил, яким повинна задовольняти

будь-як база даних, що претендує на тип реляційної. З того часу дванадцять правил Кодда вважаються визначенням реляційної СУБД.

Дванадцять правил Кодда, яким повинна відповідати реляційна СКБД.

1. Правило інформації.

Вся інформація в базі даних повинна бути надана винятково на логічному

рівні і тільки одним способом - у виді значень, що містяться в таблицях.

2. Правило гарантованого доступу.

Логічний доступ до всіх і кожного елементу даних (атомарному значенню)

у реляційній базіданих повинний забезпечуватися шляхом використання

комбінації імені таблиці, первинного ключа та імені стовпця.

3. Правило підтримки недійсних значень.

У реляційній базі даних повинна бути реалізована підтримка недійсних

значень, що відрізняються від рядка символів нульової довжини, рядка символів пробілів чи нуля будь-якого іншого числа і використовуватися для представлення відсутніх даних незалежно від типу цих даних.

4. Правило динамічного каталогу, заснованого на реляційній моделі.

Опис бази даних на логічному рівні необхідно представити в тому ж виді,

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

5.Правило вичерпної підмови даних.

Реляційна система може підтримувати різні мови і режими взаємодії з

користувачем (наприклад, режим питань і відповідей). Однак повинна існувати принаймні одна мова, оператори якої підтримують наступні елементи: визначення даних; визначення представлень; обробку даних (інтерактивну і програмну); умови цілісності; ідентифікацію прав доступу; границі транзакцій (початок, завершення і скасування).

6. Правило відновлення представлень.

Усі представлення, які теоретично можна обновити, повинні бути доступні для відновлення.

7. Правило додавання, відновлення і вилучення.

Можливість працювати з відношенням як з одним операндом повинна

існувати не тільки при читанні даних, але і при додаванні, відновленні вилученні даних.

8. Правило незалежності фізи данихчних.

Прикладні програми й утиліти для роботи з даними повинні на логічному

рівні залишатися недоторканими при будь-яких змінах методів збереження даних чи методів доступу до них.

9. Правило незалежності логічних даних.

Прикладні програми й утиліти для роботи з даними повинні на логічному

рівні залишатися недоторканими при внесенні в базові таблиці будь-яких змін, які теоретично дозволяють зберегти недоторканими дані, що містяться в цих таблицях.

10. Правило незалежностіумов цілісності.

Повинна існувати можливість визначати умови цілісності, специфічні для

конкретної реляційної бази даних, на підмові реляційної бази даних і зберігати їх у каталозі, а не в прикладній програмі.

11. Правило незалежності поширення.

Реляційна СКБД не повинна залежати від потреб конкретного клієнта.

12. Правило одиничності.

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: