- •Развитие компьютерной техники
- •Развитие ядра субд
- •Развитие внешнего окружения
- •Развитие средств работы с бд
- •Развитие моделей данных
- •Каталог объектов
- •Используемые классификаторы
- •Объекты Экземпляры объекта Свойства объекта Индекс
- •Формы представления
- •Технологии обслуживания нового поколения
- •Список литературы
- •Перечень вопросов для самопроверки
Развитие моделей данных
Создаваемые в разных организациях БД не имеют единой концептуальной основы и по большому счету не могут взаимодействовать друг с другом. Использовать вместе заложенную в них информацию очень трудно. Поэтому необходимо развитие универсальных моделей данных, стандартизации представления, обмена данными и метаданными [7, 17].
В настоящее время наблюдается три направления развития моделей данных:
использование языка XML;
унификация представления данных за счет использования многомерной модели данных;
применение формата JSON.
Язык XML уже более 10 лет широко применяется в области создания ИКТ. Основным назначением языка XML является обмен данными. Данные представленные в этом языке являются самоописывающимися, т.е. могут легко прочитаться компьютером за счет использования XML-схемы и человеком, который по именам тегов может определить, что за данные здесь имеются. Так как количество XML-файлов в некоторых системах достигает миллиона (например, в проекте Европейской Комиссии «SeaDataNet»), то имеется потребность хранить эти данные в БД. И в некоторых СУБД (Oracle, MsSQL, DB2) созданы возможности работы с XML-данными. Но главным достоинством языка XML является возможность создания XML-схемы для любой предметной области. Эта схема позволяет описать весь состав атрибутов, используемых в рассматриваемой предметной области. При разработке таблиц, форм визуализации состав атрибутов настраивается на основе созданной XML-схемы. Это позволяет создавать универсальные программные средства, как для ввода данных, так и для их визуализации [20].
Такая схема должна представлять собой не просто набор описаний атрибутов (элементов), а некоторый систематизированный их состав. Схема необходима, чтобы в разных объектах для идентификации похожих свойств применялись одни и те же имена и форматы хранения атрибутов.
Атрибуты метаданных специфицируют характеристики производства (получения, описания, обработки) данных. В атрибутах метаданных определяются идентификаторы структурных единиц данных, платформ наблюдений, инструментов измерений, методов обработки, проектов, географических объектов. В атрибутах «Метаданных» выделяются разделы:
общей идентификации;
принадлежности стране, организации, автору и др.;
спецификации производства (получения) данных – платформа, метод, прибор и др.;
географических характеристик (пространство) – районы (округа), квадранты, высота над уровнем моря, глубина, толщина слоя, горизонтальное смещение, азимут объекта на платформе, расстояние, местоположение платформы – широта, долгота, направление движения платформы;
временных характеристик (год, месяц, время начала и окончания, день и время события).
Параметры данных, специфицирующие отдельные свойства процесса (явления) могут:
быть измеренными значениями, или вычисленными статистическими, или новыми величинами, полученными на основе теоретических или эмпирических закономерностей;
указывать на интенсивность явления, процесса;
представлять диапазон изменчивости;
являться индикатором интенсивности явления;
показывать аномалию (отклонение от многолетнего среднего значения), экстремальные значения, тенденцию, характеристики тенденции, количество зарегистрированных явлений (ситуаций) и другие статистические характеристики.
Для уменьшения числа сущностей и унификации структур данных (например, вместо создания отдельных сущностей Производитель, Разработчик, Магазин можно создать одну сущность Организация) нужно ввести атрибут Роль. Атрибут Роль можно ввести таких сущностей как организация, персона, проект, товар, др.;
Значениями «Роли» являются для объектов:
организации – автор, проектировщик, производитель, владелец, разработчик (застройщик), оператор, администратор;
персоны – автор, проектировщик, владелец, разработчик, оператор, администратор;
товара – проектировщик, производитель, продавец;
проект – автор, исполнитель, участник, администратор.
Для многих объектов важно знать его изменение во времени, т.е. учитывать жизненный цикл объекта. Например, для такого объекта как прибор необходимо иметь следующие этапы жизненного цикла: проектирование, производство, поставка, продажа, хранение, монтаж, списание, уничтожение (утилизация). Для различных типов объектов могут применяться различные этапы жизненного цикла:
- Состояние транспортного объекта - отправление, переход, заход, прибытие, стоянка, на рейде, ремонт, дрейф, производство работ, погрузка, разгрузка;
- Выбросы (отходы): создание, хранение, обезвреживание, утилизация;
- Проект - инициализация; планирование; выполнение; контроль; завершение;
- Данные (управление) - производство измерений, сбор, упорядочение, контроль, создание БД, хранение, каталогизация, обмен, доведение, использование;
- Данные (обработка) - интерполяция (экстраполяция), вычисление физических характеристик, составляющих скалярных величин, вертикальных и горизонтальных градиентов, фильтрация (аппроксимация), сглаживание, удаление регулярных колебаний, расчет статистических характеристик;
- Данные (анализ) - прогноз, классификация, сравнение;
- Документы - создание, описание, модификация-редактирование, обсуждение-рассмотрение, согласование, принятие, ратификация, утверждение-принятие, подписание, вступление в силу документа, передача в печать, издание-публикация, доступность, передача на хранение, прекращение действия, доставка, уничтожение.
Для каждого этапа жизненного цикла документа необходимо знать:
дату – когда произведен, продан, подписан, др.;
кто (менеджер, автор, оператор и т.п.);
нотификацию (уведомление о прохождении каждого этапа жизненного цикла, добавление комментариев);
отражение этапа жизненного цикла в документации (новая версия, или дочерний документ, или новый родительский документ).
Унификация представления данных за счет использования многомерной модели данных. Основной идеей типизации структур данных является использование минимальной атомарной единицы хранения. Сейчас в большинстве БД атомарной единицей хранения является группа параметров, измеренных или вычисленных для одной точки в определенный момент времени или за какой-то период. В зависимости от масштаба применения этого подхода в многомерной модели можно, так же как в реляционной, выделить четыре уровня нормализации.
Первая нормальная форма предполагает наличие одного измерения, являющегося ключом. Например, все простые классификаторы, имеющие два поля – код и описание кода, объединяются в одну таблицу за счет включения третьего поля – идентификатора классификатора, табл.2.
Таблица 2 - Первая нормальная форма
ID классификатора |
Код |
Значение |
1 |
А |
ааа |
1 |
Б |
ббб |
1 |
С |
ввв |
2 |
1 |
ссс |
2 |
2 |
ддд |
Классификаторы являются одним из важнейших элементов БД, обеспечивающих единую информационную среду организации (отрасли). Каждая крупная коммерческая или государственная структура использует в своей работе большое количество разнообразных классификаторов (международных, национальных, отраслевых и других). Как правило, эти классификаторы разрознены и содержатся в различных БД, имеют множество таблиц (каждый классификатор – своя таблица), что приводит к серьезным проблемам внутреннего и внешнего взаимодействия подразделений, связанных с дублированием, противоречивостью многих данных, в итоге существенно снижается эффективность работы любой БД. Все это обуславливает высокую потребность в создании единой централизованной системы хранения и ведения классификаторов.
Если для каждого классификатора создавать свою таблицу, то число таблиц резко увеличится, поэтому предлагается следующая структура для хранения простых классификаторов: идентификатор классификатора, код и значение кода. Для повышения эффективности и удобства использования классификаторов для каждой компоненты создаются рабочие словари. Состав классификаторов и содержание кодов в них назначается в зависимости от потребности.
Во второй нормальной форме предполагается наличие нескольких измерений, например, времени (год, квартал, месяц, день) и географического местоположения (широта, долгота, страна, субъект федерации, город). По любому измерению возможен поиск и получение агрегированных показателей. При этом каждая строка таблицы состоит из ключевых атрибутов, а множество значений показателей сведено в две колонки (имя свойства и значение). Такое объединение возможно, например, при отражении статистических характеристик по кварталам, годам табл.3.
Таблица 3 - Вторая нормальная форма
ID записи |
Год |
Квартал |
Страна |
Город |
Имя характеристики |
Значение |
1 |
2009 |
1 |
RU |
Обнинск |
Кол-во населения |
110000 |
2 |
2009 |
1 |
RU |
Обнинск |
Число родившихся |
500 |
3 |
2009 |
1 |
RU |
Обнинск |
Число умерших |
600 |
Третья нормальная форма предполагает сведение всего множества ключевых и тематических атрибутов к трем колонкам (трипл) – идентификатор записи, имя свойства, значение свойства. Это есть развитие второй нормальной формы, когда и атрибуты метаданных, идентифицирующих значения показателей тематической области, представляются в две колонки (имя ключа - значение), табл.4. Такое представление данных возможно, когда число атрибутов метаданных достаточно большое, но процент их заполнения низкий, например, в области океанографии, для представления сведений о значениях океанографических параметров в открытом океане. При этом кроме пространственно–временных координат необходима дополнительная информация об океанографической станции (номер станции, номер рейса, прибор, метод использования прибора).
Основной трудностью здесь является отсутствие возможности хранить формат хранения каждого свойства объекта (атрибута). Для преодоления этого необходимо поддерживать единый словарь атрибутов, в котором должна содержаться информация о полном и кратком названии свойства, единицах измерений, формате хранения, используемом классификаторе и др.
Таблица 4 - Третья нормальная форма
ID записи |
Имя характеристики |
Значение |
1 |
Широта |
60.00 |
2 |
Долгота |
29.00 |
3 |
Дата |
30.07.2009 |
4 |
Номер станции |
1 |
5 |
Номер рейса |
15 |
6 |
Прибор |
СТД |
7 |
Метод использования прибора |
Зондирование |
|
Горизонт |
10 |
8 |
Судно |
Академик Федоров |
|
Страна |
RU |
9 |
Имя параметра |
Т w |
|
Значение параметра |
15.6 |
Четвертая нормальная форма предполагает выделение для каждого объекта (сущности) двух таблиц (каталог объектов и таблица фактов-событий), а также двух дополнительных таблиц (таблица используемых классификаторов и таблица связей таблиц и экземпляров объектов) и хранение данных в таблице в виде трипла (рис.1).
