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

В середине 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] Под «мусором» > в базах данных рассматриваются данные, которые не могут быть обработаны пользователем стандартными средствами приложения и требуют сервисных операций на уровне СУБД.