Modifications synchronization of denormalized data in Lotus Notes/Domino applications.pdf Как известно, существуют несколько моделей организа-ции хранения данных. Самая известная и широко исполь-зуемая - это, безусловно, реляционная модель. Кроме реля-ционной, специалистами в разное время разработаны такиемодели, как объектная, иерархическая и другие. В статьерассматривается система электронного документооборотаLotus Notes, или, кратко, Notes [1]. Если спросить специали-ста, какую модель организации хранения данных имеетNotes, то, скорее всего, он затруднится дать однозначныйответ на этот вопрос, так как она по своим признакам одно-значно не подходит ни под одно из определений известныхмоделей. Модель хранения данных в Lotus Notes конечно нереляционная. Возможно, иерархическая либо объектная.Что несомненно, модель хранения данных, используемая вNotes, достаточно удобна для реализации документооборотаи удовлетворяет большинству задач в Notes-приложениях.Но иногда необходимо расширить ее возможности.О СИСТЕМЕ LOTUS NOTESLotus Notes - это документо-ориентированная сис-тема групповой работы [2]. Lotus Notes имеет множе-ство встроенных интегрированных подсистем, на-пример встроенную систему электронной почты, ко-торые делают эту систему чрезвычайно мощнымсредством автоматизации документооборота. LotusNotes/Domino является клиент-серверной архитекту-рой, а сервер Lotus Domino к тому же является и веб-сервером, позволяющим получить доступ к базам до-кументов через глобальную сеть Internet.Система Lotus Notes имеет следующие компоненты:- систему управления базами документов,- почтовую систему с поддержкой календаря и задач,- систему репликации данных,- встроенный объектно-ориентированный язык про-граммирования Lotus Script и мощный язык формул,- поддержку Java и JavaScript, XML.Рассмотрим подробнее систему управления базамидокументов, в частности подсистему хранения дан-ных. Для лучшего понимания будем постоянно ис-пользовать аналогии с системами управления реляци-онными базами данных.Кортежем в Notes является документ. Помимо на-бора атрибутов, документ имеет свои собственные на-стройки управления доступом, может хранить код дляуправления своим отображением. Документ, как ми-нимальная единица данных, практически эквивален-тен записи в таблице реляционной СУБД, но имеютсяи отличия. Первое, и самое основное, группа доку-ментов, созданных с использованием одной формы(экранной формы как шаблона для создания докумен-та), не соответствует таблице. Каждый документ пол-ностью независим от других. Второе, документ можетиметь набор атрибутов, отличающийся от набора вдругих документах.Помимо этого, в системе Lotus Notes не определе-ны правила формирования и поддержки связей междукортежами, или сущностями. Документ Notes можетиметь неограниченное число ссылок на другие доку-менты по некоторому ключу, определенному в кон-кретном приложении, но поддержка и использованиеэтих связей полностью оставлена на разработчикаприложения. Наиболее часто используется автомати-чески формируемый системой ключ Document UniversalID, но могут использоваться и различные искусст-венные ключи.ПОСТАНОВКА ЗАДАЧИСначала приведем определения используемыхтерминов из теории реляционных баз данных:1. Корректной считается такая схема базы данных,в которой отсутствуют избыточные функциональныезависимости. В противном случае приходится прибе-гать к процедуре декомпозиции (разложения) имею-щегося множества отношений. При этом порождаемоемножество содержит большее число отношений, ко-торые являются проекциями отношений исходногомножества. Обратимый пошаговый процесс заменыданной совокупности отношений другой схемой сустранением избыточных функциональных зависимо-стей называется нормализацией [3].2. Отношение R находится в пятой нормальнойформе (5НФ) тогда и только тогда, когда каждая за-висимость соединения в отношении R подразумевает-ся потенциальными ключами отношения R [4].В приложениях, построенных с использованиемРСУБД, разработчики стараются реализовать такуюсхему данных, которая бы соответствовала одной изнормальных форм, как правило, пятой НФ. Это дела-ется для того, чтобы хранение и использование дан-ных было наиболее эффективно и просто. Это такжеозначает, что среди данных отсутствуют избыточныефункциональные зависимости. В отличие от РСУБД,в Lotus Notes данные хранятся даже не в первой нор-мальной форме, так как любой атрибут документаNotes в общем случае является сложным, то есть мо-жет иметь несколько значений. Ясно, что использова-ние денормализованных данных требует некоторыхдополнительных действий. Попытаемся определить,какие действия необходимы, или желательны, в связис декларированной денормализацией. Исходя из прак-тического опыта создания различных Notes-приложе-ний, можно выделить одно действие, которое совер-шенно необходимо для нормальной работы.Рассмотрим подробнее поведение системы LotusNotes в одном частном, но очень часто используемомслучае. Если в некотором документе (назовем его до-кументом-приемником) определенное поле получилосвое текущее значение из поля в другом документе(документе-источнике) то при изменении значения висточнике, значение в приемнике не изменится. Этопроисходит потому, что ссылка на значение источни-ка никаким образом не хранится в документе-приемнике (если не делать этого специально с помо-щью кода). Становится понятно, что значение прием-ника совершенно независимо от источника, и нет спе-циальных функций, производящих синхронизациюмодификаций. То есть автоматически производимойсистемой синхронизации в Lotus Notes нет. Поэтому ивозникает задача дополнения подсистемы храненияданных функцией синхронизации модификаций де-нормализованных данных.ОПРЕДЕЛЕНИЕ ВОЗМОЖНОСТИ РЕШЕНИЯПопытаемся определить, можно ли вместо обеспе-чения непротиворечивости денормализованных дан-ных просто хранить нормализованные данные в базахNotes. Можно ли применить точно такой же метод,какой применяется в приложениях, построенных нареляционных базах данных: хранение не самого зна-чения, а только ссылки на него, и затем отображениезначений вместо ссылок с помощью запросов. Этовозможно, но с некоторыми, достаточно сильнымиограничениями. Показ самих значений вместоКРАТКОЕ ОПИСАНИЕ РЕАЛИЗАЦИИВозможная реализация всех трех подходов прак-тически одинаковая: поиск документов-приемников(документов-источников в случае 2-го подхода), об-новление значений в них, сохранение документов.Итак, нам необходимо иметь структуру для поискадокументов-приемников по известному документу-источнику и наоборот. Такая структура может пред-ставлять собой, например, специальное поисковоепредставление. Однако в приложениях с большим ко-личеством документов индекс такого представленияможет быть слишком велик, что повлечет за собойпроблемы в функционировании приложения. Этапроблема решается разделением одного представле-ния на несколько, но приводит к накладным расходамна определение нужного представления. Обновлениеи сохранение документов очень простая операция, но,тем не менее, может привести к конфликтам сохране-ния, если обновляемый документ открыт на редакти-рование пользователем в данный момент времени ра-ботающим с системой. При наличии в документе фла-га редактирования можно пропускать такие докумен-ты и обрабатывать их позже, в момент

Скачать электронную версию публикации