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

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

Затем разрабатывается логический проект, который охватывает всю информацию, касающуюся данных, независимо от источника самих данных, для создания одной или нескольких диаграмм, содержащргх абстрактное представление данных в системе. После этого полученные диаграммы могут использоваться для обсуждения с клиентом вопросов о том, какие объекты данных, по мнению разработчика и клиента, должны храниться в базе данньгх, а также для уточнения перечня бизнес-правил, выявленных на этапе проектирования. Широкое применение схематических представлений для общения с заказчиком обычно позволяет заблаговременно обнаруживать ошибки в проекте, и благодаря этом) экономить время и деньги, избавившись от неьгрсных переделок. Схематические диаграммы позволяют привлечь к обсуждению проекта даже таких заказчиков, которые не привыкли рассматривать свою работ) с точки зрения обработки данных, поскольку позволяют, например, сразу же определить, учтено ли в будущей системе применение в документообороте нарядов на закупку. Такие упущения, в которых не учтено наличие целого класса документов, встречается редко, поэтому разработчику остается только указать соответствующие объекты на диаграмме и объяснить, почему он их назвал именно так, а не иначе, но иногда действительно приходится признавать справедливость сделанного замечания. Но исправление этой или любой другой ошибки, допущенной в проекте, обходится гораздо дешевле по сравнению с полной переделкой приложения, необходимость в проведении которой возникает в случае обнаружения ошибки после ввода приложения в эксплуатацию. Этап логического моделирования позволяет провести все необходимые согласования с заказчиком и уменьшить вероятность обнаружения упущений и недоработок в проекте на этапе развертывания.

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

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

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

Части логической модели

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

Структура.

Ограничения.

Правила.

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

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

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

Структура

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

Ограничения

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

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

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

Правила

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

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

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