Объектное
представление о реляционной модели
Классифицированное представление информации и возможность работы на различных уровнях абстракции позволяет пользователям, проектировщикам и разработчикам значительно проще решать свои задачи. Для пользователей удобство заключается в том, что они могут получать корректные результаты даже не подозревая об изменениях в структуре хранения информации. То есть разработчики могут добавить в систему хранения новые сущности, не прибегая к утомительной процедуре оповещения пользователей. Действительно, давайте представим, что нам потребовалось ввести новый подкласс “АВТОМОБИЛИ” класса “ТОВАРЫ”. Для пользователей, которые работали с сущностями “ПРОДУКТЫ” или “МЕБЕЛЬ” не произойдёт никаких изменений. Нет необходимости в переписывании программного обеспечения или переучивании самих пользователей. Их работа не претерпит никаких изменений. Для тех пользователей, которые оперировали абстрактным классом “ТОВАРЫ”, тоже ничего не изменится, хотя и появился новый подкласс “АВТОМОБИЛИ”. Схема трансляции объектной формы запроса на физические отношения сделает для них механизм подключения новых подклассов совершенно прозрачным. Они могут и не знать о том, что теперь их запросы включают в себя обращения к новому подклассу. Таким образом, достигается не только экономия времени разработчиков, но и исключаются многие моменты, связанные с переходом на новые информационные схемы. С точки зрения разработчиков и административного персонала удобство объектной схемы тоже не вызывает сомнения. Прежде всего, исчезает проблема соответствия схемы хранения информации (схемы БД) и программного обеспечения. Количество причин рассогласования сокращается весьма значительно, если не исчезает полностью. Упрощается и разработка нового программного обеспечения. Сегодня ведущие RAD системы позволяют создавать шаблоны диалогов (форм). Если связать понятие шаблона с понятием класса, то тогда разработка программного обеспечения для нового подкласса, начинается не с чистого листа. Разработчикам остаётся фактически определить только работу с теми атрибутами и методами, которые определены у нового подкласса. При разработке сложных систем такой подход позволяет не только экономить время, но и упрощает создание форм в едином стиле. Реальная проблема, с которой сталкиваются все проектировщики, заключается в том, что отсутствует исчерпывающее представление обо всех сущностях предметной области, их связях и ограничениях. Технология объектного проектирования, в такой ситуации, может быть панацеей. Любая объектная система обладает способностью к развитию. Следовательно, нет необходимости создавать всю систему целиком. На первом этапе определяются ключевые понятия и сущности, уточнять которые можно впоследствии бесконечно долго. Если вернуться к нашему примеру, то вначале достаточно определить такие сущности, как “ПОСТАВЩИКИ” и “ТОВАРЫ”. Определить взаимосвязи и ограничения. После этого достаточно ввести всего один реальный подкласс класса “ПОСТАВЩИКИ” и один реальный подкласс класса “ТОВАРЫ”. Этого достаточно, что бы отработать большинство функций взаимодействия, существующих между этими сущностями. В дальнейшем можно совершенно безболезненно добавлять как новые виды поставщиков, так и новые виды товаров. Система будет гарантировано работоспособна. В больших проектах очень важно достичь высокого уровня параллелизма. Использование технологии объектного проектирования позволяет решить и эту проблему. После определения основных (абстрактных) сущностей, их структуры и правил функционирования, можно приступать к детализации, разрабатывая реальные отношения и определяя их взаимодействие. Эта фаза выполняется параллельно для каждого реального отношения, поскольку основные интерфейсы и характеристики специфицированы на абстрактном уровне.
Идеи, изложенные выше, можно развивать в нескольких направлениях. Например, можно ввести понятие классов-переключателей (switch-classes). Суть этих классов понятна из следующего примера: допустим, создаётся база данных для результатов социологических опросов. Предположим, что с точки зрения исследователей очень важно иметь раздельное представление о результатах различных групп респондентов (например, по возрастным группам или по социальному положению или по половому признаку). Безусловно, можно разместить все результаты в едином отношении, введя соответствующее поле или поля, отвечающие за необходимую группировку. Но можно поступить иначе. Например, абстрактному отношению “РЕСПОНДЕНТЫ” поставить в соответствие некоторый домен значений. В этом случае результаты каждой группы будут размещены в отдельной физической таблице, что эффективнее. Работа класса-переключателя заключается в том, что он определяет из предложения WHERE к какому физическому отношению перенаправить запрос. Здесь опять пользователь использует прозрачный для себя механизм и может получать, как значения из всей совокупности таблиц данного класса, так и из конкретной таблицы. Данный пример предназначен для иллюстрации механизма работы классов-переключателей, но из него неочевидны преимущества данной схемы хранения информации. Чтобы оценить достоинства необходимо вырваться из привычной иерархии: база данных =>отношение => атрибут. Давайте рассмотрим более сложный пример. Пусть нам предстоит разработать систему класса ПРЕДПРИЯТИЕ. Любое предприятие состоит из структурных подразделений. В свою очередь структурные подразделения включают в себя три сущности: люди (сотрудники), оборудование и материалы. Следовательно, можно запроектировать абстрактное структурное подразделение! А значит и создать абстрактное предприятие. Но сущность “СОТРУДНИКИ”, как впрочем, и две другие сущности, представляются несколькими отношениями. Таким образом, появляется реальная потребность перенести объектное представление с уровня физических отношений на уровень баз данных. Но здесь и возникает основная проблема использования существующих коммерческих СУБД, так как они недостаточно эффективны при одновременном обслуживании большого числа баз данных. Даже те из них, которые декларируют мультибазовый режим работы, при таких нагрузках требуют значительных ресурсов от сервера баз данных и всё равно недопустимо теряют производительность. А между тем, использование объектных технологий позволило бы проще и эффективнее решать многие задачи. “Ахиллесова пята” предприятий – оптимальная структура и управление. Столь популярное слово как “реенжиниринг” (reengineering) сегодня не нашло своего воплощения в виде готовых программных продуктов, и это не смотря на всю привлекательность решения данной задачи. На чём базируется идея реенжиниринга – на высокой гибкости современного производства. Выживает тот, кто имеет более гибкую структуру производства и более эффективное управление. Изменения в структуре производства перестали быть единовременной акцией и должны происходить непрерывно, дабы соответствовать требованиям рынка. В современных условиях – это очень большая проблема для специалистов, отвечающих за информационное обеспечение. Однако решение есть, и оно лежит на поверхности. Предположим, что мы уже сумели создать с помощью некоторой гипотетической СУБД сеть баз данных структурных подразделений. Теперь опишем функции, которые должно выполнять это абстрактное предприятие. Очевидно, что для любого предприятия справедливо будет утверждение, что имеется один или несколько входов, на которые из внешнего мира подаётся нечто (назовём это сырьём). На другой стороне, существует один или несколько выходов, куда поступает другое нечто (назовём это продукцией). Обслуживание входов и выходов (поиск сырья и поставщиков, складирование, маркетинг, сбыт товара, поиск рынков и т.д.) – это некоторые функции. Далее, возможно, но не обязательно, сырьё в процессе производства меняет свою структуру, превращаясь в продукцию. Это ещё один набор функций, включая собственно соблюдение технологии и контроль. Все функции прекрасно представимы в виде графов, и они могут быть описаны в виде набора бизнес-правил. Теперь нам осталось предоставить менеджерам возможность накладывать полученный граф функций на сеть структурных подразделений. Это и будет основной инструмент, позволяющий наглядно и просто проводить процесс реенжиниринга. Он позволит аналитикам менять функции и структуру подразделений, определять оптимальные пути прохождения управляющих воздействий и обратных реакций, просчитывать эффективность каждой операции и выносить обоснованные заключения. Осталось ответить на вопрос о том, возможно ли создание СУБД, отвечающей заданным требованиям, в обозримом будущем? Да, создание такой СУБД вполне возможно. Собственно все идеи, высказанные выше, рождались в обратной последовательности. Сначала была разработана спецификация на объектную СУБД. Она не имеет ничего общего с теми СУБД, которые сегодня получили статус объектно-ориентированных, поэтому, чтобы избежать путаницы, теперь её называют Эго-системой. Она допускает практически неограниченное число уровней представления информации и легко адаптируется под данные классы задач. Однако её практическое воплощение не получило поддержки. Далее последовала трансляция найденных решений на существующие РСУБД, часть из которых изложена в этой статье. Описание Эго-системы тема отдельной очень большой работы. Эго-система привлекает тем, что начинается с понятия личности пользователя (отсюда в названии Эго) и может простираться до глобальных систем, создавая единую информационную среду.
Мне бы очень хотелось определить своё отношение к существующим идеологиям развития СУБД. Иерархические и сетевые модели хранения информации в своё время сыграли положительную роль в становлении информационных систем. Но появление великолепных работ Кодда, описывающих реляционную модель, стало тем поворотным моментом, когда возможность свободной работы с информацией стала доступной не только разработчикам систем, но и пользователям. Появление объектных СУБД в конце 80-х годов стало своего рода фальш-стартом. Они не привнесли ничего нового в способы хранения информации. Сегодня, когда объектный подход к созданию программного обеспечения получил широкое распространение (что, к сожалению, не всегда сопровождается пониманием этой технологии), ООСУБД вызывают большой интерес. Мне кажется, что бездумное следование моде, может сильно затормозить развитие программного обеспечения в ближайшие годы. В данной работе мне хотелось показать, что объектная технология не должна противопоставляться реляционной модели. Наоборот, достоинство той и другой парадигмы раскрываются в полной мере тогда, и только тогда, когда они работают вместе. Ранее подчёркивалось, что введение элементов объектной технологии позволяет сохранить без изменения значительную часть программного обеспечения, структуру базы данных и при этом повысить её гибкость. Именно этим и примечательна предлагаемая техника. Эго-система спроектирована исключительно на объектной технологии, но она использует всю мощь реляционной модели. Это позволило не только получить великолепную компактность как кода самой системы, так и хранимой информации, но и высокую производительность, гибкость и простоту использования. |
||||