HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является "ROLAP реального времени" (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным

53. Подготовка данных применительно к хранилищам данных

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

Подготовка данных может включать в себя сложные запросы с объемными результатами. К примеру, подготовка множества данных FSC предусматривает соединение таблицы клиентов и таблицы продаж, а также выявление 10 самых дорогих покупок для каждого клиента. Все эти вопросы, касающиеся эффективной обработки запросов для поддержки принятия решения, одинаково актуальны в контексте добычи данных. Фактически, платформы добычи данных используют реляционные серверы или серверы OLAP для решения своих задач по подготовке данных.

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

54. Магазины (витрины) данных. Банки оперативных данных

Витрина данных (англ. Data Mart; другие варианты перевода: хранилище данных специализированное, киоск данных, рынок данных) — срез хранилища данных, представляющий собой массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.

Концепция:

Концепция витрин данных была предложена Forrester Research ещё в 1991 году. По мысли авторов, витрины данных — множество тематических баз данных (БД), содержащих информацию, относящуюся к отдельным аспектам деятельности организации.

Концепция имеет ряд несомненных достоинств:

• Аналитики видят и работают только с теми данными, которые им реально нужны.

• Целевая БД максимально приближена к конечному пользователю.

• Витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.

• Для реализации витрин данных не требуется высокомощная вычислительная техника.

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

Что такое хранилище данных? Как правило, это база, в которой хранится вся масса информации по деятельности той или иной компании. Но нередко бывает нужным выделить из всего этого масштабного комплекса данные по одному направлению работы организации, подразделению, служебному вопросу. Здесь приходит на помощь иной тип хранилища – так называемые витрины данных. Что это, каковы ее достоинства, недостатки, разновидности, мы с вами будем рассматривать на протяжении статьи.

Существует несколько синонимов понятия:

• Специализированное хранилище информации (данных).

• Киоск данных.

• Рынок данных и проч.

Срез базы, хранилища данных, который призван представлять собой массив узкоспециализированной, тематической информации, ориентированный под запросы сотрудников определенного департамента, вектора работы организации. https://asu-analitika.ru/wp-content/uploads/2019/09/2665722.jpg

выделяли следующие сильные стороны своего проекта – витрин данных:

• Представление аналитикам только той информации, которая действительно нужна для определенного рабочего задания, профиля служебной деятельности.

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

• Содержание тематических подмножеств заранее агрегированных специалистами данных, которые в дальнейшем проще настраивать и проектировать.

• Для реализации витрины данных (хранилища данных специализированного типа) не требуется вычислительная техника большой мощности.

55. Многомерные базы данных. Разработка (извлечение) данных

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

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

Основные преимущества многомерных СУБД

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

• Относительно низкая общая стоимость владения, а также быстрый возврат инвестиций;

• В случае использования многомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных обеспечивает оптимизированный доступ к запрашиваемым ячейкам;

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

Преимуществами многомерных баз данных являются:

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

• более простая процедура встраивания функций в многомерную модель данных;

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

В качестве недостатков многомерных баз данных можно выделить:

• сложность изменения структуры данных;

• неэффективное использование памяти.

56. Технологии Big Data

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

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

Определяющими характеристиками для Big Data является совокупность «3V»:

1. Объем

2. Скорость

3. Многообразие (возможность одновременной обработки различных типов данных)

57. ERwin: сильные и слабые связи между сущностями. Операции прямого и обратного проектирования

Связи между сущностями на ER‑диаграммах обозначаются следующим образом:

с ильная или идентифицирующая связь типа 1 : М

с лабая или неидентифицирующая связь типа 1 : М

с вязь типа М : М

В случае связи 1 : М (один ко многим) одна из связываемых сущностей выступает в роли родительской или главной, а другая – в роли дочерней или подчиненной. Эта связь каждому кортежу родительской сущности ставит в соответствие любое (в том числе нулевое) число кортежей дочерней сущности, однако каждый кортеж дочерней сущности может быть связан только с одним кортежем родительской сущности.

Механизм реализации связи «один ко многим» состоит в том, что в дочернюю сущность добавляются атрибуты, дублирующие ключевые атрибуты родительской сущности (т.е. атрибуты, входящие в первичный или альтернативный ключ). Эти атрибуты получают название внешнего ключа (Foreign Key, сокращенно FK) и с их помощью устанавливается связь между кортежами родительской сущности – с одной стороны – и подмножествами кортежей дочерней сущности – с другой. Еще такие атрибуты называют мигрирующими из родительской сущности. Если дочерняя сущность является зависимой от родительской сущности, то мигрирующие атрибуты включаются в состав первичного ключа дочерней сущности, в противном случае – в состав ее неключевых атрибутов.

На уровне логической модели возможны также связи типа М : М (многие ко многим), которые используются тогда, когда между атрибутами сущностей существуют многозначные зависимости. Связь такого типа каждому кортежу одной сущности ставит в соответствие любое (в том числе нулевое) число кортежей другой сущности и наоборот.

Переход от логической модели данных к физической заключается в том, что сущности преобразуются в таблицы, атрибуты и кортежи становятся соответственно столбцами и строками таблиц, домены отображаются в типы данных, принятые в конкретной СУБД. Таблицы, как и сущности, снабжаются первичными и внешними ключами и связываются между собой с помощью связей типа 1:1 и 1:М. Связи типа М:М при переходе к физической модели преобразуются в пары связей типа 1:М и связующие таблицы.

Операции прямого и обратного проектирования

Если логическая модель представлена в виде ER-диаграммы, то переход к физической модели значительно упрощается. В этом случае с помощью CASE-средства, например ERwin, можно выбрать нужную СУБД и автоматически создать соответствующую физическую модель данных. Затем на ее основе ERwin может сгенерировать системный каталог базы данных или соответствующий SQL-скрипт (описание базы данных на языке SQL). Этот процесс называется прямым проектированием. Тем самым достигается масштабируемость – создав один раз логическую модель данных, можно генерировать физические модели данных под любую СУБД, которую поддерживает ERwin. С другой стороны, ERwin способен по содержимому системного каталога базы данных или SQL-скрипту воссоздать физическую и логическую модели данных. Этот процесс называется обратным проектированием. На основе логической модели, полученной в процессе обратного проектирования, можно сгенерировать физическую модель и системный каталог базы данных для другой СУБД. Тем самым решается задача по переносу структуры базы данных с одной СУБД на другую, например с SQL Server на Oracle или с Access на Sybase и т.д.

Прямое проектирование: 1. Создать пупстую бд MYDB.mdb, закрыть Access

2. Tools►Forward Engineer/Schema Generation -> Generate. В появившемся окне Access Connection задайте имя пользователя (User Name) равным Admin, а также с помощью кнопки Browse задайте полное имя созданной базы данных. Нажмите кнопку Connect. После завершения процесса прямого проектирования Database►Database Connection -> Disconnect.