Базы данных дополнительные вопросы




Дата канвертавання24.04.2016
Памер188.78 Kb.



БАЗЫ ДАННЫХ - Дополнительные вопросы


  • OLTP-технологии (OnLine Transaction Processing) - онлайновая обработка транзакций

  • OLAP-технологии (OnLine Analytical Processing) - аналитическая обработка в реальном времени)

  • Сравнение OLTP- и OLAP-технологий

  • Информационные хранилища

  • Основы фракталов. Фрактальная математика. Фрактальные методы в архивации.

  • Ограничения целостности в БД



МЕТОДИЧЕСКИЕ МАТЕРИАЛЫ
СОДЕРЖАНИЕ


OLTP-технологии [1] 2

Описание и определения 2

Использование 2

Требования 2

Преимущества и недостатки 2

OLAP-технологии [1] 2



Описание и определения 2

Действие OLAP 2

Реализации OLAP 3

История OLAP [2] 4

12 Признаков OLAP Данных [1] 4

FASMI тест [1] 5

Сравнение OLTP- и OLAP-технологий [1] 5

Информационные хранилища (хранилища данных) [1] 6

Описание и определения 6

Принципы организации хранилища 6

Процессы работы с данными 7

Фракталы [3] 7



Описание и определения 7

История 8

Применение фракталов 8

Ограничения целостности в БД [4] 10



Описание и определения 10

Целостность сущностей. 10

Целостность ссылок 10

Литература 11



===================================================================



OLTP-технологии [1]

Описание и определения


OLTP (OnLine Transaction Processing) — онлайновая обработка транзакций. Способ организации БД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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


Использование


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

Требования


  • Сильно нормализованные модели данных.

  • При возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции.

  • Обработка данных в реальном времени.

Преимущества и недостатки


OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций.

******************


OLAP-технологии [1]

Описание и определения


OLAP (англ. OnLine Analytical Processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчетов по продажам, маркетингу, в целях управления, т. н. data mining — добыча данных (способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей).

Действие OLAP


Причина использования OLAP для обработки запросов — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно. Более хорошей моделью для запросов, а не для изменения, является Пространственная БД.

OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0.1 % от аналогичных запросов в реляционную БД.

OLAP-структура, созданная из рабочих данных, называется OLAP-куб. Куб создаётся из соединения таблиц с применением схемы звезды. В центре «звезды» находится таблица фактов, которая содержит ключевые факты, по которым делаются запросы. Множественные таблицы с измерениями присоединены к таблице фактов. Эти таблицы показывают, как могут анализироваться агрегированные реляционные данные. Количество возможных агрегирований определяется количеством способов, которыми первоначальные данные могут быть иерархически отображены.

Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, три группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».

Вместе с базовой концепцией существуют три типа OLAP — OLAP со многими измерениями (Multidimensional OLAP — MOLAP), реляционный OLAP (Relational OLAP — ROLAP) и гибридный OLAP (Hybrid OLAP — HOLAP). MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми.



Реализации OLAP


Первым продуктом, выполняющим OLAP-запросы, был Express (компания IRI). Однако, сам термин OLAP был предложен Эдгаром Коддом, «отцом реляционных БД». А работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт — Essbase (позже купленный Hyperion, которая в 2007 г. была поглощена компанией Oracle) — годом ранее. Как результат, «12 законов аналитической обработки в реальном времени» Кодда появились в их описании Essbase.

Другие хорошо известные OLAP-продукты включают Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), Oracle OLAP Option, DB2 OLAP Server от IBM (фактически, EssBase с дополнениями от IBM), SAP BW, продукты Brio, BusinessObjects, Cognos, MicroStrategy и других производителей.

C технической точки зрения, представленные на рынке продукты делятся на «физический OLAP» и «виртуальный».

В первом случае наличествует программа, выполняющая предварительный расчет агрегатов, которые затем сохраняются в специальную многомерную БД, обеспечивающую быстрое извлечение. Примеры таких продуктов — Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay.

Во втором случае данные хранятся в реляционных СУБД, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов — SAP BW, BusinessObjects, Microstrategy.

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

С точки зрения пользователя оба варианта выглядят похожими по возможностям.

Наибольшее применение OLAP находит в продуктах для бизнес-планирования и хранилищах данных.


История OLAP [2]


Термин OLAP был введен в 1993 Эдгаром Коддом [5]. Цель систем OLAP — облегчение решения задач анализа данных. Кодд сформулировал 12 признаков OLAP-данных, и большинство современных средств OLAP отвечает этим постулатам. Перечислим их:

12 Признаков OLAP Данных [1]


Многомерная концепция данных.

OLAP оперирует данными CUBE (см. далее описание работ Грея [8]), которые являются многомерными массивами. Число измерений OLAP-кубов не ограничено.



Прозрачность.

OLAP системы должны опираться на открытые системы, поддерживающие гетерогенные источники данных.



Доступность.

OLAP системы должны представлять пользователю единую логическую схему данных.



Постоянная скорость выполнения запросов.

Производительность не должна падать при росте числа измерений.



Клиент/сервер архитектура.

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



Различное число измерений.

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



Динамическое представление разреженных матриц.

Под разреженной матрицей понимается такая матрица, не каждая ячейка которой содержит данные. OLAP-системы должны содержать средства хранении и обработки разреженных матриц больших объемов.



Многопользовательская поддержка.

OLAP-системы должны поддерживать многопользовательский режим работы.



Неограниченные многомерные операции.

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



Интуитивно понятные инструменты манипулирования данными.

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



Гибкая настройка конечных отчетов.

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



Отсутствие ограничений.

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


FASMI тест [1]


В дальнейшем Найджел Пендс переформулировал 12 правил Кодда (см. [18]) в более емкий тест FASMI (Fast Shared Multidimensional Information). По определению Пендса, OLAP-система должна быть:

  • Fast — быстрой, обеспечивать почти мгновенный отклик на большинство запросов;

  • Shared — многопользовательской; должен существовать механизм контроля доступа к данным, а также возможность одновременной работы многих пользователей;

  • Multidimensional — многомерной; данные должны представляться в виде многомерных кубов;

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

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

В 1995 группа исследователей во главе с Джимом Греем [8], проанализировав создаваемые тогда пользовательские приложения баз данных, предложила расширение языка SQL — оператор CUBE. Данный оператор отвечает за создание многомерных кубов в SQL. Концепция многомерного представления данных является, наряду с моделью транзакций, одной из самых известных идей Грея. В этой работе исследователи указали ряд эвристических рекомендаций по реализации новой структуры данных.

CUBE представляет собой обобщение операторов выборки с разделом GROUP BY по всем возможным комбинациям измерений с разными уровнями агрегации данных. Каждая сгруппированная таблица относится к группе ячеек, описываемых кортежами из измерений, по которым формируется сгруппированная таблица. Оператор, расширяющий SQL, называется CUBE BY (синтаксис такой же, как и у GROUP BY).

В стандарт SQL'99 включен набор операторов для работы с OLAP-данными (запросы grouping set, rollup by, cube by, window by, rank, rownum и пр).

******************

Сравнение OLTP- и OLAP-технологий [1]





Технологии

Назначение

Типы запросов

Типы вопросов

Время отклика

Типичные операции

OLTP
(оперативность)


Обработка текущих хозяйственных операций, хранение оперативных данных

Предсказуемые (регламенти­рованные)

Сколько? Как? Когда?

Не регламен­тируется

Регламенти­рованный отчет, диаграмма

OLAP
(аналитика)


Многомерный анализ, моделирование

Произвольные

Почему? Что будет, если?

Секунды

Последовательность интерактивных отчетов, диаграмм, экранных форм; динамическое изменение уровней агрегации и срезов данных

******************


Информационные хранилища (хранилища данных) [1]

Описание и определения


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

Данные, поступающие в хранилище данных, становятся доступны только для чтения. Данные из промышленной OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы промышленной системы и не нарушал её стабильность. Данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных несколько отстает от OLTP-системы.

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

Вариант 2: Хранилище данных (англ. Content Repository) — программная подсистема, сочетающая в себе функции системы управления версиями, поисковой машины и СУБД.

Примером хранилища данных может служить система Apache Jackrabbit.

В функции хранилища данных входит:


  • хранение структурированных и неструктурированных данных

  • полнотекстовый поиск

  • версионирование

  • поддержка транзакций

  • наблюдение за контентом.



Принципы организации хранилища


1. Проблемно-предметная ориентация: данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.

2. Интегрированность: объединяет данные таким образом, чтобы они удовлетворяли всем требованиям всего предприятия, а не единственной функции бизнеса.

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

4. Зависимость от времени: данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.


Процессы работы с данными


1. Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.

2. Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.

3. Анализ.

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

Источниками данных могут быть:

а) Традиционные системы регистрации операций (БД)

б) Отдельные документы

в) Наборы данных

Источники данных классифицируются:

1. Территориальное и административное размещение.

2. Степень достоверности.

3. Частота обновляемости.

4. Система хранения и управления данными.

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

Задача словаря метаданных состоит в том, что бы освободить разработчика от необходимости стандартизировать источники данных.

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

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

Логическая структура данных хранилища данных отличается от структуры данных источников данных.

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

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

Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные -> информация -> знания -> полученные решения.

******************

Фракталы [3]

Описание и определения


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





множество Мандельброта — классический образец фрактала

Фрактальная форма подвида цветной капусты (Brassica cauliflora)

Следует отметить, что слово «фрактал» не является математическим термином и не имеет общепринятого строгого математического определения. Оно может употребляться, когда рассматриваемая фигура обладает какими-либо из перечисленных ниже свойств:

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

  • Является самоподобной или приближённо самоподобной.

  • Обладает дробной метрической размерностью или метрической размерностью, превосходящей топологическую.

  • Может быть построена при помощи рекурсивной процедуры.

Многие объекты в природе обладают фрактальными свойствами, например побережья, облака, кроны деревьев, кровеносная система и система альвеол человека или животных.

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


История


Первые примеры самоподобных множеств с необычными свойствами появились в XIX веке (например, множество Кантора). Термин «фрактал» был введён Бенуа Мандельбротом в 1975 году и получил широкую популярность с выходом в 1977 году его книги «Фрактальная геометрия природы».

Применение фракталов

Компьютерная графика






Фрактальное дерево




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

Анализ рынков


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

Физика и другие естественные науки


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

Фрактальные антенны


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

Сжатие изображений


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

Децентрализованные сети


Система назначения IP-адресов в сети Netsukuku использует принцип фрактального сжатия информации для компактного сохранения информации об узлах сети. Каждый узел сети Netsukuku хранит всего 4 Кб информации о состоянии соседних узлов, при этом любой новый узел подключается к общей сети без необходимости в центральном регулировании раздачи IP-адресов, что, например, характерно для сети Интернет. Таким образом, принцип фрактального сжатия информации гарантирует полностью децентрализованную, а следовательно, максимально устойчивую работу всей сети.

******************


Ограничения целостности в БД [4]

Описание и определения


Целостность данных - это механизм поддержания соответствия базы данных предметной области.

В реляционной модели данных определены два базовых требования обеспечения целостности:



  • целостность ссылок

  • целостность сущностей.

Целостность сущностей.


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

каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).

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

Поддержание целостности сущностей обеспечивается средствами системы управления базой данных (СУБД). Это осуществляется с помощью двух ограничений:


  • при добавлении записей в таблицу проверяется уникальность их первичных ключей

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

Целостность ссылок


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

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

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

Требование целостности по ссылкам состоит в следующем:

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

Пусть, например, даны отношения ОТДЕЛ (N_ОТДЕЛА, ИМЯ_ОТДЕЛА) и СОТРУДНИК (N_СОТРУДНИКА, N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_ОТДЕЛА" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута "N_ОТДЕЛА", которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует,  значение внешнего ключа "N_ОТДЕЛА" в отношении СОТРУДНИК считается неопределенным.

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

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

_______________________

Литература


  1. Wikipedia. Статьи: OLAP, OLTP, Хранилище данных.

  2. Юрий Кудрявцев. Обзор алгоритмов MOLAP. факультет ВМиК МГУ, 2008 г. // http://www.citforum.ru/consulting/BI/molap_overview/ .

  3. Wikipedia. Статья Фрактал.

  4. Введение в базы данных, раздел 4.3. Ограничения целостности. // http://www.mstu.edu.ru/education/materials/zelenkov/ch_4_3.html

____________________________





База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка