Конспект лекции на тему "Хранилища данных и баз знаний" по дисциплине Технология разработки и защиты баз данных
план-конспект занятия
Конспект лекции на тему "Хранилища данных и баз знаний" по дисциплине Технология разработки и защиты баз данных
Скачать:
Вложение | Размер |
---|---|
![]() | 104.96 КБ |
Предварительный просмотр:
1 Хранилища данных
Основные проблемы, связанные с анализом информации, как правило, обусловлены разрозненностью данных в первоисточниках, их качеством и уровнем готовности (отсутствием агрегатов, вычисляемых показателей) для решения аналитических задач. Поэтому на сегодняшний день наиболее востребованной технологией, используемой при реализации аналитической информационной системы, являются хранилища данных, с помощью которых решается задача сбора, очистки и преобразования первичных данных.
- Основными идеями, лежащими в основе концепции хранилища данных, являются:
- интеграция разъединенных детализированных данных, которые описывают некоторые конкретные факты, свойства, события и т.д., в едином хранилище;
- разделение наборов данных и приложений на используемые для оперативной обработки и применяемые для решения задач анализа.
В начале восьмидесятых годов прошлого века в период бурного развития регистрирующих ИС возникло понимание ограниченности возможности применения БД для целей анализа данных и построения на их основе систем поддержки и принятия решений. Регистрирующие системы создавались для автоматизации рутинных операций по ведению бизнеса — выписка счетов, оформление договоров, проверка состояния склада и т.д. Пользователями таких систем был в основном линейный персонал. Основные требования, которые предъявлялись к регистрирующим системам, — обеспечение транзакционности вносимых изменений и максимизация скорости их выполнения. Именно эти требования определили выбор реляционных СУБД и соответствующей модели представления данных в качестве основных используемых технических решений при построении регистрирующих систем.
Для менеджеров и аналитиков требовались системы, которые бы позволяли:
- анализировать информацию во временном аспекте;
- формировать произвольные запросы к системе;
- обрабатывать большие объемы данных;
- интегрировать данные из различных регистрирующих систем.
Очевидно, что регистрирующие системы не удовлетворяли ни одному из вышеуказанных требований. В регистрирующей системе информация актуальна только на момент обращения к базе данных, в следующий момент времени по тому же запросу можно получить совершенно другой результат. Интерфейс регистрирующих систем рассчитан на проведение жестко определенных операций и возможности получения результатов на нерегламентированный запрос сильно ограничены. Возможность обработки больших массивов данных также мала из-за настройки СУБД на выполнение коротких транзакций и неизбежного замедления работы остальных пользователей.
Ответом на возникшую потребность стало появление новой технологии организации баз данных — технологии хранилищ данных.
Хранилище данных (ХД) – это система, содержащая непротиворечивую интегрированную предметно-ориентированную совокупность исторических данных крупной корпорации или иной организации с целью поддержки принятия стратегических решений.
Информационные ресурсы ХД формируются путем извлечения моментальных снимков БД операционной ИС организации и различных внешних источников. ХД собирает, очищает, загружает, агрегирует, хранит данные и предоставляет к ним быстрый доступ.
При эффективном использовании ХД может быть одним из основных источников достоверной информации для руководителей и специалистов всех подразделений организации. Это обеспечит согласованность, своевременность и обоснованность принятия управленческих решений, облегчит выверку обязательной отчетности, выпуск управленческой отчетности.
О хранилище данных можно говорить, как о совокупности источника данных (структура связанных таблиц — это и есть хранилище), где собирается информация для дальнейшей обработки, и процедур извлечения, преобразования и загрузки данных (ETL — extraction, transformation, loading).
Физически хранилище данных представляет собой реляционную базу данных. Однако в отличие от БД корпоративных информационных систем (КИС) хранилище имеет принципиально иную структуру. Например, хранилище содержит агрегированные данные, вычисляемые показатели, хранит исторические накопленные данные по конкретным объектам (период хранения информации — длительный). В отличие от ХД базы данных КИС содержат детализированные данные, период их хранения относительно короткий.
Классическая архитектура ХД состоит из следующих элементов: реляционная, многомерная, или гибридная БД, средства извлечения, очистки и загрузки данных, средства визуализации данных и генерации отчетов (OLAP-клиенты). Реляционная БД строится по архитектуре «звезда», в которой с одной таблицей фактов связаны несколько таблиц измерений (справочников), или «снежинка», отличающаяся наличием иерархических справочников. Это делается для оптимизации скорости выполнения объемных запросов (в последнее время появилось много статей, критикующих этот подход за его упрощенность и невозможность решения исключительно в рамках «звезды» всего многообразия задач ХД). В многомерной БД строятся «кубы» — специфические структуры, аналогичные по смыслу реляционным «снежинкам», но хранящие вычисленные агрегаты на всех пересечениях измерений.
Концептуально модель хранилища данных можно представить в виде схемы, показанной на рис. 1.
Данные из различных источников помещаются в ХД, а описания этих данных в репозитории метаданных. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т.д.) и содержимое репозитория, анализирует данные в хранилище. Результатом его деятельности является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на его структуру и функции его поддержания в актуальном состоянии.
Рисунок 1 – Концептуальная модель хранилища данных
Особенности хранилища данных связаны с особенностями задач, на решение которых оно ориентировано: аналитическую оперативную обработку информации и, как следствие, сложные для оперативных баз данных SQL-запросы.
На основе ХД создаются подмножества данных — OLAP-кубы, многомерные иерархические структуры данных, содержащие множество признаков:
- дата/время (период времени, к которому относятся данные);
- сфера деятельности (бизнес-сфера, результат), к которой относятся данные;
- субъект управления (лицо, принимающее решение — ЛПР);
- вид ресурса и др.
Эти признаки позволяют агрегировать данные путем произвольного сочетания признаков и вычисления статистических оценок. В результате анализа информации создается новое знание, полезное для целей управления.
Данные в хранилище попадают из оперативных систем (OLTP- систем), которые предназначены для автоматизации бизнес-процессов. Кроме того, хранилище может пополняться за счет внешних источников, например, статистических отчетов.
На вопрос «Зачем строить хранилища данных ‒ведь они содержат заведомо избыточную информацию, которая и так присутствует в БД или файлах оперативных систем?», можно ответить, что анализировать данные оперативных систем напрямую невозможно или очень сложно. Это объясняется различными причинами, в том числе разрозненностью данных, хранением их в форматах различных СУБД и в разных «уголках» корпоративной сети. Но даже если на предприятии все данные хранятся на центральном сервере БД, аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах.
OLAP (On-line Analytical Processing) не представляет собой необходимый атрибут хранилища данных, но он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений.
Компоненты, входящие в типичное хранилище, представлены на рис. 2.
Рисунок 2 – Структура хранилища данных
Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в реляционное хранилище. При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или оставлены в реляционном хранилище. Важнейшим его элементом являются метаданные, т.е. информация о структуре, размещении и трансформации данных.
Благодаря им обеспечивается эффективное взаимодействие различных компонентов хранилища.
Таким образом, задача хранилища — предоставить «сырье» для анализа в одном месте и в простой, понятной структуре.
Есть и еще одна причина, оправдывающая появление отдельного хранилища. Сложные аналитические запросы к оперативной информации тормозят текущую работу компании, надолго блокируя таблицы и захватывая ресурсы сервера.
Основными причинами, побуждающими организации внедрять хранилища данных, являются:
- необходимость выполнения аналитических запросов и генерации отчетов на не задействованных основными ИС вычислительных ресурсах;
- необходимость использования моделей данных и технологий, ускоряющих процесс выполнения запросов и подготовки отчетности, но не предназначенных для обработки транзакций;
- создание среды, в которой даже относительно небольших знаний основ СУБД достаточно для создания запросов и подготовки отчетов, что означает сокращение времени, требуемого от персонала ИТ-отдела для сопровождения системы;
- создание источника с предварительно очищенной информацией;
- упрощение процесса подготовки отчетов на основе информации из нескольких транзакционных систем и/или внешних источников данных и/или данных, используемых исключительно для генерации отчетов;
- создание выделенного источника в тех случаях, когда возможности операционной системы не соответствует требуемому бизнесом сроку хранения данных и/или необходимо иметь возможность подготовки отчетов на определенные моменты времени в прошлом;
- защита конечных пользователей от необходимости в какой бы то ни было степени вникать в структуру и логику работы БД регистрирующей системы.
2 Базы знаний
Переход от данных к знаниям — логическое следствие развития и усложнения информационно-логических структур, обрабатываемых с помощью компьютера. Активно развивающейся областью использования современных компьютеров является создание баз знаний (БЗ) и их применение в различных областях науки и техники.
Знания ‒ это закономерности предметной области (принципы, связи, законы), полученные в результате практической деятельности и профессионального опыта, позволяющие специалистам ставить и решать задачи в этой области.
Знания можно рассматривать как стратегическую информацию, необходимую для формирования цели и построения кинематической траектории, а информацию — как оперативные знания, используемые системой в динамическом процессе.
Под базой знаний (БЗ) понимают совокупность знаний, накопленных человеком в определенной предметной области, выраженную с помощью некоторого языка представления знаний.
Раздел искусственного интеллекта, изучающий базы знаний и методы работы со знаниями, называется инженерией знаний.
Знанием является проверенный практикой результат познания действительности. Иначе говоря, знание – это накопленные человечеством истины, факты, принципы и прочие объекты познания. Поэтому в отличие от базы данных, в базе знаний располагаются познаваемые сведения, содержащиеся в документах, книгах, статьях, отчетах.
Основная идея создания базы знаний состоит в том, чтобы взять опыт человека-эксперта в какой-либо области (мелиорации, водного хозяйства и т.д.) и, по возможности, с минимальными добавлениями, перенести его на более формальный язык представления знаний.
Итак, База знаний содержит структурированную информацию, покрывающую некоторую область знаний, для использования человеком с конкретной целью. Современные базы знаний работают совместно с системами поиска информации, имеют классификационную структуру и формат представления знаний.
Простые базы знаний могут использоваться для создания экспертных систем хранения данных в организации: документации, руководств, статей технического обеспечения. Главная цель создания таких баз - помочь менее опытным людям найти уже существующее описание способа решения какой-либо проблемы.
Для создания БЗ разрабатываются соответствующие программные средства. Они позволяют обеспечивать загрузку, актуализацию, поддержание в достоверном состоянии, расширение БЗ, формирование, обработку и включение новых знаний, соответствующих текущей ситуации. Базы знаний составляют основу экспертных систем при подготовке управленческих решений.
Экспертные системы (ЭС) — прикладные системы искусственного интеллекта, в которых база знаний представляет собой формализованные эмпирические знания высококвалифицированных специалистов (экспертов) в какой-либо узкой предметной области, а также может содержать результатную информацию, полученную при решении экономических задач.
Структура экспертной системы и ее компоненты представлены на рис. 3
Рисунок 3 – Структура экспертной системы
- База данных предназначена для временного хранения фактов или гипотез, являющихся промежуточными решениями или результатом общения системы с внешней средой, в качестве которой обычно выступает человек, ведущий диалог с экспертной системой.
- Машина логического вывода — механизм рассуждений, оперирующий знаниями и данными с целью получения новых данных из знаний и других данных, имеющихся в рабочей памяти. Для этого обычно используется программно реализованный механизм дедуктивного логического вывода (какая-либо его разновидность) или механизм поиска решения в сети фреймов или семантической сети. Машина логического вывода может реализовывать рассуждения в виде дедуктивного вывода (прямого, обратного, смешанного), нечеткого вывода, вероятностного вывода, поиска решения с разбиением на последовательность подзадач, поиска решения с использованием стратегии разбиения пространства, поиска с учетом уровней абстрагирования решения или понятий, с ними связанных, монотонного или немонотонного рассуждения, рассуждений с использованием механизма аргументации, ассоциативного поиска с использованием нейронных сетей и др.
- Подсистема общения служит для ведения диалога с пользователем, в ходе которого ЭС запрашивает у пользователя необходимые факты для процесса рассуждения, а также дает возможность пользователю в какой-то степени контролировать и корректировать ход рассуждений экспертной системы.
- Подсистема объяснений необходима для того, чтобы дать возможность пользователю контролировать ход рассуждений и, может быть, учиться у ЭС. Если нет этой подсистемы, ЭС выглядит для пользователя как «вещь в себе», решениям которой можно либо верить, либо нет. Пользователь выбирает последнее, и такая ЭС не имеет перспектив для применения.
- Подсистема приобретения знаний служит для корректировки и пополнения базы знаний. В простейшем случае это — интеллектуальный редактор базы знаний, в более сложных экспертных системах — средства для извлечения знаний из баз данных, неструктурированного текста, графической информации и т.д.
Среди специализированных систем, основанных на знаниях, наиболее значимы экспертные системы реального времени, или динамические экспертные системы. На их долю приходится 70% этого рынка.
Классы задач, решаемых экспертными системами реального времени, таковы: мониторинг в реальном масштабе времени, системы управления верхнего уровня, системы обнаружения неисправностей, диагностика, составление расписаний, планирование, оптимизация, системы — советчики оператора, системы проектирования.
3 Сравнительный анализ хранилищ данных (DWH) и баз знаний (KB)
3.1 Фундаментальные различия в концепциях
Критерий | Хранилище данных (DWH) | База знаний (KB) |
Основная цель | Поддержка аналитики и отчетности | Поддержка логического вывода и рассуждений |
Философия проектирования | "Как хранить большие объемы данных для анализа?" | "Как представить знания для машинной обработки?" |
Теоретическая база | Реляционная алгебра, OLAP | Логика предикатов, семантические сети |
Ключевое отличие:
DWH фокусируются на агрегации и анализе исторических данных, тогда как KB ориентированы на моделирование смысловых связей между сущностями.
3.2. Модели данных и структура
Аспект | DWH | KB |
Базовая модель | Реляционная/Многомерная (звезда, снежинка) | Графовая/Логическая (RDF, OWL) |
Связи между данными | Жесткие внешние ключи | Динамические семантические связи |
Пример структуры | Факты и измерения (Sales_Fact, Product_Dim) | Триплеты (Субъект-Предикат-Объект) |
Гибкость схемы | Схема определяется заранее (schema-on-write) | Схема может развиваться (schema-on-read) |
Пример:
В DWH связь "Покупатель → Заказ" требует явного внешнего ключа. В KB та же связь может быть выражена как триплет:
<Петров> <совершил_заказ> <Заказ123> с возможностью добавления свойств:
<Заказ123> <имеет_статус> <Оплачен>
3.3 Методы обработки запросов
Характеристика | DWH | KB |
Языки запросов | SQL, MDX | SPARQL, Prolog, Datalog |
Оптимизация | Для агрегаций и JOIN-операций | Для обхода графов и логического вывода |
Типичные операции | GROUP BY, оконные функции | Рекурсивные запросы, поиск путей в графе |
Пример запроса | SELECT SUM(sales) BY region, year | SELECT ?product WHERE { ?product rdf:type ex:Electronic } |
Ключевая разница:
DWH-запросы отвечают на вопрос "Сколько?", KB-запросы — на вопросы "Почему?" и "Как связаны?".
3.4 Временные характеристики
Параметр | DWH | KB |
Временная модель | Явные временные метки (timestamp) | Временные онтологии (4D-fluents) |
Историчность | Полная версионность данных | Возможна, но не обязательна |
Актуальность | Обновление по расписанию (ночные ETL) | Возможно real-time обновление |
Пример временного запроса:
- В DWH: SELECT sales FROM fact_table WHERE date BETWEEN '2023-01-01' AND '2023-12-31'
- В KB: SELECT ?event WHERE { ?event :occurredDuring [ :hasStart "2023-01-01"^^xsd:date ] }
3.5 Качество данных и метаданные
Аспект | DWH | KB |
Контроль качества | ETL-валидация, правила очистки | Логическая согласованность (consistency checking) |
Метаданные | Технические (типы данных, источники) | Семантические (онтологии, таксономии) |
Пример подхода | Проверка на NULL, форматы дат | Проверка на нарушение ограничений OWL |
Конкретный пример:
В DWH телефонный номер проверяется на соответствие шаблону. В KB дополнительно проверяется, что :hasPhoneNumber относится только к экземплярам класса :Person.
3.6 Производительность и масштабируемость
Параметр | DWH | KB |
Оптимальный размер | Петабайты структурированных данных | Миллионы сущностей со сложными связями |
Слабые места | Многотабличные JOIN-операции | Глубокие рекурсивные запросы |
Методы оптимизации | Партиционирование, материализованные представления | Индексирование графов, кэширование вывода |
Типичная задержка | Секунды-минуты для сложных отчетов | Миллисекунды-секунды для логического вывода |
Архитектурные решения:
DWH: MPP-архитектура (Massively Parallel Processing).
KB: Распределенные графовые движки (например, JanusGraph).
3.7 Практическое применение (Use Cases)
Типичные сценарии DWH:
- финансовая отчетность (IFRS, GAAP);
- анализ продаж и прогнозирование.
Типичные сценарии KB:
- диагностика заболеваний в медицине;
- рекомендательные системы (семантические связи);
- обнаружение мошенничества через анализ связей.
Гибридные кейсы:
- обогащение DWH семантическими метаданными;
- использование графовых алгоритмов для анализа данных DWH.
4 Перспективы конвергенции технологий
Современные тенденции:
- Knowledge Graphs в аналитике (Google Knowledge Graph)
- Графовые расширения для SQL (SQL/PGQ в SQL:2023)
- Гибридные системы
- Microsoft Azure Synapse + Graph API
- Neo4j + Apache Spark
Технологические вызовы:
- эффективная интеграция реляционных и графовых моделей;
- онтологическое управление Big Data;
- Кквантовые алгоритмы для анализа графов.
По теме: методические разработки, презентации и конспекты

Методические рекомендации по выполнению курсовых работ по МДК 02.02. Технология разработки и защиты баз данных для специальности 230115 Программирование в компьютерных системах
Методические рекомендации составлены в соответствии с рабочей программой профессионального модуля ПМ 02. «Разработка и администрирование баз данных» МДК 02.02 «Технология разработки и защиты баз данны...

Методические рекомендации к учебной практике МДК 02.02 Технология разработки и защиты баз данных
Методические рекомендации составлены в соответствии с рабочей программой профессионального модуля ПМ.02. «Разработка и администрирование баз данных» разработаны на основе Федерального государственного...

Отчеты к материалам УП по МДК 02.02 Технология разработки и защиты баз данных
Методические рекомендации по выполнению учебной практики по МДК 02.02 Технология разработки и защиты баз данных...

Практические работы по 1С для МДК 02.02 Технология разработки и защиты баз данных
Практические работы по 1С для МДК 02.02 Технология разработки и защиты баз данных...

Рабочая программа учебной дисциплины МДК 02.02 «Технология разработки и защиты баз данных»
Рабочая программа учебной дисциплины "Технология разработки и защиты баз данных" является частью основной профессиональной образовательной программы по специальности 09.02.03 «Программирование в...

ИСПОЛЬЗОВАНИЕ ТЕАТРАЛИЗОВАННЫХ ЗАНЯТИЙ В ПРОЦЕССЕ ИЗУЧЕНИЯ МЕЖДИСЦИПЛИНАРНОГО КУРСА "ТЕХНОЛОГИЯ РАЗРАБОТКИ И ЗАЩИТЫ БАЗ ДАННЫХ"
Одним из активных образовательных методов является применение театрализованных технологий в процессе обучения. Когда учебный процесс протекает так, что все обучающиеся оказываются вовлеченными в проце...

МЕТОДИЧЕСКИЕ УКАЗАНИЯ по выполнению курсового проекта по МДК 02.02. Технология разработки и защиты баз данных модуля ПМ.02 Разработка и администрирование баз данных
Выполнение курсового проекта имеет цель закрепить и систематизировать знание студентов по междисциплинарному курсу Технология разработки и защиты баз данных; способствовать развитию навыков самостояте...