CC BY
37
нальной структуры приложения. Указанная компонента состоит из фрагментов, относящихся к слоям различных уровней.
Интерфейсный фрагмент содержит в себе HTML-разметку для построения форм, графиков и гистограмм, а также Javascript-функции проверки корректности данных, введенных пользователем в формы. Фрагмент прикладной логики содержит PHP-функции для динамической генерации графических изображений и заполнения гипертекстовых шаблонов данными о загруженности информационных каналов, а также CORBA-объекта, обрабатывающего эти данные и предоставляющего доступ к ним. К фрагменту доступа к источникам и ресурсам данных относится таблица базы данных, в которой хранится статистическая информация об уровне загруженности информационных каналов. В предлагаемой реализации в качестве СУБД используется PostgreSQL. Для обращения к данным фрагмент прикладной логики использует интерфейс ODBC.
Разработки на основе предложенной архитектуры используются при администрировании корпоративной компьютерной сетью Ростовского госуниверсите-та, а также в информационных проектах Южно-Российского регионального центра информатизации высшей школы (ЮГИНФО).
Основным направлением дальнейшей работы будет развитие технологии в направлении создания средств, обеспечивающих использование функциональных компонентов при создании систем управления распределенными ресурсами. Это позволит собирать приложения такого класса на основе готовых программных решений, обладающих необходимыми для таких систем свойствами.
В.В. Булаев, И.Н. Котов, Б.А. Телеснин ВЫБОР СХЕМЫ ДАННЫХ В ОЬТР-ПРИЛОЖЕНИЯХ
При построении СУБД-приложений одним из первых этапов проектирования является выбор схемы данных. Если для ROLAP-приложений характерны схемы «звезда» и «снежинка», то для OLTP-приложений общеприняты нормализованные (обычно разработчики ограничиваются 3 нормальной формой) структуры данных. Однако если постановка задачи требует, например, хранения истории изменения сущностей, то в каждой таблице базы данных предполагается наличие интервалов «времени жизни» объекта. Т акой подход, с одной стороны, усложняет условия фильтрации в запросах, а с другой стороны, первичный ключ сущности должен в себя включать и эти интервалы. Причем при использовании суррогатного первичного ключа, в него входят, как минимум, три поля (например: автоинкремент, дата_начала_жизни, дата_окончания_жизни), а в случаях с естественным первичным ключом его размер за счет «времени жизни» увеличивается еще на два поля.
Для решения таких задач предлагается следующий подход: OLTP-
приложения также строить по схеме «снежинка». Здесь центральным местом является таблица «факта», содержащая ссылки на таблицы «измерений». Время жизни объекта в данной ситуации хранится только в одном месте - таблице факта.
Для примера рассмотрим следующую ситуацию. Измерения: человек, отдел, должность. Таблица факта - назначение человека на работу в таком-то отделе на такой-то должности в данный период времени (рис. 1).
Рис. 1
В данном случае факт представляет собой только одну запись в центральной таблице. Рассмотрим ситуацию, когда факт состоит из нескольких записей. Человек может работать в одном отделе сразу на нескольких должностях. Такой пример можно рассматривать как совокупность нескольких отдельных фактов, и все сводится к предыдущему случаю. Однако если меняются параметры измерений (например, человек в период своей работы сменил фамилию, изменились названия отделения и должности), то первичный ключ в таблицах измерений увеличивается (рис. 2).
Рис. 2.
В центральной таблице возникает проблема вставки внешних ключей -таблица получается перегруженной датами. Для разрешения такой ситуации предлагается следующий подход. В таблицах измерений при изменении каких-то параметров просто заводятся новые записи, а в центральной таблице (где и хранятся теперь отметки времени) появляются только новые ссылки на них. Время жизни факта делится на интервалы, соответствующие определенным фазам изменения состояния измерений. Очевидно, что при большом количестве измерений выигрыш в количестве хранимой информации значителен, однако потери логической значимости не происходит. Остается только одна проблема - идентификация принадлежности записей в центральной таблице к одному факту. Решение данной задачи уже не представляет особого труда. В таблице фактов добавляется еще один атрибут - номер факта (рис. 3)
Рис. 3.
Побочным эффектом такой организации хранения данных является, с одной стороны, сопровождение приложения, а с другой стороны, его масштабируемость.
ЛИТЕРАТУРА
1. Dey D., Storey V. C., Barron T. M. Improving Database Design through the Analysis of Relationships.
2. ACM Transactions on Database Systems, Vol. 24, No. 4, December 1999, Pages 453-486.
И.Н. Котов
ИДЕНТИФИКАЦИЯ ОБЪЕКТОВ В СПЕЦИАЛИЗИРОВАННОЙ МУЛЬТИМЕДИЙНОЙ БАЗЕ ДАННЫХ
В данной работе рассматривается проблема идентификации объектов в специализированной мультимедийной базе данных. Эта проблема в разных вариантах появляется при работе с базами данных в различных предметных областях [1, 2].
В базе данных хранятся записи, соответствующие определенному множеству объектов. Для каждого объекта может быть несколько записей. Каждая запись включает некоторый набор атрибутов, среди которых могут быть атрибуты, представляющие мультимедийную информацию. Допускаются атрибуты со специальным значением «не определено». Задается образец, в котором определены значения некоторого подмножества атрибутов (в это подмножество может входить и мультимедийная информация), а остальные атрибуты не определены. Для заданного образца необходимо определить наиболее подходящий объект из тех, информация о которых содержится в базе данных. Вариант постановки задачи состоит в определении вероятности того, что заданный образец соответствует тому или иному объекту.
Подход к решению задачи состоит в следующем. Для каждого атрибута хранимой записи определяется некоторая мера близости двух заданных значений, взятых из домена этого атрибута. Обязательным условием при выборе функции меры близости атрибутов из каждого домена является определение значения этой функции в случае неопределенности одного из аргументов. Для каждого из атрибутов определяется некоторая весовая функция. Мера близости двух записей строится как взвешенная сумма мер близости возможных атрибутов.
