Выполнение операторов модификации данных в таблицах базы данных INSERT , DELETE и UPDATE может привести к нарушению целостности данных и их корректности, т.е. к потере их достоверности и непротиворечивости.
Чтобы информация , хранящаяся в базе данных, была однозначной и непротиворечивой, в реляционной модели устанавливаются некоторые ограничительные условия – правила, определяющие возможные значения данных и обеспечивающие логическую основу для поддержания корректных значений. Ограничения целостности позволяют свести к минимуму ошибки, возникающие при обновлении и обработке данных.
В базе данных, построенной на реляционной модели, задается ряд правил целостности, которые, по сути, являются ограничениями для всех допустимых состояний базы данных и гарантируют корректность данных. Рассмотрим следующие типы ограничений целостности данных :
Некоторые поля всегда должны содержать одно из допустимых значений, другими словами, эти поля не могут иметь пустого значения.
Каждое поле имеет свой домен, представляющий собой набор его допустимых значений.
Существует понятие "корпоративные ограничения целостности " как дополнительные правила поддержки целостности данных , определяемые пользователями, принятые на предприятии или администраторами баз данных. Ограничения предприятия называются бизнес-правилами.
Это ограничение целостности касается первичных ключей базовых таблиц. По определению, первичный ключ – минимальный идентификатор (одно или несколько полей), который используется для уникальной идентификации записей в таблице. Таким образом, никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации записей.
Целостность сущностей определяет, что в базовой таблице ни одно поле первичного ключа не может содержать отсутствующих значений, обозначенных NULL .
Если допустить присутствие определителя NULL в любой части первичного ключа , это равносильно утверждению, что не все его поля необходимы для уникальной идентификации записей, и противоречит определению первичного ключа .
Указанное ограничение целостности касается внешних ключей . Внешний ключ – это поле (или множество полей) одной таблицы, являющееся ключом другой (или той же самой) таблицы. Внешние ключи используются для установления логических связей между таблицами. Связь устанавливается путем присвоения значений внешнего ключа одной таблицы значениям ключа другой.
Между двумя или более таблицами базы данных могут существовать отношения подчиненности , которые определяют, что для каждой записи главной таблицы (называемой еще родительской ) может существовать одна или несколько записей в подчиненной таблице (называемой также дочерней ).
Существует три разновидности связи между таблицами базы данных:
Отношение "один-ко-многим" имеет место, когда одной записи родительской таблицы может соответствовать несколько записей дочерней . Связь "один-ко-многим" иногда называют связью "многие-к-одному". И в том, и в другом случае сущность связи между таблицами остается неизменной.
Связь "один-ко-многим" наиболее распространена для реляционных баз данных. Она позволяет моделировать также иерархические структуры данных.
Отношение "один-к-одному" имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней . Это отношение встречается намного реже, чем отношение "один-ко-многим". Его используют, если не хотят, чтобы таблица БД "распухала" от второстепенной информации. Использование связи "один-к-одному" приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения вместо одной, когда данные хранятся в одной таблице.
Отношение "многие-ко-многим" имеет место в следующих случаях:
Считается, что всякая связь "многие-ко-многим" может быть заменена на связь "один-ко-многим" (одну или несколько).
Часто связь между таблицами устанавливается по первичному ключу , т.е. значениям внешнего ключа одной таблицы присваиваются значения первичного ключа другой. Однако это не является обязательным – в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами не требуется непременная уникальность ключа, обеспечивающего установление связи. Поля внешнего ключа не обязаны иметь те же имена, что и имена ключей, которым они соответствуют. Внешний ключ может ссылаться на свою собственную таблицу – в таком случае внешний ключ называется рекурсивным.
Ссылочная целостность определяет: если в таблице существует внешний ключ , то его значение должно либо соответствовать значению первичного ключа некоторой записи в базовой таблице, либо задаваться определителем NULL .
Существует несколько важных моментов, связанных с внешними ключами . Во-первых, следует проанализировать, допустимо ли использование во внешних ключах пустых значений. В общем случае, если участие дочерней таблицы в связи является обязательным, то рекомендуется запрещать применение пустых значений в соответствующем внешнем ключе . В то же время, если имеет место частичное участие дочерней таблицы в связи, то помещение пустых значений в поле внешнего ключа должно быть разрешено. Например, если в операции фиксации сделок некоторой торговой фирмы необходимо указать покупателя, то поле КодКлиента должно иметь атрибут NOT NULL . Если допускается продажа или покупка товара без указания клиента, то для поля КодКлиента можно указать атрибут NULL .
Следующая проблема связана с организацией поддержки ссылочной целостности при выполнении операций модификации данных в базе. Здесь возможны следующие ситуации:
Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД - это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные .
Целостность сущностей описывается совокупностью ограничений которые должны выполняться для любых отношений в любых реляционных базах данных. Теоретики баз данных формулируют эти ограничения по-разному. Например, в называют «Условиями целостности … будем называть особые, отдельно хранящиеся данные, которыми на концептуальном уровне … представлено … правило (закон, критерий) принадлежности кортежей отношению, представленному этими данными (записями) в базе данных. К уровням целостности базы данных, как правило, присоединяются также спецификации условий принадлежности значений каждого из атрибутов реляционной таблицы к соответствующему ему домену в базе данных».
Из данного определения можем извлечь следующие простые формулировки ограничений:
1. Все строки таблицы должны иметь одинаковую структуру, одно и то же количество атрибутов.
2. Никакие две записи не могут совпадать. Если определен первичный ключ отношения, то каждая строка таблицы должна иметь свое значение первичного ключа.
3. Значения атрибутов должны быть атомарными.
4. Значения каждого атрибута должны быть взяты из некоторого фиксированного множества значений (домена).
Первое ограничение фиксирующее, что единственной структурой данных, используемых в реляционных БД, является отношение, по сути определяет само понятие отношения (таблица). Следствием второго ограничения является обязательное наличие атрибута, объявленного первичным ключом, обеспечивающим уникальность записей. Третье – не является строгим, т.е. результат невыполнения этого ограничения не обязательно скажется на целостности, но вероятность ошибок велика.
В ограничения целостности сущностей заключаются в требовании уникальности кортежей отношения (записей таблицы), из которого вытекают следующие ограничения:
1. отсутствие кортежей-дубликатов (данное требование предъявляется лишь к атрибутам первичных ключей);
2. отсутствие атрибутов с множественным характером значений.
1. Найти соответствие условий целостности из условиям, названным выше, (1 – 4).
2. Составить перечень атрибутов для сведений об адресе отношения СОТРУДНИК, обеспечивающих атомарность.
Ограничения целостности ссылок заключаются в том, что для любой записи с конкретным значением внешнего ключа должна обязательно существовать запись связанной таблицы-отношения с соответствующим значением первичного ключа.
Пример 1. Рассмотрим отношение СОТРУДНИКИ с внешним ключом «Код отдела» и связано с отношением ОТДЕЛЫ с первичным ключом «Код отдела» (см. рис. 8). Если существует сотрудник Волков И. И., работающий в отделе О1, то соответствующий отдел должен существовать и данные о нем должны храниться в таблице ОТДЕЛЫ .
Отношение Сотрудники
Отношение Отделы
Пример 2. Связь между таблицами Студент и Сдал осуществляется по полю НОМЕР_Зачетки, это связь типа один-ко-многим (1:М). Причем главной является таблица Студент, а подчиненной - таблица Сдал, т.к. в ней возможно любое количество записей со значением в поле НОМЕР_Зачетки, которое в таблице Студент может быть только один раз. Поле связи должно быть обязательно первичным ключом главной таблицы. Главную таблицу иногда называют родительской, а подчиненную - дочерней.
Поля связи в связываемых таблицах не обязательно должны иметь одинаковые имена, но значения полей должны быть взяты из одного и того же множества. Возможно использование для связи не только одного поля, но и совокупности полей.
Большинство СУБД реляционного типа, но не все, осуществляют контроль ссылочной целостности данных. Контроль данных на непротиворечивость осуществляется СУБД автоматически в следующих случаях:
1)При добавлении данных в подчиненную таблицу. Нельзя добавить строку, в которой поле связи содержит значение, отсутствующее в главной таблице. При добавлении данных в главную таблицу контроль ссылочной целостности не требуется.
2)При удалении данных из главной таблицы. Из главной таблицы запрещается удалять строку, если в подчиненной таблице есть строки, связанные с ней. Альтернативным способом решения проблемы сохранения ссылочной целостности данных при удалении является каскадное удаление, то есть удаление строки из главной таблицы с одновременным удалением соответствующих ей строк из подчиненной.
3)При модификации значения поля связи, как в главной, так и в подчиненной таблице. В подчиненной таблице значение поля связи можно изменить на другое значение, но только в случае, если новое значение есть в главной таблице. Изменить значение поля связи главной таблицы нельзя или следует произвести соответствующую замену и во всех строках подчиненной таблице, то есть выполнить каскадное изменение данных. Изменение в таблицах значений полей, не участвующих в связи контроля ссылочной целостности не требует.
Задания для самостоятельной работы
1. Добавить в таблицу СОТРУДНИКИ запись о Фроловой О.А., работающей в отделе кадров. Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.
2. Удалить из таблицы ОТДЕЛЫ запись со значением атрибута Краткое_наим_отдела «ЛИД». Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.
Замечания
1 Основное внимание в ограничениях целостности в иерархической модели уделяется целостности ссылок между предками и потомками с учетом основного правила: никакой потомок не может существовать без родителя.
2 В сетевой модели данных ослаблен контроль целостности связей из-за допустимости установления произвольных связей между записями.
Все операции над базой данных сводятся к манипуляциям с записями и полями таблиц. Обращаясь к нашему студенческому архиву (см. Таб.1), возможно, захочется узнать, кто из студентов учится в группе 407 – ответ: Сидоров (запись 3) и Соловьев (запись 4). Другой пример: кто среди студентов самый старший – ответ: Петров (запись 2). Это примеры простейших операций выборки.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное счисление .
Обеспечение манипуляционной целостности характеризует свойство БД сохранять достоверность в результате выполняемых операций: выборка, объединение, пересечение, разность, соединение, проекция, деление и т.д. , входящие в набор базовых теоретико-множественных операций и специальных реляционных. Неустойчивость БД, другими словами, потеря целостности, приводит к ошибкам и даже разрушению данных. Обеспечение манипуляционной целостности находится в прямой зависимости от нормализации БД.
В основу манипуляционной части модели положена теория множеств с некоторыми уточнениями. Основная идея состоит в том, что, поскольку отношение - это множество, то средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми операциями, специфичными для БД.
Набор операций, предложенный Коддом, содержит восемь операций:
1)теоретико-множественные операции, такие как объединение, пересечение, разность и декартово произведение, а ко второму - селекция, проекция, соединение и деление
2)специальные реляционные операции, к которым относятся операция присваивания, позволяющая сохранить в БД результат вычисления алгебраических выражений, и операция переименования атрибутов, которая дает возможность корректно сформировать заголовок результирующего отношения - его схему.
Пример 1. Объединение. R3 = R1 È R2
Пусть отношение R1 - это таблица «Абитуриенты - победители олимпиады», а R2 - таблица «Абитуриенты, прошедшие по конкурсу на основании экзаменов».
Таблица Абитуриенты - победители олимпиады.
Таблица Абитуриенты, прошедшие по конкурсу на основании экзаменов.
Пусть основанием для зачисления в университет является победа в олимпиаде, либо успешная сдача вступительных экзаменов. Результат объединения (R3), который мы назовем «Абитуриенты, зачисленные в университет», включает все строки первой таблицы и недостающие строки из второй.
Таблица Абитуриенты, зачисленные в университет.
Пример 2. Пересечение. R3 = R1 Ç R2
Исходные данные те же, что и в случае объединения. Результат пересечения включает только те строки первой таблицы, которые есть во второй. В нашем случае результатом будет таблица, которую можно назвать «Абитуриенты, зачисленные в университет по двум показателям».
Таблица Абитуриенты, зачисленные в университет по двум показателям.
В теории множеств операции объединения, пересечения и разности имеют смысл для любых двух множеств. В случае реляционной алгебры это не так. Результатом любой из этих операций должно стать отношение, то есть множество однотипных строк, следовательно, операндами должны быть отношения с одинаковыми, а точнее совместимыми, схемами. Это означает, что отношения должны иметь одинаковую степень и одинаковые типы соответствующих атрибутов. Имена атрибутов могут отличаться, тогда после переименования можно выполнить основную операцию, то есть объединение, пересечение или разность.
Для операции декартово произведение, применяемой к паре отношений, важно, чтобы схемы, т.е. имена атрибутов были разными.
При нарушениях условий целостности возможно возникновение аномалий. Существует несколько видов аномалий: избыточности, обновления, включения, удаления.
Основная задача при проектировании реляционных БД -формирование оптимальных отношений.
Пример 1. Рассмотрим БД «Объединение кооперативов». В отношении ПОСТАВЩИКИ (НАЗВАНИЕ ПОСТАВЩИКА, АДРЕС ПОСТАВЩИКА, ТОВАР, ЦЕНА), в связи с такой его схемой, могут возникают следующие проблемы:
1. Аномалия избыточность: адрес поставщика повторяется для каждого повторяемого товара.
2. Аномалия обновления (потенциальная противоречивость, может и не возникнуть): вследствие избыточности можно обновить адрес поставщика в одном кортеже, оставив его неизменным в другом. При этом может оказаться, что для некоторых поставщиков нет единого адреса.
3. Аномалия удаления: при необходимости удаления всех товаров, поставляемых данным поставщиком, непреднамеренно можно утратить его адрес.
4. Аномалия включения: в БД может быть записан адрес поставщика, который в настоящее время не поставляет товар, можно поместить неопределенные значения атрибутов ТОВАР и ЦЕНА. Но если он начнет поставлять некоторый товар, можно забыть удалить кортеж с неопределенными значениями. ТОВАР и НАЗВАНИЕ ТОВАРА образуют ключ данного отношения, а поиск кортежей с неопределенными значениями может быть затруднен или невозможен.
Избыточность в данных потенциально приводит к различным аномалиям и нарушениям целостности данных. Аномалия это то, что не является нормой и в связи с этим считается странностью и исключением. Логически таблица БД построена, вроде бы, правильно, но возникает ошибка, которая может повлечь нарушение всей структуры БД. Т.к. аномалии проявляют себя при выполнении операций, изменяющих состояние базы данных, то различают следующие виды аномалий:
· Аномалии вставки (INSERT)
· Аномалии обновления (UPDATE)
· Аномалии удаления (DELETE)
Пример 2: Рассмотрим в качестве предметной области некоторую организацию, выполняющую некоторые проекты. В текущий момент состояние предметной области отражается следующими фактами:
· Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 1 и во втором проекте "Климат" задание 1.
· Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте "Космос" задание 2.
· Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте "Космос" задание 3 и во втором проекте "Климат" задание 2.
Это состояние отражается в таблице СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (курсивом выделены ключевые поля):
Аномалии вставки (INSERT)
В таблицу СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о сотруднике, который пока не участвует ни в одном проекте. Действительно, если, например, во втором отделе появляется новый сотрудник, скажем, Королев, и он пока не участвует ни в одном проекте, то мы должны вставить запись (4, Королев, 2, 33-22-11, null, null, null). Это сделать невозможно, т.к. поле №Проекта входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.
Точно также нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.
Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).
Вывод - логическая модель данных неадекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.
Целостность базы данных
Це́лостность ба́зы да́нных (database integrity) - соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.
Задача аналитика и проектировщика базы данных - возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.
Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.
Итак, БД может быть целостной, но не достоверной. Возможно и обратное: БД может быть достоверной, но не целостной. Последнее имеет место, если правила (ограничения целостности) заданы неверно.
Wikimedia Foundation . 2010 .
Свойство базы данных, означающее, что БД содержит полную и непротиворечивую информацию, необходимую для корректного функционирования приложений. Для обеспечения целостности накладывают ограничения целостности. См. также: Базы данных Финансовый… … Финансовый словарь
целостность базы данных - Свойство базы данных, определяемое способностью системы управления базой данных защищать компоненты и связи базы данных от искажения в результате некорректных операций и сбоев технических средств. [ГОСТ 20886 85] Тематики организация данных в… … Справочник технического переводчика
Целостность базы данных - 2. Целостность базы данных Свойство базы данных, определяемое способностью системы управления базой данных защищать компоненты и связи базы данных от искажения в результате некорректных операций и сбоев технических средств Источник: ГОСТ 20886 85 … Словарь-справочник терминов нормативно-технической документации
Сервер БД выполняет обслуживание и управление базой данных и отвечает за целостность и сохранность данных, а также обеспечивает операции ввода вывода при доступе клиента к информации. Архитектура клиент сервер состоит из клиентов и серверов.… … Википедия
Иерархическая модель базы данных состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней.… … Википедия
У этого термина существуют и другие значения, см. Представление. Представление (англ. view, более созвучное не стандартное название «вид», в сленге программистов часто используется в качестве заимствования из английского «вьюха», «вьюшка»)… … Википедия
Реляционная база данных база данных, основанная на реляционной модели данных. Слово «реляционный» происходит от англ. relation (отношение). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было… … Википедия
У этого термина существуют и другие значения, см. Индекс. Индекс (англ. index) объект базы данных, создаваемый с целью повышения производительности поиска данных. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в … Википедия
У этого термина существуют и другие значения, см. Триггер (значения). Триггер (англ. trigger) это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации… … Википедия
У этого термина существуют и другие значения, см. Курсор (значения). Курсор ссылка на контекстную область памяти[источник не указан 126 дней]. В некоторых реализациях информационно логического языка SQL (Oracle,… … Википедия
Информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется (integrity constraint).
Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 15; возраст родителей не может быть меньше возраста их биологического ребёнка и т. д.
Очевидно, что ограничения должны быть формально объявлены для СУБД , после чего СУБД должна предписывать их выполнение. Объявление ограничений сводится просто к использованию соответствующих средств языка базы данных, а соблюдение ограничений осуществляется с помощью контроля со стороны СУБД над операциями обновления, которые могут нарушить эти ограничения, и запрещения тех операций, которые их действительно нарушают. При первоначальном объявлении ограничения система должна проверить, удовлетворяет ли ему в настоящий момент база данных. Если это условие не соблюдается, ограничение должно быть отвергнуто; в противном случае оно принимается (то есть записывается в каталог системы) и начиная с этого момента соблюдается :338 .
Механизмы обеспечения целостности являются одной из составляющих концепции модели данных .
В теории реляционных баз данных принято выделять четыре типа ограничений целостности :353:
Примером распространённого ограничения уровня переменной отношения является потенциальный ключ ; примером распространённого ограничения уровня базы данных является внешний ключ .
Целостность БД не гарантирует достоверности (истинности) содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность (непротиворечивость) БД с истинностью БД. Истинность и непротиворечивость - не одно и то же :351 .
Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД не может гарантировать наличие в базе данных только истинных высказываний; все, что она может сделать, - это гарантировать отсутствие каких-либо данных, вызывающих нарушение ограничений целостности (то есть гарантировать то, что она не содержит каких-либо данных, не совместимых с этими ограничениями) :351 .
Целостность баз данных
Под целостностью баз данных будем понимать некоторый набор требований нарушение которых приведет к противоречию между базой данныхи предметной областью которую она отражает.
Современные СУБД поддерживают возможности соблюдения тех или иных требований целостности.
Рассмотрим типы целостности и механизмы СУБД поддерживающие эти типы.
1)Сущностная целостность или целостность по первичному ключупо своему определению значение первичного ключа в таблице должно быть уникальным т.к. основной принцип Р.Б.Д. звучит что доступ к данным в таблице осуществляется по цепочке. Имя БД à Имя таблицы à Имя столбца à первичный ключ (значение).
Все современные СУБД поддерживают уникальность первичного ключа. Механизм поддержания уникальности первичного ключа основывается на понятие индекса см.ниже.
При определение первичного ключа СУБД автоматически создает индекс для поддержки его уникальности и для поиска поп первичному ключу.
2) Ссылочная целостность – это целостность поддерживается в связях между таблицами. Для того чтобы содержимое двух связанных таблиц правильно отражало предметную область. На операции изменяющие содержимое таблиц должны накладываться определенные ограничения (ограничения целостности). Это относится к трем операциям:
Удаление записей (из главной таблицы)
Изменение записей (в главной таблице)
Вставка записей во второстепенные таблицы.
Вводят ограничения на выполнение операций: удаление из главной таблицы, Обновления в главной таблице, вставка строк во вторичной таблице.
Удаление из главной таблице
СУБДподдерживает 4 вида сценария при удаление из главной таблицы.
1) при удаление из главной таблицы автоматически удаляет связанные записи из подчиненной таблицы (каскад).
2) Запрет на удаление записи из главной таблицы если она связана с какими-либо записями в подчиненной таблице.
3) После удаления записи из главной таблицы внешним ключам связанных записей в подчиненной таблице присваиваются значения NULL .
4) При удаление записи из главной таблицы внешним ключам второстепенных записей присваиваются значения по умолчанию.
Обновление записей в главной таблице
(Это касается обновления первичного ключа)
1) При обновление первичного ключа главной таблицыкаскадно изменяются значения внешнего ключа подчиненных таблиц.
2) При изменение первичного ключа в главной таблице соответствующим значениям ключам в подчиненной таблице присваиваются значения NULL .
3) При изменение первичного ключа в главной таблице соответствующим значениям ключам в подчиненной таблице присваиваются значение по умолчанию.
4) {2} Устанавливается запрет на обновление первичных ключей тех записей главной таблицы, которые связанны с какими-либо записями в подчиненной таблице.
Значение по умолчанию – при определение структуры таблицыдля каждого столбца
А) определенное значение по умолчанию
Б) разрешено присваивание значения NULL .
Простым механизмом поддержания целостности БД является тип столбца таблицы СУБД автоматически отслеживает операции записи в таблицу и случаи несоответствия типов либо отвергает запись – генерирует ошибку или осуществляет неявное преобразование типов. Для каждой СУБД свои правила генерации ошибки и преобразования в неявный тип.
Например в одних СУБД возможно 32 бит целое à 16бит целое, а в других невозможно из-за возможности потери данных свыше 16 бит.
4)Доменный механизм поддержания целостности. Под доменом в РБД понимается множество возможных значений, которые принимают данные хранящиеся в данном столбце. В частности в случае если домен совпадает со множеством значений данного типа, но часто домен является дополнительным ограничением. Если в столбце хранится номера месяца 1..12 то в домене находится 12 значений, а тип целый то есть домен уже. В большинстве СУБД домен определяется набором условийкоторые должны выполнятся для данных хранящихся в столбце. В случае если записываемые данные не удовлетворяют условию генерируется ошибка. (условие(1 <= =>12 )), предотвращая неправильное указание месяца.
5)Поддержание наличия возможных ключей в таблице.
Уникальность возможных ключей каки первичного поддерживается индексирование. атрибут индекса уникальный гарантирует уникальность любого столбца или группы столбцов, кроме этого индекс ускоряет поиск по соответствующему ключу. Замедляет операции редактирования.
6)Некоторые СУБД поддерживают создание новых типов данных к таким относятся SQL Server 2005там на основе технологии. Net можно создавать новые типы данных, которые фактически являются объектами со своими свойствами и методами. (Уже перевод РБД в Объектное РБД).
7) Триггеры (см лекция о триггерах) являются наиболее мощным средством поддержания целостности баз данных. Триггеры представляют собойпроцедуры хранящиеся в базе данных написанной на языке соответствующие СУБД и автоматически запускаемые при наступление некоторого события. При помощи триггеров можно проверять любые условия и запретить выполнение какой-либооперации, либо внести дополнительные измененияв другие таблицы. У триггеров существует три основные функции:
1) Запретить те или иные действия которые противоречат целостности базы данных.
2) Попутно с выполняемой операцией внести изменения в др. таблицы баз данных или структуру баз данных.
3) функция журналирования тех или иных действий в базе данных.
