Согласно концепции Дейта, целостность может рассматриваться как корректность состояний данных и корректность переходов из одного состояния в другое.
Состоянием данных называется совокупность текущих значений, хранящихся в таблицах БД. В зависимости от целей проектирования, разработки и верификации БД, состояние данных можно рассматривать на различных уровнях детализации: допустимо говорить о состоянии БД в целом, а также о состоянии некоторых (выбранных) таблиц или отдельных столбцов. Состояния данных могут быть корректными и некорректными, т. е. допустимыми и недопустимыми с точки зрения здравого смысла. Требование целостности, задающее множество корректных состояний для выбранных таблиц и (или) столбцов, называется требованием к состоянию. Для одной БД можно задать много требований к состоянию, связывающих различные таблицы и столбцы. Примеры требований к состоянию: «масса груза всегда неотрицательна», «номер места в купейном вагоне не может быть больше 36».
Выполнение операций записи в таблицах – вставки, обновления и удаления строк – приводит к переходу данных из одного состояния в другое. Возможны случаи, когда для выбранных таблиц и (или) столбцов только часть возможных переходов является допустимой в данной предметной области или с точки зрения здравого смысла. Требование целостности, задающее множество допустимых переходов для выбранных таблиц и (или) столбцов, называется требованием к переходу. В рамках одного проекта БД может быть определено множество требований к переходу, связанных с различными таблицами и столбцами. Пример требования к переходу: «при регистрации нового оборудования срок эксплуатации равен нулю». Здесь подчеркивается, что нулевой срок эксплуатации имеет только регистрируемое (т. е. добавляемое) оборудование: с течением времени срок эксплуатации уже зарегистрированного оборудования может измениться на ненулевой, что не является нарушением требования.
5.3.2. Способы описания ограничений
Реализация требований целостности – достаточно сложная задача, требующая поэтапного решения. Можно выделить следующие стадии реализации требований целостности:
· словесное описание;
· формальное описание;
· разработка объектов-ограничений БД.
Данная стадия соотносится с концептуальным проектированием БД. Исходной информацией для нее является текстовое описание предметной области. Процесс формулирования требований целостности сопряжен с выявлением сущностей, атрибутов и связей. Результат – описание требования в виде высказывания на естественном языке. Например: «масса груза неотрицательна», «ИНН у разных сотрудников различны» и т. п.
Следует заметить, что в словесных описаниях требований не должны упоминаться таблицы, столбцы и строки, ключи и прочие объекты логической архитектуры БД. Речь идет о внешнем уровне абстрагирования, поэтому в данном случае используются утверждения об атрибутах сущностей и связей предметной области.
Стадия формального описания требований целостности согласуется с логическим проектированием схемы данных. На этом этапе разработчик уже знает, какая именно модель данных им используется и, следовательно, может определиться, какой именно способ формально-математического описания требований целостности является для него наиболее подходящим. Если создается реляционная БД, то схема данных описывается в терминах теории отношений, а требования целостности удобно описывать на языке реляционной алгебры.
Рассмотрим требование «номер паспорта является ключевым атрибутом сущности Сотрудник». Предположим, что сущность «Сотрудник» отображена на логическую схему БД в виде таблицы employees, а атрибут «номер паспорта» - на столбец pass этой таблицы. Поскольку pass является первичным ключом таблицы employees (по условию примера), то, сколько бы ни было значений в этом столбце, ни одно из них:
· не будет неопределенным;
· не встретится в столбце более одного раза.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.