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

• Автор: Нгуен Доан Куонг
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Санкт-Петербург
• Количество страниц: 180 с. : ил.

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ.

Сокращения и обозначения

ГЛАВА 1 ПОСТАНОВКА ЗАДАЧИ ОРГАНИЗАЦИИ ДОСТУПА И ХРАНЕНИЯ ДАННЫХ И ИЗВЛЕЧЕНИЯ ЗНАНИЙ В ТЕМПОРАЛЬНЫХ БАЗАХ ДАННЫХ

1.1. Организации доступа и хранения данных в темпоральных БД

1.2. Обзор методов интеллектуальной обработки временных рядов.

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

1.3.1. Темпоральная надстройка над реляционной СУБД.

1.3.2. Интеллектуальная обработка временных рядов.

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

2.1. Темпоральные модели данных.

2.2. Трансляция в .
2.3. Темпоральная алгебра.
2.3.1. Темпоральная выборка.
2.3.2. Темпоральная проекция
2.3.3. Темпоральное объединение.
2.3.4. Темпоральное пересечение.
2.3.5. Темпоральная разность
2.3.6. Темпоральное произведение
2.3.7. Темпоральная агрегация.
2.3.8. Склейка
2.4. Темпоральные ограничения целостности.
2.5. Операции модификации.
ГЛАВА 3 ИССЛЕДОВАНИЕ МЕТОДОВ ИЗВЛЕЧЕНИЯ ЗНАНИЙ ИЗ ВРЕМЕННЫХ РЯДОВ, ХРАНЯЩИХСЯ В ТЕМПОРАЛЬНЫХ СУБД.
3.1. Обзор методов извлечения знаний
3.2. Предварительная обработка временных рядов
3.2.1. Фильтрация данных временных рядов
3.2.2. Индикатор обобщенного тренда.
3.3. ПРОГНОЗИРОВАНИЕ ПОВЕДЕНИЯ ВРЕМЕННЫХ РЯДОВ
3.3.1. Формирование гистограмм распределения
3.3.2. Предсказание поведения временных рядов.
ЗАКЛЮЧЕНИЕ.
ЛИТЕРАТУРА


Однако темпоральные данные требуют особого рассмотрения вопроса реализации ограничений целостности и хранения данных в согласованном состоянии. Современные промышленные реляционные СУБД для работы с хранимыми данными предоставляют язык запросов Б()Ь. БС)Ь обычно очень большие и, следовательно, подвержены ошибкам. Решением этой проблемы является расширения языка запросов для поддержки темпоральных данных. Методы индексирования данных, поддерживаемые в реляционных СУБД, оказываются неэффективными в случае темпоральных данных. В работе [6] говорится, что одной из основных проблем темпоральных баз данных является поддержка эффективной работы с временными метками данных, в частности, поддержка темпоральных отношений в склеенном состоянии. В темпоральных моделях данных с каждой сущностью ассоциируется временная метка. То, как трактуется эта метка, влияет на семантику большинства операций языка запросов и на дизайн базы данных. Пусть есть два отношения, моментальные снимки которых в любой момент времени эквивалентны. Модель называется моментальной, если такие отношения являются эквивалентными в ней. В интервальной модели такие отношения не обязательно являются эквивалентными. Семантика операций в интервальной модели зависит от набора интервалов, из которых состоят временные метки элементов в базе данных. Не зависимо от типа темпоральной модели, для удобной работы с темпоральными данными конечному пользователю необходимо иметь их представление в склеенном виде. Не должны быть смежными - если два интервала являются смежными, то они должны быть представлены одним интервалом, являющимся их объединением. Следует заметить, что даже в случае, когда отношение хранится в склеенном виде, в результате операций проекции, агрегации или произведения могут получаться отношения в не склеенном состоянии. Склейка позволяет устранить перекрывающиеся и смежные интервалы для кортежей, у которых остальные атрибуты одинаковые. Одним из самых больших достоинств реляционной модели является возможность создавать в ней ограничения целостности, такие как ограничение первичного ключа и ограничение внешнего ключа. При реализации подобных ограничений в темпоральной модели необходимо учитывать временные аспекты сущностей. Предположим, что имеется сущность, представляющая работника компании с атрибутами имя и название отдела, в котором он работает в данный момент. Предположим, что имеется еще одно отношение, хранящее информацию об умениях, которые присущи некоторому работнику и подтверждены некоторым документом с уникальным идентификатором. Для каждого навыка необходимо уметь идентифицировать работника, которому этот навык принадлежит. Для этого используется дополнительный атрибут, в котором записывается ключ, однозначно идентифицирующий работника. Нельзя допускать существования навыков, у которых значение атрибута не соответствует никакому работнику. Это типичный пример внешнего ключа. Все крупные промышленные реализации СУБД сейчас имеют встроенную поддержку ограничений первичного ключа и внешнего ключа. При этом все они (были рассмотрены MS SQL Server, PostgreSQL, Oracle) требуют уникальности от атрибутов, на которые ссылается внешний ключ. Ограничение первичного ключа по определению требует уникальности атрибутов, входящих в первичный ключ. Для эффективной и удобной обработки темпоральных данных было предложено множество специальных языков запросов, многие из которых добавляют поддержку времени к уже существующим языкам. Поскольку стандартом де-факто в настоящее время являются реляционные СУБД с языком запросов SQL-, то имеет смысл рассматривать темпоральные расширения языка SQL-. В новом стандарте языка SQL поддержке темпоральных данных отведен отдельный раздел, в котором описываются конструкции языка, необходимые для полноценной поддержки темпоральных данных. По сравнению со стандартом SQL-, в котором поддержка временных аспектов данных ограничивается тремя типами данных (DATE, TIME и TIMESTAMP), в язык добавлен тип PERIOD и специфические для него предикаты и функции.