Проектирование структуры хранилища электронных изданий

Для лучшей защиты издательской базы данных от несанкционированного доступа и ускорения работы поисковой системы путем перехода к атрибутивному поиску целесообразно разделить функции поиска документов и их хранения, извлечения и передачи клиенту.

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

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

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

Хранилище изданий или архив издательства является ядром всей информационной издательской системы. Как должно быть организовано такое хранилище? Сейчас преимущественно используются реляционные базы данных, обладающие мощным потенциалом, масштабируемостью, стандартным языком запросов по атрибутам SQL. Для проектирования таких баз разработано большое количество различных программных оболочек, называемых системами управления базами данных (СУБД). Наиболее широко применяется СУБД Oracle, которые обеспечивают практически неограниченный объем хранимой информации.

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

Реляционные базы данных не слишком удобны и для представления отношений «используется в» и «содержится». Вообще, в реляционных системах трудно представлять отношения между конкретными объектами. В ООБД можно создать индексные структуры и методы доступа специально для объектов определенного типа. Кроме атрибутов для объектов можно определить семантику, формализованную в операциях над ними, и создать иерархию типов, которая будет отражать все более и более специфическую семантику. Например, система, построенная на основе ООБД, может иметь тип данных content-object с операцией play. На следующем уровне иерархии могут быть подтипы для объектов со специфическим содержанием: audio-object, video-object, animation-object, и подтипы для специфических форматов: WAV-audio-object, MIDI-audio-object, MP3-audio-object, а также MPEG2-video-object, MPEG4-video-object, QuickTime-video-object и т. д. Независимо можно ввести тип text-index, определив для него операции автоматической индексации и выполнения запросов. В ООБД в число атрибутов могут включаться указатели, что позволяет легко реализовать упомянутые выше отношения вхождения документов.

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

Система хранения должна обеспечивать несколько видов представления документов. В частности, представление «только для просмотра»дает пользователю возможность изучения содержания издания, без права редактировать его. Примеры такого представления - формат Adobe Acrobat PDF, представление изображений в формате экрана (вьюерах), файлы в формате видео QuickTime и пр.

Информационное хранилище должно опираться на файловую систему сервера. Чтобы реализовать стратегию хранения данных, от файловой системы требуется поддержка управления томами и иерархического управления памятью (Hierarchical Storage Management - HSM). HSM для иерархической памяти сверхбольшой емкости - это примерно то же самое, что виртуальная память для физического оперативного запоминающего устройства: она позволяет рассматривать различные уровни памяти (в частности, жесткие и оптические диски, магнитную ленту, если она используется) как одну большую файловую систему.

Если пользователь или приложение открывает файл, то либо он уже находится на жестком диске, либо HSM считывает его автоматически с текущего оптического диска из многотомной дисковой системы, либо извещает оператора о необходимости найти нужный том. Илиэтоттом мо-жетнаходится внутри специального сменника дисков (чейнджера), или его следует найти в библиотеке оптических дисков, на полке. В последнем случае для поиска тома с нужным номером и установки его в дисковод требуется участие оператора, в результате чего полное время обращения многократно возрастает.

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

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

Date: 2015-05-22; view: 526; Нарушение авторских прав