|
Санкт-Петербурзький політехнічний університет
Факультет управління та інформаційних технологій
Кафедра комп'ютерних інтелектуальних технологій у проектуванні
реферат
з історії науки
на тему: "Розвиток реляційної моделі представлення даних"
науковий керівник, к.т.н., проф .: Курочкін М.А.
виконала, асп .: Петрова М.А.
Санкт-Петербург
2006
БАЗИ ДАНИХ, РЕЛЯЦІЙНА МОДЕЛЬ, СУБД, СТАНДАРТ SQL, МОВА ОПИСУ ДАНИХ.
Реферат, сторінок: 17, література: 10 джерел.
Реферат присвячений.
зміст
Реляційна модель даних
Базою даних (БД) називають спеціальним чином форматований інформацію, збережену на машинному носії ... З базою даних безпосередньо працює система управління базою даних (СКБД) [8].
У широкому сенсі система управління базами даних (СКБД) - це комплекс мовних і програмних засобів, призначених для створення і експлуатації бази даних. У вузькому сенсі СУБД - це комплекс програм, що забезпечують інтерфейс (взаємозв'язок) прикладних програм і бази даних під час її експлуатації [8].
До складу СУБД входить мова визначення даних - Data Definition Language (DDL) [8].
Дані і доступ до них можуть бути організовані різними способами, що визначається моделлю даних, яку підтримує конкретна СУБД.
Наведене нижче визначення, дозволяє ефективно розділити модель даних і її реалізацію.
Модель даних - це абстрактне, самодостатнє, логічне визначення об'єктів, операторів і інших елементів, в сукупності складових абстрактну машину, з якою взаємодіє користувач. згадані об'єкти
дозволяють моделювати структуру даних, а оператори - поведінка даних [7].
Реалізація (implementation) заданої моделі даних - це фізичне втілення на реальній машині компонентів абстрактної машини, які в сукупності складають цю модель [7].
Кожна СУБД використовує одну, рідко кілька моделей даних. Модель даних CУБД реалізується двома мовами - мовою визначення даних (МОД) і мовою маніпулювання даними (ЯМД), тобто модель даних СУБД - це впорядкована пара: áЯОД СУБД, ММД СУБДñ [8].
На початку 70-80-х років існувало безліч різних моделей даних, найбільш популярними з яких були:
ієрархічна модель даних,
мережева модель даних
і реляційна модель даних [2].
Еволюція розвитку різних моделей даних добре простежується в книгах К. Дж. Дейта «Введення в теорію баз даних», які є класичним підручниками по курсу «Теорія баз даних» протягом останніх 30 років. Якщо в перших виданнях книги всі три підходи розглядалися рівноцінно, то в останніх виданнях ієрархічна і мережна моделі даних описуються як альтернативні додаткові підходи: перш за все, старі (дореляціонние) системи можна розділити на три великі категорії, а саме: системи інвертованих списків (inverted list ), ієрархічні (hierarchic) і мережеві (network). У даній книзі ми не будемо детально розглядати ці категорії, оскільки, по крайней мере, з точки зору технології, їх можна вважати застарілими [7].
В даний час більшість сучасних систем управління базою даних засновані на реляційній моделі даних.
Реляційна модель даних була вперше описана доктором Е.Ф. Коддом в 1970 році. Спочатку реляційна модель викликала більше академічний (стаття доктора Е. Ф. Кодда викликала хвилю досліджень в області реляційних баз даних, включаючи великий дослідницький проект компанії IBM. Мета цього проекту, названого System / R, полягала в тому, щоб довести працездатність реляційної моделі і придбати досвід реалізації реляційної СУБД. [4]), ніж практичний інтерес. У процесі дослідження знову з'явилася моделі, ряд компаній, помітивши явні її переваги, поспішили запропонувати власні комерційні реалізації цього реляційного підходу. Однак не всі розроблені СУБД реалізовували реляційну модель повністю. Щоб уникнути некоректного використання терміна «реляційний» в 1985 році доктор Кодд написав статтю, де сформулював 12 правил, які повинні бути необхідно виконані в будь-який реляційної СУБД. Дані 12 правил вважаються визначенням реляційної СУБД.
Для подальшого розгляду, можна скористатися спрощеним визначенням:
Реляційної називається база даних, в якій всі дані, доступні користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до операцій над цими таблицями [4].
В основі подання та обробки даних у вигляді таблиць лежить абстрактна теорія даних, заснована на деяких положеннях математики (в основному, теорії множин і логіки предикатів) [7]. Таким чином, об'єкти реляційної моделі мають точне формальне математичне опис, на основі якого і був розроблений стандарт мови опису даних, що дозволяє описувати таблиці і зв'язку між ними в сучасних СУБД. Незважаючи на те що, математична теорія надала інструменти для точного і повного опису методів представлення та обробки даних, реалізація реляційного підходу в СУБД відбувалася еволюційно:
На початку 60-х і початку 70-х років стали з'являтися спеціалізовані комп'ютерні програми, призначені для вирішення цієї [зберігання і обробка даних] завдання і відомі під назвою системи управління базами даних (СКБД) [4].
Досліджуючи можливості спрощення структури бази даних, науковий співробітник компанії IBM доктор Е.Ф. Кодд, запропонував використання нової реляційної моделі представлення даних. У червні 1970 року доктор Е.Ф. Кодд опублікував в журналі Communications of the Association for Computing Machinery статтю під назвою «Реляційна модель для великих банків спільно використовуваних даних» ( «A Relational Model of Data for Large Shared Data Banks»), в якій в загальних рисах була викладена математична теорія зберігання даних в табличній формі і їх обробки. Від цієї статті ведуть свій початок реляційні бази даних і SQL ... Стаття доктора Кодда викликала хвилю досліджень в області реляційних баз даних, включаючи великий дослідницький проект компанії IBM. ... Крім розробки самої СУБД в рамках проекту System / R проводилася робота над створенням мов запиту до бази даних. [4] Перша стаття з описом мови запиту вийшла в 1974 році. Дослідна експлуатація проекту System / R відбулася в 1978 році, а в 1979 році вже з'явилася перша комерційна версія реляційної СУБД компанії Oracle. На початку 80-х років з'являється ще кілька реалізацій реляційних СУБД і в 1986 році ANSI приймає перший стандарт SQL1. З цього моменту починається комерційне визнання реляційних СУБД і активний розвиток реляційної моделі представлення даних.
Реляційна модель даних
Математичною абстракцією реляційної моделі даних є реляційна алгебра [8].
Якщо A 1, A 2, ¼, A n ¾ безлічі, то будь-яка підмножина a Í A 1'A 2 '¼'A n, або будь-який елемент булеана (безлічі всіх підмножин) a Î P (A 1'A 2' ¼ 'A n), називають ставленням між множинами A 1, A 2, ¼, A n, т. е. ставлення ¾ це безліч впорядкованих «кортежів», в яких перший член є елементом множини A 1, другий ¾ елементом множини A 2 і т.д. [8]. Таким чином, можна сказати, що ставлення складається з ряду атрибутів, а ступінь відносини є число атрибутів у відношенні. У свою чергу, сукупність всіх кортежів для відносини називається таблицею, а визначення сукупності відносин залишає визначення бази даних [9].
Атрибут є нерозкладний елемент іменованих даних [9]. Несуча безліч реляційної алгебри складається з елементів, які конструюються з елементів двох словникових множин. Одне з цих множин позначимо N і будемо називати множиною імен атрибутів, а інше позначимо V і будемо називати множиною значень атрибутів [8]. Тоді відображення Dom: N ® P (V) визначається умовою: якщо A Î N, то Dom (A) = im T A. Пару á A, Dom (A) ñ називають атрибутом з ім'ям A і доменом Dom (A). [8]. З цього визначення також видно, що домен є сукупність значень, які можна асоціювати з одним або більше атрибутом [9]. Функція Dom: N ® P (V) розбиває безліч N на класи еквівалентності імен атрибутів. Еквівалентність атрибутів A, B Î N означає, що Dom (A) = Dom (B), т. Е. Цим іменам атрибутів призначена одна і та ж область значень. Наприклад, іменах атрибутів ВЕС і ВИСОТА може бути призначена одна і та ж область значень ¾ безліч позитивних дійсних чисел [8].
У реляційної моделі відносини мають певні властивості, причому всі вони дуже важливі і випливають безпосередньо з наведеного вище визначення відносини:
- все кортежі відносини різні;
- всі атрибути відносини різні;
- кортежі відношення не мають впорядкованості;
- кожен кортеж містить рівно одне значення для кожного атрибута,
- ставлення може не містити жодного кортежу (так як порожня множина також є ставлення);
- відношення має містити, принаймні, один атрибут;
- безліч атрибутів різних відносин можуть перетинатися;
- безлічі кортежів різних відносин можуть перетинатися.
Так як всі кортежі відносини необхідно різні, то кожне відношення матиме деяку комбінацію атрибутів, які, взяті разом, будуть однозначно ідентифікувати кортеж щодо [5]. Така комбінація атрибутів в реляційної моделі називається первинним ключем. Первинний ключ відносини може складатися як з одного атрибута, так і з усіх атрибутів відносини.
Якщо відношення містить кілька комбінацій атрибутів однозначно ідентифікують кортеж, то такі комбінації називають можливими ключами. Поняття первинного ключа дозволяє встановлювати зв'язки між відносинами: атрибут відносини R1 є зовнішнім ключем, якщо цей атрибут - не первинні ключ відносини R1, але його значення є значеннями первинного ключа деякого відносини R2 [5].
Додатковим об'єктом, включеним в реляційну модель представлення даних, є каталог.
Каталог - це набір системних змінних-відносин, що містять метадані про різні елементи, важливих для системи (базових змінних-відносинах, представлених, індексах, користувачів і т.д.). [7]
Чудовим властивістю реляційних систем є те, що їх каталог також складається з змінних-відносин (точніше, з системних змінних-відносин, названих так для того, щоб відрізняти їх від звичайних користувальницьких). В результаті користувач може звертатися до каталогу так само, як до своїх даних. Наприклад, в каталозі зазвичай містяться системні змінні-відношення TABLES і COLUMNS, призначення яких - опис відомих системі таблиць (тобто змінних-відносин) і стовпців цих таблиць. (Ми говоримо "зазвичай", тому що каталоги в різних системах різні, адже чимала частина інформації каталогу є специфічною для конкретної системи.) [7].
Таким чином, реляційна модель представлення даних вводить поняття:
домен
Атрибут
ставлення
Первинний ключ відносини
Зовнішній ключ відносини
Каталог
Конкретна реалізація реляційної СУБД, як правило, включає також можливість визначення додаткових об'єктів.
Таким чином, в 70-х роках була сформульована математична теорія, основоположником якої є доктор Е.Ф. Кодд, на основі якої була розроблена реляційна модель і засоби її опису, що лягли в основу сучасних СУБД.
Мова опису даних в стандарті SQL
У статті, опублікованій в журналі Computerworld в 1985 році, доктор Е. Ф. Кодд сформулював 12 правил, яким повинна відповідати реляційна база даних. Перераховані правила засновані на теоретичних засадах реляційної моделі даних:
Дванадцять правил Кодда, яким повинна відповідати реляційна база даних:
1. Правило інформації. Вся інформація в базі даних повинна бути представлена виключно на логічному рівні і лише одним способом - у вигляді значень, що містяться в таблицях.
2. Правило гарантованого доступу. Логічний доступ до всіх і кожного елементу даних (атомарному значенню) в реляційної базі даних повинен забезпечуватися шляхом використання комбінації імені таблиці, первинного ключа і імені стовпця.
3. Правило обробки відсутніх значень. У цій реляційній базі даних повинна бути реалізована підтримка відсутніх значень, які відрізняються від рядка символів нульової довжини, рядки символів пробілів і від нуля або будь-якого іншого числа і використовуються для подання відсутніх даних незалежно від типу цих даних.
4. Правило динамічного каталогу, заснованого на реляційної моделі. Опис бази даних на логічному рівні має бути представлено в тому ж вигляді, що і основні дані, щоб користувачі, які володіють відповідними правами, могли працювати з ним за допомогою того ж реляційного мови, який вони застосовують для роботи з основними даними.
5. Правило вичерпного под'язика бази даних. Реляційна система може підтримувати різні мови і режими взаємодії з користувачем. Однак повинен існувати, принаймні, одна мова, інструкції якого можна представити у вигляді рядків символів відповідно до деяким чітко визначеним синтаксисом і який в повній мірі підтримує всі наступні елементи:
a. визначення даних;
b. визначення уявлень;
c. обробку даних (інтерактивну і програмну);
d. умови цілісності даних;
e. ідентифікацію прав доступу;
f. кордони транзакцій (початок, завершення і скасування).
6. Правило поновлення уявлень. Всі вистави, які теоретично можна оновити, повинні бути доступні для оновлення.
7. Правило додавання, оновлення та видалення. Можливість працювати з ставленням як з одним операндом повинна існувати не тільки при вибірці даних, по і при додаванні, оновленні та видаленні даних.
8. Правило фізичної незалежності даних. Прикладні програми і утиліти для роботи з даними повинні па логічному рівні залишатися недоторканими при будь-яких змінах способів зберігання даних або методів доступу до них.
9. Правило логічної незалежності даних. Прикладні програми і утиліти для роботи з даними повинні на логічному рівні залишатися недоторканими при внесенні в таблиці бази даних будь-яких змін, які теоретично дозволяють зберегти недоторканими що містяться в цих таблицях дані.
10. Правило незалежності умов цілісності даних. Повинна существвать можливість визначати умови цілісності, специфічні для конкретної реляційної бази даних, на підмові цієї бази даних і зберігати їх в динамічному каталозі, а не в прикладній програмі.
11. Правило незалежності розміщення. Реляційна база даних не повинна залежати від особливостей системи, в якій вона розташована.
12. Правило єдиності. Якщо в реляційної системі є низькорівневий мову (що обробляє один запис за один раз), то має бути відсутня можливість використання його для того, щоб обійти правила і умови цілісності даних, виражені на реляционном мовою високо: рівня (обробному кілька записів за один раз) [4 ].
Поява реляційних баз даних викликала поява кількох діалектів мови керування базами даних. Стандартом де-факто стала мова структурованих запитів (SQL). Робота над офіційним стандартом SQL почалася в 1982 році і перший стандарт був офіційно виданий в 1986 році. Однак конкретні реалізації значно відрізнялися від оголошеного стандарту.
У стандарті SQL використовуються поняття, які засновані на поняттях реляційної моделі:
Таблиця - Ставлення
Рядок або запис - Кортеж
Кількість рядків - кардинально
Стовпець або поле - Атрибут
Кількість стовпців - Ступінь
Унікальний ідентифікатор - Первинний ключ
Сукупність допустимих значень - Домен.
Для зміни і опису структури бази даних призначений набір інструкцій SQL, який називається мовою визначення баз даних (МОД). У більшості випадків інструкції ЯОД забезпечують високий рівень доступу до даних і дозволяють користувачеві не вникати в деталі зберігання інформації в базі даних на фізичному рівні [4].
Основними операторами, реалізованими в ЯОД є:
- Оператор створення об'єкта бази даних (CREATE)
- Оператор видалення об'єкта (DROP)
- Оператор модифікації об'єкта (ALTER)
Практично всі комерційні СУБД підтримують ЯОД як невід'ємну частину мови SQL, хоча стандарт SQL1 цього не вимагає. У прийнятому в 1992 році стандарті SQL2 були визначені ті частини ЯОД, які є незалежними від структур фізичного зберігання, особливостей операційної системи та інших специфічних особливостей СУБД. В конкретних же реалізаціях СУБД включають безліч доповнень ЯОД, пов'язаних зі специфікою реалізації кожної конкретної СУБД [4].
Якщо розглянути три версії стандарту SQL (1986год, 1992 рік, 2003 рік), то можна простежити розвиток реалізації реляційної моделі представлення даних.
стандарт SQL1
Реляційна модель даних не вказує на те, як різні відносини групуються в різні бази даних. Внаслідок цього, в різних СУБД спочатку застосовувалися неоднакові підходи до цього питання. У стандарті SQL1 міститься специфікація мови SQL, що використовується для опису структури бази даних, але не вказується спосіб створення бази даних [4]. В даний час, методи створення баз даних в різних СУБД також мають явні відмінності:
В СУБД DB2 структура бази даних визначена за замовчуванням. База даних асоціюється з виконуваної копією серверного забезпечення DB2, і користувач отримує доступ до бази даних, підключаючись до сервера DB2. База даних створюється в процесі інсталяції DB2 на конкретну комп'ютерну систему.
У СУБД Oracle база даних створюється в ході процесу установки програмного забезпечення, як і в DB2 [4] В останніх версіях СУБД Oracle з'явилася інструкція CREATE DATABASE, яка визначається стандартом SQL2.
В СУБД MySQL при установці серверного забезпечення створюється дві системних бази даних: mysql - містить, системну інформацію і test - тестова база даних. Користувач може створювати бази даних за допомогою інструкції CREATE DATABASE або просто створивши каталог з ім'ям бази даних в каталозі даних сервера mysql.
Опис таблиці відбувається за допомогою спеціальної інструкції SQL: кожен оператор CREATE TABLE задає ім'я створюваної базової таблиці, імена і типи даних стовпців цієї таблиці, а також первинний ключ таблиці і будь-які зовнішні ключі, присутні в ній [7].
При цьому, важливою відмінністю від реляційної моделі є заборона на визначення користувачем власних типів даних. Для визначення стовпців можна використовувати тільки вбудовані (певні системою) типи [6].
стандарт SQL2
У стандарті SQL2 навмисне не дано визначення терміна база даних, оскільки цей термін в різних СУБД трактується по-різному. Замість нього вживається термін каталог, що означає іменовану колекцію системних таблиць, що описують структуру бази даних. У стандарті також не вказано як повинен створюватися і знищуватися каталог [4].
У мові SQL існує аналог того, що прийнято називати каталогом, - інформаційна схема. ... Нестрой кажучи, каталог в мові SQL складається з дескрипторів (метаданих) для окремої бази даних, а схема складається з дескрипторів тієї частини бази даних, яка належить окремому користувачеві. Іншими словами, в системі може бути будь-яке число каталогів (по одному для кожної бази даних), кожен з яких ділиться на довільне число схем. Однак кожен каталог повинен містити рівно одну схему з ім'ям INFORMATION_SCHEMA (інформаційна схема), яка, з точки зору користувача, і є схемою (як уже зазначалося), яка виконує функції звичайного каталогу.
Таким чином, інформаційна схема складається з набору SQL-таблиць, вміст яких фактично відображає (точно певним чином) все визначення з усіх інших схем розглянутого каталогу. ... Для підтримки схеми визначення реалізація не потрібно, але вона потрібна, по-перше, для підтримки деякого виду "схеми визначення" і, по-друге, для підтримки уявлень такий "схеми визначення", які мають вигляд, подібний уявленням інформаційної схеми [7].
У стандарті SQL2 з'являється можливість визначення динамічних масивів з елементами будь-якого допустимого в SQL типу, крім типу масиву. Тип масиву утворювався за допомогою конструктора типів масивів ARRAY.
Таким чином, значенням атрибута може бути не атомарним!
Ця зміна настільки важливо, що К. Дж. Дейт пише в своєму останньому виданні:
"Основною причиною того, що тут явно розглядається можливість використання відносин з атрибутами, які беруть в якості значень відносини, є те, що історично в більшості публікацій по базах даних (включаючи попередні видання цієї книги) це вважалося неприпустимим (а в більшості видань вважається таким і понині). Ось, наприклад, кілька відредагована цитата з попереднього видання цієї книги.
'Зверніть увагу на те, що всі значення стовпців атомарні ... Це означає, що на кожному місці в стовпці або рядку завжди знаходиться рівно одне значення, а не група з декількох значень ... У реляційних базах даних повторювані групи неприпустимі, тому використання другого варіанту таблиці в рамках реляційної моделі заборонено.
Ось ще одна цитата з тієї ж книги.
[Домени] складаються тільки з атомарних значень ... [Тому] відносини не містять повторюваних груп. Ставлення, що відповідає цим умовам, називається нормалізованим або, що рівносильно, ставленням в першій нор мальної формі ... Під терміном відношення в контексті реляційної моделі завжди буде матися на увазі нормалізоване відношення.
Однак, по крайней мере, в цілому, ці висловлювання невірні. Вони є наслідком помилкового розуміння автором справжньої природи типів і предикатів "[7].
У стандарті SQL2 з'являється також можливість визначення власного типу даних: домен - це не що інше, як тип даних (або, для стислості, - просто тип); зокрема, можливо, простий, який визначається системою, подібно типам INTEGER і CHAR. У загальному випадку цей тип визначається користувачем, як, наприклад, типи Si, Pi, WEIGHT і QTY в базі постачальників і деталей. Насправді терміни домен і тип даних взаємозамінні [7].
стандарт SQL3
Найбільш серйозні зміни мови SQL, що відносяться до опису даних в SQL3, стосуються наступних аспектів:
· Типи даних;
· Розширені можливості оператора CREATE TABLE;
· Новий об'єкт схеми - генератор послідовностей;
· Нові види стовпців - ідентифікують стовпці (identity column) і генеруються стовпці (generated column);
Всі найбільш очевидні аспекти новизни в мові SQL3 пов'язані з типами даних. З'явилися нові вбудовані типи даних, точніше - нові вбудовані скалярні типи даних, а також нові генератори типів, які в мові SQL3 називаються конструкторами типу. Оператор CREATE TYPE дозволяє користувачам визначати власні типи (звичайно, є і відповідний оператор DROP TYPE) [7].
Стандарт SQL3 розширює можливості використання колекцій в двох важливих напрямках. По-перше, запроваджується новий конструктор типів мультимножин MULTISET. По-друге, типом елементів будь-якого типу колекцій тепер може бути будь-який допустимий в SQL тип даних, крім самого конструюється типу колекції. Тим самим, в базі даних допускається довільна вкладеність таблиць. Можливості вибору структури бази даних безмежно розширюються.
У SQL3 з'явилася можливість визначення нового виду об'єктів бази даних - генераторів послідовностей (sequence generators). Такого роду об'єкти виробляють змінювані в часі точні числові значення
Нарешті, один або декілька стовпців визначається базової таблиці можуть бути специфіковані як генеруються стовпці (generated columns).
Розвиток реалізації реляційного представлення даних СУБД MySQL
СУБД MySQL класифікується як реляційна система управління базами даних (RDBMS- relational database management system). Ця абревіатура розбивається на частини таким чином.
• База даних (БД) (DB в RDBMS) - це сукупність інформації, розбитою простим, регулярним чином.
• Сукупність даних в базі даних об'єднана в таблиці.
• Таблиця складається з рядків і стовпців.
• Рядок таблиці є її записом.
• Записи містять кілька одиниць інформації, кожен стовпець таблиці містить одну таку одиницю.
• Система управління (СУ) (MS - management system) є програмним забезпеченням, що дозволяє вставляти, вибирати, модифікувати і видаляти записи.
• Слово "реляційна" позначає популярну різновид СУБД, в яких відстежується "відповідність" записів в одній таблиці на "відповідність" записів в іншій таблиці. Міць реляційних СУБД полягає в їх здатності вибирати відповідні дані з цих таблиць і створювати відповіді на питання, які не можна отримати тільки з однієї такої таблиці [10].
Одна з головних задач при розробці цього [СУБД MySQL] продукту полягає в тому, чоби продовжувати роботу в напрямку максимальної відповідності стандарту SQL, однак, не жертвуючи при цьому продуктивністю і надійністю [1]
Грунтуючись на теоретичних положеннях, виробники реляційних баз даних розробляють конкретні реалізації СУБД, в яких для опису даних використовується реляційна модель. При цьому постійно відбувається розширення (розвиток) реалізації реляційної моделі, в тому числі за рахунок появи реалізації представлення нових об'єктів.
Розвиток реалізації реляційної моделі в СУБД MySQL відбувалося наступним чином:
домен:
В СУБД MySQL підтримується безліч типів стовпців різних категорій: числові типи, типи дати і часу і строкові (символьні) типи [2]. Тим самим СУБД MySQL, реалізує заздалегідь певні домени, але не дозволяє визначати домен, тобто безліч значень даного атрибута. Дане обмеження присутній і в поточній реалізації цього продукту.
Наближеною і неповної реалізацією домену є два типи даних: ENUM і SET, що дозволяють задавати безліч з різних строкових елементів. Але це абсолютно не відповідає вимогам реляційної моделі.
Атрибут:
Атрибут (стовпець) в СУБД MySQL може приймати тільки скалярні значення і не допускає можливість використання множинних або табличних типів.
Дане обмеження також присутній і в поточній реалізації цього продукту.
ставлення:
Інструкція CREATE TABLE створює таблицю з вказаним ім'ям і переліком стовпців [2]. Можливості деталізації опису таблиці помітно збільшилися в порівнянні з першими версіями системи.
Первинний ключ відносини:
Унікальність кожного запису таблиці виконується на фізичному рівні реалізації СУБД. Тим самим, таблиці можуть містити рядки однакових значень. На практиці, унікальність кожного рядка таблиці можна визначити за допомогою завдання первинного ключа, який може складатися як з одного стовпчика таблиці, так і з групи стовпців. Визначений таким способом первинний ключ, дозволить СУБД автоматично відстежувати унікальність вводяться в таблицю значень. Крім цього, реалізована можливість автоматичної генерації первинного ключа. Обмеженням на автоматично генерується значення є те, що воно є цілим числом. У наступних версіях реалізації СУБД MySQL, це обмеження стало ще суворіше: значення автоматично генерується первинного ключа є натуральним.
Зовнішній ключ відносини:
У перших версіях можливість визначення зовнішнього ключа не підтримувалася і перекладалася на розробника бази даних. У версії MySQL 4.0 вперше з'явилася можливість визначати зовнішні ключі і забезпечувати кількість посилань цілісність баз даних.
Каталог:
Можливість визначення рейтингів була реалізована в СУБД MySQL тільки у версії 5.0, c введенням об'єкта INFORMATION SCHEMA.
Сучасні СУБД послідовно включають в свій склад нові і все більш складні елементи реляційної моделі представлення даних.
Ефективна реалізація конкретного об'єкта реляційної моделі часто вимагає великих затрат часу, які складаються з часу проектуванні, впровадження та налагодження конкретного програмного забезпечення.
Шляхи розвитку сучасних реалізацій реляційних СУБД
Як зазначалося у вступі до цієї чолі, мова SQL далекий від досконалості і має недоліки, викликані численними недоробками і переробками. ... Тут лише зазначимо, що основний недолік полягає в тому, що, строго кажучи, мова SQL, в цілому, некоректно підтримує реляційну модель. Тому виникає сумнів, чи заслуговують сучасні SQL-продукти права називатися дійсно реляційними. Фактично, наскільки це відомо автору, на сьогоднішній день на ринку немає жодне го продукту, який підтримував би реляційну модель в повному обсязі. Ми не хочемо цим сказати, що якісь аспекти реляційної моделі не важливі; як раз навпаки, кожен елемент в моделі важливий. Більш того, кожен з її елементів важливий по чисто практичних міркувань. Не можна не підкреслити той незаперечний факт, що призначення реляційної теорії полягає не в тому, щоб просто бути "теорією для теорії". Зовсім ні, її призначення - забезпечити базу для побудови систем, які бу дуть практичними на всі сто відсотків. Але, як це не сумно, з боку виробників продуктів ще не зроблено реальних кроків до вирішення проблеми реалізації реляційної теорії у всій її повноті. В результаті "реляційні" продукти сьогоднішнього дня всі як один з тих чи інших причин виявляються нездатними реалізувати переваги, які теоретично можуть бути отримані в результаті використання реляційної технології [7].
Сьогодні конкуренція між постачальниками СУБД лежить в області продуктивності, нових можливостей, спеціалізованих засобів розробки, якості служб технічної підтримки і т. П., Про відповідність правилам Кодда згадують рідко. Проте, вони залишаються важливою частиною історії реляційної моделі даних [4].
У 90-х роках реляційним СУБД склали конкуренцію СУБД, засновані на принципах об'єктно-орієнтованого програмування. В даний час дані принципи впроваджуються в реляційну модель, модифікуючись в її складову частину.
Таким чином, розвиток сучасних СУБД відбувається на поточний момент в наступних напрямках:
· Розвиток реалізації реляційної моделі, з метою найбільш повної відповідності реляційної алгебри, без втрат продуктивності і ефективності програмних продуктів.
· Розвиток реляційно-об'єктних СУБД.
· Поєднання реалізації реляційної алгебри з сучасними технологіями програмування.
Фактично введення реляційної моделі в 1969 і 1970 роках було, безсумнівно, найбільш важливою подією в історії розвитку теорії баз даних [7].
Список літератури
[1] - MySQL. Керівництво адміністратора. : Пер. з англ. - М.: Видавничий дім «Вільямс», 2005.
[2] - MySQL. Довідник по мові. : Пер. з англ. - М.: Видавничий дім «Вільямс», 2005.
[3] - Гектор Гарсіа-Моліна, Джеффрі Ульман, Дженніфер Уідом. Система баз даних. Повний курс .: Пер. з англ. - М .: Видавничий дім «Вільямс», 2003.
[4] - Дж. Грофф, П. Вайнберг. Енциклопедія SQL. 3-е видання. - СПб .: Пітер, 2003.
[5] - К. Дейт. Введення в системи баз даних, 2-е видання: М .: 1980.
[6] - К. Дж. Дейт. Введення в системи баз даних, 6-е видання: Пер. з англ. - К .; М .; СПб .: Видавничий дім «Вільямс», 2000..
[7] - К. Дж. Дейт. Введення в системи баз даних, 7-е видання: Пер. з англ. - К .; М .; СПб .: Видавничий дім «Вільямс», 2001.
[8] - В. П. Євменов. Бази даних, частина 1, Методологія теорії баз даних. Навчальний посібник. - СПб, СПбДПУ, 2005
[9] - Т. В. Олле. Пропозиція Кодас з управління базами даних. : Пер. з англ. - М .: Фінанси і статистика, 1981.
[10] - Джо Селко. Програмування на SQL для професіоналів. 2-е видання: Пер. з англ. - М .; Видавництво «Лорі», 2004.
|