Пример проектирования структры хд

Лабораторная работа №1

Хранилища разрешённых

Цель: ознакомиться с изюминками хранилищ данных и кубов данных, купить практику работы в среде Deductor.

Теоретические сведения:

Сейчас, фактически в любой организации сложилась прекрасно всем знакомая обстановка: информация помой-му, где-то и имеется, её кроме того через чур много, но она неструктурированна, несогласованна, разрознена, не всегда точна, её фактически нереально отыскать и взять.

Именно на разрешение этого несоответствия — отсутствие информации при наличии а также избытке и нацелена концепция Хранилищ Данных (Data Warehouse). В базе концепции Хранилищ Данных лежат две основополагающие идеи:

Интеграция ранее разъединенных детализированных данных:
Разделение комплектов данных применяемых для наборов и операционной обработки данных применяемых для ответа задач анализа.

Хранилища данных строятся на базе клиент-серверной архитектуры, реляционной СУБД и утилит помощи принятия ответов.

Существуют два архитектурных направления – нормализованные хранилища данных и размерностные хранилища.

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

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

Таблицы данных и соответствующие размерности образуют архитектуру ШИНА.

Размерности довольно часто создаются в третьей обычной форме (медлительно изменяющиеся размерности), для протоколирования трансформации в размерностях. Главным преимуществом размерностных хранилищ есть понятность и простота для пользователей и разработчиков, кроме этого, благодаря более действенному хранению данных и формализованным размерностям, облегчается и ускоряется доступ к данным, в особенности при сложных анализах. Главным недочётом есть более загрузки и сложные процедуры подготовки данных, и изменение и управление размерностей данных.

Процессы работы с данными

Источниками разрешённых могут быть:

Классические совокупности регистрации операций (БД)
Отдельные документы
Комплекты данных

Источники данных классифицируются:

Территориальное и административное размещение.
Степень достоверности.
Частота обновляемости.
управления и Система хранения данными.

Операции с данными:

Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.
Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, нужного для принятия ответов.
Загрузка – помещение данных в хранилище, производится атомарно, методом добавления новых фактов либо корректировкой существующих.
Анализ – OLAP, Data Mining, Reporting и т. д.

Deductor Warehouse

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

При работе с хранилищем данных от пользователя не нужно знание структуры хранения данных и языка запросов. Он оперирует привычными бизнес-терминами – отгрузка, товар, клиент. Для импорта из хранилища необходимо всего лишь позвать мастер и выбрать, какого именно рода данные хотелось бы взять.

Все нужные для извлечения данных операции будут произведены машинально.

Все данные хранится в схемах типа снежинка, где в центре расположены таблицы фактов, а «лучами» являются измерения. Любая снежинка обрисовывает определенное воздействие, к примеру, продажи товара, отгрузки, поступления денежных средств и другое.

Пример проектирования структры ХД

Имеется история продаж разных товаров по дням в нескольких торговых объектах. Товары объединены в группы. Все сведенья возможно представитьв в виде 4 таблиц: Товарные группы, Товары, Отделы, Продажи.

В таблице 1 Код группы – измерение, Наименование группы– его атрибут.В таблице 2 Код товара – измерение, а Наименование товара – его атрибут.В таблице 3 Код отдела – измерение, а Наименование отдела – его атрибут.В таблице 4 Дата, Отдел, Код товара, Код группы, Час приобретения – измерения, а Сумма и Количество – факты, т.к. таблица 4 есть описанием процесса продаж в трех аптеках.

Измерения смогут быть как несложными перечнями, к примеру, дата, так и содержать дополнительные столбцы, именуемые атрибутами. К примеру, измерение Товар может складываться из Наименование товара – фактически измерение (первичный ключ), а Вес, Количество и другое – его атрибуты. Время от времени измерения смогут быть связаны с другими измерениями.

Загрузка данных в Deductor Warehouse производится при помощи Deductor Studio или Deductor Server, причем данную операцию возможно произвести с любыми данными, импортированными либо обработанными программой. Это снабжает много возможностей – до загрузки возможно совершить целый цикл предобработки и очистки, к примеру, удалить аномальные значения, заполнить пропуски и загрузить в хранилище очищенные и нужным образом трансформированные эти.

Deductor Warehouse может строиться на базе одной из трех СУБД: Oracle, MS SQL либо Firebird. Выбор информации из хранилища производится при помощи Мастера импорта: пользователь, какие конкретно эти из имеющейся в хранилище его интересуют, а совокупность самостоятельно формирует специфичный для каждой СУБД SQL запрос. Работа с любой из баз данных происходит совсем прозрачно для пользователя.

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

Deductor Warehouse оптимизирован для ответа как раз аналитических задач, что гарантирует высокую скорость доступа. При загрузке данных машинально производятся все нужные чтобы получить лучшее качество операции. Помимо этого, процедуру загрузки в хранилище возможно запускать машинально ночью либо в любое второе время, в то время, когда сервер наименее занят.

Deductor Warehouse есть совершенным местом хранения аналитических данных:

Централизованное хранилище
Оптимизированный доступ
Непротиворечивость данных
Применение бизнес-понятий для доступа к информации
Автоматическое обновление.

Хранилище данных оптимизировано для ответа задач анализа, исходя из этого при загрузке машинально выполняются все нужные действия:

Эти преобразовываются из плоских таблиц в многомерное представление, наилучшим образом подходящее для анализа данных.
Исключаются все дублирующиеся эти для уменьшения количеств базы данных.
Обеспечивается непротиворечивость информации.
Проводятся все требуемые манипуляции, разрешающие в последствии в 10-100 раз расширить скорость извлечения данных из хранилища.

Применение хранилища данных не есть необходимым при анализе. Все нужные действия в Deductor Studio возможно совершить с любыми табличными данными, но использование Deductor Warehouse разрешает существенно ускорить создание законченного ответа, обеспечить более высокую производительность и сделать несложнее работу с информацией конечным пользователям.

Пример проектирования структры хд

Удивительные статьи:

Похожие статьи, которые вам понравятся: