|
271 Реляционная модель данных.
Модель данных описывает некоторый набор родовых понятий и признаков, которыми должны обладать все конкретные СУБД и управляемые ими базы данных, если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.
Хотя понятие модели данных является общим, и можно говорить о иерархической, сетевой, некоторой семантической и т.д. моделях данных, нужно отметить, что это понятие было введено в обиход применительно к реляционным системам.
Согласно Кодду реляционная модель состоит из 3 частей, описывающих разные аспекты реляц. подхода: структурной части, манипуляционной части и целостной части.
В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.
Отношения можно использовать для представления классов объектов реального мира и их свойств. Каждый класс объектов можно описать схемой отношения, атрибуты которой описывают свойства объекта.
Отношения можно использовать для представления связей между классами объектов. Связь между двумя объектами можно представить схемой, в которую входят ключевые атрибуты объектов и атрибуты, характеризующие эту связь.
В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.
В октябре 1985 года Э.Ф. Кодд опубликовал ряд статей, где сформулировал 12 критериев или правил, которым должна удовлетворять СУБД, чтобы называться реляционной. Несмотря на то, что правил 12, Кодд утверждал, что реляционная модель основана на единственном правиле, названном нулевым правилом. Это правило является фундаментальным принципом и формулируется следующим образом:
Правило 0. “Каждая R-система (реляционная СУБД) должна быть в состоянии управлять БД используя ее реляционные свойства.” Кроме того, должны отсутствовать обходные пути 0-правило. Это второй фундаментальный принцип.
Правило 1 - “правило информации”. Вся информация реляционной базы данных на логическом уровне представляется только одним способом - в виде значений в таблицах. РБД является набором таблиц и не содержит ниичего, кроме таблиц.
Правило 2 - правило гарантированного доступа. Гарантируется, что каждый элемент данных (атомарное значение) реляционной бвзы данных логически доступен через комбинацию имени таблицы, значения первичного ключа и имени столбца.
Это правило утверждает, что для нахождения конкретного элемента данных нужно знать три компонента: имя таблицы, имя столбца и первичный ключ. Следовательно, необходимо поддержание первичного ключа.
Правило 3 - правило недостающей информации. Null - значения (заметим, что они отличаются от пустой строки символов и от строки символов пробела) поддерживаются в полностью реляционной СУБД для представления отсутствующей информации систематически и независимо от типа данных.
В виде null- значений в базе данных представляется недостающая или некорректная информация. Если есть Null , то значение отсутствует по некоторой причине.
Правило 4 - правило системног каталога. Описание базы данных представляется на логическом уровне так же, как и обычные данные (в виде табл. значений). Язык реляционных БД должен иметь возможность изменять конструкцию БД точно так же, как он изменяет хранящиеся в таблице данные. Системный каталог - это словарь данных.
Правило 5 - полноценный язык. Реляционная система может поддерживать несколько языков и различных режимов работы с терминалом. Однако, должен существовать по меньшей мере один язык, который поддерживает: описание данных; описание представлений; манипулирование данными; ограничения целостности; границы транзакций (начало, завершение и откат); права доступа.
Правило 6 - правило обновления представлений. “Все представления, которые обновляются теоретически, может обновить и система”
Представления данных предоставляют пользователю возможность увидеть выборку из таблиц базы данных, в кот. отражается только то, что нужно и доступно данному пользователю. СУБД должна поддерживать возможность обновления представлений.
Правило означает, что при изменении некоторых представлений, СУБД должна изменять базовые таблицы, а также изменять представления при изменении базовых.
Правило 7 - ввод, обновление и удаление данных на высоком уровне. “Возможность работы с базовыми или производными отношениями в качестве одного операнда применима не только к считыванию, но и к вводу, обновлению и удалению данных”.
Означает возможность выполнения этих операций не одной строки, а наборов строк, т.е. реляционных наборов или отношений.
Правило 8 - физическая независимость данных. “Прикладные программы и терминальные операции не зависят от любого изменения области хранения информации и методов доступа”.
Правило 9 - логическая независимость данных. “Прикладные программы и терминальные операции не должны изменяться при внесении в базовые таблицы любого рода изменений,сохраняющих инфо и теоретич сохраняющих возможность неизменения”.
Это означает, что при изменении схемы, например, добавлении и удалении столбцов, таблиц другие части, которые не затронуты изменениями остаются неизменными. Это выполняется при добавлении новых столбцов и таблиц и не всегда при удалении. Если удаляется какие-либо данные, с которыми работало приложение, то приложение должно изменится. Если же меняется представление, то может и не меняться.
Правило 10 - независимость целостности. “Должна существовать возможность описания ограничений целостности, специфичных для конкретной реляционной базы данных при помощи подъязыка реляционных данных и сохранения их в каталоге, а не в прикладных программах”.
Должны соблюдаться, как минимум два следующих ограничения целостности:
Сущностная целостность: ни один из компонентов первичного ключа не может принимать Null-значение.
Ссылочная целостность: для каждого значения внешнего ключа отличного от других и не являющегося Null- значением, в реляционной базе данных должно существовать соответствующее значение первичного ключа из того же домена.
Это правило требует, чтобы объявление ограничений целостности являлось частью языка, используемого для описания структуры данных.
Правило 11 - независимости распределения. “В реляционной СУБД распределение независимо”.
В соответствии с данным правилом распределенная база данных должна выглядеть для пользователя как централизованная. Прикладные пользователи и программы не обязаны знать. где именно хранятся данные, в твкже где размещаются несколько копий одних и те же данных.
Правило 12 - правило соблюдения правил. “Если в реляционной системе имеется язык низкого уровня (“одна запись за раз”), его нельзя использовать для нарушения или пропуска правил или ограничений целостности, установленных в реляционном языке более высокого уровня (“несколько записей за раз”)”.
Правила целостности должны соблюдаться безо всякого исключения.
Do'stlaringiz bilan baham: |
