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

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

Однако СУБД и управляемые ими базы данных не проектировались изначально для

хранения электронных изданий, содержащих большое количество неструктурированного

текста и рисунки, а иногда и мультимедийные компоненты. Для работы с такими

документами более пригодными представляются не реляционные, а объектно-

ориентированные базы (ООБД), в которых могут быть включены различные индексные

структуры и методы доступа для объектов определенного типа. В них же проще создать

иерархию типов, которая будет отражать специфическую семантику.

Возможно также создание комбинированных объектно-реляционных баз данных.

Реляционные базы данных не слишком удобны и для представления отношений

≪используется в≫ и ≪содержится≫. Вообще, в реляционных системах трудно представлять отношения между конкретными объектами. В ООБД можно создать индексные структуры и методы доступа специально для объектов определенного типа. Кроме атрибутов для объектов можно определить семантику, формализованную в операциях над ними, и создать иерархию типов, которая будет отражать все более и более специфическую семантику.

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

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

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

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

последнем случае для поиска тома с нужным номером и установки его в дисковод

требуется участие оператора, в результате чего полное время обращения многократно возрастает.

Дата добавления: 2015-10-30