Для того чтобы оценить качество принимаемых решений на уровне логической модели данных, необходимо сформулировать некоторые критерии качества в терминах физической модели и конкретной реализации и посмотреть, как различные решения, принятые в процессе логического моделирования, влияют на качество физической модели и на скорость работы базы данных.
Конечно, таких критериев может быть очень много и выбор их, в достаточной степени, произволен. Мы рассмотрим некоторые из таких критериев, которые являются важными с точки зрения получения качественной базы данных:
- адекватность предметной области;
- легкость разработки и сопровождения базы данных;
- скорость выполнения операций обновления данных – вставка, обновление, удаление кортежей;
- скорость выполнения операций выборки данных;
- отсутствие неоправданной избыточности данных.
Адекватность базы данных предметной области. База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:
1) Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области;
2) Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных.
3) Ограничения предметной области, отраженные в модели предметной области, должны отражаться и учитываться базе данных.
Легкость разработки и сопровождения базы данных. Практически любая база данных, за исключением совершенно элементарных, реализованная средствами сервера базы данных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры – это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных. Хранимые процедуры обычно пишутся либо на специальном процедурном расширении языка SQL (например, Transact-SQL для MS SQL Server или PL/SQL для ORACLE), или на некотором универсальном языке программирования (например, C++, с включением в код операторов SQL в соответствии со специальными правилами такого включения). Основное назначение хранимых процедур – реализация бизнес-процессов предметной области на стороне серверной части программного обеспечения информационной системы.
Триггеры – это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров – автоматическая поддержка целостности базы данных. Триггеры могут быть как достаточно простыми, например, поддерживающими ссылочную целостность, так и довольно сложными, реализующими какие-либо сложные ограничения предметной области или сложные действия, которые должны произойти при наступлении некоторых событий. Например, с операцией вставки нового товара в накладную может быть связан триггер, который выполняет следующие действия:
1) проверяет, есть ли необходимое количество товара;
2) при наличии товара добавляет его в накладную и уменьшает данные о наличии товара на складе;
3) при отсутствии товара формирует заказ на поставку недостающего товара и тут же посылает заказ по электронной почте поставщику.
Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.
С другой стороны, наличие программного кода на сервере базы данных упрощает обновление информационной системы в процессе эксплуатации и сопровождения, т.к. обновление затронет только базу данных, и не потребуется обновление клиентских приложений.
Скорость операций обновления данных – вставка, обновление, удаление. На уровне логического моделирования определяются реляционные отношения и атрибуты этих отношений. На этом уровне не могут определяться какие-либо физические структуры хранения – индексы, способы хеширования и т.п. Единственное, чем можно управлять на этапе логического моделирования – это распределением атрибутов по различным отношениям. Можно описать мало отношений с большим количеством атрибутов, или много отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос – влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такой вопрос, конечно, не является достаточно корректным, т.к. скорость выполнения операций с базой данных сильно зависит от физической реализации базы данных. Тем не менее, попытаемся качественно оценить это влияние при одинаковых подходах к физическому моделированию.
Скорость операций выборки данных. Одно из назначений базы данных – предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SELECT языка SQL. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.
Избыточность данных. Формальное определение термина избыточность базы данных дать невозможно. Но существуют общепринятые трактовки стандартных ситуаций, связанных с избыточностью.
Во-первых, считается, что не рационально (избыточно) идентифицировать сущности первичными ключами из доменов, содержащих текстовые данные, даже если это соответствует логике модели.
Вторая типичная ситуация, связанная с избыточностью данных, возникает, когда одни и те же факты можно многократно получить из разных объектов базы данных.
Наличие избыточности может принести как пользу, так и являться недостатком, с точки зрения общей производительности системы. Основная польза от внесения избыточности в базу данных состоит в возможности ускорения выполнения запросов, т.к. часть необходимой информации уже сохранена в готовом виде, и не нужно разыскивать ее по разным таблицам, осуществляя иногда достаточно сложные соединения таблиц и вычисления.
Основной проблемой, связанной с наличием избыточности любого типа, является то, что избыточность должна быть контролируемой. То есть, необходима программная реализация проверок того, что избыточные и базовые данные адекватно согласованы между собой. В OLTP-приложении обычно процедуру контроля избыточности выносят в транзакции, что, разумеется, замедляет их выполнение.