Слайд 1Базы данных
Управление данными
Слайд 3Основные требования, предъявляемые к банкам данных
Слайд 4Основные требования, предъявляемые к банкам данных
Слайд 5Основные требования, предъявляемые к банкам данных
Слайд 6Основные требования, предъявляемые к банкам данных
Слайд 7Основные требования, предъявляемые к банкам данных
Слайд 9Информационная база
Данные, отражающие состояние определенной предметной области и используемые информационной
системой
Слайд 10Уровни представления данных
Обобщенный взгляд на данные с позиций предметной области
Не
затрагивает физической организации (размещения) данных во внешней памяти
Глобальное представление БД,
определяет необходимые условия для организации хранения данных на внешних запоминающих устройствах
Слайд 11Лингвистические средства
в состав СУБД включаются
Слайд 13Языковые средства работы с базой данных
Слайд 14Языковые средства работы с базой данных
Слайд 18Язык для работы с базами данных
SQL (Structured Query Language)
Слайд 21Централизованное управление данными обеспечивает:
Слайд 23Организационно-административные подсистемы и нормативно-методическое обеспечение
Слайд 31Типология баз данных с точки зрения информационных процессов
Слайд 32Система моделей представления информации
Инфологические модели
Модели представления хорошо структурированной информации
Модели
представления плохо структурированной информации
IDEF-модели
Диаграммы потоков данных
ER-модели
Дескрипторные модели
Семантические сети. Тезаурусы
Фреймы
Даталогические модели
Модели
представления фактографической информации
Модели представления документальной информации
Объектно-ориентированные
Теоретико-графовые
Теоретико-множественные
Инвертирования организация
Прямая организация
Иерархические
Сетевые
Реляционные
Бинарных отношений
Схемно-определяемая структура
Контекстно-определяемая структура
Физические модели
Модели, основанные на файловых структурах
Модели, имеющие страничную организацию
IDEF – одно из семейств стандартов ICAM (Integrated Computer-Aided Manufacturing)
IDEF – ICAM DEFinition
DFD – Data Flow Diagram
ER – Entity-Relationship – Сущность-Связь
Слайд 33Примерная схема организации ввода-вывода
Слайд 36Первые системы управления базами данных
Слайд 38Схема обработки запроса на выборку данных из БД
прикладная программа (клиентское
приложение) формирует и выдает системе управления базами данных запрос на
чтение необходимых данных, содержащихся в базе
СУБД отыскивает описание затребованных данных в структуре описания данных прикладного уровня (внешняя модель)
СУБД по глобальному описанию БД (концептуальная схема) определяет необходимые данные на логическом уровне
СУБД по описанию физической структуры БД (физическая модель) определяет физическую запись (или совокупность записей), которую необходимо считать для выборки данных, затребованных прикладной программой
СУБД через подсистему управления потоками данных выдает операционной системе запрос на чтение хранимой записи
подсистема управления вводом-выводом операционной системы осуществляет физическое чтение записи в системный буфер ОС
СУБД выделяет необходимую логическую запись, осуществляет форматные преобразования, обусловленные различиями описаний на глобальном и прикладном уровнях, и передает для функциональной обработки приложением данные в рабочий буфер, выделяемый прикладной программой или самой СУБД
Слайд 40Варианты размещения данных и их описания
Программа
Описание данных
Данные
В прикладной программе
Программа
Описание данных
Д
а
н
н
ы
е
В
файле данных
Программа
Данные
Отдельным набором данных (словарь данных)
Описание данных
Слайд 41Основные отличительные особенности обработки данных, характерные для файловых систем и
систем управления базами данных
Слайд 42Основные задачи обработки данных, решаемые на основе концепций баз данных,
сводятся к следующим вопросам
Слайд 43Эффективность
Простота
Скорость выборки
Стоимость (сложность) аппаратных средств
Скорость выборки
Сложность
процедур доступа
Плотность данных
Время доступа и сложность процедур
Независимость
данных
Производительность
Гибкость средств поиска
Избыточность данных
Гибкость поиска
Скорость поиска
Сложность процедур доступа
Простота обслуживания
Создание базы данных — это попытка найти компромисс сразу по нескольким направлениям и сочетаниям нескольких взаимообратных факторов (с точки зрения прагматики)
Слайд 44Соотношение понятий концептуальной и внутренней схем
набор объектов, представляющих интерес для
актуальных или предполагаемых пользователей
совокупность функциональных характеристик объектов и особенностей представления
информации (например, в числовой или текстовой форме)
Абстрагированное описание предметной области с фиксированной (логической) точки зрения
Отображение концептуальной схемы на физический уровень называют внутренней схемой
Отражение взгляда (точки зрения) отдельного пользователя на концептуальную схему (как вариант восприятия предметной области) называют внешней схемой
Слайд 45Варианты решений трехуровневого представления
Слайд 46Трехуровневая архитектура обеспечивает выполнение основных требований, предъявляемых к системам баз
данных
Слайд 47Трехуровневая архитектура имеет следующие достоинства с точки зрения пользователей различных
категорий
Слайд 48Идентификация объектов и записей
Основные понятия
Слайд 49Атрибутивный способ идентификации
(используется для хорошо структурированной информации)
Слайд 50Информация
Объект
предметной области
Свойство
Данные
Запись
Элементы данных
Значение
Атрибутивный способ идентификации
(используется для хорошо структурированной информации)
Слайд 51Поиск записей
В качестве ключа, обеспечивающего доступ к записи, можно использовать
идентификатор — отдельный элемент данных
Слайд 53Способы хранения ключа и атрибута
Инвертируемый список
Слайд 54Типология простых (атомарных) запросов:
в запросах типов 2, 3, 6 вместо
оператора равенства может быть использован другой оператор сравнения (больше, меньше,
неравно или другие)
Запросы типа 1 выполняются поиском по «прямому» массиву: доступ к записи производится по первичному ключу
Запросы типа 2 выполняются поиском по инвертированному списку: доступ к записи(ям) производится по указателю, выбираемому из списка по значению вторичного ключа. Ответом в этих случаях будет значение атрибута или идентификатора
Запросы типа 3 имеют ответом имя атрибута
Запросы типа 2, 5, 6 относятся к нескольким атрибутам, и в этом случае могут быть построены несколько индексов, облегчающих поиск по этим ключам
Слайд 55Составные условия поиска могут использовать несколько простых условий, обычно связанных
логическими (булевыми) операторами
Слайд 56Этапы преобразования представлений предметной области
Слайд 611
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
21
17
18
19
20
Дерево
Корень
Листья
Слайд 62Деревья
Сбалансированное дерево в каждом узле имеет одинаковое число ветвей, причем
процесс включения новых ветвей в узлы дерева идет сверху вниз,
а на каждом уровне дерева — слева направо
Двоичные деревья — это особая категория сбалансированных древовидных структур, в которой допускается не более двух ветвей для одного узла
Пример несбалансированного двоичного дерева
Слайд 631
Сетевые структуры
2
3
4
5
6
7
8
9
10
11
1
2
3
4
5
Слайд 64Поставщик
Изделие
Пример простой сетевой структуры
Расценка
Заказ
на закупку
Партия
товара
Слайд 65Руководитель
Служащий
руководит
Изделие
Узел
Деталь
Пример сетевой структуры с петлей
Слайд 66Основные понятия реляционной модели
Первичный ключ
PK
FIO
YEAR
JOB
KAF
Домены
Отношение
Кортежи
Кардинальность
Атрибуты
Степень
Слайд 67Реляционная модель предъявляет к таблицам следующие требования:
1) данные в ячейках
таблицы должны быть структурно неделимыми ;
2) данные в одном столбце
должны быть одного типа;
3) каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
4) столбцы размещаются в произвольном порядке;
5) строки размещаются и таблице также в произвольном порядке;
6) столбцы имеют уникальные наименования.
Слайд 75Деление
Делимое
Посредник
Делитель
Деление
Слайд 76Физические модели баз данных
Организация данных на машинных носителях
Слайд 77Физические модели баз данных
Типы записей
Слайд 78Способы организации файлов данных
Слайд 79Физическое представление с разделением данных и связей
Слайд 80Требования, предъявляемые к базам данных
Описания должны быть понятны пользователю,
не проектировавшему базу
2. Однажды принятые способы представления данных должны допускать
присоединение новых элементов данных без изменения существующих схем данных и прикладных программ
3. СУБД должны позволять эффективно обрабатывать произвольные запросы к базе данных
Слайд 81Модели и этапы проектирования баз данных
Проектирование базы данных — это
упорядоченный формализованный процесс создания системы взаимосвязанных описаний, т. е. таких
моделей предметной области, которые связывают (фиксируют) хранимые в базе данные с объектами предметной области, описываемыми этими данными
Такие описания реализуются, например, в виде схем
Слайд 82Модели и этапы проектирования баз данных
Проектирование начинается c анализа предметной
области и выявления функциональных и других требований к проектируемой системе
Проектирование
обычно выполняется человеком (группой людей) — системным аналитиком (а на практике чаще администратором базы данных), которым может быть как специально выделенным сотрудником, так и будущим пользователем базы данных, достаточно хорошо знакомым с машинной обработкой данных
Слайд 83Модели и этапы проектирования баз данных
Объединяя отдельные представлений о содержимом
базы данных, полученные в результате опроса пользователей, и свои представления
о данных, которые могут потребоваться для решения практических задач, системный аналитик сначала создает обобщенное неформальное описание создаваемой базы данных.
2. Это описание, выполненное с использованием естественного языка, математических выражений, таблиц, графов и других средств, понятных всем людям, работающим над проектированием базы данных, называют инфологической моделью
Слайд 84Модели и этапы проектирования баз данных
Инфологическая человеко-ориентированная модель практически полностью
независима от физических параметров среды хранения данных, которой может быть
как память человека, так и ЭВМ
Инфологическая модель не изменяется до тех пор, пока какие-то изменения в реальном мире (той его части, которая отнесена к предметной области) не потребуют изменения в модели соответствующего фрагмента описания, чтобы эта модель продолжала адекватно отражать предметную область.
Слайд 85Модели и этапы проектирования баз данных
Все модели, кроме инфологической, являются
машинно-ориентированными
С их помощью СУБД дает возможность программам и пользователям
осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных
Так как доступ к данным осуществляется с помощью конкретной СУБД, то модели должны быть представлены на языке описания данных этой СУБД. Такое описание, создаваемое по инфологической модели данных, называют даталогической моделью данных.
Для размещения и поиска данных на внешних запоминающих устройствах СУБД использует физическую модель данных.
Слайд 86Стадии и объекты процесса проектирования
Слайд 88Сущность, с помощью которой моделируется класс однотипных объектов, определяется как
«предмет, который может быть четко идентифицирован».
Сущность должна определяться таким набором
атрибутов, который позволял бы различать отдельные экземпляры сущности.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра.
Сущности подразделяются на сильные и слабые.
Сущности
Слайд 89Свойства
Cвойство - характер связи свойства с сущностью.
Свойство может быть множественным
или единичным
Свойство может быть простым или составным
В некоторых случаях полезно
различать базовые и производные свойства
Если наличие некоторого свойства для всех экземпляров сущности не является обязательным, то такое свойство называется условным
Значения свойств могут быть постоянными – статическими или динамическими
Свойство может быть неопределенным
Свойство может рассматриваться как ключевое
Слайд 90Связь определяется как «ассоциация, объединяющая несколько сущностей»
Сущности, объединяемые связью, называются
участниками. Степень связи определяется количеством участников связи
Если каждый экземпляр сущности
участвует, по крайней мере, в одном экземпляре связи, то такое участие этой сущности называется полным (или обязательным); в противном случае — неполным (или необязательным)
Количественный характер участия экземпляров сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:M), «многие ко многим» (М:М).
Отношение «часть — целое» используются для представления составных объектов.
Связи
Слайд 91Сотрудник
Рабочий
Программист
Табельный номер
ФИО
Язык программирования
Прикладной программист
Системный программист
Отношение «род – вид» используется для
представления обобщенных объектов.
Сущность может быть расщеплена на два или более
взаимоисключающих подтипов, каждый из которых включает общие атрибуты и/или связи.
Сущность, на основе которой определяются подтипы, называется супертипом.
Супертипы
Слайд 92Сущности. Каждый тип сущности в ER-диаграммах представляется в виде прямоугольника,
содержащего имя сущности.
В качестве имени обычно используются существительные (или
обороты существительного) в единственном числе.
Для отражения сущностей слабых типов используются прямоугольники, стороны которых рисуются двойными линиями.
Нотация ER-диаграмм
Слайд 93Нотация ER-диаграмм
Свойства. Свойства служат для уточнения, идентификации, характеристики или выражения
состояния сущности или связи. Свойства отображаются в виде эллипсов, содержащих
имя свойства. Эллипс соединяется с соответствующей сущностью или связью линией.
Имена ключевых свойств подчеркиваются
Контур эллипса рисуется двойной линией, если свойство многозначное
Контур эллипса рисуется штриховой линией, если свойство производное
Эллипс соединяется пунктирной линией, если свойство условное
Если свойство составное, то составляющие его свойства отображаются другими эллипсами, соединенными с эллипсом составного
Слайд 94Нотация ER-диаграмм
Связь – это графически изображаемая ассоциация, устанавливаемая между сущностями.
Каждый тип связи на ER-диаграмме отображается в виде ромба с
именем связи внутри. И качестве имени обычно используются отглагольные существительные.
Стороны ромба рисуют двойными линиями, если это связь сущности слабого типа с сущностью, от которой она зависит.
Участники связи соединены со связью линиями. Двойная линия обозначает полное участие сущности в связи с данной стороны.
Связь может быть модифицирована указанием роли.
Тип связи указывается индексами «1» или «М» над соответствующей линией
Слайд 95В первой нормальной форме ER-диаграммы устраняются повторяющиеся атрибуты или группы
атрибутов, т. е. производится выявление неявных сущностей, «замаскированных» под атрибуты.
Во
второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.
Нормальные формы ER-диаграмм
Слайд 96Пример ER-диаграммы в третьей нормальной форме
Слайд 97Транзакции
Исходное состояние
Исходное состояние
Измененная БД
Нарушение целостности
COMMIT
ROLLBACK
Исходное состояние
Транзакция – неделимая с точки
зрения воздействия на БД последовательность операторов манипулирования данными, такая, что:
1)
либо результаты всех операторов, входящих в транзакцию, отображаются в БД;
2) либо воздействие всех этих операторов полностью отсутствует.
Слайд 98Модель автоматического выполнения транзакций
INSERT
COMMIT
UPDATE
COMMIT
INSERT
COMMIT
UPDATE
ROLLBACK
Непротиворечивая БД
Непротиворечивая БД
Непротиворечивая БД
Слайд 99Модель управляемого выполнения транзакций
BEGIN TRANSACTION
Исходное состояние БД
UPDATE
SAVE TRANSACTION A
INSERT
ROLLBACK
TO A
DELETE
COMMIT TRANSACTION
Точка сохранения А
Cостояние БД после транзакции
Слайд 100Протокол журнализации (и управления буферизацией) действует по правилу Write Ahead
Log (WAL) — «пиши сначала в журнал», и состоит в
том, что если требуется сохранить во внешней памяти измененный объект базы данных, то перед этим нужно гарантировать сохранение во внешней памяти журнала записи о его изменении.
Журнал транзакций
Слайд 101Пользователь не должен осуществлять рестарт транзакций или повторный ввод данных.
Восстановление должно проходить на базе транзакции с помощью отмены или
изменения отдельных транзакций.
2. Быстрое восстановление данных обеспечивается генерацией данных, используемых для восстановления.
3. При выполнении процедур автоматизированного восстановления пользователь не должен анализировать состав данных и выбирать сами процедуры.
Общие требования к системе восстановления данных в составе СУБД
Слайд 102Программы ведения системного журнала регистрируют операции над БД: описание соответствующей
транзакции, код пользователя, текст входного сообщения, тип изменения БД, адреса
изменяемых данных вместе с их значениями до и после изменения.
Программы архивации используются для регулярного получения копий БД для последующего ее восстановления.
Программы восстановления применяются для возврата БД или некоторых ее частей и состояние, предшествующее возникновению отказа. При этом используют архивную копию БД и системный журнал.
Программы отката ликвидируют последствия выполнения определенной транзакции в БД.
Программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.
Сервисные программные средства для восстановления
Слайд 103Кладовщик 1
Кладовщик 2
Запрос количества пива на складе для ID_Сорт =
5
Ответ: 30
Запрос количества пива на складе для ID_Сорт = 5
Ответ:
30
Заполнение столбца ID_Сорт таблицы «Пиво» с Количеством 25
Заполнение столбца ID_Сорт таблицы «Пиво» с Количеством 18
Изменение значения столбца Количество и занесение нового значения (5) в строку таблицы
Изменение значения столбца Количество и занесение нового значения (12) в строку таблицы
ID_Сорт … Количество
… … …
5 … 30
… … …
ID_Сорт … Количество
… … …
5 … 5
… … …
ID_Сорт … Количество
… … …
5 … 12
… … …
«Проблема пропавшего изменения»
Слайд 104Кладовщик 1
Кладовщик 2
Запрос количества пива на складе для ID_Сорт =
5
Ответ: 30
Заполнение столбца ID_Сорт таблицы «Пиво» с количеством 30
Увеличение значения
столбца Количество на 30 и занесение нового значения (60) в строку таблицы
Запрос количества пива на складе с ID_Сорт=5
Ответ: 60
ID_Сорт … Количество
… … …
5 … 30
… … …
ID_Сорт … Количество
… … …
5 … 60
… … …
ID_Сорт … Количество
… … …
5 … 30
… … …
Проблема чтения «грязных данных» (dirty data)
ROLLBACK
(возврат к исходному состоянию)
Заполнение столбца ID_Сорт таблицы «Пиво» с количеством 60
!! ОШИБКА !!
Слайд 105Кладовщик 1
Кладовщик 2
Запрос количества пива на складе для ID_Сорт =
5
Ответ: 30
Заполнение столбца ID_Сорт таблицы «Пиво» с количеством 30
Увеличение значения
столбца Количество на 30 и занесение нового значения (60) в строку таблицы
Запрос количества пива на складе с ID_Сорт=5
Ответ: 30
ID_Сорт … Количество
… … …
5 … 30
… … …
ID_Сорт … Количество
… … …
5 … 60
… … …
Не то продали! Бестолковые менеджеры!
Проблема чтения несогласованных данных
Запрос количества пива на складе с ID_Сорт=6
Ответ: 50
Продаем 6ой сорт, раз его больше!
Запрос количества пива на складе с ID_Сорт=5
Ответ: 60
Слайд 106Проблема «строк-призраков»
Декан ФИТ
Выгрузить данные аттестации!!!
Компьютер деканата
Выгружаем список…
Студент Пупкин
Ура!
Я только что переписал аттестацию!
Преображенский Ю.П.
Беги в деканат, расскажи
им об этом!
Студент Пупкин
Бягу!!!
Студент бежит…, список выгружается….
Декан ФИТ
Всё! Пупкин не сдал! Отчислить его!
Студент Пупкин
Аааа! Я ж сдал!
Список выгружается еще раз…. Пупкин сдал… но его уже отчислили…
Слайд 107Сериализация транзакций
Метод сериализации транзакций — это механизм их выполнения по
такому плану, когда результат совместного выполнения транзакций эквивалентен результату некоторого
последовательного выполнения этих же транзакций.
Между транзакциями могут существовать следующие виды конфликтов:
Транзакция 2 пытается изменять объект, измененный незакончившейся Транзакцией 1 (W-W — конфликт);
Транзакция 2 пытается изменять объект, прочитанный незакончившейся Транзакцией 1 (R-W — конфликт);
Транзакция 2 пытается читать объект, измененный незакончившейся Транзакцией 1 (W-R — конфликт).
Слайд 108Захват и освобождение объекта
Выделяются два основных режима захватов:
совместный режим
— S (Shared), означающий разделяемый захват объекта и необходимый для
выполнения операции чтения объекта;
монопольный режим — X (exclusive), означающий монопольный захват объекта и необходимый для выполнения операций записи, удаления и модификации.
Слайд 109В контексте реляционных баз данных возможны следующие варианты:
файл - физический
(с точки зрения базы данных) объект, область хранения нескольких отношений
и, возможно, индексов
таблица - логический объект, соответствующий множеству записей данного отношения;
страница данных - физический объект, хранящий записи одного или нескольких отношений, индексную или служебную информацию;
запись - элементарный физический объект базы данных.
Потенциально возможные объекты для захвата
Слайд 110Транзакция — это законченный блок обращений к базе данных и
некоторых действий над ней, для которого гарантируется выполнение четырех условий,
так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability):
атомарность — операции транзакции образуют неразделимый атомарный блок с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию
согласованность — по завершении транзакции все задействованные объекты находятся в согласованном состоянии
изолированность — одновременный доступ транзакций различных приложений к разделяемым объектам координируется таким образом, чтобы эти транзакции не влияли друг на друга
долговременность — все изменения данных, осуществленные в процессе выполнения транзакции, не могут быть потеряны
Правила ACID
Слайд 112Основные особенности распределенных баз данных
Репликация
Удаленные транзакции
Распределенные запросы
Слайд 113OLTP
(Online Transaction Processing)
транзакционная система
обработка транзакций в реальном времени
Способ организации
БД, при котором система работает с небольшими по размерам транзакциями,
но идущими большим потоком, и при этом клиенту требуется от системы минимальное время отклика.
Слайд 114Типовой запрос к OLTP-системе:
«Каков был уровень импорта товара в январе
2012 года?»
Невозможны аналитические запросы вида:
«Будет ли получена от этого прибыль?»
«Какие
клиенты наиболее выгодны с позиции таможенных платежей и почему?»
Слайд 115Использование OLTP
OLTP-системы оперативной обработки транзакций, характеризуются большим количеством изменений, одновременным
обращением множества пользователей к одним и тем же данным для
выполнения разнообразных операций - чтения, записи, удаления или модификации данных. Для нормальной работы множества пользователей применяются блокировки и транзакции. Эффективная обработка транзакций и поддержка блокировок входят в число важнейших требований к системам оперативной обработки транзакций.
OLTP-системы предназначены для ввода, структурированного хранения и обработки информации (операций, документов) в режиме реального времени.
Слайд 116Системы OLTP характеризуются:
поддержкой большого числа пользователей;
малым временем отклика на
запрос;
относительно короткими запросами;
короткими транзакциями;
участие в запросах небольшого
числа таблиц.
Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных.
Слайд 117Требования к OLTP
Сильно нормализованные модели данных;
При возникновении ошибки транзакция должна
целиком откатиться и вернуть систему к состоянию, которое было до
начала транзакции;
Обработка данных в реальном времени.
Слайд 119Хранилища данных
SQL
Каково среднее значение промежутка времени между выставлением счета и
оплатой его участником ВЭД в текущем и прошедшем году для
разных групп участников ВЭД ?».
Данные практически не обновляются, а лишь накапливаются.
Необходима хронологическая упорядоченность данных
При запросах импорта нет нужды учитывать «каждый контейнер», достаточно иметь агрегированную информацию за прошлый сезон/прошлый год/несколько лет
Слайд 123Хранилища данных
Основные операции над кубами данных:
Сечение
Вращение
Свертка
Детализация
Слайд 124OLAP
(Online Analytical Processing)
аналитическая обработка в реальном времени
технология обработки данных,
заключающаяся в подготовке суммарной (агрегированной) информации на основе больших массивов
данных, структурированных по многомерному принципу
это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным
Слайд 127Критерии OLAP
(FASMI)
Fast (Быстрый). Приложение OLAP должно обеспечивать минимальное время доступа
к аналитическим данным - в среднем порядка 5 секунд;
Analysis
(Анализ). Приложение OLAP должно давать пользователю возможность осуществлять числовой и статистический анализ;
Shared (Разделяемый доступ). Приложение OLAP должно предоставлять возможность работы с информацией многим пользователям одновременно;
Multidimensional (Многомерность);
Information (Информация). Приложение OLAP должно давать пользователю возможность получать нужную информацию, в каком бы электронном хранилище данных она не находилась.
Слайд 129Методы аналитической обработки данных в хранилище
Традиционные статистические методы регрессионного, факторного,
дисперсионного анализа, анализа временных рядов, а также методы, основанные на
искусственном интеллекте (нейронные сети, нечеткую логику, генетические алгоритмы, методы извлечения знаний)
Слайд 130Средства анализа данных в СППР на основе хранилищ данных используются
для решения следующих задач:
выделение в данных групп сходных по некоторым
признакам записей (кластерный анализ);
2) нахождение и аппроксимация зависимостей, связывающих анализируемые параметры или события, а также поиск параметров, наиболее значимых в терминах конкретной задачи;
3) поиск данных, существенно отклоняющихся от выявленных закономерностей (анализ аномалий);
4) прогнозирование развития объектов различной природы на основе хранящейся ретроспективной информации об их состоянии в прошлом.