Бизнес-правила и ограничения целостности
. Пусть в нашей ПО действуют следующие правила:
· номер поставщика уникален;
· номер изделия уникален;
· номер вида детали уникален;
· номер поставщика должен иметь вид ‘Sх’, где х любая последовательность цифр;
· номер вида изделия должен иметь вид ‘Jх’, где х любая последовательность цифр;
· номер вида детали должен иметь вид ‘Pх’, где х любая последовательность цифр;
· значение статуса поставщика может быть только целым, кратным 5 в диапазоне 5 ¸100;
· цвет детали должен выбираться из определенного списка;
· названия городов должны выбираться из определенного списка;
· красные детали хранятся только в Яе;
· если город поставщика Яя, то его статус 50;
· конкретный поставщик может в течение одного дня поставить конкретную деталь для конкретного изделия только однажды;
· количество деталей в одной поставке не может быть меньше 100 или больше 1000;
· месячный объем поставки любой детали не может превосходить 10000.
Если в нашей БД есть, например, кортеж {(номер поставщика, ‘S1’), (название поставщика, ‘Рога и копыта’), (статус, 100), (город размещения, ‘Черноморск’)}[15], то он имеет вполне осмысленную интерпретацию в терминах ПО, если значение S# = ‘S1’ встречается только в этом кортеже и Черноморск включен в список городов. Если такого названия нет в списке, то и кортеж осмысленной интерпретации не имеет.
Если мы просуммируем значения поля Qt во всех строках таблицы SPJ, в которых значение P# = ‘P1’, а значения дат лежат в интервале от 01.03.98 до 31.03.98, и увидим, что эта сумма больше 10000, то либо наши данные ошибочны (этого не должно быть по правилам), либо кто-то из служащих нарушил правила.
Подобных правил в любой ПО очень много. Они подчас бывают очень сложными и действуют независимо от способа хранения данных – на бумаге, на диске, … Если они соблюдаются, то гарантирована интерпретируемость данных. Как все правила, они формальны. Их можно сформулировать в виде предикатов и реализовать алгоритмы вычисления значений этих предикатов на текущих значениях хранимых данных.
Иными словами, существует принципиальная возможность
автоматической проверки правил целостности данных.
Проверить истинность данных автомат не может. Интерпретируемый кортеж {‘S1’, ‘Рога и копыта’, 100, ‘Черноморск’}
может вводить в заблуждение, если не существует в Черноморске фирмы с таким названием.
Целостность
данных и адекватность данных – не одно и то же. Данные могут быть целостными, но при этом не соответствующими действительности. Обеспечение адекватности – проблема пользователя, поддержание целостности может быть проблемой СУБД.
Правила, о которых мы только что говорили, являются специфическими в том смысле, что они применяются к одной конкретной БД. Их называют внешними
ограничениями целостности (ОЦ) данных.
Внешние ОЦ
– это обусловленные требованиями конкретной ПО правила, соблюдение которых обеспечивает интерпретируемость хранимых данных.
Замечание 4.
Поддержание правил бизнеса, которые отображены в БД как правила целостности данных, – обязанность младшего и среднего звена администрации предприятия. Поэтому одна из важнейших задач проектировщика БД – выявить все бизнес-правила и максимально полно представить их в системе. Только при этом условии проект будет действительно полезным.
Все БД, основанные на РМД, кроме специфических правил (внешних ОЦ), подчиняются еще общим
правилам целостности. Эти правила называются внутренними ОЦ РМД. Однако, прежде чем обсуждать их, введем важнейшие понятия возможного, первичного и внешнего ключей отношения.
