
- •Тема 1 Понятие экономической информации и классификация экономических информационных систем Введение
- •1.1. Понятие экономической информации. Требования, предъявляемые к экономической информации
- •1.2. Классификация экономических информационных систем и принципы их проектирования
- •Тема 2 Введение в теорию баз данных
- •2.1. Определение базы данных. Особенности организации данных в базе данных
- •Тема 3 Структурные элементы информационной системы с базой данных
- •3.1. Компоненты информационной системы с бд
- •3.2. Трехуровневая архитектура субд
- •Тема 4 Виды моделей данных
- •4.1. Иерархическая модель данных
- •4.2. Сетевая модель данных
- •4.3. Реляционная модель данных
- •4.4. Многомерная модель данных
- •4.5. Объектно-ориентированная модель данных
- •Тема 5 Реляционный подход при построении информационно-логической модели: основные понятия
- •5.1. Реляционная модель данных. Основные понятия
- •5.2. Реляционная целостность данных
- •5.3. Индексирование
- •Тема 6 основны реляционной алгебры
- •6.1. Основные определения, относящиеся к реляционной алгебре
- •6.2. Традиционные операции над множествами (теоретико-множественные операторы)
- •Лекция 7 Нормализация отношений в реляционной модели
- •7.1. Понятие нормализация отношений. Цель нормализации. Типичные ограничения для реляционной модели данных. **
- •7.2. Вторая и третья нормальные формы
- •Вторая нормальная форма (2nf)
- •Третья нормальная форма (3nf)
- •Тема 7 субд. Основные свойства и функциональные возможности
- •7.1. Основные требования к обработке данных средствами субд
- •7.2. Языковые средства субд: яод и ямд
- •7.3. Основные понятия о сетевых, распределенных и объектных бд. Классификация субд
- •1. По типу поддерживаемой в субд модели данных: реляционная или объектно–ориентированная.
- •2. По типу использования ресурсов: локальные и сетевые.
- •3. По типу использования распределенных ресурсов: гомогенная, гетерогенная, мультибазовая.
- •4. По виду специализации: специализированные субд и субд общего назначения.
- •5. По типу платформы.
- •Рекомендуемая литература
- •Осень 2007 г.
4. По виду специализации: специализированные субд и субд общего назначения.
Специализированные СУБД разрабатываются специально для данной предметной области. Однако специализированные СУБД общего назначения могут использоваться для различных предметных областей, в разных информационных системах (ИС). Примером специализированных СУБД может быть СУБД в ИС по продаже железнодорожных билетов. Для большинства же современных ИС используются СУБД общего назначения. Так, например, в информационной системе 1С: Предприятие – СУБД MS SQL SERVER, в системе «Парус» – СУБД ORACLE.
5. По типу платформы.
Под платформой понимается комплекс аппаратно-программных средств для функционирования СУБД. Так используемая в учебном процессе СУБД Access устанавливается на локальных или клиентских IBM-подобных персональных компьютерах и может функционировать под управлением операционных систем семейства Windows. А сетевая СУБД MS SQL Server может использоваться под управлением Windows NT 7.0, Windows 2000 и выше. В качестве клиентов могут служить MS SQL Client или Access.
Хранилища данных
По определению, сформулированному автором термина "хранилище данных" (Data Warehouse) Биллом Инмоном, хранилище данных – это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений.
Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные БД предназначены для того, чтобы помочь пользователям выполнять повседневную работу, в то время как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций (транзакция – это последовательность операций над БД, рассматриваемая СУБД как единое целое), а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, осуществляется с помощью хранилища данных. Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.
Обычные БД чаще всего и являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например, статистических отчетов. Хранилища содержат заведомо избыточную информацию, однако, анализировать данные оперативных систем напрямую невозможно или очень затруднительно, а сложные аналитические запросы к оперативной информации тормозят текущую работу предприятия. Основными требованиями к хранилищам данных являются:
- поддержка высокой скорости получения данных из хранилища;
- поддержка внутренней непротиворечивости данных;
- возможность получения и сравнения так называемых срезов данных;
- наличие удобных утилит просмотра данных в хранилище;
- полнота и достоверность хранимых данных;
- поддержка качественного процесса пополнения данных.
Удовлетворять всем перечисленным требованиям в рамках одного и того же программного (или программно-аппаратного) продукта зачастую не удается. Поэтому для реализации хранилищ данных обычно применяются несколько программных продуктов, одни их которых представляют собой собственно средства хранения данных, другие – средства их извлечения и просмотра, третьи – средства их пополнения и т.д.
Системы поддержки принятия решений, как правило, обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном для восприятия и анализа виде. Для такого представления используется многомерная модель данных (см. п. 2.4.3) в виде гиперкуба. Оси гиперкуба содержат параметры, а ячейки включают зависящие от них агрегатные данные. Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных, пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных (см. рис. 2.15).
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP – это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, а в 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information – быстрый анализ разделяемой многомерной информации), основными требованиями которого являются:
- предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с.), пусть даже ценой менее детального анализа;
- возможность осуществления логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для пользователя виде;
- многомерное представление данных (концептуальное требование OLAP);
- возможность обращаться к любой необходимой информации независимо от ее объема и места хранения.
Будучи средством поддержки принятия решений OLAP работает не с оперативными базами данных, а с ретроспективными архивами, хранящими данные за значительный период времени. Это позволяет вычислить промежуточные данные, которые ускоряют анализ гигантских объемов информации [26].