Смарт ТВ 

Базы данных. Целостность базы данных

Одним из основополагающих понятий в технологии баз данных является понятие целостности. В общем случае, это понятие, прежде всего, связано с тем, что база данных отражает в информационном виде некоторый объект реального мира или совокупность взаимосвязанных объектов реального мира. В реляционной модели объекты реального мира представлены в виде совокупности взаимосвязанных отношений. Целостность базы данных – это правила и средства, обеспечивающие надежную реализацию установленных межтабличных связей между всеми данными, содержащимися в базе. Поддержание целостности данных является достаточно серьезным и сложным вопросом. При эксплуатации базы данных ее повреждение может возникнуть по нескольким причинам: при сбое компьютера, вследствие ошибок в программном обеспечении, из-за некорректных действий пользователя.

Любое изменение в предметной области, значимое для построенной модели, должно отражаться в базе данных, и при этом должна сохраняться однозначная интерпретация информационной модели в терминах предметной области.

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

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

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

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

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

В-третьих, это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

· кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ним;

· кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ним, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

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

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

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

Семантическая поддержка может быть обеспечена двумя путями:

· декларативный, выполняемый средствами языка SQL;

· процедурный, выполняемый посредством триггеров и хранимых процедур.

Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего «бизнес-правилами» (Business Rules) или декларативными ограничениями целостности.

Выделяются следующие виды декларативных ограничений целостности:

· ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов. Задание значения по умолчанию означает, что каждый раз при вводе новой строки в отношение, при отсутствии данных в указанном столбце этому атрибуту присваивается именно значение по умолчанию;

· ограничения целостности, задаваемые на уровне доменов, при поддержке доменной структуры. Эти ограничения удобны, если в БД присутствуют несколько столбцов разных отношений, которые принимают значения из одного и того же множества допустимых значений;

· ограничения целостности, задаваемые на уровне отношения. Некоторые семантические правила невозможно преобразовать в выражения, которые будут применимы только к одному столбцу;

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

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

Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 15; возраст родителей не может быть меньше возраста их биологического ребёнка и т. д.

Очевидно, что ограничения должны быть формально объявлены для СУБД , после чего СУБД должна предписывать их выполнение. Объявление ограничений сводится просто к использованию соответствующих средств языка базы данных, а соблюдение ограничений осуществляется с помощью контроля со стороны СУБД над операциями обновления, которые могут нарушить эти ограничения, и запрещения тех операций, которые их действительно нарушают. При первоначальном объявлении ограничения система должна проверить, удовлетворяет ли ему в настоящий момент база данных. Если это условие не соблюдается, ограничение должно быть отвергнуто; в противном случае оно принимается (то есть записывается в каталог системы) и начиная с этого момента соблюдается :338 .

Механизмы обеспечения целостности являются одной из составляющих концепции модели данных .

Классификация ограничений целостности [ | ]

В теории реляционных баз данных принято выделять четыре типа ограничений целостности :353:

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

Целостность и истинность данных в БД [ | ]

Целостность БД не гарантирует достоверности (истинности) содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность (непротиворечивость) БД с истинностью БД. Истинность и непротиворечивость - не одно и то же :351 .

Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД не может гарантировать наличие в базе данных только истинных высказываний; все, что она может сделать, - это гарантировать отсутствие каких-либо данных, вызывающих нарушение ограничений целостности (то есть гарантировать то, что она не содержит каких-либо данных, не совместимых с этими ограничениями) :351 .

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

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

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

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-значений.

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

Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).

Вывод - логическая модель данных неадекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.

44. Базы данных. Классификация баз данных. Понятие целостности и непротиворечивости базы данных, методы и средства обеспечения целостности и непротиворечивости. Понятие банка данных, свойства банка данных: независимость, ограниченность доступа по отношению к каким параметрам/точкам (объектам) банка данных можно ограничить доступ, как это реализуется;

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

Не следует путать Базу данных с Системой управления баз данных (СУБД) – программное обеспечение, предназначенное для организации и ведения баз данных.

Обычно так же акцентируют внимание на следующих особенностях: 1) БД хранятся в вычислительной системе - данная особенность нередко включается в определение БД, 2) данные в БД логически структурированы, 3) помимо прочего в БД содержатся метаданные, описывающие логическую структуру данных БД в формальном виде Классификация баз данных : Классификация БД по модели данных:

Примеры: Иерархические, Сетевые, Реляционные, Объектные, Объектно-ориентированные, Объектно-реляционные

Классификация БД по степени распределённости: Централизованные (сосредоточенные), Распределённые

Кроме того можно выделить: Классификация БД по технологии физического хранения: БД во вторичной памяти (традиционные); БД в оперативной памяти (in-memory databases); БД в третичной памяти (tertiary databases)

Классификация БД по содержимому:

Примеры: Географические:Исторические: Научные; Мультимедийные.;

По характеру хранимой информации: Фактографические (картотеки); Документальные (архивы)

Всего существует более 50 видов классификаций БД

Отдельное место в теории и практике занимают пространственные (spatial), временные, или темпоральные (temporal) и пространственно-временные (spatial-temporal) БД.

По технологии обработки данных базы данных подразделяются на централизованные и распределенные.

Централизованная база данных хранится в памяти одной вычислительной системы. Эта вычислительная система может быть мэйнфреймом - тогда доступ к ней организуется с использованием терминалов - или файловым сервером локальной сети ПК.

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

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

Централизованные базы данных с сетевым доступом могут иметь следующую архитектуру:

    файл-сервер;

    клиент-сервер базы данных;

    "тонкий клиент" - сервер приложений - сервер базы данных (трехуровневая архитектура).

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

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

Трехуровневая архитектура функционирует в Интранет- и Интернет-сетях. Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к базе данных, передаваемых на выполнение серверу баз данных. Сервер приложений может быть Web-сервером или специализированной программой.

Понятие целостности и непротиворечивости базы данных, методы и средства обеспечения целостности и непротиворечивости.

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

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

База данных находится в согласованном (целостном) состоянии, если выполнены (удовлетворены) все ограничения целостности, определенные для базы данных.

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

Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения.

Непротиворечивость или Консистентность(от англ. сonsistency)данных - согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость. Множество всех условий, налагаемых на данные определяется моделью (структурой) данных

Условия консистентности данных в модели сущность-связь(ER-модели)

Если данные представляют собой связанные отношениями узлы различного типа, в которых хранятся какие-то данные, то в модели данных могут быть оговорены условия: какие именно данные там могут хранится, и узлы каких типов могут быть связаны заданными в модели отношениями (связями)

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

Классификация ограничений целостности

Классификация ограничений целостности по способам реализации

Каждая система обладает своими средствами поддержки ограничений целостности. Различают 2 способа реализации: 1. Декларативная поддержка ограничений целостности. 2. Процедурная поддержка ограничений целостности.

Декларативная поддержка ограничений целостности заключается в определении ограничений средствами языка определения данных (DDL - Data Definition Language). Обычно средства декларативной поддержки целостности (если они имеются в СУБД) определяют ограничения на значения доменов и атрибутов, целостность сущностей (потенциальные ключи отношений) и ссылочную целостность (целостность внешних ключей). Декларативные ограничения целостности можно использовать при создании и модификации таблиц средствами языка DDL или в виде отдельных утверждений (ASSERTION).

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

Классификация ограничений целостности по времени проверки

1. Немедленно проверяемые ограничения. 2. Ограничения с отложенной проверкой.

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

Ограничения с отложенной проверкой проверяется в момент фиксации транзакции оператором COMMIT WORK. Внутри транзакции ограничение может не выполняться. Если в момент фиксации транзакции обнаруживается нарушение ограничения с отложенной проверкой, то транзакция откатывается.

Классификация ограничений целостности по области действия

1. Ограничения домена 2. Ограничения атрибута 3. Ограничения кортежа 4. Ограничения отношения 5. Ограничения базы данных 6. Ограничения домена.

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

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

Ограничения целостности кортежа представляют собой ограничения, накладываемые на допустимые значения отдельного кортежа отношения, и не являющиеся ограничением целостности атрибута. Требование, что ограничение относится к отдельному кортежу отношения, означает, что для его проверки не требуется никакой информации о других кортежах отношения. Приведенное ограничение кортежа, по сути, является дополнительным ограничением на значения одного атрибута. В этом случае допустимы два решения. Можно объявить новый домен "Возраст сотрудника спецподразделения" и тогда ограничение кортежа становится ограничением домена и атрибута, либо рассматривать это ограничение именно как ограничение кортежа. Оба решения имеют свои положительные и отрицательные стороны.

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

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

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

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

Связи между данными, хранимыми в разных отношениях, в реляционной БД устанавливаются с помощью использования внешних ключей - для установления связи между кортежом из отношения A с определённым кортежом отношения B в предусмотренные для этого атрибуты кортежа отношения A записывается значение первичного ключа (а в общем случае значение потенциального ключа) целевого кортежа отношения B. Таким образом, всегда имеется возможность выполнить две операции: определить, с каким кортежем в отношении B связан определённый кортеж отношения A;найти все кортежи отношения A, имеющие связи с определённым кортежем отношения B.Благодаря наличию связей в реляционной БД можно хранить факты без избыточного дублирования, то есть в нормализованном виде. Ссылочная целостность может быть проиллюстрирована следующим образом: Дана пара отношений A и B, связанных внешним ключом. Первичный ключ отношения B - атрибут B.key. Внешний ключ отношения A, ссылающийся на B - атрибут A.b. Ссылочная целостность для пары отношений A и B имеет место тогда, когда выполняется условие: для каждого кортежа отношения A существует соответствующий кортеж отношения B, то есть кортеж, у которого (B.key = A.b).

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

Если вышеприведённое условие не выполняется, говорят, что в базе данных нарушена ссылочная целостность. Такая БД не может нормально эксплуатироваться, так как в ней разорваны логические связи между зависимыми друг от друга фактами. Непосредственным результатом нарушения ссылочной целостности становится то, что корректным запросом не всегда удаётся получить корректный результат.

Поддержание ссылочной целостности в БД

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

Некорректная работа прикладного программного обеспечения

Неполная запись объектов. Данные объекта размещаются в записях нескольких таблиц, а программа не записывает какую-то из них.

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

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

Сбои в работе системного программного обеспечения и оборудования. Даже когда прикладное программное обеспечение работает совершенно правильно, возможно нарушение ссылочной целостности. Например, если при добавлении объекта в базу нужно добавить несколько связанных записей в несколько таблиц, очевидно, что ссылочная целостность будет нарушена в процессе добавления данных (когда часть связанных записей уже добавлена, а часть - ещё нет), и восстановится только после завершения операции. Если во время выполнения операции она будет прервана (из-за переполнения диска, сбоя питания, или по каким-то другим причинам), часть записей будет добавлена в БД, часть - нет. Часть добавленных записей останется с некорректными ссылками.

Пустые внешние ключи. Возможна ситуация, когда внешний ключ вместо ссылки на существующую запись в таблице БД содержит «отсутствующее значение» NULL. Такое положение можно трактовать как отсутствие какой-то части объекта. Хотя с точки зрения чистой теории это недопустимо, на практике иногда бывает удобно разрешить использование пустых внешних ключей. Чтобы корректно работать с группами связанных таблиц, допускающих пустые внешние ключи, используется специфическая операция языка SQL - открытое соединение (другое название - «внешнее соединение», англ. outer join).

Транзакции. Обязательным (хотя и не достаточным) условием сохранения ссылочной целостности базы данных является поддержка транзакций. Если программное обеспечение выполняет группу связанных между собой операций, которые по отдельности могут приводить к нарушению целостности ссылок, СУБД должна предоставлять возможность выполнения всей этой группы в одной транзакции, то есть так, чтобы при любом сбое производилась автоматическая отмена всех операций группы, в том числе уже полностью завершённых. Так же для обеспечения этого механизма в БД поддерживается журнал транзакций. Прежде чем транзакция будет выполнена, данные о ней заносятся в журнал. После выполнения транзакции делается пометка о завершении транзакций. Далее восстановление транзакций происходит по журналу.

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

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

Запрет - удаление блокируется и возвращается ошибка.

Каскадное удаление - в одной транзакции производится удаление данной записи и всех записей, ссылающихся на данную. Если на удаляемые записи также есть ссылки и настройки также требуют удаления, то каскадное удаление продолжается дальше. Таким образом, после удаления данной записи в базе не остаётся ни одной записи, прямо или косвенно ссылающейся на неё. Если хотя бы одну из ссылающихся записей удалить не получается (либо для неё настроен запрет, либо происходит какая-либо ещё ошибка), то все удаления запрещаются.

Обнуление внешних ключей - во все внешние ключи записей, ссылающихся на данную, записывается псевдозначение NULL (SQL). Если хотя бы для одной из ссылающихся записей это невозможно (например, если поле внешнего ключа описано так, что его нельзя обнулять), то удаление запрещается.Итак, основные аспекты целостности БД:

    обязательные данные;

    ограничения для доменов полей;

    целостность сущностей;

    ссылочная целостность.

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

Понятие банка данных : В узком смысле БнД=Бд + СУБД. В широком БнД =АС (автоматизированная система) (понятие во многом устаревает). По законодательству РФ, банк данных - совокупность баз данных, а также программные, языковые и другие средства, предназначенные для централизованного накопления данных и их использования с помощью электронных вычислительных машин.

Банк данных (БнД) - это Автоматизированная информационная система(АИС), включающая в свой состав комплекс специальных методов и средств (математических, информационных, программных, языковых, организационных, технических) для поддержания динамической информационной модели предметной области с целью обеспечения обработки информационных запросов пользователя.

В состав банка данных входят одна или несколько баз данных, справочник баз данных, СУБД, а также библиотеки запросов и прикладных программ.

Обычно со стороны внешних пользователей к БнД формулируются следующие требования . БнД должен:

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

    Обеспечивать заданный уровень достоверности хранимой информации.

    Обеспечивать доступ к данным только пользователям с соответствующими полномочиями.

    Обеспечивать возможность поиска информации по произвольной группе признаков.

    Удовлетворять заданным требованиям по производительности при обработке запросов.

    Иметь возможность реорганизации и расширения при изменении границ ПО.

    Обеспечивать выдачу информации пользователю в различной форме.

    Обеспечивать простоту и удобство обращения внешних пользователей за информацией.

    Обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

С совершенствованием архитектуры ЭВМ и ростом эффективности программного и аппаратного обеспечения, должны претерпевать изменения и методы доступа, и способы хранения данных. Если же методы доступа и способы хранения будут заложены в логике прикладной программы, то программистам придется приложить гораздо большие усилия на поддержание и обновление программ, что приведет к дополнительным ошибкам и расходу ресурсов. С другой стороны, пользователей базы данных (прикладных программистов и пользователей терминалов) следует ориентировать на информационное содержание данных и не посвящать в детали их представления и расположения. Таким образом, можно использовать базу данных и не знать внутреннее представление данных. Этим и достигается их независимость . В идеальном случае нужно так проектировать базу данных, СУБД и БнД так, чтобы изменения природы БД не приводили к изменению прикладных программ

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

Защита данных (ЗД) - предупреждение несанкционированного (случайного или умышленного) доступа к данным, их изменения или разрушения со стороны пользователей; предупреждения изменения или разрушения данных при сбоях аппаратных или программных средств и ошибках в работе сотрудников группы эксплуатации.

Функции ЗД : -·обеспечение безопасности данных; - обеспечение секретности данных.

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

Уровни доступа к БД :

1. Неограниченный доступ ко всем отношениям в БД и их поколениям.

2. Неограниченный доступ к группе отношений и их поколениям

3. Ограниченный доступ к группе отношений и их поколениям.

45. Реляционная модель данных: суть, достоинства и недостатки; понятие о нормализации, виды нормальных форм, какие недостатки они устраняют. Реляционная модель данных - логическая модель данных, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных. 1. Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений. 2. Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных. 3. Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление). Кроме того, в состав реляционной модели данных обычно включают теорию нормализации. Реляционная модель данных является приложением к задачам обработки данных таких разделов математики как теория множеств и формальная логика. Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране.

Для лучшего понимания РМД следует отметить три важных обстоятельства:

    модель является логической, т.е. отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

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

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

Принципы реляционной модели были сформулированы в 1969-1970 годах Э. Ф. Коддом. Альтернативами реляционной модели являются иерархическая модель и сетевая модель. Некоторые системы, использующие эти старые архитектуры по-прежнему используется до сих пор. Кроме того, можно упомянуть об объектной модели данных, на которой строятся так называемые объектные СУБД, хотя однозначного и общепринятого определения такой модели нет. Достоинства реляционной модели

    Простота и доступность понимания конечным пользователем - единственной информационной конструкцией является таблица.

    При проектировании реляционной БД применяются строгие правила, базирующие на математическом аппарате.

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

    Для построения запросов и написания прикладных программ нет необходимости знания конкретной организации БД во внешней памяти.

Недостатки реляционной модели

    Относительно низкая скорость доступа и большой объем внешней памяти.

    Трудность понимания структуры данных из-за появления большого кол-ва таблиц в результате логического проектирования.

    Далеко не всегда предметную область можно представить в виде совокупности таблиц.

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

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

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

Понятие нормальной формы было введено Эдгаром Коддом при создании реляционной модели БД. Основное назначение нормальных форм - приведение структуры базы данных к виду, обеспечивающему минимальную избыточность. Устранение избыточности производится за счёт декомпозиции отношений (таблиц) таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). Таким образом, нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Типы нормальных форм. Нормализация может применяться к таблице, которая представляет собой правильное отношение.

Первая нормальная форма (1NF). Таблица находится в первой нормальной форме, если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.

Замечание: в реляционной модели отношение всегда находится в 1 (или более высокой) нормальной форме в том смысле, что иные отношения не рассматриваются в реляционной модели. То есть само определение понятия отношение заведомо подразумевает наличие 1NF.

Вторая нормальная форма (2nf)

Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов(частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1NF).

Третья нормальная форма (3nf)

Таблица находится в третьей нормальной форме (3NF), если она находится во второй нормальной форме 2NF и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK) (иначе говоря, один факт хранится в одном месте ).

Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A - набор ключевых атрибутов (ключ), B и С - различные множества неключевых атрибутов.

При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3NF.

Нормальная форма Бойса - Кодда (bcnf)

Это модификация третьей нормальной формы (в некоторых источниках именно 3NF называется формой Бойса - Кодда). Таблица находится в BCNF, если она находится в 3NF, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов. Таблица может находиться в 3NF, но не в BCNF, только в одном случае: если она имеет, помимо первичного ключа, ещё по крайней мере один возможный ключ. Все зависимые от первичного ключа атрибуты должны быть потенциальными ключами отношения. Если это условие не выполняется, для них создаётся отдельное отношение. Чтобы сущность соответствовала BCNF, она должна находиться в третьей нормальной форме. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в BCNF.

Четвёртая нормальная форма (4nf)

Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y. То есть, таблица находится в 4NF, если все ее многозначные зависимости являются функциональными.

Пятая нормальная форма (5nf)

Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной. Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции - соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

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

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

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

Ограничения целостности могут относиться к разным информационным объектам: атрибутам, кортежам, отношениям, связям между ними и тому подобное.

Для полей (атрибутов) используются следующие виды ограничений:

· Тип и формат поля (автоматически допускают ввод только данных определенного типа).

· Задание диапазона значений. Данное ограничение используется обычно для числовых полей. Различают открытые и закрытые диапазоны: первые фиксируют значение только одной из границ, вторые – обеих границ.

· Недопустимость пустого поля. Ограничение позволяет избежать появления в БД «ничейных» записей, в которых пропущены какие-либо обязательные данные, например: поле «ФИО» должно обязательно иметь значение, а у поля «ученая степень» значение может отсутствовать.

· Задание домена. Ограничение позволяет избежать излишнего разнообразия данных, если его можно ограничить, например, значением поля «должность» для преподавателей может быть одно из следующих значений: ассистент, старший преподаватель, доцент, профессор.

· Проверка на уникальность значения какого-либо поля. Ограничение позволяет избежать записей-дубликатов. Данное ограничение возникает при отображении в базе данных каких-либо объектов, когда уникальное поле является идентификатором объекта; поэтому данное ограничение часто называют ограничением целостности объекта .

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

Перечисленные выше ограничения определяют проверку значения поля вне зависимости от того, вводится ли это ограничение впервые или корректируется имеющееся в БД значение. Ограничения, используемые только при проверке допустимости корректировки, называют ограничениями перехода . Например, если в БД имеется поле «возраст сотрудника», то при корректировке значение этого поля может только увеличиваться; если в БД имеется поле «год рождения», то на корректировку этого поля должен быть наложен запрет. В случае попытки произвести некорректное исправление должно выдаваться диагностирующее сообщение.

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

Существуют ограничения, проверяющие соотношения между записями одной таблицы, например, «год рождения матери» должен быть меньше, чем «год рождения ребенка»; нельзя быть родителем и ребенком одного и того же человека.

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

Если СУБД не позволяет контролировать какие-либо ограничения целостности, то следует создавать процедуры (программы), позволяющие это делать.

Все ограничения, которые были рассмотрены выше, затрагивают информационные единицы в пределах одной таблицы. Кроме такого рода ограничений имеются ограничения, относящиеся к нескольким взаимосвязанным таблицам, например, ограничение целостности связи , которое выражается в том, что значение атрибута, отражающего связь между объектами и являющегося внешним ключом отношения, обязательно должно совпадать с одним из значений атрибута, являющегося ключом отношения, описывающего соответствующий объект. Например, в БД имеются три таблицы: «Преподаватели», «Дисциплины» и таблица, отражающая связь между преподавателями и дисциплинами: код преподавателя в последней из трех таблиц должен соответствовать одному их кодов в таблице «Преподаватели», а код дисциплины – значению соответствующего поля в таблице «Дисциплины».

Своеобразным видом ограничения является запрет на обновление . Он может относиться и к отдельному полю, и ко всей записи, и к целой таблице. Например, не могут меняться значения таких полей, как «Дата рождения», «Место рождения»; или пусть имеется таблица «Поощрения» с полями: «Табельный номер сотрудника», «Вид поощрения», «Дата», - в такую таблицу записи могут только добавляться, а изменяться не могут.

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

Ограничения целостности разделяют по моменту контроля за соблюдением ограничения – на одномоментные и отложенные. Отложенные ограничения целостности могут не соблюдаться в процессе выполнения какой-либо группы операций, но обязаны быть соблюдены по завершении выполнения этой группы операций. С понятием отложенного ограничения тесно связано понятие транзакции. В системе Microsoft Access транзакция определяется как набор операций, результат которых подтверждается (сохраняется) в том и только том случае, если все операции набора прошли успешно. Если какая-либо из операций транзакции не выполнена, то все выполненные ранее операции отменяются, и данные возвращаются к тому состоянию, которое они имели до начала выполнения транзакции. Примером может служить перевод денег с одного банковского счета на другой, состоящий из двух операций: удаление денег с одного счета и добавление такой же суммы денег на другой счет.

Ограничения целостности разделяют по способу задания – на явные и неявные. Неявные ограничения определяются спецификой модели данных и проверяются СУБД автоматически. Неявные ограничения обычно относятся к классу синтаксических ограничений в отличие от семантических ограничений целостности, обусловленных спецификой предметной области.

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

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

Резюме. Задание ограничений целостности и их проверка являются важной частью проектирования и функционирования БнД. При проектировании БнД необходимо изучить, какие возможности по контролю целостности предоставляет используемая СУБД. Если СУБД автоматически не поддерживает нужное ограничение, то обеспечение его соблюдения становится заботой проектировщика.

Тесты для самоконтроля


1 . Утверждения о допустимых значениях отдельных информационных единиц и связях между ними называют:

а) ограничениями перехода;

б) ограничениями целостности связи;

в) ограничениями целостности.

2 . Ограничения целостности:

а) определяются в основном особенностями предметной области;

б) предназначены для отражения чисто информационных характеристик;

в) подразумевают, что пользователям разрешается выполнять некоторые действия.

3 . Могут не соблюдаться в процессе выполнения какой-либо группы операций, но обязаны быть соблюдены по завершении этой группы операций:

а) отложенные ограничения;

б) ограничения перехода;

в) явные ограничения.

4 . К классу синтаксических ограничений относятся:

а) ограничения целостности связи;

б) неявные ограничения;

в) ограничения перехода.

5 . Понятие транзакции связано с понятием:

а) отложенного ограничения;

б) одномоментного ограничения;

в) явного ограничения.

6 . По способу задания ограничения разделяют:

а) на одномоментные и отложенные;

б) на синтаксические и семантические;

в) на явные и неявные.

7 . Обеспечение соблюдения ограничений целостности:

а) является заботой пользователя;

б) является заботой проектировщика;

в) является функцией СУБД.

8 . Ограничения целостности являются важной компонентой:

а) даталогической модели;

б) базы данных;

в) инфологической модели.

НАСТОЛЬНЫЕ СУБД

На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, считаются dBase , Раrаdох , FoxPro и Access . Отмечают также СУБД Microsoft Data Engine – по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server , но предназначенную для использования главным образом в настольных системах и небольших рабочих группах.

Сведения о производителях перечисленных выше СУБД представлены в табл. 9.1.

DBase и Visual dBase

Первая промышленная версия СУБД dBase – dBase II появилась в начале 80-х годов. Благодаря простоте в использовании, нетребовательности к ресурсам компьютера и, что не менее важно, грамотной маркетинговой политике компании-производителя, этот продукт приобрел немалую популярность, а с выходом следующих его версий – dBase III и dBase III Рlus (1986 г.), оснащенных весьма комфортной по тем временам средой разработки и средствами манипуляции данными, быстро занял лидирующие позиции среди настольных СУБД и средств создания использующих их приложений.

Хранение данных в dBase основано на принципе «одна таблица – один файл» (эти файлы обычно имеют расширение *.dbf ). МЕМО – поля и ВLОВ – поля (доступные в поздних версиях dBase ) хранятся в отдельных файлах (обычно с расширением *.dbt ). Индексы для таблиц также хранятся в отдельных файлах.

Формат данных dBase является открытым, что позволило ряду других производителей заимствовать его для создания dBase -подобных СУБД, частично совместимых с dBase по форматам данных.

Помимо популярного формата данных dBase является родоначальником и некогда популярного семейства языков программирования, получившего название хВаsе . Однако для работы с данными формата dBase (или иных dBase -подобных СУБД) совершенно необязательно пользоваться диалектами хВаsе . Доступ к этим данным возможен с помощью ОDВС АРI (и соответствующих драйверов) и некоторых других механизмов доступа к данным.

После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase , приобрел набор дополнительных возможностей, характерных для средств разработки этой компании, и для имевшейся у нее другой настольной СУБД – Раrаdох . Среди этих возможностей можно отметить специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования ВDЕ АРI и SQL Links .

В настоящее время Visual dBase принадлежит компании dBase , Inс . Его версия – Visual dBase 7.5 имеет следующие возможности:

dBase и FoxPro всех версий;

· средства публикации данных в Internet и создания Web -клиентов;

· ядро доступа к данным Аdvantage Database Server фирмы Extended Systems и ОDВС - драйвер для доступа к данным этой СУБД;

· средства публикации отчетов в Web ;

· средства генерации исполняемых файлов и дистрибутивов.

В настоящее время к Visual dBase в качестве дополнения может быть приобретен компонент dСоnnections , позволяющий осуществить доступ к данным Оracle , Sybase , Informix , МS SQL Server , DB2 , InterBase из Visual dBase 7.5 и приложений, созданных с его помощью.

Компания DBase , Inс объявила также о проекте dBASE Open Source , целью которого является разработка сообществом пользователей dBase новых компонентов и классов с целью включения их в последующую версию dBase (получившую название dBase 2000 ). Иными словами, имеется тенденция превращения dBase (или его частей) в некоммерческий продукт с доступными исходными текстами.

Рarаdох

Раrаdох был разработан компанией Аnsa Software , и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Воrland . С июля 1996 года он принадлежит компании Соrеl и является составной частью Соrеl 0ffice Professional .

В конце 80-х - начале 90-х годов Раrаdох , принадлежавший тогда компании Воrland International , был весьма популярной СУБД, в том числе и в нашей стране.

Принцип хранения данных в Раrаdох сходен с принципами хранения данных в dВаsе – каждая таблица хранится в своем файле (расширение *.db ), МЕМО - и ВLOB -поля хранятся в отдельном файле (расширение *.md ), как и индексы (расширение *.рх ). Однако, в отличие от dBase , формат данных Раrаdох не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки.

Отсутствие «открытости» формата данных имеет свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании «открытых» форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах – все эти сервисы предоставляются Раrаdох , начиная с первых версий этой СУБД.

По сравнению с аналогичными версиями dВаsе ранние версии Раrаdох обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS -приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QВЕ – Query by Ехаmрlе , средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования РАL (Paradox Аррlication Language ).

Windows -версии СУБД Раrаdох , помимо перечисленных выше сервисов, позволяют также манипулировать данными других форматов, в частности dВаsе и данными, хранящимися в серверных СУБД. Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Раrаdох как средство разработки приложений и манипуляции данными.

Версия данной СУБД – Раrаdох 9 , поставляется в двух вариантах – Раrаdох 9 Standalone Edition и . Первый из них предназначен для использования в качестве настольной СУБД и входит в Соrеl Оffice Professional , второй – в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:

· средства манипуляции данными Раrаdох и dBase ;

· средства создания форм, отчетов и приложений;

· средства визуального построения запросов;

· средства публикации данных и отчетов в Internet и создания Web -клиентов;

· Cоrеl Web – сервер;

· ОDВС – драйвер для доступа к данным формата Раrаdох из Windows -приложений;

· средства для доступа к данным формата Раrаdох из Java -приложений.

Помимо этого, Раrаdох 9 Developer’s Edition содержит:

· Run – time - версию Раrаdох для поставки вместе с приложениями;

· средства создания дистрибутивов;

· драйверы SQL Links для доступа к данным серверных СУБД.

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