Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Принципи реляційної моделі

У середині 1980-х рр. співробітник IBM Е. Кодд [1] , розглядаючи особливості подання реляційних баз даних і роботи з ними, сформулював основні принципи. Ці принципи лягли в основу створення всіх сучасних систем управління базами даних і застосовуються при розробці реляційних моделей. Ці принципи були названі "Правила Кодда".

правило Про

Фундаментальне правило. Реляційна СУБД повинна бути здатна повністю управляти базою даних через її реляційні можливості.

Це правило було сформульовано Е. кодло через деякий час після формулювання всіх основних правил, але стало основним правилом, поставленим з номером "О", оскільки є основоположним, відображаючи необхідність жорсткого дотримання всіх інших правил.

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

правило 1

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

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

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

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

правило 2

Гарантований доступ. Логічний доступ до будь-якого елементу даних повинен бути забезпечений через використання комбінації імені таблиці, імені поля (колонки) і значення первинного ключ [2] .

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

  • • кожна таблиця в базі даних має унікальний найменуванням;
  • • кожне поле (колонка) таблиці володіє унікальним найменуванням;
  • • в кожній таблиці значення первинного ключа є унікальним.

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

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

правило 3

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

Передбачається, що в процесі обробки даних деякі значення не будуть визначені ні користувачем, ні СУБД, ні будь-яким іншим способом або джерелом даних. Такі значення є невідомими (unknown), і в багатьох засобах роботи з даними такі значення призводять до появи помилок і непередбачуваних результатів.

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

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

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

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

правило 4

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

Словник даних представляється відомостями про структуру бази даних, що використовуються в базі даних об'єктах, процедурах, запитах і т.д. Правилом визначається сувора необхідність доступу до цих відомостей, при наявності відповідних прав доступу, на рівні операцій з реля- ційних і відноси ІЯМ і.

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

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

правило 5

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

Це правило не заперечує наявності безлічі мов роботи з даними, але зобов'язує до використання такої мови, який дозволить виконати будь-які операції над даними, включаючи відомості про структуру даних (словник даних). Такою мовою став Б () Ц є стандартом для роботи з даними в СУБД. При цьому практично у всіх СУБД існують розширення мови БОБ, що формують власну мову СУБД.

Єдина мова роботи з даними обов'язково повинен мати наступні властивості:

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

складових прикладної програми, де оператори мови є компонентами прикладного мови програмування.

При цьому мова обов'язково повинен забезпечувати ряд операцій, що реалізують всеосяжний набір дій з даними:

визначення структури даних, де оператори мови дозволяють формувати словник даних і дають можливість користувачеві отримувати необхідні відомості про об'єкти бази даних;

- Визначення уявлень, коли оператор мови дає можливість сформувати результат вибірки даних на основі запиту користувача до даних;

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

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

  • - Ідентифікація прав доступу, коли операторами мови можна призначити або зняти право на доступність даних і об'єктів бази даних для будь-яких операторів обробки даних і надання відомостей але запитам користувачів;
  • - Визначення меж транзакцій, коли для кожної транзакції чітко визначено початок, завершення або скасування, враховуючи, що транзакція містить безліч операторів мови, дозволяючи, тим самим, забезпечити більш якісну обробку даних, не створюючи "сміття" [3] в базі даних.

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

правило 6

Модифікація уявлень. Всі вистави повинні бути поновлюваними.

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

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

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

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

правило 7

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

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

правило 8

Незалежність фізичних даних. Прикладні програми не повинні залежати від правил зберігання та розміщення відомостей у базі даних.

Дане правило розділяє прикладні рішення на два рівня: прикладна програма і база даних. Кожен з рівнів є умовно незалежною від іншого, в припущенні, що, коректуючи фізичне розміщення бази даних на носіях і змінюючи апаратне забезпечення комп'ютерів і серверів, ми жодним чином не повинні міняти прикладні програми, звертаючись до даних в базі даних.

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

правило 9

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

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

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

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

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

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

правило 10

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

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

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

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

правило 11

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

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

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

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

правило 12

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

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

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

Хоча перелічені правила мають відношення переважно до реалізації технологій роботи з даними в СУБД, вони дають більш широке розуміння в частині організації моделі даних і параметрів, які повинні описуватися в моделі даних. Реляційна модель, крім організації структури даних, передбачає зазначення відомостей про типи і потужностей (кардинальності) зв'язків, визначаючи деякі правила цілісності, які будуть використовуватися в базі даних на фізичному рівні. Вказівка ​​замовчувань і обмежень для атрибутів також застосовується для забезпечення цілісності і створює передумови для коректного застосування розглянутих правил. Те ж має відношення і до багатьох інших параметрах моделей, до яких можна віднести визначення тригерних дій, формулювання уявлень, встановлення правил по ключам (первинні, зовнішні і ін.).

  • [1] Codd Е. F. Is Your DBMS Really Relational? // ComputerWorld. 1985. 14, Oct.
  • [2] Термін "Первинний ключ * буде розглядатися в гл. 2.
  • [3] Під "сміттям"> в базах даних розглядаються дані, які не можуть бути оброблені користувачем стандартними засобами програми і вимагають сервісних операцій на рівні СУБД.
 
<<   ЗМІСТ   >>