Классика баз данных - статьи



         

Универсальная модель данных (УМД)


Существующие традиционные технологии проектирования ИС ориентированы на проектирование БД для одной конкретной предметной области. Такой подход не позволяет тиражировать модель данных на разные предметные области, не обеспечивает простое расширение состава информации в БД и не способствует использованию устоявшихся решений. Повышение надежности решений по проектированию БД и сокращению затрат на их создание и развитие возможно при стандартизации модели данных, что не раз обсуждалась на международных симпозиумах сообщества баз данных [1,2,3].

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

УМД удовлетворяет основным требованиям, предъявляемым к моделям данных [4]:

структурная достоверность;

простота;

отсутствие избыточности;

способностью к совместному использованию;

расширяемость;

целостность;

представление в виде понятных обозначений.

Для УМД определен перечень понятий (таблица 1), на основе которых спроектирован набор таблиц реляционной БД. Заранее не ограниченное разнообразие элементов ПрО распределяется по перечисленным понятиям и формируется в фиксированном наборе таблиц [5]. Элемент ПрО относится к одному из понятий и определяется именем, местом в некоторой иерархии, величиной и/или временем. Используемыми понятиями можно описать любую совокупность компонентов предприятия с их качествами, возможными событиями и другими подробностями.

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




Содержание  Назад  Вперед