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

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

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

• родительская сущность;

• дочерняя (зависимая) сущность;

• мощность связи (cordiality);

• допустимость пустых (null) значений.

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.

Хранимые процедуры - это приложение (программа), объединяющее запросы и процедурную логику (операторы присваивания, логического ветвления и т. д.) и хранящееся в базе данных.

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

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

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

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

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

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

Обратите внимание на исключительную важность в этом определении слова "автоматически".

Ссылочная целостность - это обеспечение соответствия значения внешнего ключа экземпляра

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

Ссылочная целостность может контролироваться при всех операциях, изменяющих данные.

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

• отсутствие проверки;

• проверка допустимости;

• запрет операции;

• каскадное выполнение операции обновления или удаления данных сразу в нескольких связанных таблицах;

• установка пустого (NULL) значения или заданного значения по умолчанию.

Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной БД.

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

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

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

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

• Ограничения, для реализации которых собственно и создается триггер.

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

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

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

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

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

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

РЫНОК

КЛИЕНТ

РазраЕстнга кап-элога

Оформление заказа

Рис. 1.4. Упрощенная схема бизнес-процесса

1.2. Описание, постановка задачи и разработка бизнес-правил

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

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

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

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

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