- •Шехтман в. Е.
- •1. Базы данных и модели данных
- •1.1. Введение.
- •1.2. Файлы операционной системы
- •1.3. Пример базы данных.
- •1.4. Иерархическая модель данных
- •1.5. Сетевая модель данных
- •1.6. Инвертированные списки.
- •2. Введение в реляционную модель данных.
- •1.7. Реляционная модель данных
- •3. Реляционная алгебра
- •3.1. Теоретико-множественные операции.
- •3.2. Специальные операции ra
- •4. Нормализация данных
- •4.1. Полная декомпозиция.
- •Магазин товар ндс
- •Товар ндс
- •Магазин ндс
- •Товар ндс
- •Магазин товар ндс
- •4.2. Проблема дублирования данных.
- •1 Глобус 33-33-33
- •2 Глобус 33-33-33
- •4 Океан 77-77-77
- •4.3. Висячие записи.
- •Поставщик Тел
- •4.4. Проблемы, возникающие из-за неудачной структуры данных.
- •4.5. Пятая нормальная форма (5нф).
- •4.6. Функциональная зависимость.
- •4.7. Связь между фз и полной декомпозицией отношения.
- •4.8. Первая нормальная форма (1нф).
- •4.9. Вторая нормальная форма (2нф).
- •4.10. Третья нормальная форма (3нф).
- •4.11. Нормальная форма Бойса-Кодда (нфбк).
- •4.12. Многозначная зависимость.
- •4.13. Четвертая нормальная форма (4нф).
- •4.14. Пример нормализации.
- •4.15. Резюме. Нормальные формы.
- •5. Инфологическое моделирование.
- •5.1. Сущность и набор сущностей
- •5.2. Связи между сущностями.
- •5.3. Рекурсивная связь. Роли.
- •5.4. Множественные связи.
- •5.5. Суперсущности и производные сущности
- •5.6. Слабые наборы сущностей
- •5.7. Борьба с избыточнотью
- •5.8. Преобразование инфологической модели в физическую модель.
- •5.9. Пример инфологического моделирования.
- •6. Язык sql
- •6.1. История sql.
- •6.2. Структура sql.
- •6.3. Язык запросов
- •6.4. Простые запросы на выборку данных.
- •6.5. Агрегатные (групповые) функции.
- •6.6. Вложенные запросы
- •6.7. Внешние объединения
- •6.8. Изменение данных
- •Insert into r1 (o, fio, d) values (5, ‘Иванов’, ’бд’)
- •7. Представления.
- •8. Определение схемы базы данных и ограничений целостности
- •9. Транзакции
- •9.1. Свойства транзакций
- •9.2. Надежное хранение данных
- •9.3. Параллельное выполнение транзакций
- •9.3.1. Коллизия “пропавшие изменения” - lost update problem
- •9.3.2. Коллизия “промежуточные данные” - dirty read
- •9.3.3. Коллизия “Несогласованные данные” - unrepeatable read, inconsistent analysis
- •9.3.4. Коллизия “фантом” - phantom
- •9.4. Уровни изолированности
- •9.5. Тупики
- •10. Ограничение прав доступа в целях обеспечения безопасности
- •11. Физическая организация баз данных
- •11.1. Организация размещения данных.
- •11.2. Организация индексов
- •11.2.1. Поиск в бд.
- •11.2.2. Плотный индекс (индексно-прямые файлы).
- •11.2.3. Неплотный индекс (индексно-последовательные файлы).
- •11.2.4. Сбалансированные деревья.
- •11.2.5. Инвертированные списки.
- •12. Архитектура субд. Методы оптимизации запросов.
- •Логические преобразования запросов.
- •Преобразования запросов с изменением порядка реляционных операций.
- •13. Аналитические системы.
- •Анализ данных.
- •Хранилища данных
- •Типы ошибок
- •Способы реализации olap.
- •Требования к средствам реализации систем оперативной и аналитической обработки данных
- •Многомерная модель данных.
- •Разработка данных
- •14. Загружаемые процедуры.
- •In pr double precision)
- •If eof then leave Cl end if;
- •Insert into providers(code, name)
- •Values (nr.Codec, ‘*** новый поставщик ***’);
- •15.4. Модель сервера приложений (трёхзвенная архитектура, “тонкий клиент”)
- •Список литературы
- •15. Модели совместного доступа к бд
- •15.1. Файл-серверная модель.
- •15.2. Модель клиент-сервер с бизнес-логикой на клиенте.
- •15.3. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
Многомерная модель данных.
"Многомерный взгляд на данные наиболее характерен для пользователя, занимающегося анализом данных" - это утверждение Э. Кодда сегодня стало аксиомой. Однако, что такое многомерное представление, откуда появляется многомерность в трехмерном мире, чем оно отличается и чем оно лучше ставшего уже привычным реляционного представления? И, наконец, откуда среди нас появились люди, мыслящие в четырех и более измерениях, и как это им удается - именно эти вопросы возникают практически у любого, впервые столкнувшегося с этим утверждением.
На самом деле все сказанное в этом утверждении - чистая правда, и пользователю, занимающемуся анализом, действительно присуща многомерность мышления. Весь вопрос в том, что понимать под измерением.
Многомерный анализ - представление анализируемых фактов как функций от большого числа характеризующих их парамектров (измерений).
Двухмерное представление данных конечному пользователю.
Достаточно очевидно, что даже при небольших объемах данных отчет, представленный в виде двухмерной таблицы (Товар по оси Y и Время по оси X), нагляднее и информативнее отчета с реляционной построчной формой организации, представленной на табл. 1.
Товар |
Месяц |
Объем |
Бананы |
Июнь |
150 |
Бананы |
Июль |
130 |
Бананы |
Август |
120 |
Яблоки |
Июнь |
100 |
Яблоки |
Июль |
155 |
Яблоки |
Июль |
110 |
Таблица 1. Реляционное представление данных.
Так называемая сводная таблица (характерная форма представления при использовании многомерной модели) представлена на табл. 2.
|
Июнь |
Июль |
Август |
Бананы |
150 |
130 |
120 |
Яблоки |
100 |
155 |
110 |
Таблица 2. Сводная таблица.
А теперь представим, что у нас не 2 вида товара, а 150 и не 3, а 12 различных месяцев. В случае построчного (реляционного) представления мы получим отчет в 1800 строк (150х12), который займет много страниц. В случае же многомерного (в нашем случае двухмерного) представления мы получим достаточно компактную таблицу 150 на 12, которая вполне уместится на одной - двух страницах и которую, даже при таком объеме данных, можно реально оценивать и анализировать.
И когда говорится о многомерной организации данных, вовсе не подразумевается, что данные представляются конечному пользователю (визуализируются) в виде четырех или пятимерных гиперкубов. Это невозможно, да и пользователю более привычно и комфортно иметь дело с двухмерным табличным представлением и двухмерной бизнес - графикой.
Закономерен вопрос: "Где же здесь многомерность, откуда она берется и куда исчезает?" Ответ прост. Когда говорится о многомерности, имеется в виду не многомерность визуализации, а многомерное представление при описании структур данных и поддержка многомерности в языках манипулирования данными.
Многомерное представление при описании структур данных.
Основными понятиями, с которыми оперирует пользователь и проектировщик в многомерной модели данных, являются:
измерение (Dimension);
показатель или мера (Measure)
Измерение - это множество однотипных данных, образующих одну из граней гиперкуба. Например - Дни, Месяцы, Кварталы, Годы - это наиболее часто используемые в анализе временные измерения. Примерами географических измерений являются: Города, Регионы, Страны. Другой пример: Класс товаров, Группа товаров, Товар и т.д.
В многомерной модели данных измерения играют роль индексов, используемых для идентификации конкретных значений (мер), находящихся в ячейках гиперкуба.
В свою очередь, показатель - это поле (обычно цифровое), значения которого однозначно определяются фиксированным набором измерений. В зависимости от того, как формируются его значения, показатель может быть определен, как:
переменная (Variable) - значения таких показателей один раз вводятся из какого-либо внешнего источника или формируются программно и затем в явном виде хранятся в многомерной базе данных (МБД);
формула (Formula) - значения таких показателей вычисляются по некоторой заранее специфицированной формуле. То есть для показателя, имеющего тип формула, в БД хранятся не его значения, а формула, по которой эти значения могут быть вычислены.
Заметим, что это различие существует только на этапе проектирования и полностью скрыто от конечных пользователей.
В примере на рисунке каждое значение поля Объем продаж однозначно определяется комбинацией полей:
Товар;
Месяц продаж.
Но в реальной ситуации для однозначной идентификации значения показателя, скорее всего, потребуется большее число измерений, например:
Товар;
Магазин;
Время.
Измерения:
Время (Год) – явнварь, февраль, март, …
Магазин - N, M, …
Показатель:
Объем Продаж
Измерения и показатели (ячейки).
И в терминах многомерной модели речь будет идти уже не о двухмерной таблице, а о трехмерном гиперкубе:
первое Измерение - Товар;
второе Измерение - Магазин;
третье Измерение - Время;
на пересечении граней которого находятся значения показателя Объем продаж.
Заметим, что, в отличие от измерений, не все значения Показателей должны иметь и имеют реальные значения. Например, магазин N мог не торговать лимонами в определенный период, и в этом случае все значения показателя Объем продаж за этот период по лимонам будут иметь неопределенные значения.
Операции манипулирования измерениями
Формирование среза. Пользователя редко интересуют все потенциально возможные комбинации значений измерений. Более того, он практически никогда не работает одновременно сразу со всем гиперкубом данных. Подмножество гиперкуба, получившееся в результате фиксации значения одного или более измерений, называется срезом (Slice). Например, если мы ограничим значение измерения Товар константой "Бананы", то получим подмножество гиперкуба (в нашем случае - двухмерную таблицу), содержащее информацию об истории продаж этого товара различными магазинами в различные месяцы.
Операция Вращение. Изменение порядка представления (визуализации) измерений (обычно применяется при двухмерном представлении данных) называется вращением (Rotate). Эта операция обеспечивает возможность визуализации данных в форме, наиболее комфортной для их восприятия. Например, если аналитик первоначально вывел отчет, в котором Товары были перечислены по оси ординат, а Магазины по оси абсцисс, он может решить, что такое представление не наглядно, и поменять местами координаты (выполнить Вращение на 90 градусов).
Отношения и иерархические отношения. В нашем примере значения показателей определяются только тремя измерениями. На самом деле их может быть гораздо больше и между их значениями обычно существуют множество различных отношений типа "один ко многим".
Например, каждый Товар может принадлежать только одному Классу товаров, а каждому виду фруктов однозначно соответствует страна происхождения:
Магазин -> Район города
Товар -> Класс товара
Заметим, что для измерений, имеющих тип “время” (таких как День, Месяц, Квартал, Год), все отношения устанавливаются автоматически, и их не требуется описывать.
В свою очередь, множество отношений может иметь иерархическую структуру - иерархические отношения. Вот несколько примеров таких иерархических отношений:
День -> Месяц -> Квартал -> Год;
Партия товара ->Товар -> Подгруппа товара -> Класс товара
И часто более удобно не объявлять новые Измерения и затем устанавливать между ними множество отношений, а использовать механизм иерархических отношений. В этом случае все потенциально возможные значения из различных измерений объединяются в одно множество. Например, мы можем добавить к множеству значений измерения Товар ("Бананы", "Апельсины", "Яблоки", "Арбузы", “Капуста”, “Лосось”), значения Измерения Группа товара ("Фрукты", "Овощи", "Ягоды") и измерения Класс товара ("Фрукты-овощи", "Рыба") и затем определить между этими значениями отношение иерархии. Например:
Фрукты и овощи |
|
Рыба |
|
Фрукты |
Фрукты и овощи |
Овощи |
Фрукты и овощи |
Ягода |
Фрукты и овощи |
Бананы |
Фрукты |
Апельсины |
Фрукты |
Арбузы |
Ягода |
Операция Агрегации. С точки зрения пользователя, Товар, Группа товаров, Класс товаров являются точно такими же измерениями, как и Товар. Но каждое из них соответствует новому, более высокому уровню агрегации значений показателя Объем продаж. В процессе анализа пользователь не только работает с различными срезами данных и выполняет их вращение, но и переходит от детализированных данных к агрегированным, т.е. производит операцию агрегации (Drill Up). Например, посмотрев, насколько успешно в июне магазин 1 продавал бананы и яблоки, аналитик может захотеть узнать, как выглядит соотношение продаж этих товаров по фирме в целом.
Операция детализации. Переход от агрегированных к детализированным данным называется операцией детализации (Drill Down). Например, начав анализ на уровне фирмы в целом, пользователь может захотеть получить более точную информацию о работе конкретного магазина, или, узнав, что хорошо продаются фрукты, пользователь может захотеть узнать, какой конкретно фрукт внес основной вклад.
