- •Шехтман в. Е.
- •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. Модель клиент-сервер с бизнес-логикой на сервере субд (хранимые процедуры и триггеры) и частично на клиенте.
13. Аналитические системы.
В технологии баз данных всегда существовало два взаимодополняющих направления развития:
системы, ориентированные на оперативную (транзакционную или операционную) обработку данных;
системы, ориентированные на анализ данных - системы поддержки принятия решений.
До сих пор мы занимались системами, предназначенными исключительно для оперативной обработки данных. Именно для этого изначально и создавались и на это были ориентированы РСУБД, которые сегодня стали основным средством построения информационных систем самого различного масштаба и назначения. Они в основном предназначены для выполнения большого количества маленьких, простых запросов. Но, являясь высокоэффективным средством реализации систем оперативной обработки данных, РСУБД оказались менее эффективными в задачах аналитической обработки. В этих системах напротив требуется небольшое число сложных, требующих длительного времени запросов. Кроме того, анализ необязательно производить с учетом самых последних фактов – его целью обычно является выявление тенденций и зависимостей, составление прогноза а отнюдь не определение, сколько товара определенного вида имеется на конкретном складе в настоящий момент времени.
Анализ данных.
Конечно, средствами традиционных РСУБД и на основании данных, хранящихся в реляционной БД, можно построить заранее регламентированный аналитический отчет. Но, как правило, после просмотра такого отчета у пользователя (аналитика) появится не готовый ответ, а новая серия вопросов. Однако если бы ему захотелось получить ответ на новый вопрос, пришлось бы ждать его часы, а иногда и дни. Обычно каждый новый непредусмотренный заранее запрос должен быть сначала формально описан, передан программисту, запрограммирован и, наконец, выполнен. После того как аналитик получит долгожданный ответ, достаточно часто оказывается, что решение не могло ждать и оно уже принято, или что случается еще чаще, произошло взаимное непонимание и получен ответ на не совсем тот вопрос. Системы, которые позволяют эффективно проводить анализ, заключающийся в непредусмотренных заранее запросах сложной структуры персоналом, не обязанным разбираться в информационных технологиях (аналитики, руководители), называются системами OLAP (OnLine Analitical Processing – интерактивная аналитическая обработка). Напротив, традиционные задачи, которыми мы занимались до сих пор, принято относить к классу OLTP (OnLine Transaction Processing –транзакционная обработка в реальном масштабе времени).
Заметим, что многие критически необходимые для систем OLTP функциональные возможности, являются избыточными для задач OLAP. Например, в аналитических системах данные обычно загружаются достаточно большими порциями из различных внешних источников (оперативных БД, заранее подготовленных файлов, электронных таблиц). И, как правило, время и последовательность работ по загрузке, резервированию и обновлению данных могут быть спланированы заранее. Поэтому в таких системах обычно не требуются и, соответственно, не предусматриваются, например, развитые средства обеспечения целостности, восстановления и устранения взаимных блокировок и т.д. А это не только существенно облегчает и упрощает сами средства реализации, но и значительно снижает внутренние накладные расходы и, следовательно, повышает производительность при выполнении их основной функции - поиске и выборке данных.
В 1993 г. появилась программная статья одного из основоположников реляционного подхода Э. Ф. Кодда ("Providing OLAP to User Analysis: An IT Mandate"), в которой он сформулировал основные требования к средствам реализации OLAP и произвел анализ недостатков реляционного подхода, затрудняющих его использование в задачах, требующих сложной аналитической обработки данных.
Требования |
Описание |
Многомерное представление данных |
Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные. |
Равноправность всех измерений |
Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными). |
Поддержка операций на основе различных измерений |
Все многомерные операции (например, Агрегация) должны единообразно и согласованно применяться к любому числу любых измерений. |
Простота манипулирования данными |
Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс. |
Развитые средства представления данных |
Средства должны поддерживать различные способы представления данных. |
Неограниченное число измерений и уровней агрегации данных |
Не должно быть ограничений на число поддерживаемых Измерений. |
Динамическая обработка разреженных матриц |
Неопределенные значения должны храниться и обрабатываться наиболее эффективным способом. |
Прозрачность |
Пользователь не обязан знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся. |
Согласованная производительность |
Производительность практически не должна зависеть от количества Измерений в запросе. |
Поддержка многопользовательского режима работы с данными |
Средства должны обеспечивать возможность работать более чем одному пользователю. |
Основные требования к OLAP.
Пример OLAP: фирма оптовой торговли анализирует покупки клиентов с целью предсказать спрос на товары определенного вида в предстоящем сезоне.
