5.2. Стадии проектирования и объекты моделирования

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

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

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

Можно, конечно, поставить под сомнение ценность таких исследований. Действительно, каким бы плохим ни был язык программирования, его, в конце концов, всё-таки можно выучить. Точно так же и средства СУБД можно освоить за определенный период времени. Но проблема состоит не в освоении средств, а в эффективности их использования!

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

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

Характер взаимосвязей (и, соответственно, отличий) проявляет­ся и в процессе проектирования системы баз данных. Модель пред­метной области скорее ассоциируется с неформальным³³ уровнем семантического моделирования, а модель базы данных — с форма­лизованным уровнем системы (и в частности, СУБД). В идеале це­лью семантического моделирования является формирование систе­матического основания для хорошо формализованного процесса проектирования базы данных. Здесь необходимо вспомнить следую­щие требования, предъявляемые к базам данных, и, в частности, к способам описания данных:

1. описания должны быть понятны пользователю, не проектировавшему базу;

2. однажды принятые способы представления данных должны допускать присоединение новых элементов данных без изменения существующих схем данных и прикладных программ;

3. СУБД должны позволять эффективно обрабатывать произвольные запросы к базе данных.

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

Забегая несколько вперед, рассмотрим взаимосвязь двух из­вестных методов семантического моделирования инфологического уровня — ER-диаграммы (ER — Entity Relation) и метода нормали­зации, воспринимаемых зачастую как альтернативные. На самом деле нормализация с помощью хорошо формализованных методов обеспечивает декомпозицию исходных отношений (переменных) большой размерности к возможно большему набору отношений, но меньшей размерности. Эти методы не зависят от особенностей предметной области (семантики обрабатываемых данных), но вследствие этого и не позволяют определить исходное отношение. Для этого удобнее использовать методики, подобные ER-диаграммам — для них свойственны подходы технологии нисходящего проектирования, которые дают представление «в целом», но имен­но поэтому (из-за сравнительной простоты) не позволяют провести полноценное проектирование базы. То есть, можно сказать, что метод нормализации и ER-диаграммы по существу являются взаи­модополняющими.

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

Рассмотрим основные стадии процесса³⁴ моделирования, пред­ставленные на рис. 5.1.

Рис. 5.1. Стадии и объекты процесса проектирования