Проектирование объекто-ориентированных баз данных в строительстве

ПРОЕКТИРОВАНИЕ ОБЪЕКТО-ОРИЕНТИРОВАННЫХ БАЗ ДАННЫХ В СТРОИТЕЛЬСТВЕ

OBJECT-ORIENTED DATABASE DESIGN IN CONSTRUCTION

B.M. Гинзбург

V.M. Ginzburg

ГОУ ВПО МГСУ

В статье рассмотрена проблема применения объектно-ориентированных моделей данных в проектировании информационных систем в строительстве.

In article examines the problem of application object-oriented data model in design information system in construction.

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

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

Выделяют три существенных момента объектно-ориентированного подхода (ООП) [2]:

• ООП использует в качестве элементов объекты, а не алгоритмы;

• каждый объект является реализацией какого-либо определенного класса;

• классы организованы иерархически.

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

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

Иерархичность - это упорядочение системы абстракций. Основным видом иерархических структур применительно к сложным системам являются классы по отношению «род - вид» и «целое - часть».

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

Модульность - это разделение программной системы на фрагменты, имеющие между собой средства сообщения.

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

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

• все предметы множества (экземпляры) имеют одни и те же характеристики (свойства);

• все экземпляры подчинены и согласовываются с одним и тем же набором правил поведения.

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

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

В объектно-ориентированной программе встречаются классы трех основных видов: предметные, управляющие и интерфейсные. Предметные классы (Entity classes) используются для создания объектов, занимающихся обработкой данных. Классы, представляющие людей, материальные объекты и события являются предметными. В большинстве программ есть хотя бы один предметный класс, по которому создаются объекты. Управляющие классы (Control classes) не занимаются обработкой данных и не продуцируют видимый результат. Вместо этого они управляют ходом выполнения программы. Интерфейсные классы (Interface classes) занимаются вводом и выводом информации.

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

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

Продолжение существования предметных объектов после завершения программы называется устойчивостью (persistence). Объектно-ориентированные СУБД основаны на идее устойчивости объектов. Однако в объявлении класса не только должно быть

указано на устойчивость объекта, созданного на его основе, но также должны быть заданы связи между объектами.

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

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

У этого метода представления связей между данными есть две важнейших особенности:

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

• для перемещения по базе данных можно пользоваться только теми связями, которые были заранее определены путем сохранения в атрибутах идентификаторов связанных объектов.

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

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

В отличие от реляционной модели, объектно-ориентированная модель данных допускает многозначные атрибуты. Эта возможность особенно полезна, когда в базе необходима связь со «многими» объектами на одном из концов модели.

Для представления степени отношения или связи «один ко многим» (1 : М) в классе, находящемся на конце «много», нужно определить атрибут, в котором будет храниться идентификатор объекта-родителя. В класс родительских объектов будет включен атрибут, содержащий множество значений идентификаторов объектов, с которыми он связан. Например, чтобы показать связь участков с машинами, классу Строительная Машина требуется атрибут с типом данных Строительный Участок, а в классе Строительный Участок должен быть атрибут с типом Строительная Машина, который должен быть объявлен множественным. Необходимо иметь в виду, что хотя связь определяется с помощью атрибутов класса, в самой базе данных связи существуют между объектами, точно так же, как в реляционной базе связи при помощи первичного внешнего ключа устанавливаются между конкретными строками, а не целыми таблицами.

В ООБД можно представлять связи «многие ко многим» (М : М), не прибегая к анализу их композиционных сущностей. Для этого в участвующих в связях классах определяется атрибут, в котором хранится множество значений, принадлежащих типу второго класса. На первый взгляд, возможность непосредственно представлять связи М : М может показаться огромным преимуществом ООБД, но к сожалению, использовать такую связь следует с большой осторожностью. Во-первых, если со связью ассоциированы данные (например, если цена Строительного материала может зависеть от Поставщика, что на практике весьма вероятно), то придется создать композиционную сущность для их хранения. Таким образом, связь М : М будет для каждого Поставщика заменена связями 1 : М точно так же, как в реляционной базе. Во-вторых, можно спроектировать такую базу со связями М : М, в которой либо будет теряться информация, либо связи нельзя будет определить точно.

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

ООБД должна поддерживать еще один вид наследования - связь типа «расширяет». При использовании этой связи подкласс развивает функциональность суперкласса, а не ограничивает ее частным случаем. Например, работая с иерархией класса Строительная Машина, описывающего оснащение строительной площадки, можно столкнуться с фактом, что на строительной площадке имеются временные сооружения для размещения складов или выполнения административно-бытовых функций. Видимо помимо этого класса, необходимо включить класс Сооружение, содержащий дополнительный перечень необходимых атрибутов. Класс Сооружение, например, может в качестве нового атрибута содержать список материалов, хранящихся на складе, или список рабочих и служащих, закрепленных за данным бытовым или административным домиком. В определенном смысле Сооружение - это не просто частный случай оснащения строительной площадки, а объект, выполняющий дополнительные функции.

Одна из концепций, чуждых реляционной базе данных, - это представление идеи о частях целого. Так, в базе данных о производстве надо отслеживать, из каких материалов, изделий и конструкторских блоков монтируется сооружение. В ООБД можно воспользоваться связью вида «целое-часть», описывающей, что объект одного класса содержит объекты других классов в качестве своих частей. В случае производственной базы данных между классами Конструкция и классами Изделие и Материал существовала бы связь «целое-часть». Связь «целое-часть» - это вариант связи М : М, обла-

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

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

В классе Строительный_участок (Building_site) есть атрибут строительные_машины (construction_machinery), причем Building_site в construc -tion_machinery определен как множество. В то же время в классе Строитель-ная_машина (Construction_machinery) есть атрибут строительный_участок (construction_machinery. building_site). Чтобы гарантировать целостность связи, объектно-ориентированная СУБД представляет разработчику базы синтаксическую конструкцию, необходимую, чтобы задать место нахождения обратного идентификатора объекта, например:

construction_machinery: (set) Construction_machinery

inverse is construction_machinery. building_site для класса Building_site и building_site: Building_site

inverse is building_site. construction_machinery для класса Construction_machinery.

Когда пользователь или прикладная программа вставляет или удаляет идентификатор объекта из атрибута construction_machinery объекта Building_site, СУБД автоматически обновляет атрибут building_site в связанном объекте Constmction_machinery. Если же модифицируется объект Construction_machinery, то СУБД таким же образом изменяет связанный объект Building_site. Так же как обязанность задавать ограничения ссылочной целостности лежит на проектировщике реляционной базы данных, так же выявлять и описывать ограничения целостности связи должен проектировщик ООБД.

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

Литература

1. Гинзбург В.М. Проектирование информационных систем в строительстве. М.: Издательства АСВ, 2008.

2. Харрингтон Дж. Проектирование объектно-ориентированных баз данных. М.: Издательство ДМК, 2001.

The literature

1. Ginzburg V.M. Information management system design in construction. M.: IASV, 2008.

2. Harrington Jan L. Object-Oriented Database Design Clearly Explained. M.: IDMK, 2001.

Ключевые слова: информационные системы, базы данных, объектно-ориентированные модели данных, классы, объекты, иерархия, отношения, автоматизированные системы проектирования в строительстве.

Key words: information system, data base, object-oriented data model, classes, entity, hierarchy, relation, computer-aided in construction.

E-mail автора: vmg@ginzburgi.ru Рецензент: В.О. Чулков доктор технических наук профессор, МГАКХиС