Что значит реляционная база данных

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Реляционная база данных

Содержание

История

Реляционные системы берут свое начало в математической теории множеств. Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970).

Нечеткость многих терминов, используемых в сфере обработки данных, заставила Кодда отказаться от них и придумать новые или дать более точные определения существующим. Так, он не мог использовать широко распространенный термин «запись», который в различных ситуациях может означать экземпляр записи, либо тип записей, запись в стиле Кобола (которая допускает повторяющиеся группы) или плоскую запись (которая их не допускает), логическую запись или физическую запись, хранимую запись или виртуальную запись и т.д. Вместо этого он использовал термин «кортеж длины n» или просто «кортеж», которому дал точное определение.

Кодд предложил модель, которая позволяет разработчикам разделять свои базы данных на отдельные, но взаимосвязанные таблицы, что увеличивает производительность, но при этом внешнее представление остается тем же, что и у исходной базы данных. С тех пор Кодд считается отцом-основателем отрасли реляционных баз данных. Кодд сформулировал 12 правил для реляционных баз данных, большинство которых касаются целостности и обновления данных, а также доступа к ним.

Правила Кодда

Правило 0: Основное правило (Foundation Rule):

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

Правило 1: Информационное правило (The Information Rule):

Вся информация в реляционной базе данных на логическом уровне должна быть явно представлена единственным способом: значениями в таблицах.

Правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):

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

Правило 3: Систематическая поддержка отсутствующих значений (Systematic Treatment of Null Values):

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

Правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):

Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.

Правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):

Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который (а) имеет линейный синтаксис, (б) может использоваться как интерактивно, так и в прикладных программах, (в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).

Правило 6: Возможность изменения представлений (View Updating Rule):

Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, изменения и удаления данных.

Правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):

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

Правило 8: Физическая независимость данных (Physical Data Independence):

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

Правило 9: Логическая независимость данных (Logical Data Independence):

Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

Правило 10: Независимость контроля целостности (Integrity Independence):

Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.

Правило 11: Независимость от расположения (Distribution Independence):

База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияния на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.

Правило 12: Согласование языковых уровней (The Nonsubversion Rule):

Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.

Сущность реляционной базы данных

Реляционная база данных представляет собой набор таблиц (сущностей). Таблицы состоят из колонок и строк (кортежей). Внутри таблиц могут быть определены ограничения, между таблицами существуют отношения. При помощи SQL можно выполнять запросы, которые возвращают наборы данных, получаемых из одной или нескольких таблиц. В рамках одного запроса данные получаются из нескольких таблиц путем их соединения (JOIN), чаще всего для соединения используются те же колонки, которые определяют отношения между таблицами.

Нормализация — это процесс структурирования модели данных, обеспечивающий связность и отсутствие избыточности в данных. Целью нормализации реляционной базы данных является устранение недостатков структуры базы данных, приводящих к избыточности, которая, в свою очередь, потенциально приводит к различным аномалиям и нарушениям целостности данных.Теоретики реляционных баз данных в процессе развития теории выявили и описали типичные примеры избыточности и способы их устранения. Реляционные хранилища обеспечивают наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости. Касаемо масштабируемости, реляционные БД хорошо масштабируются только в том случае, если располагаются на единственном сервере.

Особенностью реляционной базы данных является использование в ней реляционной модели данных и вытекающие из этого последствия:

В реляционной базе данных данные создаются, обновляются, удаляются и запрашиваются с использованием языка структурированных запросов (SQL). SQL-запросы могут извлекать данные как из одиночной таблица, так и из нескольких таблиц.Такие запросы могут включать агрегации и сложные фильтры. Реляционная БД обычно содержит встроенную логику, такую как триггеры, хранимые процедуры и функции.

Реляционная система управления базой данных (РСУБД)

Доступ к реляционным базам данных осуществляется через реляционные системы управления базами данных (РСУБД). Почти все системы баз данных, которые мы используем, являются реляционными, такие как Oracle, SQL Server, MySQL, Sybase, DB2, TeraData и так далее. Причины такого доминирования неочевидны. На протяжении всего существования реляционных БД они постоянно предлагали наилучшую смесь простоты, устойчивости, гибкости, производительности, масштабируемости и совместимости в сфере управлении данными.

Например, простой SELECT запрос может иметь сотни потенциальных путей выполнения, которые оптимизатор оценит непосредственно во время выполнения запроса. Все это скрыто от пользователей, однако внутри РСУБД создает план выполнения, основывающийся на вещах вроде алгоритмов оценки стоимости и наилучшим образом отвечающий запросу. Однако чтобы обеспечить все эти особенности, реляционные хранилища невероятно сложны внутри.

Реляционная система управления базой данных содержит:

Источник

Реляционные базы данных: объяснение понятий, вводный обзор

Системы управления базами данных (СУБД) организует и структурирует данные таким образом, чтобы пользова­тели и прикладные программы могли их сохранять и выбирать из базы данных. Структуры данных и способы доступа к ним, обеспечиваемые конкретной СУБД, называются ее моделью данных. Модель данных определяет как «индивидуальность» СУБД, так и круг приложений, для которых она подходит наилучшим образом.

SQL представляет собой язык для работы с реляционными базами данных и ос­нован на реляционной модели данных. Что это такое? В каком виде информация хранится в реляционной базе данных? Чем реляционные базы данных отличаются от более ранних баз данных, таких как иерархические и сетевые? Какими пре­имуществами и недостатками обладает реляционная модель? В данной статье опи­сана реляционная модель данных, поддерживаемая языком SQL, и приведено ее сравнение с более ранними стратегиями организации баз данных.

Ранние модели данных

Когда в 1970-80-х годах стали популярны базы данных, появилось множество различных моделей данных. Каждая из них имела свои преимущества и недостат­ки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить ранние модели данных. Чтобы понять роль SQL и реляционных баз данных и оценить их вклад в развитие СУБД, следует кратко изучить ряд моделей данных, предшество­вавших появлению SQL.

Системы управления файлами

До появления СУБД все данные, которые содержались в компьютерной системе постоянно, хранились в виде отдельных файлов. Система управления файлами, ко­торая обычно являлась частью операционной системы, следила за именами фай­лов и их размещением. Системы управления файлами широко используются и се­годня — вероятно, вы знакомы со структурой папок и файлов, предоставляемой файловыми системами операционных систем Microsoft Windows или Macintosh компании Apple. Аналогичные файловые системы используются и в UNIX- серверах и всех коммерческих вычислительных системах.

В системах управления файлами модели данных, как правило, отсутствуют; эти системы ничего не знают о внутреннем содержимом файлов. В лучшем случае фай­ловая система поддерживает информацию о «типе файла» наряду с его именем, по­зволяя отличить документ текстового редактора от файла, содержащего данные о начисленной зарплате. Знание о содержимом файла — какие данные в нем хранятся и как они организованы — удел прикладных программ, использующих этот файл, как показано на рис. 1. В этом приложении начисления зарплаты каждая из про­грамм на языке программирования COBOL, работающая с основным файлом с ин­формацией о сотрудниках, содержит описание файла (file description, FD), в котором указана схема размещения данных в файле. Если структура данных изменяется — например, при решении хранить некоторую дополнительную информацию о каж­дом сотруднике— должны быть соответствующим образом модифицированы все программы, работающие с данным файлом. Это не слишком большая проблема в случае файла с документом текстового редактора или электронных таблиц, кото­рые обычно обрабатываются одной программой. Но при корпоративной работе с данными файлы зачастую совместно используются десятками, а то и сотнями про­грамм (см. рис. 1). При увеличении количества файлов и программ отделу обра­ботки данных придется тратить больше усилий на поддержание работоспособности старых программ, чем на разработку новых.

Проблемы сопровождения больших систем, основанных на файлах, привели в конце 1960-х годов к появлению СУБД. В основе СУБД лежала простая идея: изъ­ять из отдельных программ определение структуры содержимого файла и хранить это определение вместе с данными, в базе данных. Используя информацию, хра­нящуюся в базе данных, СУБД может играть существенно более активную роль как в управлении данными, так и в изменениях структуры данных. Кроме того, СУБД представляют собой расширения систем управления файлами, а не их заме­ну. СУБД используют системы управления файлами (обычно входящими в состав операционных систем) для хранения структур баз данных. Затем пользователь ба­зы данных обращается к СУБД, которая работает с деталями физического хране­ния информации. Это тот уровень абстракции, который обеспечивает физическую независимость данных.

Рис. 1. Приложение для начисления зарплаты, исполь­зующее систему управления файлами

Иерархические базы данных

Одной из наиболее важных сфер применения первых СУБД было планирова­ние производства для компаний, занимающихся выпуском продукции. Например, если автомобильная компания хотела выпустить 10000 машин одной модели и 5000 машин другой модели, ей необходимо было знать, сколько деталей следует заказать у своих поставщиков. Чтобы ответить на этот вопрос, необходимо выяс­нить, из каких частей состоит изделие, затем определить, из каких деталей состоят эти части, и т.д. Например, машина состоит из двигателя, корпуса и ходовой час­ти; двигатель состоит из клапанов, цилиндров, свечей и т.д. Для обработки таких списков частей идеально подходят компьютеры.

Список составных частей изделия по своей природе является иерархической структурой. Для хранения данных, имеющих такую структуру, была разработана иерархическая модель данных, которую иллюстрирует рис. 2. В этой модели каж­дая запись базы данных представляла конкретную деталь. Между записями суще­ствовали отношения предок-потомок, связывающие каждую часть с деталями, вхо­дящими в нее.

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

Рис. 2. Иерархическая база данных, содержащая информацию о составных частях

Таким образом, для чтения информации из иерархической базы данных требо­валась возможность перемещения по записям, за один шаг переходя на одну за­пись вверх, вниз или в сторону.

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже пере­числены преимущества IMS и реализованной в ней иерархической модели.

СУБД IMS все еще остается одной из распространенных СУБД для мэйнфрей­мов компании IBM. Обладающая очень высокой производительностью, она иде­ально подходит для приложений, связанных с обработкой большого числа тран­закций, таких как транзакции с кредитными карточками или резервирование авиабилетов. Хотя за последние пару десятилетий производительность реляцион­ных баз данных возросла столь существенно, что описанное преимущество IMS стало не столь важным, большое количество корпоративных данных, хранящихся в базах данных IMS, и множество старых приложений, работающих с этими дан­ными, гарантируют, что СУБД IMS будет использоваться еще много лет.

Сетевые базы данных

Если структура данных оказывалась сложнее, чем обычная иерархия, простота организации иерархической базы данных становилась ее недостатком. Например, в базе данных для хранения заказов один заказ может участвовать в трех различных отношениях «предок-потомок», связывающих заказ с покупателем, разместившим его, продавцом, принявшим его, и с заказанным товаром, что проиллюстрировано на рис. 3. Такие структуры данных не соответствовали строгой иерархии IMS.

Рис. 3. Множественные отношения “предок-потомок”

В связи с этим для таких приложений, как обработка заказов, была разработана новая, сетевая, модель данных. Она расширила иерархическую модель, позволяя одной записи участвовать в нескольких отношениях «предок-потомок», именуе­мых множествами (set) (рис. 4). В 1971 году на конференции по языкам обработки данных (Conference on Data Systems Languages, CODASYL) был опубликован офи­циальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД, но в 1970-х го­дах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность. Однако IBM усовер­шенствовала IMS, обеспечив путь обхода правила единственного предка в класси­ческих иерархических структурах, в котором дополнительные предки рассматри­ваются как логические. Эта модель данных, ставшая известной как расширенная иерархическая модель, сделала базу данных IMS конкурентом сетевых СУБД.

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

Рис. 4. Сетевая (CODASYL) база данных для работы с заказами

И опять программисту приходилось искать информацию в базе данных, после­довательно перебирая записи, но указывая при этом не только направление, но и требуемое отношение.

Сетевые базы данных обладали рядом преимуществ.

Конечно, у сетевых баз данных имелись недостатки. Подобно своим иерархиче­ским предкам, сетевые базы данных были очень «жесткими». Наборы отношений и структура записей должны были быть заданы наперед. Изменение структуры ба­зы данных обычно означало полную перестройку последней.

И иерархическая, и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос какой товар наиболее часто заказывает компания X? или сколько всего заказано единиц товара Y?, программисту приходилось пи­сать программу для навигации по базе данных, выборки нужных записей и под­счета результата. Реализация пользовательских запросов часто затягивалась на не­дели и месяцы, и к моменту появления программы возвращаемая ею информация часто оказывалась бесполезной.

Недостатки иерархической и сетевой моделей привели к повышенному инте­ресу к новой реляционной модели данных, впервые описанной доктором Коддом в 1970 году. Поначалу она представляла лишь академический интерес. Сетевые ба­зы данных продолжали оставаться важной технологией на протяжении 1970-х и в начале 1980-х годов, особенно в мини-компьютерных системах, переживавших пик популярности. Однако в середине 1980-х годов начался взлет реляционной моде­ли. В начале 1990-х годов сетевые базы данных утратили популярность и сегодня не играют значительной роли на рынке баз данных.

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

Реляционная модель данных, предложенная Коддом, была попыткой упростить структуру базы данных. В ней отсутствовала явная структура «предок-потомок», а все данные были представлены в виде простых таблиц, разбитых на строки и столбцы. На рис. 5 показана реляционная версия рассмотренной выше сетевой базы данных, содержащей информацию о заказах (рис. 4).

Рис. 5. Реляционная база данных для работы с заказами

Работа Кодда дает точное, математическое определение реляционной базы данных, а также теоретический фундамент для операций, которые могут быть вы­полнены над ней. Однако более полезно следующее неформальное определение реляционной базы данных.

Определение. Реляционной называется база данных, в которой все данные, доступные пользо­вателю, организованы в виде таблиц, а все операции базы данных выполняются над этими таблицами

Приведенное определение не оставляет места пользовательским структурам, та­ким как встроенные указатели иерархических и сетевых СУБД. Реляционная СУБД способна реализовать отношения «предок-потомок», однако эти отношения пред­ставлены исключительно значениями, содержащимися в таблицах базы данных.

Учебная база данных

На рис. 6 показана маленькая реляционная база данных для приложения, вы­полняющего обработку заказов. Большинство примеров в данном блоге построено на ее основе. Полное описание структуры и содержимого учебной базы данных, изображенной на рис. 6, приведено в приложении А, «Учебная база данных». Здесь представлено только по нескольку строк каждой таблицы.

Рис. 6. Учебная база данных (представлена частично)

В учебной базе данных содержится пять таблиц. В каждой таблице хранится информация об одном конкретном типе данных:

Таблицы

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

Рис. 7. Структура реляционной таблицы

Каждый вертикальный столбец таблицы OFFICES представляет один элемент данных для каждого из офисов. Например, в столбце CITY содержатся названия городов, в которых расположены офисы. В столбце SALES содержатся объемы продаж, обеспечиваемые офисами. В столбце MGR содержатся идентификаторы управляющих офисами.

Все значения, содержащиеся в одном и том же столбце, являются данными од­ного типа. Например, в столбце CITY содержатся только слова, в столбце SALES — денежные суммы, а в столбце MGR — целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, на­зывается доменом этого столбца. Доменом столбца CITY является множество всех названий городов. Домен столбца SALES — это любая денежная сумма. Домен столбца region состоит всего из двух значений, «Eastern» и «Western», поскольку у компании всего два торговых региона.

У каждого столбца в таблице есть свое имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различ­ных таблицах. На практике такие имена столбцов, как NAME (имя), ADDRESS (адрес), PRICE (цена) и тому подобные, часто встречаются в различных таблицах одной базы данных.

Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO максимально допустимое число столбцов в таблице не ука­зывается; однако почти во всех коммерческих СУБД такой предел существует, но он редко бывает меньше 255 столбцов.

В отличие от столбцов, строки таблицы не имеют определенного порядка. Это значит, что если последовательно выполнить два одинаковых запроса для отобра­жения содержимого таблицы, нет гарантии, что оба раза строки будут перечисле­ны в одном и том же порядке. Конечно, можно попросить SQL-запрос отсортиро­вать строки перед выводом, однако порядок сортировки не имеет совершенно ни­чего общего с фактическим расположением строк в таблице.

В таблице может содержаться любое количество строк. По очевидным причи­нам допускается существование таблицы с нулевым количеством строк. Такая таб­лица называется пустой. Пустая таблица сохраняет структуру, определенную ее столбцами, просто в ней не содержатся данные. Стандарт ANSI/ISO не наклады­вает ограничений на количество строк в таблице, и во многих СУБД размер таб­лиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако обычно он весьма высок, — два мил­лиарда строк, а то и больше.

Первичные ключи

Поскольку строки в реляционной таблице не упорядочены, нельзя выбрать строку по ее номеру в таблице. В таблице нет «первой», «последней» или «тринадцатой» строки. Тогда каким же образом можно выбрать в таблице кон­кретную строку, например строку для офиса, расположенного в Денвере?

Рис. 8. Таблица с составным первичным ключом

Первичный ключ у каждой строки таблицы является уникальным в пределах таблицы, поэтому в таблице с первичным ключом нет двух совершенно одинако­вых строк. Таблица, в которой все строки отличаются друг от друга, в математиче­ских терминах называется отношением (relation). Именно этому термину реляци­онные базы данных и обязаны своим названием, поскольку в их основе лежат от­ношения, т.е. таблицы с отличающимися друг от друга строками.

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) явная их поддерж­ка обеспечена не была. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи; в самих СУБД не было воз­можности задать для таблицы первичный ключ. И только СУБД DB2 Version 2, появившаяся в апреле 1988 года, была первым коммерческим SQL-продуктом с поддержкой первичных ключей. После этого подобная поддержка была добав­лена в стандарт ANSI/ISO, и сегодня практически все СУРБД предоставляют та­кую возможность.

Взаимоотношения

Одним из отличий реляционной модели от ранних моделей представления данных было то, что в ней отсутствовали явные указатели, такие как использовав­шиеся для реализации отношений «предок-потомок» в иерархической модели данных. Однако вполне очевидно, что такие отношения существуют и в реляци­онных базах данных. Например, в нашей учебной базе данных каждый из служа­щих закреплен за конкретным офисом, поэтому ясно, что между строками табли­цы OFFICES и таблицы SALES REPS существует отношение. Не приводит ли отсут­ствие явных указателей в реляционной модели к потере информации?

Отношение «предок-потомок», существующее между офисами и работаю­щими в них людьми, в реляционной модели не утеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явно­го указателя. Таким способом реализуются все отношения, существующие меж­ду таблицами реляционной базы данных. Одним из главных преимуществ языка SQL является возможность извлекать связанные между собой данные, используя эти отношения.

Рис. 9. Отношение “предок-потомок” в реляционной базе данных

Внешние ключи

Внешний ключ, как и первичный, тоже может представлять собой комбинацию столбцов. Фактически внешний ключ всегда будет составным (состоящим из не­скольких столбцов), если он ссылается на составной первичный ключ в другой таблице. Очевидно, что количество столбцов и их типы данных в первичном и внешнем ключах совпадают.

Если таблица связана с несколькими другими таблицами, она может иметь не­сколько внешних ключей. На рис. 10 показаны три внешних ключа таблицы ORDERS из учебной базы данных:

Рис. 10. Множественные отношения “предок-потомок” в реляционной базе данных

Внешние ключи являются фундаментальной частью реляционной модели, по­скольку реализуют отношения между таблицами базы данных. К сожалению, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД. Она была реализована в DB2 Version 2, а затем добавлена в стандарт ANSI/ISO и теперь имеется во всех основных коммерческих СУБД.

Двенадцать правил Кодда для реляционных баз данных

Когда в средине 1980-х годов реляционная модель стала очень популярной, почти все производители СУБД стали добавлять слово «реляционный» в описание своих продуктов. Но ряд из них был не более чем тонким слоем SQL-подобного языка на поверхности сетевой или иерархической базы данных. Некоторые реали­зовывали только рудиментарную табличную структуру, даже не пытаясь реализо­вать язык запросов. Вскоре вопрос так что же такое настоящая реляционная ба­за данных? стал подниматься все чаще и чаще, а производители СУБД стали ут­верждать, что их продукты «реляционнее», чем продукты их конкурентов.

В 1985 году Тед Кодл (чья статья 15-летней давности определила реляционную модель данных) задался этим вопросом и ответил на него в журнале Compu­terworld (Is Your DBMS Really Relational? (Действительно ли ваша СУБД реляционная?, 14.10.1985) и Does Your DBMS Run By the Rules? (Работает ли ваша СУБД по правилам?, 21.10.1985)). Здесь он изложил двенадцать правил, которым должна соответствовать настоящая реляционная база данных.

Хотя дискуссии по этому вопросу давно завершились, эти 12 правил интересны, как минимум, с исторической точки зрения, поскольку они раз и навсегда разрешили все вопросы и представляют собой хорошее неформальное определение реляционной базы данных. Правило 1 напоминает неформальное определение реляционной базы данных, приведенное ранее; остальные правила уточняют и дополняют его.

Правило 2 указывает на роль первичных ключей при поиске информации в ба­зе данных. Имя таблицы позволяет найти требуемую таблицу, имя столбца — тре­буемый столбец, а первичный ключ — строку, содержащую искомый элемент данных. Правило 3 требует, чтобы отсутствующие данные можно было предста­вить с помощью значения NULL.

Правило 4 гласит, что реляционная база данных должна описывать сама себя. Другими словами, база данных должна содержать набор системных таблиц, опи­сывающих структуру самой базы данных.

Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных, например SQL, хотя явно SQL в правиле не упомянут. Такой язык должен под­держивать все основные функции СУБД, а не только выборку данных.

Правило 6 касается представлений, которые являются виртуальными таблица­ми, позволяющими показывать различным пользователям различные фрагменты структуры базы данных.

Правило 7 акцентирует внимание на том, что реляционные базы данных по своей природе ориентированы на работу с множествами. Оно требует, чтобы опе­рации добавления, удаления и обновления можно было выполнять над множест­вами строк. Это правило предназначено для того, чтобы запретить реализации та­ких СУБД, в которых поддерживаются только операции над одной строкой.

Правила 8 и 9 изолируют пользователей и прикладные программы от низко­уровневой реализации базы данных и даже от изменений в структуре таблиц.

Правило 10 гласит, что язык базы данных должен поддерживать возможность определения ограничений на вводимые данные и изменения базы данных, кото­рые могут быть выполнены.

Правило 11 говорит о том, что язык базы данных должен обеспечивать возмож­ность работы с распределенными данными, расположенными в различных ком­пьютерных системах.

И наконец, правило 12 предотвращает использование других средств работы с ба­зой данных, помимо ее подъязыка, поскольку это может нарушить ее целостность.

Заключение

SQL основан на реляционной модели данных, в которой данные организованы в виде коллекции таблиц.

Отношения между таблицами реализуются с помощью содержащихся в них данных. В реляционной модели данных для представления этих отношений ис­пользуются первичные и внешние ключи.

Источник