Ограничение целостности

 

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

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

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

Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных. Но при этом следует отметить, что целостность базы данных не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность базы данных с достоверностью базы данных. Достоверность (или истиность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности базы данных требуется обладание полными знаниями, как о содержимом базы данных, так и о реальном мире. Для определения целостности базы  данных требуется лишь обладание знаниями о содержимом базы данных и о заданных для неё правилах.

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

Итак, базы данных может быть целостной, но не достоверной. Возможно и обратное: базы данных может быть достоверной, но не целостной. Последнее имеет место, если правила (ограничения целостности) заданы неверно.

Вопрос №12

Реляционные структуры данных Кодд предложил использовать в качестве родовой структуры БД «таблицы», в которых и столбцы, и строки не являются упорядоченными. Легко видеть, что такая «таблица» со множеством столбцов {A1, A2, …, An}, в которой каждый столбец Ai может содержать значения из множества Ti = {vi1, vi2, …, vim} (все множества конечны), в математическом смысле представляет собой отношение над множествами {T1, T2, …, Tn}.  В математике отношением над множествами {T1, T2, …, Tn} называется подмножество декартова произведения этих множеств, т.е. некоторое множество кортежей v1, v2, …, vn, где vi Ti. Поэтому для обозначения родовой структуры Кодд стал использовать термин отношение (relation), а для обозначения элементов отношения – термин кортеж. Соответственно, модель данных получила название реляционной модели. Схема БД в реляционной модели данных – это набор именованных заголовков отношений вида Hi = {<Ai1, Ti1>, < Ai2, Ti2>, …, < Aini, Tini>}. Ti называется доменом атрибута Ai. По Кодду, каждый домен Ti является подмножеством значений некоторого базового типа данных Ti+, а значит, к его элементам применимы все операции этого базового типа (в конце 1960-х гг. базовыми типами данных считались типы данных распространенных тогда языков программирования; в IBM наиболее популярными языками были PL1 и COBOL). Реляционная база данных в каждый момент времени представляет собой набор именованных отношений, каждое из которых обладает заголовком, таким как он определен в схеме БД, и телом. Имя отношения Ri совпадает с именем заголовка этого отношения HRi.  Тело отношения BRi – это множество кортежей вида {<Ai1, Ti1, vi1>, < Ai2, Ti2, vi2>, …, < Aini, Tini, vini>}, где tij Tij1. Во время жизни БД тела отношений могут изменяться, но все содержащиеся в них кортежи должны соответствовать заголовкам соответствующих отношений.

Вопрос №13

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

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

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

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

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

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

Вопрос №14