Логическая многомерная модель

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

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

21.Системы оперативной аналитическая обработка (OLAP). Сравнение архитектур построения OLAP. Использование технологии OLAP.

Архитектуры olap

При анализе архитектур OLAP следует принять во внимание два основных технологических решения: размещение данных и способ обработки многомерных данных (выполнения многомерных запросов). Данные могут размещаться в реляционной СУБД, в многомерной СУБД, или локально в файлах. Запросы могут выполняться с помощью SQL, серверным многомерным процессором, или клиентским многомерным процессором. Всего существует 9 комбинаций решений, из которых смысл имеют только 6, вынесенных в таблицу (Error: Reference source not found). В эту таблицу также вписаны названия продуктов, использующих соответствующую архитектуру.

Другой часто используемой классификацией архитектур OLAP является их подразделение на: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP), HOLAP (Hybrid OLAP), и DOLAP (Desktop OLAP). Эта классификация соотносится с описанной выше следующим образом:

ROLAP – квадраты 1, 2, 3 .

MOLAP – квадраты 4, 5 .

Desktop OLAP – квадрат 6 .

Hybrid OLAP – продукты, названия которых в таблице выделены курсивом.

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

О преимуществах и недостатках различных архитектур Реляционное хранилище

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

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

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

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

Использование технологии OLAP

Функциональность можно разбить на OLAP-серверы и OLAP-клиенты. OLAP-серверы обеспечивают создание и наполнение кубов, а также выполнение многомерных запросов и передачу многомерных данных клиенту, реализуя при этом какой-то из интерфейсов обмена, который может быть стандартным, либо принятым у одного разработчика OLAP-решений. OLAP-клиенты предоставляют возможность работы с многомерными данными, их визуализации и пользовательской обработки. Они подразделяются на группы в зависимости от функциональной нагруженности. Самым простым OLAP-клиентом является такой, который не может работать без OLAP-сервера. Такой клиент образует интерактивную оболочку для доступа к данным OLAP-сервера (примером является Analysis Manager из набора MS SQL Server 2000 Analysis Services).

Блок 2.

22.Основы SQL. Средства определения схемы БД. Типы данных и домены. Общий формат оператора создания таблиц. Ограничения целостности. Первичные и уникальные (альтернативные) ключи. Внешний ключ и определение ссылочной целостности. Требования к значениям столбцов. Изменение объявлений таблицы. Удаление таблицы.

Общие сведения

Базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции. В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL.

SQL - Structured Query Language

(иногда понимается как Standard Query Language).

Язык SQL стал фактически стандартным языком доступа к базам данных. Все СУБД, претендующие на название "реляционные", реализуют тот или иной диалект SQL. Многие нереляционные системы также имеют в настоящее время средства доступа к реляционным данным. Целью стандартизации является переносимость приложений между различными СУБД.

• В настоящее время, ни одна система не реализует стандарт SQL в полном объеме. Кроме того, во всех диалектах языка имеются возможности, не являющиеся стандартными. Таким образом, можно сказать, что каждый диалект - это надмножество некоторого подмножества стандарта SQL. Это затрудняет переносимость приложений, разработанных для одних СУБД в другие СУБД.

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

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

• Язык SQL является реляционно полным. Это означает, что любой оператор реляционной алгебры может быть выражен подходящим оператором SQL.

Средства определения схемы БД

DDL (Data Definition Language)

• CREATE SCHEMA - создать схему базы данных

• DROP SHEMA - удалить схему базы данных

• CREATE TABLE - создать таблицу

• ALTER TABLE - изменить таблицу

• DROP TABLE - удалить таблицу

• CREATE DOMAIN - создать домен

• ALTER DOMAIN - изменить домен

• DROP DOMAIN - удалить домен

• CREATE VIEW - создать представление

• DROP VIEW - удалить представление

Создание БД CREATE { DATABASE | SHEMA } “<имя_файла>”

{ USER “имя_пользователя” [PASSWORD “пароль”] ]

[ PAGE_SIZE [=] целое ]

[ LENGTH [=] целое [PAGE [S] ] ] Размер страницы БД в байтах

[ DEFAULT CHARASTER SET набор_символов ] Определяет используемый в БД набор символов

[ <вторичный_файл> ];

<вторичный файл> = FILE “<имя_файла>” [<файлов_информ>]

[<вторичный файл>] Имя одного или нескольких файлов, в которых располагается БД

<файлов_информ> = LENGTH [ = ] целое [ PAGE [S] ] | Длина файла в страницах. По умолчанию 50. Мин 50.

STARTING [AT [PAGE]] целое <файлов_информ> Если БД занимает несколько файлов, предложение определяет с какой страницы располагается БД в указанном файле

Типы данных:

• Символьные (CHAR, VARCHAR)

• Целочисленные (INTEGER, SMALLINT)

• Вещественные (FLOAT, DOUBLE PRECISION)

• Фиксированно-десятичные значения (DECIMAL, NUMERIC)

• Значения типа даты (DATE)

• Двоичные (BLOB)

Понятие домена: CREATE DOMAIN домен [AS] <тип данных>

[DEFAULT {литерал} | NULL | USER]

[NOT NULL] [CHECK (<Ограничение домена>) ]

Типы данных и домены

< Ограничение домена >= {

VALUE <оператор> <значение>

| VALUE [NOT] BETWEEN <значение1> AND <значение2>

| VALUE [NOT] LIKE <значение1> [ESCAPE <значение2>]

| VALUE [NOT] IN <значение1> [, <значение2> …])

| VALUE IS [NOT] NULL

| VALUE [NOT] CONTAINING <значение>

| < Ограничение домена >

| NOT < Ограничение домена >

| < Ограничение домена > OR | < Ограничение домена >

| < Ограничение домена > AND < Ограничение домена >

};

Где <оператор> = { = | < | > | <= | >= | != | !< | !> | <> }

Общий формат оператора создания таблиц CREATE TABLE ИмяТаблицы

( <опр_столбца>

[, <опр_столбца> | <ограничение> …] );

<опр_столбца> - определение столбца таблицы.

<опр_столбца> = столбец { тип_данных | COMPUTED [ BY ]

(<выражение>) | домен }

[ DEFAULT {литерал | NULL | USER } ]

[NOT NULL] [<огранич_столбца>]

Ограничения целостности

Ограничения целостности бывают двух видов:

• Накладываемые на отдельный столбец;

• Накладываемые на всю таблицу.

При наложении на отдельный столбец :

TOVAR VARCHAR(20) NOT NULL PRIMARY KEY, …

При наложении ограничений на таблицу :

CREATE TABLE … (

TOVAR VARCHAR(20) NOT NULL…

PRIMARY KEY (TOVAR)

);

Первичные и уникальные (альтернативные) ключи

На уровне столбцов:

CREATE TABLE VLADLIM (

KODVLAD INTEGER NOT NULL PRIMARY KEY,

NAZVVLAD VARCHAR(50) NOT NULL UNIQUE

);

На уровне таблицы:

CREATE TABLE VLADLIM (

KODVLAD INTEGER NOT NULL,

NAZVVLAD VARCHAR(50) NOT NULL,

PRIMARY KEY ( KODVLAD),

UNIQUE ()NAZVVLAD)

);

Внешний ключ строится в дочерней таблице.

Описание формата:

[CONSTRAINT <имя ссылочной целостности>]

FOREIGN KEY ( <список столбцов внешнего ключа>)

REFERENCES <имя родительской таблицы>

[ <список столбцов родительской таблицы > ]

[ON DELETE { NO ACTION | CACADE | SET DEFAULT | SET NULL}]

[ON UPDATE { NO ACTION | CACADE | SET DEFAULT | SET NULL}]

Требования к значениям столбцов

- Столбец должен содержать сочетание символов USD

…. CHECK (STOLBEZ CONTAINING “USD”)

-Столбец должен начинаться с сочетания символов USD

…. CHECK (STOLBEZ STARTING WITH “USD”)

Изменение объявлений таблицы

Оператор ALTER TABLE позволяет:

1.Добавить определение нового столбца

ALTER TABLE <имя таблицы> ADD <определение столбца>;

2.Удалить столбец из таблицы

ALTER TABLE <имя таблицы> DROP <имя столбца1> [,<имя столбца2>…

3. Удалить атрибуты целостности таблицы или отдельного столбца

ALTER TABLE <имя таблицы> DROP <имя ограничения целостности>

4.Добавить новые ограничения целостности

ALTER TABLE <имя таблицы> ADD [CONSTRAINT <имя ограничения>]

<определение целостности>;

Удаление таблицы

Удаление таблицы целиком:

DROP TABLE <имя таблицы>

23.Основы SQL. Средства определения схемы БД. Общий формат оператора создания таблиц. Первичные и уникальные (альтернативные) ключи. Работа с индексами. Необходимость создания индексов.

Первая часть из 8.

Работа с индексами

Логическое разделение на ключи индексы

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

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

Индексы необходимо создавать в случае, когда по столбцу или группе столбцов:

• Часто производится поиск в БД;

• Часто строятся объединения таблиц;

• Часто производится сортировка;

• Часто производится сортировка;

Не рекомендуется строить индексы по столбцам или группам столбцов, которые:

• Редко используются для поиска, объединения , сортировки результатов запроса

• Часто меняют значение, что приводит к необходимости часто обновлять индекс и способно существенно замедлить скорость работы с БД;

• Содержит небольшое число вариантов значения

Логическое разделение на ключи индексы

Создание индексаCREATE [UNIQUE] ASC | DESC ]

INDEX ИмяИндекса ON ИмяТаблицы (столбец1 [, столбец2 … ]

UNIQUE – требует создания уникального индекса, не допускающего одинаковых значений индексных полей для разных записей таблицы.

ASC – указывает на необходимость сортировки полей по возрастанию (принят по умолчанию)

DESC - указывает на необходимость сортировки полей по убыванию

Определения всех индексов можно вывести оператором SHOW INDEX ;

Для конкретной таблицы SHOW INDEX <имя таблицы>;

Удаление существующих ключей DROP INDEX <имя индекса>;

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

Для улучшения показателя индекса необходимо выполнить его перестроение:

ALTER INDEX <имя индекса> DEACTIVATE;

ALTER INDEX <имя индекса> ACTIVATE;

• Нельзя перестроить индекс, если он используется в данный момент в запросах

• Нельзя перестроить индекс, созданный в результате создания первичного ключа, внешнего и уникального ключей.