DROP CONSTRAINT ограничение
Язык sql. Задание условий отбора в предложении where.
WHERE – выполняется фильтрация строк объекта в соответствии с заданными условиями. SELECT поле1, …, поле2, …,
FROM таблица1
WHERE условие;
Замечания:
Даты заключаются в символы "решетки" (#) и вводятся в SQL в американском формате: мм/дд/гг.
В условиях могут использоваться: операторы сравнения: = – равенство; < –меньше; > – больше; <= – меньше или равно; >= – больше или равно; <> – не равно. Более сложные предикаты могут быть построены с помощью логических операторов AND, OR или NOT, а также скобок,
используемых для определения порядка вычисления выражения.
В условиях отбора могут
применяться операторы принадлежности к диапазону или множеству или соответствия шаблону или значению NULL:
IN (NOT IN) – используется для сравнения некоторого значения со списком заданных значений;
BETWEEN (NOT BETWEEN) –используется для поиска значения внутри некоторого интервала, определяемого своими минимальным и максимальным значениями;
LIKE – можно выполнять сравнение выражения с заданным шаблоном, где допускается использование символов-заменителей:
* – вместо этого символа может быть подставлено любое
количество произвольных символов;
? – заменяет один символ строки;
[ ] – вместо символа строки будет подставлен один из возможных символов, указанный в этих ограничителях;
[!] – вместо соответствующего символа строки будут подставлены все символы, кроме указанных в
ограничителях;
IS NULL (IS NOT NULL) – для проверки пустого значения.
63.Язык sql. Предложения where и having.
Инструкция SQL состоит из нескольких частей, называемых предложениями. Каждое предложение в инструкции SQL имеет свое назначение.
WHERE –определяет условия отбора полей, которым должны соответствовать все записи, включаемые в результаты, это не обязательное поле.
Когда необходимо использовать данные для ограничения числа записей, возвращаемых запросом, можно использовать условия. Условие запроса похоже на формулу-это строка, которая может включать ссылки на поля, оператор и константа. Условие запроса является разновидностью выражение.
SELECT поле1, …, поле2, …,
полеN
FROM таблица1
WHERE условие;
Предложение WHERE имеет следующий базовый синтаксис:
WHERE поле = условие
Условие в предложении WHERE необязательно должно быть основано на равенстве значений. Можно использовать другие операторы сравнения, такие как «больше чем» (>) или «меньше чем» (<), например WHERE [Цена]>100.Более сложные предикаты могут быть построены с помощью логических операторов AND , OR или NOT , а также скобок. В условиях отбора могут применяться операторы принадлежности к диапазону или множеству или соответствия шаблону или значению NULL :
IN (NOT IN) – используется для сравнения некоторого значения со списком заданных значений;
BETWEEN (NOT BETWEEN) –используется для поиска значения внутри некоторого интервала, определяемого своими минимальным и максимальным значениями;
LIKE – можно выполнять сравнение выражения с заданным шаблоном, где допускается
использование символов-заменителей:
* – вместо этого символа может быть подставлено любое количество произвольных
символов;
? – заменяет один символ строки;
[ ] – вместо символа строки будет подставлен один из возможных символов, указанный в этих
ограничителях;
[!] – вместо соответствующего символа строки будут подставлены все символы, кроме указанных в ограничителях;
ISNULL (ISNOTNULL) – для проверки пустого значения.
Иногда необходимо объединить источники данных на основе полей с совпадающими значениями, но разными типами данных. Например, поле в одной таблице может иметь числовой тип данных, а сравнить его нужно с полем из другой таблицы, которое имеет текстовый тип данных.
Создать объединение между полями, имеющими разные типы данных, нельзя. Чтобы объединить данные их двух источников на основе значений полей с разными типами данных, нужно создать предложение WHERE, в котором одно поле используется с ключевым словом LIKE как условие отбора для другого поля.
Предположим, например, что необходимо использовать данные из Таблицы1 и Таблицы2, но только в том случае, когда данные в Поле1 (текстовое поле в Таблице1) совпадают с данными из Поля2 (числовое поле в Таблице2). Предложение WHERE будет выглядеть следующим образом:
WHERE поле1 LIKE поле2
HAVING – фильтрует группы строк объекта в соответствии с указанным условием. В инструкции SQL, которая содержит статистические функции, определяет условия, применяемые к полям, для которых в предложении SELECT вычисляется сводное значение. Не обязательное поле
Если необходимо указать условия для ограничения результатов, но поле, к которому их требуется применить, используется в статистической функции, предложение WHERE использовать нельзя. Вместо него следует использовать предложение HAVING. Предложение HAVING работает так же, как и WHERE, но используется для статистических данных.
Запрос может включать и предложение WHERE, и предложение HAVING, при этом условия отбора для полей, которые не используются в статистических функциях, указываются в предложении WHERE, а условия для полей, которые используются в статистических функциях, — в предложении HAVING.
При помощи HAVING отражаются все предварительно сгруппированные посредством GROUP BY блоки данных, удовлетворяющие заданным в HAVING условиям.
SELECT поле1, …, итоговая
функция AS имя для
вычисляемого поля
FROM таблица1
GROUP BY поля группировки
HAVING условие ;
64. Надежность систем обработки данных. Защита от потери информации. Восстановление базы данных.
Надежность
Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:
атомарность - при любых обстоятельствах будут либо выполнены все операции транзакции, либо не выполнена ни одна; целостность данных при завершении транзакции;
независимость - транзакции, инициированные разными пользователями, не вмешиваются в дела друг друга;
устойчивость к сбоям - после завершения транзакции, ее результаты уже не пропадут.
Механизм транзакций, поддерживаемый сервером баз данных, намного более эффективен, чем аналогичный механизм в настольных СУБД, так как сервер централизованно контролирует работу транзакций. Кроме того, в файл-серверной системе сбой на любой из рабочих станций может привести к потере данных и их недоступности для других рабочих станций, в то время, как в клиент-серверной системе сбой на клиенте, практически, никогда не сказывается на целостности данных и их доступности для других клиентов.
Безопасность
Сервер баз данных предоставляет мощные средства защиты данных от несанкционированного доступа, невозможные в настольных СУБД. При этом, права доступа администрируются очень гибко - до уровня полей таблиц. Кроме того, можно вообще запретить прямое обращение к таблицам, осуществляя взаимодействие пользователя с данными через промежуточные объекты - представления и хранимые процедуры. Так что администратор может быть уверен - никакой слишком умный пользователь не прочитает то, что ему читать не положено.
Восстановление базы данных — это функция СУБД, которая в случае логических и физических сбоев приводит базу данных в актуальное и консистентное состояние.
В случае логического отказа или сигнала отката одной транзакции журнал изменений сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции. Этот процесс называется откат (rollback).
В случае физического отказа, если ни журнал изменений, ни сама база данных не повреждены, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется сначала, но восстановление фактически продолжится с той точки, где оно прервалось.
В случае физического отказа, если журнал изменений доступен, но сама база данных повреждена, то должен быть выполнен процесс восстановления базы из резервной копии. После восстановления база будет находиться в состоянии на момент выполнения резервной копии. Для восстановления базы данных на момент отказа необходимо выполнить прогонку всех изменений, используя журнал изменений.
В случае физического отказа, если журнал изменений недоступен, но сама база данных не повреждена, восстановление возможно только на момент предыдущей контрольной точки.
В случае физического отказа, если повреждены как журнал изменений, так и сама база данных, то восстановление возможно только на момент выполнения резервной копии
65. Базы данных коллективного пользования. Компоненты модели клиент/сервер. Взаимодействие баз данных и приложений-клиентов.
По характеру хранения данных и обращения к ним БД могут быть персонального и коллективного пользования.
База данных коллективного пользования - это БД с распределенной обработкой данных. Сопровождение крупных БД коллективного пользования осуществляет администратор базы данных. Если работать с базой данных со своих локальных компьютеров через сеть могут одновременно несколько пользователей, получающими доступ со своих компьютеров к ней через сеть, то такая база данных называется сетевой (коллективного пользования). Преимущество сетевой базы в том, что всем пользователям не нужно иметь ее копию в своем компьютере, периодически рассылая и обращаясь за изменениями. Сделанное в базе данных изменение сразу становиться видно всем ее пользователям. БД коллективного пользования делятся на централизованные и распределенные. Централизованная база хранится в одном компьютере, распределенная состоит из нескольких частей, хранимых в разных компьютерах. Централизованные базы по схеме обработки информации делятся на 2 типа - файл-сервер и клиент-сервер.
Архитектура файл-сервер предполагает выделение одной из машин в качестве центральной (сервер файлов) - в ней хранится совместно используемая централизованная база данных. Все другие машины сети выполняют роль рабочих станций. По запросу с рабочей станции файлы базы данных передаются с файл-сервера на рабочую станцию, где и производится обработка данных. При большой интенсивности доступа к одним и тем же данным производительность системы может быть невысокой. Пользователи могут создавать на рабочих станциях свои локальные БД, которые используются ими монопольно.
В концепции клиент-сервер подразумевается, что центральный компьютер не только хранит данные, но и производит основной объем операций по их обработке. Запрос с рабочей станции порождает поиск и извлечение данных на сервере. Извлеченные данные (а не файлы базы данных) транспортируются по сети от сервера к клиенту.
Компоненты архитектуры клиент-сервер
Существуют три основных программных компонента архитектуры клиент-сервер:
· Программное обеспечение конечного пользователя.
· Промежуточное обеспечение.
· Программное обеспечение сервера.
К ПО конечного пользователя относятся средства разработки программ и генераторы отчетов, в том числе электронные таблицы и текстовые процессоры. С помощью этого ПО пользователи устанавливают связь с серверами, отправляют на рассмотрение серверу запросы и получают ответную информацию.
Промежуточное обеспечение предоставляет общий интерфейс для ПО конечного пользователя и сервера, проникающий сквозь сквозь слои GUI (графический интерфейс пользователя), операционную систему, вычислительной сети и собственных драйверов базы данных с помощью общих вызовов. Для завершения операции сервер базы данных выполняет запрос и передает клиенту затребованные данные для обработки их программой клиента.
Под ПО сервера подразумевается операционная система и конкретный сервер базы данных, используемый для обработки запросов клиентской части информационной системы.
Серверы баз данных занимаются не только обслуживанием данных. В них предусмотрены также механизмы блокировок и элементы управления многопользовательским доступом, которые обеспечивают защиту данных от опасности параллельного доступа. Кроме этого, серверу баз данных приходится ограждать данные от несанкционированного доступа, оптимизировать запросы к базе данных, обеспечивать кэширование и предоставлять место для размещения словаря данных.
Взаимодействие клиентской и серверной частей приложения осуществляется через сеть - локальную или глобальную. При этом с точки зрения клиента и сервера взаимодействие осуществляется прозрачно, соответственно сетевой компонент здесь включает в себя совокупность необходимого сетевого оборудования, набор программных технологий, обеспечивающих передачу данных между узлами сети, а также собственно протокол или протоколы для обмена запросами и результатами их выполнения.
Компонент визуализации прикладной задачи осуществляет ввод информации пользователем с помощью тех или иных средств, а также вывод информации на экран и печать. Компонент визуализации для архитектуры клиент-сервер всегда исполняется на рабочем месте пользователя (поскольку должен же он наблюдать какие-либо результаты работы программы).
Компонент прикладной логики решает собственно ту или иную задачу, связанную с обработкой данных в той или иной предметной области. Этот компонент может быть распределен между клиентской и серверной частью различным образом в зависимости от применяемой модели.
Компонент хранения базы данных осуществляет физические операции, связанные с хранением данных, чтением информации из БД и записью в нее. В архитектуре клиент-сервер этот компонент всегда выполняется на сервере.
66. Автоматизация. Сервер приложений. Клиент приложений.
Автоматизация – одно из наиболее важных средств технологии ActiveX, позволяющее программно управлять объектами из других приложений. И это основное средство, с помощью которого можно интегрировать функциональные возможности различных приложений.
При интеграции двух приложений одно предоставляет свои объекты для использования, а другое использует объекты первого приложения. Приложение, объекты которого доступны для других приложений, называется сервером автоматизации (иногда его ещё называют компонентом). Приложение, которое использует объекты другого приложения, называется клиентом (или контроллером) автоматизации. Объекты, которые доступны для других приложений, называют объектами автоматизации.
Через объекты автоматизации приложение-сервер открывает доступ другим программам к тем своим функциям, которые могут быть им полезны. Это позволяет разработчикам ускорить процесс разработки своих приложений, благодаря использованию готовых функций сервера. Объекты приложения-сервера образуют библиотеку объектов, которая может быть подключена к приложению-клиенту. Приложение-клиент использует объекты приложения-сервера путем доступа к их свойствам и методом. При этом он имеет все те возможности, которые есть у сервера автоматизации.
67. Особенности и назначение sql server.
Сервер БД выполняет обслуживание и управление базой данных и отвечает за целостность и сохранность данных, а также обеспечивает операции ввода-вывода при доступе клиента к информации.
Microsoft SQL Server - одна из наиболее мощных систем работы с базами данных в архитектуре "клиент-сервер". В своем составе система имеет средства создания баз данных, работы с информацией баз данных, перенесения данных из других систем и в другие системы, резервного копирования и восстановления данных, развитую систему транзакций, систему репликации данных, реляционную подсистему для анализа, оптимизации и выполнения запросов клиентов, систему безопасности для управления правами доступа к объектам базы данных и пр. Система не содержит средств разработки клиентских приложений.
68. Язык transact sql.
Transact-SQL (T-SQL) — процедурное расширение языка SQL, созданное компанией Microsoft (для Microsoft SQL Server) и Sybase (для Sybase ASE).
SQL был расширен такими дополнительными возможностями как:управляющие операторы,
локальные и глобальные переменные,
различные дополнительные функции для обработки строк, дат, математики и т. п.,
поддержка аутентификации Microsoft Windows
Язык Transact-SQL является ключом к использованию MS SQL Server. Все приложения, взаимодействующие с экземпляром MS SQL Server, независимо от их реализации и пользовательского интерфейса, отправляют серверу инструкции Transact-SQL.
Временные переменные, таблицы.
Довольно часто приходится слышать то, что различие между табличными переменными и временными таблицами заключается в том, что первые всегда хранятся в памяти, а последние в tempdb. Но на самом деле это миф. И временные таблицы, и табличные переменные, создаются в tempdb (так как обязательно должно быть постоянное хранилище данных, на случай, если памяти всё же не хватит).
Убедиться в том, что табличные переменные создаются в tempdb так же, как и временные таблицы, можно проделав вот такой опыт:
SELECT COUNT(*) FROM tempdb.sys.tables; GO DECLARE @table_var table(id int); SELECT COUNT(*) FROM tempdb.sys.tables; GO
Результат выполнения 2-го COUNT(*) будет на 1 больше чем первого. Следовательно, в результате объявления табличной переменной в tempdb создалась таблица, и в способе хранения данных они не особо отличаются. Давайте теперь посмотрим на отличия табличных переменных от временных таблиц:
Преимущества:
Автоматически очищаются в конце функции, хранимой процедуры или пакета, где они были определены
При использовании в хранимых процедурах табличных переменных приходится прибегать к рекомпиляциям реже, чем при использовании временных таблиц
Транзакции с использованием табличных переменных продолжаются только во время процесса обновления соответствующих табличных переменных. Поэтому табличные переменные реже подвергаются блокировке и требуют меньших ресурсов для ведения журналов регистрации
Табличной переменной можно присвоить результат выполнения табличной функции, для повторного использования результатов
Табличную переменную можно передавать как параметр в хранимую процедуру (SQL Server 2008)
Недостатки:
На табличных переменных нельзя создавать некластерные индексы
Табличные переменные не содержат статистику
Табличные переменные не могут использоваться в INSERT EXEC или SELECT INTO
Запросы, изменяющие табличные переменные, не создают параллельных планов выполнения запроса
Общие рекомендации Microsoft, относительно использования табличных переменных таковы: "Используйте их везде, где это возможно, кроме тех случаев, когда у вас хранятся значительные объёмы данных, и присутствует повторное использование таблиц". Кроме того, отмечено, что сценарии использования могут быть разными, и в каждом конкретном случае нужно смотреть и пробовать что вам больше подходит.
Пользовательские функции.
(Упоминание на странице 80 и 81 первоначального варианта методички)
Пользовательская функция - функция, созданная пользователем Функция, как и процедура, - изолированный фрагмент кода, способный включать в себя произвольное число операторов. И, так же как и процедуры, функции можно добавлять в модули. В модуле может сосуществовать рядом любое количество процедур и функций. Главное отличие функции от процедуры заключается в том, что функция формирует конечный результат.
Функция записывается в формате
Function ИмяФункции(Аргументы) [As Тип]
Инструкции
End Function
Function, End и As - ключевые слова. Остальные слова формата должны быть заменены на слова пользователя.
ИмяФункции - слово, отражающее назначение функции и отличающееся от имен других функций. Оно не должно содержать пробелов и спецзнаков.
Аргументы - список аргументов, служащих для передачи значений из точки вызова в функцию. Список может быть пустым, но круглые скобки после имени функции обязательны.
Для создания новой функции необходимо написать слово Function , имя функции и нажать Enter. При этом осуществится переход к новой (пустой) строке. После имени функции автоматически вставляются круглые скобки. Вслед за пустой появляется строка “End Function”.
Тип - тип результата. Квадратные скобки свидетельствуют о том, что конструкция Asтип необязательна. Если она отсутствует, то значение функции имеет тип Variant (любой тип).
Инструкции - последовательность инструкций языка VBA. На одной строке можно разместить несколько инструкций, разделив их двоеточиями.
Пример
Function Завтра()
Завтра = “Завтра будет “ & (Date + 1) End Function
Функция Завтра аргументов не имеет. Еe результат имеет тип Variant. В теле процедуры (между первой и последней строкой) присутствует всего одна инструкция - инструкция присваивания. Признаком присваивания служит знак равенства. Как и в других языках программирования, справа от знака присваивания располагается выражение. Выражение вычисляется и его результат присваивается переменной левой части.
В выражении с помощью оператора & осуществляется конкатенация (сцепление, соединение) двух строк. Первая строка - “Завтра будет”, а вторая - выражение в круглых скобках. Результат вычисления выражения – дата. Функция Date вычисляет текущую дату и прибавляет один день. VBA преобразует полученную дату в строку и осуществляет конкатенацию.
71.Хранимые процедуры.
Хранимые процедуры (stored procedures) - являются механизмом, с помощью
которого можно создавать подпрограммы, работающие на сервере и управляемые его
процессами. Хранимые процедуры могут возвращать значения, в них можно передавать значения и получать результаты, не обязательно имеющие отношение к рабочей таблице.
Хранимые процедуры используют для добавления записей в таблицу, создания таблицы и вставки данных с помощью оператора SELECT (insert into), удаления и обновления данных.
При разработке хранимых процедур можно использовать:
1. встроенные функции:
функции просмотра конфигурации;
функции для работы с курсорами;
функции работы с датой и временем;
математические функции;
функции метаданных;
функции подсистемы безопасности;
строковые функции;
системные функции;
статистические функции;
функции для работы с типами данных image, text и ntext.
2. оператор SELECT:
с вычисляемыми полями;
с операторами сравнения ;
с фразой BETWEEN;
с фразой IN;
с фразой LIKE;
с сортировкой по алфавиту;
с фразой TOP;
с использованием агрегатных функций;
с фразой GROUP BY;
с фразой HAVING;
с использованием функций для работы со строками;
3. управляющие конструкции и циклы:
IF ... ELSE (IF EXISTS...);
BEGIN ... END;
WHILE;
CASE;
4. локальные и глобальные переменные;
5. возвращать код завершения (RETURN).
Через хранимые процедуры осуществляются правила ограничения целостности
данных и алгоритмы обработки данных. Располагаясь на сервере, по сети передается только вызов процедуры и, возможно, необходимые ей параметры. Это может значительно снизить нагрузку на сеть, процедура выполняется под присмотром сервера, который сам заботится о допустимости и устойчивости к ошибкам.
Технологии разработки хранимых процедур подобны пользовательским функциям,
только выбирается объект Programmability Stored Procedures New .
72.Триггеры.
Одним из базовых требований к проектируемой базе данных является требование ее логической независимости от приложений, которые с ней работают. Все ограничения целостности должны задаваться не логикой работы приложения, а определяться на уровне базы данных. Цель механизма триггеров - обеспечение целостности базы данных и обеспечение логической независимости базы данных.
Триггер - это выполняемый модуль, привязанный к объекту базы данных – чаще всего к таблицам и событию, связанному с этим объектом (insert, update или delete). Триггер вызывается неявно при возникновении события над этим объектом. Триггер получает всю информацию о выполняемых пользователем изменениях в таблице. Разработчик реализовывает в триггере необходимые проверки и изменения данных в других таблицах базы данных. Когда пользователь начинает изменение данных, сервер автоматически начинает транзакцию, в которой и выполняется триггер. В теле транзакции разработчик может реализовывать произвольные алгоритмы, которые могут выполнять как проверку, так и изменения данных. В конце концов, работа триггера сводится либо к фиксации, либо к откату транзакции, которая осуществляет изменение данных. Если выполняется откат транзакции, то попытка пользователя изменить данные отменяется. При этом также отменяются все исправления, сделанные самим триггером в различных таблицах (если они выполнялись). При фиксации транзакции производится как фиксирование изменений, выполненных пользователем, так и изменений, сделанных самим триггером. Триггер хранится в базе данных наряду с таблицами, представлениями, хранимыми процедурами.
При вызове триггеров используются две специальные таблицы: таблица удаления (deleted table) и таблица добавления (inserted table). Они используются для проверки операторов модификации данных и создания условий для работы триггеров. В таблице deleted сохраняются копии строк, которые удаляются операторами update или delete. В таблице inserted сохраняются копии строк, которые вставляются операторами insert или update. Пользователь не может непосредственно изменять данные в этих таблицах, но может использовать находящуюся в них информацию для проверки последствий выполнения
операторов insert, update или delete.
При определении триггера задаются его имя и имя таблицы, при обращении к которой срабатывает триггер, момент срабатывания триггера и действие, выполняемое при срабатывании триггера (операторы Insert, Delete, Update, Execute procedure).
«Каскадирующий» триггер: при изменении кода специальности в таблице Специальность обновляются строки со старым кодом на новое значение в таблице Предмет:
CREATE TRIGGER tr_up ON Специальность
FOR UPDATE
AS
DECLARE @sschar(20), @dd char(20)
SELECT @dd=Спец FROM deleted
SELECT @ss=Спец FROM inserted
UPDATE Предметы SET Спец=@ss
WHERE Спец=@dd
73.Многомерные хранилища данных. Модели кубов данных.
Основное назначение многомерных хранилищ данных (МХД) — поддержка систем, ориентированных на аналитическую обработку данных, поскольку такие хранилища лучше справляются с выполнением сложных нерегламентированных запросов.
Многомерная модель данных, лежащая в основе построения многомерных хранилищ данных, опирается на концепцию многомерных кубов, или гиперкубов. Они представляют собой упорядоченные многомерные массивы, которые также часто называют OLAP-кубами (аббревиатура OLAP расшифровывается как On-LineAnalyticalProcessing — оперативная аналитическая обработка). Технология OLAP представляет собой методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов.
В основе многомерного представления данных лежит их разделение на две группы — измерения и факты.
Измерения — это категориальные атрибуты, наименования и свойства объектов, участвующих в некотором бизнес-процессе. Значениями измерений являются наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т.д. Измерения могут быть и числовыми, если какой-либо категории (например, наименованию товара) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора. Измерения качественно описывают исследуемый бизнес-процесс.
Факты — это данные, количественно описывающие бизнес-процесс, непрерывные по своему характеру, то есть они могут принимать бесконечное множество значений. Примеры фактов — цена товара или изделия, их количество, сумма продаж или закупок, зарплата сотрудников, сумма кредита, страховое вознаграждение и т.д.
Структура многомерного куба
Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например Дата, Товар, Покупатель. По осям будут откладываться значения измерений — даты, наименования товаров, названия фирм-покупателей, ФИО физических лиц и т.д.
В такой системе каждому набору значений измерений (например, «дата — товар — покупатель») будет соответствовать ячейка, в которой можно разместить числовые показатели (то есть факты), связанные с данным набором. Таким образом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь.
Принцип организации многомерного куба поясняется на рис. 5. В ячейке 1 будут располагаться факты, относящиеся к продаже цемента ООО «Спецстрой» 3 ноября, в ячейке 2 — к продаже плит ЗАО «Пирамида» 6 ноября, а в ячейке 3 — к продаже плит ООО «Спецстрой» 4 ноября.
Многомерный
взгляд на измерения Дата, Товар и
Покупатель представлен на рис. 6. Фактами
в данном случае могут быть Цена,
Количество, Сумма. Тогда выделенный
сегмент будет содержать информацию о
том, сколько плит, на какую сумму и по
какой цене приобрела фирма ЗАО «Строитель»
3 ноября.
Таким
образом, информация в многомерном
хранилище данных является логически
целостной. Это уже не просто наборы
строковых и числовых значений, которые
в случае реляционной модели нужно
получать из различных таблиц, а целостные
структуры типа «кому, что и в каком
количестве было продано на данный момент
времени». Преимущества многомерного
подхода очевидны.
Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД.
Возможности построения аналитических запросов к системе, использующей МХД, более широки.
В некоторых случаях использование многомерной модели позволяет значительно уменьшить продолжительность поиска в МХД, обеспечивая выполнение аналитических запросов практически в режиме реального времени. Это связано с тем, что агрегированные данные вычисляются предварительно и хранятся в многомерных кубах вместе с детализированными, поэтому тратить время на вычисление агрегатов при выполнении запроса уже не нужно.
В принципе, OLAP-куб может быть реализован и с помощью обычной реляционной модели. В этом случае имеет место эмуляция многомерного представления совокупностью плоских таблиц. Такие системы получили название ROLAP — Relational OLAP.
Использование многомерной модели данных сопряжено с определенными трудностями. Так, для ее реализации требуется больший объем памяти. Это связано с тем, что при реализации физической многомерности используется большое количество технической информации, поэтому объем данных, который может поддерживаться МХД, обычно не превышает нескольких десятков гигабайт. Кроме того, многомерная структура труднее поддается модификации; при необходимости встроить еще одно измерение требуется выполнить физическую перестройку всего многомерного куба. На основании этого можно сделать вывод, что применение систем хранения, в основе которых лежит многомерное представление данных, целесообразно только в тех случаях, когда объем используемых данных сравнительно невелик, а сама многомерная модель имеет стабильный набор измерений.
74. витрины данных — множество тематических баз данных (БД), содержащих информацию, относящуюся к отдельным аспектам деятельности организации.
На сегодняшний день предложено множество архитектур, опишем пять наиболее распространенных:
независимые витрины данных (independentdatamarts);
шинавзаимосвязанныхвитринданных(data-mart bus architecture with linked dimensional data marts);
архитектура «звезда» (hub-and-spoke);
централизованное хранилище данных (centralizeddatawarehouse);
федеративная архитектура (federatedarchitecture).
Независимые витрины данных
Нередка ситуация, когда каждое подразделение компании разрабатывает свою собственную витрину данных. Все эти витрины удовлетворяют потребностям, для которых создавались, но при этом не зависят друг от друга и не обеспечивают единого представления о ситуации в компании. В них несогласованно заданы данные, используются разные измерения и показатели, а следовательно, анализ данных между витринами затруднен.
Шина взаимосвязанных витрин данных
Предложена Ральфом Кимбэллом (RalphKimball).
Создание такой архитектуры начинается с анализа требований для конкретных бизнес-процессов, таких как заказы, клиенты, счета и проч. Первая витрина данных строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах.
Последующие витрины данных разрабатываются с использованием этих измерений, что в результате приводит к созданию логически интегрированных витрин.
Архитектура «Звезда»
Продвигается известным экспертом в области хранилищ данных Билом Инмоном (BillInmon). Представляет собой централизованное хранилище данных с зависимыми витринами данных.
Эта архитектура разрабатывается на основе корпоративного анализа требований к данным. Тут важно обратить внимание на создание масштабируемой и поддерживаемой инфраструктуры. На основе использования корпоративного представления данных выполняется итеративная разработка архитектуры, при этом вовлекается одна предметная область за другой. Детальные данные хранятся в нормализованной форме в хранилище данных. Зависимые витрины данных получают данные из хранилища данных.
Зависимые витрины данных разрабатываются для подразделений или конкретных функциональных областей, целей (например, для datamining) и могут быть как нормализованными, так и денормализованными, либо в виде любой агрегированной структуры данных. Большинство пользователей выполняет запросы на зависимых витринах данных.
Иногда архитектуру hub-and-spoke называют подходом «сверху вниз», а шину витрин данных — подходом «снизу вверх». В этом есть некоторый смысл, так как первая ориентирована на исходно заданную инфраструктуру и процессы, а шина витрин данных — на разработку проекта, в котором решаются критические бизнес-задачи.
Подходы «снизу вверх» и «сверху вниз» со временем сближаются. Сторонники первого из них утверждают важность поэтапной разработки и достижения «маленьких побед». Приверженцы второй методологии считают важным наличие корпоративного плана для интеграции поэтапно создаваемых витрин данных.
Централизованное хранилище данных (без зависимых витрин)
Эта архитектура похожа на архитектуру «звезда» за исключением отсутствия зависимых витрин данных. Хранилище данных содержит детальные данные, некоторое количество агрегированных данных и логические представления. Запросы и приложения выполняются как на реляционных данных, так и на многомерных представлениях.
Федеративная архитектура
В этой архитектуре используются уже существующие структуры поддержки принятия решений (операционные системы, витрины и хранилища данных). Данные извлекаются из перечисленных систем на основе бизнес-требований. Данные логически или физически интегрируются с помощью метаданных, распределенных запросов и других методов. Эта архитектура является практическим решением для компаний, которые уже пользуются аналитическими средствами и не хотят от них отказываться.
75. Понятие мер, измерений, иерархий и агрегирования данных
Меры куба — функции, которые каждой точке пространства ставят в соответствие данные.
Измерения куба — набор доменов, по которым создается многомерное пространство.
Иерархичность данных — одно из важнейших свойств многомерных кубов. Иерархии призваны добавлять новые уровни в аналитическое пространство пользователя. Самым распространенным примером иерархии является ''день-неделя-месяц-год''.
Агрегатами называют агрегированные по определенным условиям исходные значения показателей. Обычно под агрегацией понимается любая процедура формирования меньшего количества значений (агрегатов) на основании большего количества исходных значений. В дальнейшем под терминами агрегирование и агрегация будем понимать исключительно процесс суммирования данных.