Поддержание ссылочной целостности
Рассмотрим связь между таблицами «Groups» и «Students». Все значения столбца Students.IDGroup должны присутствовать в столбце Groups.IDGroup, т.е. первый столбец ссылается на второй. Тогда Students.IDGroup называют внешним ключом, а Groups.IDGroup – родительским.
Каждое значение (каждая строка) внешнего ключа должно ссылаться на одно и только одно значение (строку) родительского ключа. Если это условие выполняется, система находится в состоянии ссылочной целостности.
Внешний ключ может состоять из нескольких столбцов. Совместимость предполагает, что:
· Количество столбцов внешнего и родительского ключей должно быть одинаковым.
· Первый, второй и т.д. столбцы внешнего ключа должны иметь те же типы данных и размеры, что и первый, второй и т.д. столбцы родительского ключа. При этом имена столбцов не обязаны совпадать.
Целостность может быть нарушена при изменении и удалении строк в родительской таблице. В SQL Server существует четыре варианта поведения связанных таблиц.
1) CASCADE. Внешний ключ будет приведен в соответствие родительскому ключу. При изменении р.к. внешний ключ также изменится, при удалении – будет удалены все содержащие ключ записи.
2) SET NULL. Значения внешнего ключа будут установлены в NULL.
3) SET DEFAULT. Для внешнего ключа будет установлено значение по умолчанию, а при отсутствии такового – NULL.
4) NO ACTION. Применяется по умолчанию. Внешний ключ не меняется, но если в результате применения оператора ссылка может стать недействительной, оператор игнорируется.
|
|
|
Правила Кодда
Эдгар Кодд (1923-2003) – английский математик, участвовал во второй мировой войне, после переехал в Нью-Йорк и стал сотрудником компании IBM, в 1969-1970 гг. создал реляционную модель данных. Со временем реляционные СУБД набирали популярность, появлялось очень много некачественных продуктов, потому что производители очень многие устаревшие СУБД выдавали за реляционные. Тогда Кодд описал 12 правил, которые сейчас широко известны.
Кстати, язык SQL Кодд считал неподходящим под его теорию. Однако компания IBM выпускала очень большое число продуктов, основанных на SQL. Поэтому работать в IBM ученый не смог и вскоре основал собственную консалтинговую компанию.
1. Явное представление данных (правило информации). Информация должна быть записана в виде данных, хранящихся в ячейках таблицы, составные значения недопустимы. Порядок строк не должен влиять на смысл данных. По сути это – определение реляционной БД. (Искл. постреляционные СУБД)
2. Гарантированный доступ к данным. К каждому элементу данных должен быть обеспечен доступ при помощи следующей комбинации: имя таблицы, значение первичного ключа и имя столбца. В реальных СУБД добавлены ещё такие параметры, как имя пользователя или имя БД.
|
|
|
3. Полная обработка неопределённых значений. Для любых операций с любыми типами данных должны поддерживаться неопределённые значения (NULL). Пустая строка, 0, false <> NULL.
4. Доступ к описанию БД в терминах реляционной БД. Словарь данных должен сохраняться в виде таблицы и СУБД должна обеспечивать к нему доступ стандартными средствами, теми же, которые используются для работы с таблицами, содержащими пользовательские данные. Словарь данных – это описание структуры БД. Получается, что реляционная база данных должна сама себя описывать. БД должна содержать набор системных таблиц, описывающих структуру самой базы данных.
5. Полнота подмножества языка.Хотя бы один из поддерживаемых языков должен иметь четко определенный синтаксис и быть всеобъемлющим. Он должен поддерживать описание структуры данных и манипулирование ими, правила целостности, авторизацию и транзакции.
6. Возможность обновления представлений. Все представления, которые теоретически можно обновить, должны быть обновляемы. Представление – виртуальная таблица, в которой содержится динамический набор данных из основных таблиц (например, объединение двух таблиц, результат выполнении операции над таблицей, подмножество столбцов или записей). Чаще всего строится на основе SQL-запросов. Сложность может возникнуть, например, если представление создано на основе нескольких таблиц.
|
|
|
7. Наличие высокоуровневых операций управления данными. Должна быть возможность применения операций добавления, удаления и обновления данных не только к одной строке, но и ко множеству строк, т.е. ко всей таблице. Например, изменить в таблице зарплату всех сотрудников.
8. Физическая независимость данных. Прикладные программы не должны зависеть от способа хранения данных и методов обращения к ним. Независимо от носителей, аппаратного обеспечения компьютеров – прикладные программы будут работать по-прежнему.
9. Логическая независимость данных. Прикладные программы не должны зависеть от структуры реляционных таблиц. (При разбиении таблицы на две создается представление её заменяющее, чтобы изменение не сказывалось на работе приложений). Например, добавление в таблицу нового столбца не может сказаться на функционировании прикладных программ, так как доступ к данным осуществляется по именам столбцов. Правила 8 и 9 означают отделение пользователя и прикладных программ от низкоуровневой реализации БД.
|
|
|
10. Независимость контроля целостности. Всё необходимое для контроля целостности должно храниться в словаре данных. Язык БД должен быть способен определять правила целостности и не должно существовать способа их обойти. Для каждой СУБД можно определить свои специфические правила целостности.
11. Дистрибутивная независимость (правило независимости распространения). Реляционная БД должна быть переносимой и способной к распространению. (Как с системы на систему, так и по сети, объединяющей несколько систем). Дистрибутивность – согласованность двух операций, определенных на одном и том же множестве. База данных может быть распределенной или переноситься на другие компьютеры и это не должно сказаться на функционировании прикладного программного обеспечения.
12. Согласование языковых уровней. Если в реляционной базе данных есть низкоуровневый язык, то должна отсутствовать возможность использования его для обхода правил и условий целостности данных, сформулированных на языке высокого уровня. Низкоуровневым называется язык, обрабатывающий одну запись за один раз, а высокоуровневым - обрабатывающий несколько записей за один раз.
13. Правило 0. Реляционная СУБД должна быть способна полностью управлять базой данных через ее реляционные возможности. Получить доступ к словарю данных, обеспечить целостность, которую нельзя обойти даже на низкоуровневом языке, обрабатывать массивы записей. Всё управление реализуется с помощью связей между данными. Правило 0 требует выполнения всех остальных 12 правил. В SQL – представления, доступ к данным через имя БД.
Дата добавления: 2018-06-27; просмотров: 343; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!