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

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

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

• диаграммы " сущность-связь " (Entity - Relationship Diagrams);
• определения сущностей;
• уникальные идентификаторы сущностей ;
• определения атрибутов сущностей ;
• отношения между сущностями;
• супертипы и подтипы.

Внимание! Элементы информационной модели данных предметной области являются входными данными для решения задачи проектирования базы данных - создания логической модели данных .

Сущности, атрибуты и идентификаторы (ключи) сущности, домены атрибутов

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

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

Внимание! При представлении сущности в базе данных хранятся только ее атрибуты.

Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.

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

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

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

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

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

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

Отношения, связи

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

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

Связи характеризуются степенью связи и классом принадлежности сущности к связи. Степень ( мощность) связи - это отношение числа сущностей, участвующих в образовании связи. Например, "один-к-одному", "один-ко-многим", "многие-ко-многим". На уровне информационной модели допускается неопределенная или неразрешенная связь. Класс принадлежности сущности - это характер участия сущности в связи. Различают обязательные и необязательные классы принадлежности сущности к связи. Обязательным является такой класс принадлежности, когда экземпляры сущности участвуют в установлении связи в обязательном порядке. В противном случае сущность принадлежит к необязательному классу принадлежности. Для необязательного класса принадлежности сущности степень связи может быть равна нулю, т.е. экземпляр сущности можно связать с 0, 1 или несколькими экземплярами другой сущности. Для обязательного класса принадлежности степень связи не может равняться нулю.

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

С точки зрения отношений различают слабые ( weak ) сущности. Слабые сущности - это сущности, которые не могут присутствовать в базе данных, пока не существует связанного с ней экземпляра другой сущности. Примером такой сущности является заказ, который не может существовать без клиента. Слабые сущности имеют обязательный класс принадлежности, и степень связи такой сущности не может равняться нулю. Связь "заказ-клиент" является обязательной.

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

Подтипы и супертипы

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

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

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

Пример. Сущность Автомобиль можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.

Для проектировщика базы данных важно знать, что все экземпляры сущности - супертипа относятся только к одному из ее подтипов. Наличие в модели подтипов и

3 . Компоненты модели данных

Сущность (entity), определение сущности, источники информации о сущностях

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

3 .1 Сущности

Сущность - это что-то такое, о чем нужно хранить информацию в базе данных.

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

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

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

Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов

1. Какие проблемы могут возникнуть у разработчика при проектировании базы данных?

При проектировании базы данных и разработке программного продукта наиболее важной проблемой есть проблема взаимодействия разработчика с заказчиком. Задача разработчика – наиболее точно воссоздать пожелания заказчика при разработке программного продукта управления базой данных. Основная проблема, которую нужно решить разработчику – правильное построение базы данных, а точнее схемы (структуры) базы данных.

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

• поиск эффективных алгоритмов;
• подбор надлежащих структур данных;
• отладка и тестирование сложного кода;
• дизайн и удобство интерфейса приложения.

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

Чтобы облегчить процесс разработки (проектирования) базы данных, используются так называемые семантические модели данных. Для разных видов баз данных наиболее известной есть ER-модель данных (Entity-Relationship model).

2. Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?

ER-модель (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных. Из ER-модели могут быть порождены все виды баз данных: реляционные, иерархические, сетевые, объектные. В основе ER-модели лежат понятия «сущность», «связь» и «атрибут».

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

ER-модель – это представление базы данных в виде наглядных графических диаграмм. ER-модель визуализирует процесс, который определяет некоторую предметную область. Диаграмма «сущность»-«связь» – это диаграмма, которая представляет в графическом виде сущности, атрибуты и связи.

ER-модель – это только концептуальный уровень моделирования. ER-модель не содержит деталей реализации. Для той же самой ER-модели детали ее реализации могут отличаться.

3. Что такое сущность в базе данных? Примеры

Сущность в базе данных – это любой объект в базе данных, который можно выделить исходя из сути предметной области для которой разрабатывается эта база данных. Разработчик базы данных должен уметь правильно определять сущности.

Пример 1. В базе данных книжного магазина можно выделить следующие сущности:

• книга;
• поставщик;
• размещение в магазине.

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

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

4. Какие существуют разновидности типов сущностей? Обозначение типов сущностей в ER-модели

В модели «сущность»-«связь» различают две разновидности типов сущностей:

• слабый тип . Этот тип сущности есть зависимым от сильной сущности;
• сильный тип . Это самостоятельный тип сущности, который ни от кого не зависит.

На рисунке 1 изображены обозначения слабого и сильного типа сущности в ER-модели.

Рис. 1. Обозначение сильного и слабого типов сущности

5. Для чего предназначены атрибуты? Виды атрибутов. Обозначение атрибутов на ER-модели

Каждый тип сущности имеет определенный набор атрибутов. Атрибуты предназначены для описания конкретной сущности.

Различают следующие виды атрибутов:

• простые атрибуты. Это атрибуты, которые могут быть частью составных атрибутов. Эти атрибуты состоят из одного компонента. Например, к простым атрибутам можно отнести: код книги в библиотеке или курс обучения студента в учебном заведении;
• составные атрибуты. Это атрибуты, которые состоят из нескольких простых атрибутов. Например, адрес проживания может содержать название страны, населенного пункта, улицы, номера дома;
• однозначные атрибуты. Это атрибуты, которые содержат только одно единственное значение для некоторой сущности. Например, атрибут «Номер зачетной книги» для типа сущности «Студент» есть однозначным, так как студент может иметь только один номер зачетной книги (одно значение);
• многозначные атрибуты. Это атрибуты, которые могут содержать несколько значений. Например, многозначный атрибут «Номер телефона» для сущности «Студент», так как студент может иметь несколько номеров телефона (домашний, мобильный и т.д.);
• произвольные атрибуты. Это атрибуты, значение которых формируется на основе значений других атрибутов. Например, текущий курс обучения студента можно вычислить на основе разности текущего года обучения и года поступления студента в учебное заведение (если студент не имел проблем с учебой и хорошо учил дисциплину «Организация баз данных и знаний»).

На ER-диаграмме атрибуты обозначаются так, как изображено на рисунке 2. Как видно из рисунка, любой атрибут обозначается в виде эллипса с названием внутри эллипса. Если атрибут есть первичным ключом, то его название подчеркивают.

Рисунок 2. Представление атрибутов на диаграммах ER-модели

6. Как типы сущностей и атрибуты ER-модели реализуются в реальных базах данных и управляемых ими программах?

При разработке программ управления базами данных, типы сущностей и их атрибуты можно представлять по разному при этом придерживаясь нескольких подходов:

• выбрать в качестве источника данных известную технологию (например Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source и т.п.), которая уже исследована, протестирована, стандартизирована и имеет огромный набор средств управления базой данных;
• разработать собственный формат базы данных и реализовать методы ее обработки, а взаимодействие с известными источниками данных реализовать в виде специальных команд наподобие Импорт/Экспорт. В этом случае придется собственноручно программировать всю рутинную работу по ведению и обеспечению надежной работы базы данных;
• реализовать объединение двух вышеприведенных подходов. Современные средства разработки программного обеспечения имеют мощный набор библиотек для обработки сложных наборов и визуализации данных в них (коллекции, массивы, компоненты визуализации и т.п.).

Если база данных реализуется в известных реляционных СУБД (например Microsoft Access, Microsoft SQL Server и т.п.), то типы сущностей представляются таблицами. Атрибуты из ER-модели соответствуют полям таблицы. Одна запись в таблице базы данных представляет один экземпляр сущности.

Каждый вид атрибута реализуется следующим образом:

• простой атрибут или однозначный атрибут может быть представлен доступным набором базовых типов, которые есть в любом языке программирования. Например, целочисленные атрибуты представляются типом int , integer , uint и т.д.; атрибуты содержащие дробную часть могут быть представлены типом float , double ; строчные атрибуты типом string и т.д.;
• составной атрибут – это объект, который включает в себя несколько вложенных простых атрибутов. Например, в СУБД Microsoft Access составной атрибут некоторой таблицы может формироваться на основе набора простых типов (полей). В языках программирования объединение полей реализуется структурами или классами;
• многозначный атрибут может быть реализован массивом или коллекцией простых или составных атрибутов;
• произвольный атрибут реализуется дополнительным полем, которое вычисляется при обращении к таблице. Такое поле называется вычислительным полем (calculated field) и формируется на основе других полей таблицы;
• атрибут, который есть первичным ключом может быть целочисленным, строчным или иного порядкового типа. В этом случае, значение каждой ячейки таблицы, которая соответствует первичному ключу, есть уникальным. Наиболее часто, в качестве первичного ключа выступает целый тип (int , integer ).

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

7. Пример фрагмента ER-модели для типа сущности «Студент»

Приведенный пример демонстрирует фрагмент ER-модели для типа сущности «Студент».

Рисунок 3. Фрагмент ER-модели для типа сущности «Студент»

На вышеприведенном рисунке объявляются следующие атрибуты, которые в СУБД (программе) могут иметь следующие типы:

• атрибут Первичный ключ – есть уникальным целочисленным значением которое формируется автоматически. В СУБД это есть поле-счетчик;
• атрибут Год вступления – простой атрибут, который можно реализовать целочисленным значением (int , integer );
• атрибут Номер телефона – многозначный атрибут, который может быть реализован как массив или коллекция и т.п.;
• атрибут Номер зачетной книжки – простой атрибут, который можно реализовать как строку символов, поскольку номер зачетной книжки кроме цифр может содержать и буквы;
• атрибут Страна , Город , Улица , Номер дома – это атрибуты, которые образуют составной атрибут Адрес . Все эти атрибуты могут быть строчного (текстового) типа (string , Text );
• атрибут Фамилия , Имя , Отчество – это простые атрибуты, которые являются частью составного атрибута Имя студента . Все эти атрибуты могут быть строчного (текстового) типа (string , Text );
• атрибут День рождения – простой атрибут типа Дата (DateTime );
• атрибут Возраст студента – вычисляемое поле, которое определяется как разность текущей (системной) даты и значения атрибута День рождения .

Сущность (Entity) - реальный или абстрактный объект, имеющий существенное значение для предметной области. Сущность должна иметь наименование, выраженное существительным в единственном числе

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

Экземпляр сущности - это конкретный представитель данной сущности. Например, экземпляром сущности Сотрудник может быть сотрудник Иванов.

Каждая сущность должна обладать следующими свойствами:

иметь уникальное имя;

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

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

Атрибут (Attribute) - характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для идентификации, классификации, количественной характеристики или выражения состояния сущности.

Существуют следующие виды атрибутов:

простой - состоит из одного элемента данных;

составной - состоит из нескольких элементов данных;

однозначный - содержит одно значение для одной сущности;

многозначный - содержит несколько значений для одной сущности;

необязательный - может иметь пустое (неопределенное) значение;

производный - значение, производное от значения другого атрибута.

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

Каждая сущность может обладать любым количеством связей с другими сущностями.

Связи между сущностями

Связь (Relationship) - поименованная ассоциация между сущностями, значимая для рассматриваемой предметной области.

Степенью связи называется количество сущностей, участвующих в связи.

Мощность связи - число экземпляров сущности, участвующих в связи.

В зависимости от значения мощности связь может иметь один из трех типов:

один-к-одному (обозначается 1:1).

один-ко-многим(обозначается 1:N).

многие-ко-многим(обозначается M:N).

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

Один-ко-многим. Сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

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

Основное правило при создании таблиц сущностей - это «каждой сущности - отдельную таблицу».

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

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

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

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

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

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

Более сложные связи (не бинарные) следует сводить к бинарным. Для описания взаимосвязей N объектов требуется N-1 таблиц связей. Транзитивных связей не должно быть. Избыток связей приводит к противоречиям (см. пример отношений СОТРУДНИКИ-ОТДЕЛ, СОТРУДНИКИ-ПРОЕКТЫ и ОТДЕЛЫ-ПРОЕКТЫ предыдущего подраздела).

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

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

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

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

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

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

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

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

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

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

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

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

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