Программные продукты и системы, 2011, № 2

Программные продукты и системы
№ 2, 2011 г.

3

УДК 007:519.816

ВОЗМОЖНОСТИ РЕАЛИЗАЦИИ ТЕМПОРАЛЬНОЙ БАЗЫ ДАННЫХ 

ДЛЯ ИНТЕЛЛЕКТУАЛЬНЫХ СИСТЕМ

(Работа выполнена при финансовой поддержке РФФИ, проект № 11-01-00140)

А.П. Еремеев, д.т.н.; А.А. Еремеев; А.А. Пантелеев

(Московский энергетический институт (технический университет), 

eremeev@appmat.ru, ballack29@mail.ru, amigo-sa@mail.ru)

Рассматриваются возможности реализации темпоральной БД для интеллектуальных систем на примере интел
лектуальных систем поддержки принятия решений реального времени. Предлагается использование средств реляционной СУБД, языка XML, а также методов, разработанных для пространственных БД. Также рассматриваются возможности применения перспективной OLAP-технологии для реализации темпоральной БД. 

Ключевые слова: темпоральная БД, интеллектуальная система, пространственная БД, хранилище данных, 

OLAP-технология.

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

Представление темпоральных данных 

на основе реляционной БД

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

В темпоральной модели категория времени 

является базовой сущностью, в большинстве моделей используется интервальное представление 
времени. Объект темпоральной модели – это любая информационная либо структурная сущность, 
например, домен, атрибут, кортеж, отношение. 
Предполагается, что объект О определен на временном интервале I, если для любого момента 

t  значение либо структура O существует. В 
темпоральной модели структура или значения любого объекта могут неограниченно изменяться. 
При каждом изменении структуры или значения 
объекта O образуется его новая версия. Заслуживает внимания представление темпорального кортежа данных <t1, t2, ..., tn> для возможности хранения
и обработки
темпоральных атрибутов, 

имеющих временную поддержку. 

Представление темпоральных данных на ос
нове РБД является естественным и распространенным решением. Разумеется, в реляционной 
модели существует ряд ограничений, которые не 
позволяют полностью реализовать темпоральную 
модель, однако для частных пользовательских задач такое решение бывает оправданным. В работе
[4] дается обзор методов представления в реляционной таблице изменяющихся данных и анализируются следующие типы представления темпоральной (исторической) информации.

Первый тип представления является прими
тивным, так как отсутствует какое-либо явное моделирование темпоральных данных. Каждая операция изменения данных update уничтожает предыдущую копию. Недостаток метода в том, что по 
сути темпоральная информация не поддерживается, а достоинство – в невысоких требованиях к 
хранилищу данных. Средством информирования 
пользователя о наличии изменений данных может 
выступать логический атрибут: его значение равно 
true при добавлении новой записи и false – при 
обновлении. 

Второй тип представления предполагает до
бавление в исходное отношение дополнительных 
атрибутов, отвечающих за версионность записи. 
Это могут быть как простой счетчик записей, так 
и пара значений (Start_date, End_date), указывающих временной диапазон (интервал) актуальности 
записи. Пример такого представления приведен в 
таблице.

Key
Data_1
Data_2
Start_date
End_date

001
ABC
125,01
01-01-2010
01-06-2010

Программные продукты и системы
№ 2, 2011 г.

4

Это наиболее распространенный способ пред
ставления темпоральной информации. Достоинствами его являются простота реализации и полнота 
исторической информации, недостатками – необходимость явного представления времени в БД, 
отсутствие контроля со стороны СУБД разработчиков, усложнение ключа исходной таблицы и
индексов. Кроме того, в случае нескольких темпоральных атрибутов в одном отношении происходит дублирование информации аналогично дублированию статических атрибутов. Главный недостаток данного метода применительно к ИСППР 
РВ в отсутствии языка запросов к темпоральной 
информации со стороны блока логического вывода, что делает этот метод непригодным для ИС 
типа ИСППР РВ. 

Третий тип представления предполагает до
бавление дополнительных атрибутов для хранения 
измененных атрибутов, а не информации о версиях записи. Данный способ позволяет хранить 
весьма ограниченную историю, кроме того, отсутствует какая-либо информация о времени актуальности каждой записи. Этот способ еще менее 
пригоден для ИСППР РВ, чем второй. 

Четвертый тип представления темпораль
ной информации самый громоздкий. Он предполагает создание отдельного отношения для каждого объекта, хранящего исторические данные, и
является реализацией известной модели темпоральных объектов с абстрактным идентификатором [5]. При данном подходе возможно в полной 
мере
моделировать 
темпоральную 
структуру 

атрибутов, однако моделирование доменов и отношений недоступно. Методы на основе этого 
подхода позволяют реализовать намного более 
сложную логику темпоральных запросов, чем уже 
рассмотренные, но для ИСППР РВ, ориентированных на управление и мониторинг сложных 
многокомпонентных систем (объектов), они не 
подходят, так как расходы памяти и вычислительных ресурсов на хранение и обработку информации слишком велики.

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

Шестой тип – альтернативная реализация

предыдущего, ориентированного на упрощение 
представления связи «многие ко многим». Идея 
метода состоит в том, что, кроме интервала времени, в отношение добавляется атрибут с номером 
версии. При операции «естественное соединение» 
между отношениями для каждой пары записей 
проверяется номер версии, что намного проще
анализа временных интервалов.

Краткий анализ различных подходов и мето
дов представления темпоральной информации на 
основе РБД позволяет утверждать, что для динамических ИС типа ИСППР РВ эти методы неприменимы. Известные подходы к реализации ТБД с 
использованием 
классической 
реляционной 

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

Использование языка XML

С помощью языка разметки XML для хранения 

темпорального атрибута можно обойти требование атомарности, хотя это и требует дополнительной информации о структуре XML. По своей 
природе XML-документ обладает бесконечной 
вложенностью и может быть плохо структурированным. Эта особенность позволяет использовать 
его для моделирования временной оси в темпоральной модели. Для хранения темпоральных атрибутов в реляционной таблице Microsoft SQL 
Server 2005 позволяет описать структуру XML, 
удобную для моделирования времени, с помощью 
XML Schema Definition и назначить ее атрибуту в 
реляционной таблице. Таким образом осуществляется контроль над структурой XML, типами тэгов и атрибутов.

Рассмотрим пример использования XML для 

моделирования 
темпоральной 
структуры 
в 

Microsoft SQL Server 2005. Создание схемы XML и 
добавление ее к объектам сервера осуществляются 
с помощью команды T-SQL
CREATE XML 

SCHEMA. Продемонстрируем задание схемы для 
темпорального атрибута:

CREATE XML SCHEMA COLLECTION dbo.sample_xsd AS
‘<xs:schema 

targetNamespace="http://tempuri.org/XMLSchema.xsd" 
elementFormDefault="qualified" 
xmlns="http://tempuri.org/XMLSchema.xsd" 
xmlns:mstns="http://tempuri.org/XMLSchema.xsd" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="temporal_attribute">
<xs:complexType id="temporal_type">
<xs:sequence id="history_sequence" minOccurs="1" 

maxOccurs="unbounded">

<xs:element name="atomic_value" minOccurs="1" 

maxOccurs="unbounded">

<xs:complexType id="atomin_type">
<xs:attribute name="id" type="xs:integer" />
<xs:attribute name="value" type="xs:string" />
<xs:attribute name="time_stamp" 

type="xs:dateTime">

<xs:annotation>
<xs:documentation>Time stamp for presentation 

single point of time.

</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="beginnig_of_period" 

type="xs:dateTime">

<xs:annotation>
<xs:documentation>
Time stamp for presentation a beginning of time 

period.

</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="end_of_period" 

type="xs:dateTime">

Программные продукты и системы
№ 2, 2011 г.

5

<xs:annotation>
<xs:documentation>
Time stamp for presentation a finishing of time 

period.

</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>’

Данная схема позволяет хранить список изме
няющихся значений с временными метками. Создание таблицы с атрибутами типа XML также не 
представляет сложности:

CREATE TABLE xml_example_table (Record_ID int 

primary key, Temporal_Attribute XML(sample_xsd)).

Как уже отмечалось, к элементам типа XML

можно обращаться при помощи запросов XQuery. 
Это позволяет смоделировать любые необходимые отношения между временными интервалами, 
которыми оперирует временная логика. Следующий пример демонстрирует извлечение записей из 
таблицы, удовлетворяющей условию, сформулированному на базе интервальной логики Аллена:
«Найти все периоды жизни персонажа, пересекающиеся с периодом working» (заметим, что данный запрос крайне трудно было бы сформулировать на языке SQL):

SELECT Temporal_Attribute.query
(‘for $p in /temporal_attribute/atomic_value 
where $p/@beginnig_of_period < 

/temporal_attribute/ 
atomic_value[@value=’working’]/@end_of_period

and $p/@end_of_period> /temporal_attribute/ 

atomic_value 
[@value=’working’]/@beginnig_of_period’) 

as life_periods from xml_example_table
В работе [6] исследованы различные варианты 

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

информации в ИС. 

Низкоуровневое представление 

темпоральной информации

Как уже отмечалось, основным препятствием 

для представления темпоральной информации и 
реализации соответствующей темпоральной модели в РБД является плоская структура БД. Поэтому 
для обеспечения требуемой выразительности и
эффективности темпоральной модели необходимо
отойти от реляционной структуры. 

Интересную аналогию с ТБД можно найти в 

пространственных БД (ПБД), предназначенных

для хранения и обработки информации, представленной в пространственных координатах [7]. Отметим очевидное сходство структур пространственных и темпоральных данных. В обоих случаях 
речь идет о кубическом наборе данных. Рассмотрим основные задачи при реализации СУБД, способной эффективно работать как с пространственными, так и с темпоральными данными.

Физическая организация данных. Наиболее 

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

Эта задача решается с помощью построения в 

координатах на плоскости или в координатах 
«время–значение» особых кривых, которые при 
заданном приближении могут охватить сколь 
угодно малую окрестность любой точки (например, кривая Гильберта). Таким образом, физически располагая данные на устройстве хранения в
заданном порядке, можно значительно сократить
дисковые операции при выборке данных. Это 
имеет решающее значение для ИС реального времени типа ИСППР РВ.

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

Язык запросов. Как пространственные, так и 

временные данные для собственной обработки используют свои диалекты языка SQL (к сожалению, 
язык темпоральных запросов до сих пор не включен в стандарт). Между языками запросов РБД и 
ПБД или ТБД существует ряд отличий [7]. Так, 

Программные продукты и системы
№ 2, 2011 г.

6

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

Отметим, что построение собственного языка 

запросов является ключевым преимуществом для 
использования ТБД в ИСППР РВ, так как машина 
вывода в данном случае общается на одном языке 
с БД, что существенно упрощает разработку подобных систем и повышает их производительность.

Применение OLAP-технологии

Рассмотрим темпоральные аспекты в храни
лищах данных (ХД) и их воздействие на среду 
OLAP (On-Line Analitical Processing) [8]. 

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

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

Сервер OLAP должен быть в состоянии вы
полнять темпоральные запросы. При использовании этого вида запросов могут произойти некоторые события, например, ряд элементов станут
недопустимыми в определенное время. Решить
проблему помогут цветные таблицы для явного 
представления подобных ситуаций.

Данные в ХД могут принадлежать различным 

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

размерности (называемые качественными данными) данных пользователя. Если, например, моделируются продажи на предприятии, то количество 
проданных товаров представляет факт, тогда как 
время, филиалы и продукты – это размерности 
(измерения). Факты
и размерности
образуют

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

Используя гиперкуб, можно реализовать инте
рактивный анализ данных. Этот процесс известен 
как OLAP-процесс, и пользователь может задать и
процесс конкретизации данных (называемый детализацией), и обратный процесс – свертку.

Обобщенная 
среда 
(архитектура) 
OLAP

(рис. 1) включает три уровня: клиент (пользовательский интерфейс), воспринимающий запросы 
пользователя; сервер, осуществляющий обработку 
информации (данных); компонент для хранения 
данных, состоящий из ХД (Date Warehause, DWH)
и репозитория метаданных и предоставляющий
информацию о фактах, размерностях и иерархиях.

Сервер OLAP принимает запрос (шаг 1) и по
лучает метаинформацию о выбранном кубе и соответствующих иерархиях (шаги 2, 3), заносит запрос в ХД (шаг 4), получает результат (шаг 5) и 
возвращает его клиенту (шаг 6), а тот передает результат пользователю. При последующем анализе
(шаг 7) сервер OLAP использует метаинформацию.

Навигационный доступ осуществляется с по
мощью команд ROLL-UP и DRILL-DOWN, причем 
изменения происходят в выбранной иерархии в 
соответствии с уровнем детализации. Представление результатов может быть как в двухмерном виде (таблица), так и в трехмерном (вложенные таблицы). Элементы размерностей имеют свойство 
снимка БД. Ребра дерева иерархии снабжены сроком действия промежутков времени. Самая мел
Рис. 1. Обобщенная среда OLAP

OLAP-сервер

Метаинформация

OLAP-клиент

Представление

ХД
Репозиторий
метаданных

1
Запрос
6
Результат
7
Свертка/
детализация

4

Запрос

2
Запрос
3

Метаинформация
5

Результат

Программные продукты и системы
№ 2, 2011 г.

7

Рис. 2. Архитектура OLAP для обработки 

темпоральной информации

ХД
Репозиторий
метаданных

7

Свертка/
детализация
6
Результат

5
Результат
4
Запрос

1

3

2

Версия 

информа
ции

Запрос о допустимых сущностях

Темпоральный 

запрос

OLAP-сервер

Метаинформация
Версия информации

OLAP-клиент

Представление

кая грануляция размерности «время» должна выбираться как единица границ интервала. При этом 
родительские вершины дерева – это строки, дочерние – столбцы, а элементы соответствующей 
матрицы – интервалы.

В ТOLAP допустимы темпоральные запросы. 

Язык запросов расширяется условием WITH 
TIME <Date> ON DIMENSION <Dimension>, 
определяющим размерности, на которых должен 
базироваться
OLAP-процесс. Вследствие этого 

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

Архитектура OLAP, ориентированная на обра
ботку темпоральных запросов, представлена на 
рисунке 2. Изменения выделены темным фоном: в 
репозитории метаданных дополнительно будут 
храниться сроки (интервалы) действия; сервер 
должен понимать темпоральные запросы и хранить метаданные с информацией о версии. Сервер
принимает темпоральный запрос (шаг 1) от клиента, интерпретирует его и определяет, какие измерения для какой даты должны использоваться. 

В репозитории метаданных решается вопрос о допустимых сущностях к требуемой дате (шаг 2), 
определяется соответствующая версия информации (шаг 3), на основе чего сервер делает запрос 
к ХД (шаг 4) и получает результат (шаг 5). Компонент представления должен показать пользователю, какие данные затронуты темпоральными 
аспектами (шаги 6 и 7). Для этого используются 
цветной фон и дополняющая изображение легенда. 

В настоящее время описанные средства пред
ставления и оперирования темпоральной информацией с использованием ТБД и OLAP-технологии реализуются в составе базовых инструментальных средств конструирования ИСППР РВ для 
мониторинга и управления сложными объектами и 
процессами типа объектов энергетики и транспортных систем.

Литература

1. Вагин В.Н., Еремеев А.П. Некоторые базовые принци
пы построения интеллектуальных систем поддержки принятия 
решений реального времени // Изв. РАН: Теория и системы 
управления. 2001. № 6. C. 114–123.

2. Еремеев А.П., Еремеев А.А., Пантелеев А.А. Темпо
ральные базы данных и их применение в интеллектуальных 
системах // Интеллектуальные системы: коллектив. монография. Вып. 4; [под. ред. В.М. Курейчика]. М.: Физматлит, 2010. 
С. 253–276. 

3. Кузнецов С.Д. История и актуальные проблемы темпо
ральных баз данных. 2007. URL: http://www.citforum.ru/database/articles/temporal/ (дата обращения: 01.09.2010).

4. Kimball R., Ross M. The Data Warehouse Toolkit: The 

Complete Guide to Dimensional Modeling (Second Edition). John 
Wiley & Sons. 2002, pp. 188–198.

5. Петухова Н. Проблемы обеспечения информационной 

безопасности в темпоральных базах данных // Transport and 
Telecommunications. 2006. № 03. С. 30–32.

6. Fusheng Wang et al. Using XML to Build Efficient 

Transaction-Time Temporal Database Systems on Relational 
Databases, 
2006.
URL: 
http://www.cs.ucla.edu/~zaniolo/pa
pers/icde06xml.pdf (дата обращения: 01.09.2010).

7. Шекхар С., Чуалуа С. Основы пространственных баз 

данных. М.: Кудиц-образ, 2004. 322 с.

8. Herden O. TOLAP: Temporal Online Analytical Processing

// International Baltic Conference on Databases and Information 
Systems 2, 2002, pp. 55–66.

УДК 004.738.1:004.9

РАЗРАБОТКА САЙТОВ ДЛЯ ИНСТИТУТОВ 

РОССИЙСКОЙ АКАДЕМИИ НАУК

НА ОСНОВЕ СИСТЕМЫ УПРАВЛЕНИЯ КОНТЕНТОМ NetCat

(Работа поддержана УрО РАН, грант РЦП-11-И9)

Н.М. Резина; Р.Н. Шакиров, к.т.н. 

(Институт машиноведения УрО РАН, г. Екатеринбург, nad@imach.uran.ru, raul@imach.uran.ru)

Системы управления контентом (CMS, Content Managements Systems) являются популярным средством разра
ботки сайтов с динамическим содержанием. CMS позволяет разрабатывать, заполнять и сопровождать сайт путем 
визуального редактирования и заполнения веб-форм, при этом необходимость писать коды сводится к минимуму 

Программные продукты и системы
№ 2, 2011 г.

8

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

Ключевые слова: cистема управления контентом, веб-программирование, веб-дизайн, разработка сайтов, 

NetCat.

В данной статье под CMS будем понимать ин
струментальную систему, предназначенную для 
разработки, наполнения и сопровождения сайтов с 
динамическим содержимым, хранящимся в реляционной или объектной БД; обеспечивающую интерфейс разработчика и редактора сайта (контентменеджера) в стиле WYSIWYG (What You See Is 
What You Get); являющуюся самодостаточной, то 
есть не испытывающей необходимости в систематическом применении нижележащих технологий –
модулей веб-сервера, языков веб-программирования и управления БД.

Многие CMS (например Joomla!) рассчитаны 

на применение сайтов непрограммирующими разработчиками. Такие CMS называют системамисборниками, так как содержат множество готовых настраиваемых модулей для создания различных веб-страниц.

В отличие от систем-сборников системы
конструкторы в большей степени ориентированы 
на программирующего разработчика. Готовых модулей в них меньше или вообще нет, но зато имеется продуманный программный интерфейс (API) 
для самостоятельной разработки или адаптации 
различных компонент сайта. Если система-конструктор применяется профессиональным разработчиком, то она значительно (на 1–2 порядка) сокращает объем веб-программирования за счет 
встроенной в систему реализации рутинных задач.

Очевидные 
концептуальные 
преимущества 

CMS частично нивелируются проблемой их правильного выбора. На рынке существуют сотни 
платных и бесплатных CMS, которые могут иметь 
ограниченный срок активного существования, 
плохую техническую поддержку и большое число 
ошибок с тенденцией к накоплению. Особенно это
касается бесплатных CMS, в том числе таких некогда популярных, как PostNuke и Mamba.

Поэтому веб-студии склоняются к примене
нию платных CMS (http://www.romver.ru/services/
services.php?razdel=255). По данным каталога 
CMS 
(http://www.cmsmagazine.ru/catalogue/)
за 

2009–2010 годы, более 1000 внедрений было у 
CMS NetCat, 1С-Битрикс, TYPO3 free, HostCMS, 
UMI.CMS, AMIRO.CMS, Joomla! Free. Эти же системы сохранили лидирующие позиции и в 2011 
году.

В число семи лидеров рейтинга CMS попали 

только две бесплатные системы: TYPO3 и Joomla! 
(Joomla! имела бы лучшую позицию, если бы рейтинг учитывал непрофессиональных разработчиков). Пять позиций занимают платные CMS отечественной разработки. Из них три – Host, UMI и 
Amiro – имеют бесплатные редакции с ограниченными возможностями, а лидеры рейтинга – NetCat 

и 1С-Битрикс – только платные редакции различной стоимости.

Остановимся на внедрении CMS NetCat.

Особенности и функции CMS NetCat

Система управления сайтами NetCat основана

на технологии Apache+PHP+MySQL, является одной из ведущих CMS на российском рынке и рассчитана на использование для разработки следующих видов сайтов: корпоративные представительства; интернет-серверы
портального типа; 

библиотеки данных, файлы-архивы; интернетиздания, СМИ; электронные магазины и прочее, в 
том числе сложные интерактивные веб-системы.

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

Дополнительный функционал реализован в 

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

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

Программные продукты и системы
№ 2, 2011 г.

9

дактирования, могли только добавлять данные, 
что ограничивало социальные возможности сайтов. Функционал редактирования и комментирования материалов появился в 2009 году с выпуском версии 3.5. В систему был добавлен модуль 
кэширования, позволяющий в несколько раз сократить нагрузку на процессор хост-системы. В 
версии 4.1 введена поддержка международной кодировки UTF-8 (Unicode) вместо устаревающих 
кодовых страниц.

Стоимость NetCat зависит от входящего в нее 

набора модулей. Базовые модули – календарь, кэширование, защита форм – картинкой входят во 
все редакции системы. Полноценное ядро с открытым исходным кодом, поддержкой иностранных языков и возможностью установки дополнительных модулей поставляется, начиная с редакции Standard стоимостью 5820 рублей. Регистрация посетителей, подписка и комментирование 
возможны, начиная с редакции Corporate стоимостью 16900 рублей. Техническая поддержка, 
включая закачку и автоматическую установку обновлений, предоставляется сроком на один год, 
стоимость ее продления еще на год составляет 
40 % от стоимости редакции. Фактор стоимости 
системы смягчается значительными дилерскими 
скидками от 20 до 50 %. При появлении брешей в 
системе безопасности возможен несанкционированный доступ к сайтам системы NetCat, поэтому 
обновления предоставляются бесплатно для всех 
актуальных на данный момент версий системы. 
При установке обновлений функциональность 
разработанных на NetCat сайтов не утрачивается, 
так как API обладает обратной совместимостью.

Процесс разработки и заполнения сайта 

в CMS NetCat

На одной лицензионной копии NetCat можно 

создать произвольное количество сайтов. Каждый 
сайт представляется как дерево разделов, которые 
выводятся в виде страниц сайта.

Оформление сайта. Каждая страница сайта 

представляется в виде макета дизайна, состоящего из хедера, футера и шаблонов вывода навигации. Макет дизайна создается в любом редакторе 
HTML, разрезается на хедер и футер и помещается 
в соответствующие поля формы, предназначенной 
для ввода макета в систему NetCat. Между хедером и футером располагается поле, в которое выводится динамическое содержимое 
(рис. 1). Макет 
дизайна 

привязывается к сайту или 
разделу, 
при 

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

Для автоматического формирования отдельных 

элементов страницы применяются вставки PHPкода. К примеру, следующий код автоматически 
формирует главное меню сайта, меню по дереву 
разделов:

".s_browse_level(0, $browse_sub[0])."
Преимущество автоматического способа фор
мирования меню в том, что его не надо переделывать при изменении дерева разделов. Возникающая при этом дополнительная нагрузка на сервер 
снижается с помощью модуля кэширования, который запоминает однажды сформированные динамические элементы страницы. 

Внешний вид меню задается массивом $brow
se_sub[0], помещаемым в шаблоны вывода навигации. Это вложенный код, который можно 
написать самостоятельно или скопировать из 
предустановленного макета дизайна. Например, 
простое двухуровневое меню задается так:

$browse_sub[1][prefix]="<ul><font size=-1>";
$browse_sub[1][suffix]="</font></ul>";
$browse_sub[1][active]=

"<li><b><a href=%URL>%NAME</a></b>";

$browse_sub[1][active_link]="<li><b>%NAME</b>";
$browse_sub[1][unactive]=

"<li><a href=%URL>%NAME</a>";

$browse_sub[1][divider]="";

$browse_sub[0][prefix]="<ul>";
$browse_sub[0][suffix]="</ul>";
$browse_sub[0][active]=

"<li><b><a href=%URL>%NAME</b></a>"
.s_browse_level(1,$browse_sub[1]);

$browse_sub[0][active_link]=

"<li><b>%NAME</b>"
.s_browse_level(1,$browse_sub[1]);

$browse_sub[0][unactive]=

"<li><a href=%URL>%NAME</a>";

$browse_sub[0][divider]="";

Вместо %NAME подставляется имя каждого раз
дела, а вместо %URL – его относительный URL.

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

элементы – содержимое тега title, полей description и keywords, путь к текущему разделу, карта 
сайта. Макет дизайна может содержать любое 
число настраиваемых параметров, которые задаются при создании разделов.

При необходимости в макете дизайна может 

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

Формы отображения и добавления данных.

Для вывода данных к разделу привязывается одна 
или несколько компонент. Компоненты выводятся
в свободном пространстве между хедером и футером – все вместе друг за другом или по отдельно
Хедер

Контент

Футер

Рис. 1. Разбиение страницы сайта

Программные продукты и системы
№ 2, 2011 г.

10

сти с переключением с помощью вкладок. Каждой 
компоненте соответствует таблица MySQL.

Разработка компоненты проводится путем 

описания полей следующих встроенных типов:

Тип NetCat
Реализация в MySQL

строка –
поле char(255)

целое число –
поле int

текстовый блок – поле longtext (версия 3.1.1 

и выше, иначе text)

список –
поле int для left join … where

логическая переменная – поле tinyint 

со значениями 0/1

файл –
объект в файловой системе 
с указанием имени файла и mimetype
в поле char(255)

число с плавающей запятой – поле double
дата и время –
поле datetime

связь c другим объектом – поле int для where

(версия 3 и выше)

множественный выбор – перечень индексов 

в поле text (версия 3.2 и выше).

Соответственно полям в БД создается таб
лица. Для отображения объектов в списке и по отдельности, а также добавления, редактирования и 
поиска объектов создаются HTML/PHP-коды с переменными вида $f_поле. Коды строятся автоматически и при необходимости могут быть отредактированы (обычно редактирование требуется 
для кодов отображения объектов, так как от них 
зависит внешний вид сайта). SQL-запросы к БД
также строятся автоматически, включая все необходимые операции объединения таблиц. Если возникает необходимость, SQL-запросы могут быть 
дополнены и переопределены.

При подключении компоненты к разделу для 

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

При необходимости форма добавления объек
та может быть вызвана из списка объектов по 
внутренней ссылке $addLink, а в NetCat 3.5 появилась важная возможность вызывать форму редактирования объектов по ссылке $editLink и удалять объекты по ссылке $deleteLink.

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

Заполнение сайта и система разделения 

прав. Система управления сайтом вызывается по 
http://домен/netcat/admin. В системе управления 
можно создавать сайты, разделы, макеты, компоненты, списки, вводить данные, выполнять различные операции по обслуживанию системы (архивирование, установку обновлений и модулей, 
управление задачами, создание переадресаций, 
проверку ссылок, SEO-анализ и т.п.) и назначать 
права для доступа к сайту.

Права доступа назначаются на весь сайт или 

только на поддерево разделов и распространяются 
на все данные, которые там содержатся. Отдельно 
разрешаются следующие типы доступа: 

 просмотр закрытых страниц (открытые 

страницы доступны всем посетителям сайта);

 комментирование (при наличии соответст
вующего модуля);

 добавление объектов;
 изменение, включение и удаление своих 

объектов;

 подписка;
 модерирование – возможность изменять и 

удалять любые объекты на сайте;

 администрирование – возможность изме
нять структуру сайта.

Для входа в подсистему редактирования при
меняется ресурс http://домен/netcat. В этом режиме сайт отображается в своем естественном виде с 
добавкой административных панелей для создания, включения, изменения и удаления объектов. 
Административные панели выводятся в том случае, если у редактора есть соответствующие права, иначе вместо панели будет выведено сообщение об отсутствии прав.

Собственно сайт http://домен не имеет адми
нистративных панелей редактирования, но может 
быть снабжен своими средствами ввода и коррекции данных. Например, средства ввода данных 
представлены ссылкой редактировать. Эта ссылка показывается только автору записи, остальные 
посетители сайта ее не видят.

Таким образом, сайт можно заполнять тремя 

различными способами: через систему управления 
сайтом, через подсистему редактирования сайта 
или собственными средствами сайта. Система разграничения прав позволяет назначить любое число 
лиц, ответственных за наполнение сайта и его отдельных подразделов.

Разработка сайтов на базе NetCat

Система NetCat применена авторами для раз
работки 5 сайтов организаций, входящих в систему РАН (http://www.iep.uran.ru, http://www.ihim.
uran.ru, http://www.iegm.ru, http://www.ifp.uran.ru, 
http://www.imach.uran.ru). 
Все 
сайты 
разра

Программные продукты и системы
№ 2, 2011 г.

11

батывались на едином шаблоне, который был создан в 2004–2006 годах 
на основе CMS NetCat Standard версий 2.1 и 2.3. Следует отметить, что в 
версиях NetCat 2.1–2.3 уже имеются 
развитая система разделения прав и 
подсистема редактирования, необходимая для заполнения сайта силами 
сотрудников института. Поддержка 
социальных сервисов в данном случае не требовалась, поскольку создавались именно сайты, а не порталы. 
На 2011 год запланировано обновление сайта http://www.imach.uran.ru до 
NetCat 4.5, которое в перспективе позволит перевести его в категорию порталов.

С помощью CMS NetCat созданы легкие и в то 

же время функционально емкие модели сайтов.

Для их реализации сделаны следующие до
полнения в исходный функционал NetCat:

 двуязычный  интерфейс с переключением 

между внутренними страницами сайта;

 шаблоны двухуровневой навигации с двух
линейным выпадающим меню;

 механизм регистрации на конференции с 

экспортом данных для Excel;

 механизм автоматической генерации меню 

по годам и темам;

 механизм пополнения списков из подсисте
мы редактирования;

 механизм простой подписки на рассылку, 

не требующий авторизации на сайте.

Методика заполнения сайтов 

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

Основное требование 

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

разработкам и патентам. Обеспечиваются выборки: сотрудников – по алфавиту, степеням; публикаций – по сотрудникам и подразделениям; разработок и патентов – по подразделениям. Базы иностранных публикаций, патентов и конференций 
являются общими в русскоязычной и англоязычной частях сайта (рис. 2, 3).

Списки сотрудников формируются в разных 

разделах сайта путем выборки из сводной базы, 
которая ведется независимо в русскоязычной и 
англоязычной частях сайта. Для каждого сотрудника заводится персональная информация, например, фамилия, имя, отчество; подразделение; 
должности и почетные звания; членство в РАН; 
ученая степень (доктор/кандидат), специализация, 
код специальности и пр.

Если сотрудник имеет публикации, то для не
го заводятся индивидуальные авторские сокращения для связи с базами публикаций на русском и 
иностранных языках – «Фамилия И.О.» и «Family 
N.P.» соответственно.

Списки публикаций формируются для ин
ститута, подразделений и отдельных сотрудников
путем выборки из сводной базы публикаций, которая ведется отдельно для публикаций на русском и иностранных языках. Сводная база публи
Список авторов

Фамилия И.О.

Список авторов

Family N.P.

Сотрудники

(рус)

Публикации

(рус)

Публикации

(eng)

Сотрудники 

(eng)

Подразделения 

(рус)

Подразделения 

(eng)

Институт

(рус)

Институт 

(eng)

Рис. 2. Базы сотрудников и публикаций

Рис. 3. Базы разработок, патентов, конференций и новостей

Разработки

(рус)

Патенты

(рус)

Патенты

(eng)

Разработки

(eng)

Подразделения 

(рус)

Подразделения 

(eng)

Институт 

(рус)

Институт 

(eng)

Новости 

(рус)

Конференции 

(рус)

Конференции 

(eng)

Новости 

(eng)

Программные продукты и системы
№ 2, 2011 г.

12

каций содержит полный список публикаций без 
разбивки по подразделениям. Для каждой публикации указываются, например, вид публикации, 
авторы, название публикации, журнал или сборник, место публикации, издательство, аннотация 
или текст публикации на отдельной странице, 
описание публикации и пр.

От вида публикации зависит, попадет ли она в 

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

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

В сведениях о подразделении указывается 

заведующий (на страницу лаборатории автоматически попадают его звания и контактная информация). 

Остальная информация, которая не дублиру
ется в различных частях сайта, вводится в свободном текстовом формате в тот раздел, где она 
должна находиться. Примером могут служить 
разделы «Историческая справка», «Научные направления» лабораторий и т.п.

Результаты разработки 

и наполнения сайтов

При разработке и внедрении сайтов РАН при
ходится решать разнообразные вопросы – от приобретения сервера для хостинга сайта до обучения
редактора сайта. Разработка сайта проводится в 
три этапа:

1) создание структуры и дизайна сайта разра
ботчиками;

2) назначение редактора, ответственного за 

заполнение сайта, который вводит сведения по 
исходным данным заказчика, в том числе о заведующих и ведущих сотрудниках подразделений, и 
основные публикации;

3) получение кодов доступа и заполнение со
ответствующих разделов сайта ответственными 
сотрудниками подразделений.

Первый этап выполняется быстро, так как его 

сроки лимитируются договором. На второй этап 
уходит больше времени, от нескольких месяцев до 
двух лет. Тем не менее, во всех случаях удавалось 

найти лицо, активно занимающееся сайтом, для 
поддержания его в актуальном состоянии. 

Третий этап, к сожалению, всегда проходит 

сложно из-за организационных мероприятий в институтах. 

В таблице приведена статистика сайтов РАН 

на 12
марта 2011 года по данным сайта 

http://www.pr-cy.ru/.

Сайт

Версия NetCat

Год
Яндекс

Google

Проиндекси
рованных 
страниц

разра
ботки

ввода в 

эксплуа
тацию

ТИЦ

Rank

PR

Яндекс

Google

iep.
uran.ru 2.1 2003
2004
275 4/6 4/10
989
725

126
372

ihim.
uran.ru 2.3 2004
2004
30
40
3/6 4/10
3893
5285

200
659

iegm.ru 2.3 2005
2006
130
40

4/6
3/6 4/10
3035
1661

354
150

ifp.
uran.ru 2.3 2006
2008
20
2/6 4/10
812
1315

131
1980

imach.
uran.ru 2.3 2008
2010
140
130 4/6 5/10

4/10

419

13000

631
1680

Примечание: изменения, произошедшие за год, выделены 

жирным шрифтом.

Показатели для первых четырех доменов в ос
новном или полностью относятся к разработанным авторами сайтам на движке NetCat, так как
старая версия сайта частично сохранилась только 
на домене iep.uran.ru, а на домене ifp.uran.ru ее не 
было вообще. Иная ситуация на домене imach.
uran.ru: там сохранены все внутренние страницы 
старого сайта, а его новая версия запущена только 
в 2010 году. Поэтому показатели 2010 года относятся 
в 
основном 
к 
старой 
версии 
сайта 

imach.uran.ru, а показатели 2011 года учитывают 
обе версии.

Дальнейшее развитие сайтов

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

– упростить ввод информации о сотрудниках;
– обеспечить возможность ввода личных све
дений и публикаций отдельными сотрудниками 
института;

– обеспечить возможность импорта публика
ций из текстовых источников;

– обеспечить поддержку UNICODE для ввода 

данных на различных мировых языках;

– реализовать возможность включения пре
зентаций в структуру сайта;