Как написать дипломную работу по разработке хранилища баз знаний — пошаговый гайд

Введение. Как эта статья проведет вас к успешной защите

Написание дипломной работы, особенно на такую сложную и масштабную тему, как разработка хранилища данных, часто вызывает у студентов страх и неуверенность. Огромный объем информации, необходимость разбираться в архитектурах, технологиях и бизнес-процессах могут обескуражить кого угодно. Но что, если взглянуть на это иначе? Ваша тема — одна из самых актуальных и востребованных в современном IT-мире. Компании отчаянно нуждаются в специалистах, способных превращать хаотичные потоки данных в ценные инсайты. Ваша дипломная работа — это не просто учебный проект, а реальный шанс создать что-то значимое.

Эта статья — ваш персональный научный руководитель и пошаговая дорожная карта. Мы создали ее, чтобы провести вас через все этапы — от формулировки идеи до расчета экономической выгоды вашего проекта. Вам не придется больше судорожно искать информацию по разным источникам, компилируя разрозненные фрагменты. Здесь вы найдете четкую и логичную структуру, которая ляжет в основу вашей дипломной работы.

Ценность хранилищ данных (DWH) для бизнеса сложно переоценить. Они являются ядром систем для поддержки принятия управленческих решений, глубокой аналитики и стратегического прогнозирования. Своевременный и удобный доступ к правильно организованной информации — это прямое конкурентное преимущество. В этой статье мы последовательно разберем, как спроектировать и описать такую систему, чтобы на защите вы чувствовали себя уверенно и компетентно. Итак, когда важность темы ясна, а перед глазами — четкий план, давайте заложим прочный теоретический фундамент.

Глава 1. Как грамотно описать теоретическую базу в дипломной работе

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

Чтобы глава получилась структурированной и убедительной, рекомендуем придерживаться следующего плана:

1. От данных к знаниям: Начните с базовых определений. Четко разграничьте понятия «данные», «информация» и «знания». Покажите, что сырые данные сами по себе бесполезны, и только их обработка, хранение и анализ превращают их в информацию, пригодную для принятия решений.
2. Эволюция систем хранения: Кратко опишите путь от простых баз данных (БД) к современным хранилищам (DWH). Объясните, почему классические OLTP-системы, рассчитанные на быстрые транзакции, не подходят для сложной аналитики, и как это привело к появлению специализированных DWH.
3. Ключевые понятия DWH: Этот подраздел — сердце вашей теоретической главы. Здесь необходимо раскрыть суть основных компонентов и технологий:
   • Хранилище данных (DWH): Дайте определение DWH как предметно-ориентированной, интегрированной, стабильной и зависимой от времени совокупности данных для поддержки принятия решений.
   • Витрины данных (Data Marts): Объясните, что это такое — тематические, урезанные копии данных из основного хранилища, предназначенные для конкретного отдела или бизнес-задачи.
   • Метаданные: Подчеркните их важность. Опишите метаданные как «данные о данных» — информацию о структуре, происхождении, преобразованиях и местоположении данных в хранилище.
   • OLAP-кубы (Online Analytical Processing): Расскажите об OLAP как о технологии многомерного анализа данных, которая позволяет пользователям интерактивно манипулировать данными, получая срезы и отчеты с разных точек зрения.
4. Современные архитектуры: Чтобы показать, что вы в курсе последних тенденций, кратко рассмотрите современные подходы и их отличия от классического DWH: Data Lake (озеро данных для хранения сырых данных любого формата), Data Lakehouse (гибрид DWH и Data Lake) и Data Mesh (децентрализованный подход к управлению данными).

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

Глава 2. Как определить цели и задачи вашего проекта

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

Давайте на конкретном примере разберем, как это сделать. Предположим, вы пишете работу на базе рекламного агентства, которое страдает от разрозненности данных: статистика по кампаниям ведется в одной системе, финансы — в другой, а данные по клиентам — в третьей. Анализ занимает дни, а отчеты часто содержат ошибки. Это — ваша проблема.

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

Для правильной формулировки предлагаем использовать следующий шаблон:

• Цель работы: Разработать и реализовать прототип корпоративного хранилища данных для повышения эффективности анализа рекламных кампаний в агентстве «N».
• Объект исследования: Бизнес-процессы анализа и отчетности в рекламном агентстве «N».
• Предмет исследования: Процессы сбора, интеграции, хранения и аналитической обработки данных о клиентах, рекламных кампаниях и финансовых показателях.

Теперь, когда у нас есть глобальная цель, ее нужно декомпозировать на конкретные, измеримые шаги — задачи. Задачи — это ваш план действий от начала и до конца.

1. Проанализировать предметную область и выявить требования пользователей к аналитической системе.
2. Спроектировать архитектуру хранилища данных, включая его концептуальную, логическую и физическую модели.
3. Выбрать и обосновать стек технологических средств для реализации хранилища (СУБД, ETL-инструменты, BI-системы).
4. Разработать программные модули для извлечения, преобразования и загрузки данных (ETL-процессы) из разрозненных источников.
5. Продемонстрировать работу системы на примере построения аналитических отчетов и оценить экономическую эффективность от внедрения разработки.

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

Глава 3. Проектируем архитектуру хранилища данных

Проектирование архитектуры — это фундамент вашего хранилища. От того, насколько грамотно вы его заложите, напрямую зависит производительность, масштабируемость и удобство использования всей системы. Этот процесс нельзя выполнить одним махом; он представляет собой последовательный переход от общего видения к конкретной технической реализации. Весь путь проектирования принято делить на три ключевых уровня: концептуальный, логический и физический. Такой подход позволяет системно двигаться от бизнес-требований к таблицам в базе данных.

1. Концептуальная модель: взгляд с высоты птичьего полета

На этом этапе мы забываем о технологиях и думаем исключительно о бизнесе. Наша задача — определить ключевые сущности, важные для анализа, и связи между ними. Для нашего примера с рекламным агентством это могут быть: Клиенты, Кампании, Объявления, Площадки (сайты, соцсети), Платежи, Показы, Клики. Результатом этого этапа обычно является ER-диаграмма (Entity-Relationship), которая наглядно показывает, как «Клиент» связан с «Кампаниями», а «Кампании» — с «Платежами» и «Объявлениями». Эта модель — язык, понятный и разработчику, и менеджеру.

2. Логическая модель: строим чертежи

Теперь мы переводим абстрактные сущности на язык, более близкий к базам данных. Логическая модель детализирует концептуальную, превращая сущности в таблицы с конкретными атрибутами (столбцами) и определяя первичные и внешние ключи для связи этих таблиц. Именно здесь вы должны сделать важнейший выбор — определить схему организации данных. Наиболее популярными в DWH являются:

• Схема «Звезда» (Star Schema): В центре находится таблица фактов (например, «Результаты кампаний» с числовыми показателями: клики, показы, затраты), а вокруг нее располагаются таблицы измерений (Клиенты, Календарь, Объявления). Это простая и очень производительная схема.
• Схема «Снежинка» (Snowflake Schema): Это усложненная версия «звезды», где таблицы измерений нормализуются, то есть разбиваются на несколько связанных под-таблиц. Например, измерение «География» может быть разделено на «Страны», «Регионы» и «Города». Это экономит место, но усложняет запросы.

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

3. Физическая модель: воплощение в металле

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

• Точные типы данных для каждого столбца (например, VARCHAR(255), INTEGER, TIMESTAMP).
• Индексы для ускорения поиска по часто запрашиваемым полям.
• Партиционирование таблиц (если необходимо) для управления большими объемами данных.
• Ограничения целостности (constraints) для обеспечения качества данных.

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

Глава 4. Выбираем и обосновываем стек технологий

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

1. Система управления базами данных (СУБД)

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

Критерий	MS SQL Server	PostgreSQL	MySQL
Стоимость	Есть платные версии с расширенной поддержкой и бесплатная Express-версия с ограничениями.	Полностью бесплатное ПО с открытым исходным кодом.	Полностью бесплатное ПО с открытым исходным кодом.
Производительность	Высокая производительность, особенно в задачах OLAP благодаря встроенным службам Analysis Services.	Отличная производительность и расширяемость, хорошо справляется со сложными запросами.	Исторически больше ориентирован на OLTP, но подходит для небольших и средних DWH.
Экосистема	Тесная интеграция с другими продуктами Microsoft (SSIS, SSAS, Power BI).	Огромное сообщество, множество расширений для разных задач.	Очень популярен в веб-разработке, большое сообщество.

Обоснование выбора: Например, вы можете выбрать MS SQL Server, потому что он предлагает мощную встроенную экосистему для ETL (SSIS) и аналитики (SSAS, Power BI), что упрощает интеграцию всех компонентов проекта.

2. Средства интеграции данных (ETL/ELT)

Это «кровеносная система» проекта, отвечающая за доставку данных из источников в хранилище. Важно понимать разницу между двумя подходами:

• ETL (Extract, Transform, Load): Данные сначала извлекаются, затем преобразуются на промежуточном сервере и только потом загружаются в хранилище. Это классический подход.
• ELT (Extract, Load, Transform): Данные извлекаются и сразу загружаются в DWH, а все преобразования происходят уже внутри хранилища силами его СУБД. Этот подход набирает популярность с развитием мощных облачных DWH.

В качестве инструментов можно рассмотреть: Apache Spark для обработки больших данных, Apache Hive для выполнения SQL-подобных запросов к большим массивам данных или встроенные средства, такие как SQL Server Integration Services (SSIS).

3. Инструменты моделирования и BI-аналитики

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

• Средства моделирования: Для создания концептуальной, логической и физической моделей, описанных в предыдущей главе, идеально подходят такие инструменты, как PowerDesigner или бесплатные аналоги (например, draw.io для простых схем).
• BI-инструменты (Business Intelligence): Это «витрина» вашего проекта. С помощью таких систем, как Power BI, Tableau или Apache Superset, вы сможете строить интерактивные дашборды и отчеты, которые и будут демонстрировать пользу от вашего хранилища.

Когда архитектура спроектирована и инструменты выбраны, самое время описать самую динамичную часть системы — процесс загрузки и преобразования данных.

Глава 5. Реализуем процессы интеграции данных (ETL/ELT)

Если архитектура — это скелет хранилища, то процессы интеграции — его кровеносная система, которая непрерывно питает организм свежими данными. В этой главе вы должны детально описать, как именно вы реализовали программные модули, отвечающие за перенос и обработку данных. Это одна из самых важных практических частей работы, где вы демонстрируете свои навыки разработчика. Весь процесс принято описывать в соответствии с классической аббревиатурой ETL (Extract, Transform, Load) — Извлечение, Преобразование, Загрузка.

Extract (Извлечение)

Первый шаг — получить данные из их родных систем. Здесь нужно подробно описать:

• Источники данных: Перечислите все системы, откуда вы забираете данные. В нашем примере с рекламным агентством это могут быть:
  • База данных CRM-системы (например, PostgreSQL).
  • Выгрузки из рекламных кабинетов в формате CSV или Excel-файлов.
  • API финансовой системы для получения данных о платежах.
• Способ подключения: Опишите технические детали. Как вы подключаетесь к базам данных (строки подключения, драйверы)? Как вы работаете с файлами (парсеры для CSV)? Как обращаетесь к API (авторизация, эндпоинты)?

На этом этапе данные еще «сырые» и «грязные», они просто извлечены из своих источников и готовы к дальнейшей обработке.

Transform (Преобразование)

Это сердце всего процесса. Здесь происходит магия превращения разрозненных и несогласованных данных в целостную и достоверную информацию. Ваша задача — на конкретных примерах показать, какие преобразования вы выполняете:

• Очистка данных: Приведение к единому формату (например, все даты к ‘ГГГГ-ММ-ДД’), удаление дубликатов, обработка пропущенных значений (например, замена пустых полей на 0 или ‘N/A’).
• Обогащение данных: Добавление новой, вычисляемой информации. Например, на основе даты рождения клиента можно вычислить его возрастную группу.
• Агрегация: Группировка данных. Например, данные о ежедневных кликах можно сагрегировать до недельного или месячного уровня перед загрузкой в таблицу фактов.
• Слияние: Объединение данных из разных источников. Например, соединение данных о кампаниях из рекламного кабинета с данными о клиентах из CRM по единому идентификатору.

Важно не просто перечислить эти шаги, а показать небольшой фрагмент кода или псевдокода, иллюстрирующий, как, например, поле «ФИО» из одного источника разбивается на три поля «Фамилия», «Имя», «Отчество» в целевой таблице.

Load (Загрузка)

Финальный этап — помещение очищенных и преобразованных данных в целевые таблицы вашего хранилища данных (DWH), которые вы спроектировали в Главе 3. Опишите, в какие именно таблицы (фактов и измерений) загружаются данные и с какой периодичностью должен выполняться этот процесс (например, раз в сутки, ночью). Укажите, используется ли полная перезагрузка данных или инкрементальная (добавление только новых или измененных записей).

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

Глава 6. Оцениваем экономическую эффективность проекта

Любой IT-проект, включая дипломный, в конечном счете создается для того, чтобы принести пользу. Экономическая глава — это ваш шанс доказать комиссии, что разработанное хранилище данных является не просто техническим упражнением, а выгодной инвестицией. Цель этого раздела — показать, что выгоды от внедрения вашей системы превышают затраты на ее создание. Для этого необходимо провести расчеты, которые можно структурировать следующим образом.

1. Расчет затрат на разработку

Сначала нужно посчитать, сколько «стоил» ваш проект. Даже если вы не получали реальную зарплату, для расчета используется условная стоимость вашего времени.

• Затраты на оплату труда: Это основная статья расходов. Определите общее количество часов, потраченных на проект, и умножьте на среднюю часовую ставку Junior-разработчика или аналитика данных в вашем регионе.
  
  Пример: 240 часов * 1000 руб./час = 240 000 руб.
• Стоимость программно��о обеспечения: Если вы использовали платные версии СУБД или других инструментов, их лицензионная стоимость включается в затраты. В большинстве случаев для дипломных проектов используются бесплатные версии, и эти затраты равны нулю.
• Накладные расходы: Часто для простоты их принимают в виде процента (например, 50-60%) от затрат на оплату труда. Они условно покрывают расходы на электричество, амортизацию оборудования и т.д.

Суммировав все эти пункты, вы получите общую сумму капитальных вложений в проект.

2. Расчет годовой выгоды (экономии)

Теперь самое интересное — показать, как ваша система помогает экономить деньги или зарабатывать больше. Выгода может быть прямой или косвенной.

• Экономия времени сотрудников: Это самый простой и наглядный способ. Посчитайте, сколько времени уходило у сотрудников (например, у маркетолога) на подготовку отчетов до внедрения системы, и сколько стало уходить после.
  
  Пример: Раньше маркетолог тратил 8 часов в неделю на сбор отчетов. Теперь отчет генерируется за 15 минут (0.25 часа). Экономия = 7.75 часов в неделю. За год это ~372 часа. Умножаем на часовую ставку маркетолога и получаем годовую экономию.
• Повышение качества решений: Это косвенная выгода, которую сложнее посчитать, но важно упомянуть. Благодаря быстрым и точным отчетам, агентство может оперативно перераспределять бюджет с неэффективных рекламных кампаний на эффективные, что напрямую ведет к росту прибыли.

3. Расчет показателей эффективности (ROI)

В завершение нужно рассчитать ключевые показатели, которые докажут окупаемость проекта.

Return on Investment (ROI) — самый известный показатель. Он показывает рентабельность инвестиций. Формула проста:

ROI = (Годовая выгода — Себестоимость) / Себестоимость * 100%

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

Заключение. Формируем выводы и готовимся к защите

Мы подошли к финалу — этапу, где нужно подвести итоги проделанной работы и подготовиться к ее презентации. Заключение и защита — это возможность еще раз подчеркнуть ценность вашего исследования и продемонстрировать уверенное владение темой. Отнеситесь к этому разделу серьезно: именно введение и заключение комиссия читает наиболее внимательно.

1. Как правильно написать заключение

Хорошее заключение не содержит новой информации. Его главная задача — зеркально ответить на цели и задачи, поставленные во введении. Это создает ощущение целостности и завершенности работы. Используйте следующую структуру:

1. Подтверждение достижения цели: Начните с фразы: «В ходе выполнения дипломной работы была достигнута основная цель — разработан прототип корпоративного хранилища данных…»
2. Перечисление решенных задач: Последовательно пройдитесь по каждой задаче, сформулированной во введении, и кратко опишите результат ее выполнения.
   • «Для достижения цели были решены следующие задачи: «
   • «Был проведен анализ предметной области, в результате которого выявлены ключевые требования к аналитической системе…»
   • «Была спроектирована трехуровневая архитектура хранилища на основе схемы «звезда»…»
   • «Были разработаны ETL-процессы, обеспечивающие сбор и очистку данных из трех источников…»
   • «Была рассчитана экономическая эффективность, показавшая, что проект является рентабельным с ROI в X%».
3. Обозначение практической значимости: Кратко укажите, какую пользу ваша работа может принести конкретному предприятию или отрасли.
4. Перспективы развития: Укажите, как можно развивать ваш проект в будущем (например, подключить новые источники данных, внедрить алгоритмы машинного обучения для прогнозирования).

2. Подготовка к защите: несколько практических советов

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

• Подготовьте презентацию: Идеальный объем — 10-12 слайдов. Каждый слайд должен отражать один ключевой раздел вашей работы (Цель, Архитектура, Выбор стека, Демонстрация работы, Экономика, Выводы). Избегайте перегружать слайды текстом или кодом. Используйте схемы, графики и скриншоты.
• Напишите и отрепетируйте речь: Ваше выступление должно длиться 7-10 минут. Не читайте с листа — это производит плохое впечатление. Говорите уверенно, глядя на комиссию. Лучший способ — несколько раз прорепетировать речь перед зеркалом или друзьями.
• Продумайте ответы на вопросы: Поставьте себя на место комиссии. Какие вопросы они могут задать? «Почему вы выбрали именно PostgreSQL, а не MySQL?», «Чем схема ‘звезда’ лучше ‘снежинки’ для вашей задачи?», «Как вы обеспечивали качество данных?». Подготовьте краткие и четкие ответы.

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

Список использованных источников

1. Обзор сетевого хранилища Synology DS412+ [Интернет-ресурс] Режим доступа: http://hitech.vesti.ru/news/view/id/4178
2. Три основных недостатка хранилищ данных. [Интернет-ресурс]. Режим доступа: http://www.osp.ru/os/2003/02/182655/
3. Хранилища данных. [Интернет-ресурс]. Режим доступа: http://www.tadviser.ru/index.php
4. Щавелев Л.В. Автоматизация проектирования систем оперативной обработки данных: [Текст] на примере информационно-аналитических систем в энергетике: Автореф. дисс. ктн.- Иваново, 1999. – 382 с. — ISBN 5-85242-524-3.
5. Codd E.F., Codd S.B., Salley C.T. Providing OLAP[Текст] (on-line analytical processing) to user-analysts: An IT mandate//Technical report, 1993 – 415 с. — ISBN 5-82102-421-1.
6. Ralph Kimball. The Data Warehouse Toolkit: [Текст] Practical Techniques for Building Dimensional Data Warehouses//John Wiley & Sons, 1996 – 225 с. — ISBN 5-85232-423-2.
7. Ralph Kimball. The Data Webhouse Toolkit: [Текст] Building the Web-Enabled Data Warehouse// John Wiley & Sons, 2000 – 344 с. — ISBN 5-86404-210-
8. Архипенков С., Голубев Д., Максименко О. ХРАНИЛИЩА ДАННЫХ. От концепции до внедрения — М.: ДИАЛОГ-МИФИ, 2002.
9. Спирли, Эрик. Корпоративные хранилища данных. Планирование, разработка, реализация. Том 1. – М. : Издательский дом «Вильямс», 2001.
10. Ефимов, Е.Н., Патрушина, С.М., Панферова, Л.Ф., Хашиева, Л.И. Информационные системы в экономике / Е.Н. Ефимов, С.М. Патрушина, Л.Ф. Панферова, Л.И. Хашиева. — М.: ИКЦ «МарТ»; Ростов н/Д: издательский центр «МарТ», 2004. — 352 с.
11. Иванов, В.В., Коробова, А.Я. Муниципальный менеджмент / В.В. Иванов, А.Я. Коробоваю. — М.: ИНФРА-М, 2002.
12. Конаржевский Ю.А. Менеджмент и внутришкольное управление. М.: Общеобразовательный центр «Педагогический поиск», 2009. – 224 с.
13. Марселлус Д.Н. Программирование экспертных систем на Турбо Прологе. — М.: Финансы и статистика, 1994. 523с.
14. Нейлор К. Как построить свою экспертную систему. — М.: Энергоатомиздат, 1991. 564с.
15. Нейлор, К. Как построить свою экспертную систему. – М.: Энергоатомиздат, 2011.
16. Нильсон Н.Д. Искусственный интеллект. Методы поиска решений. — М.: Мир, 1973. 232с.
17. Нильсон, Н. Искусственный интеллект. Методы поиска решений. – М.: Мир, 1973.
18. Сафонов В.О. Экспертные системы — интеллектуальные помощники специалистов. — С.-Пб.: Санкт-Петербургская организация общества «Знания» России, 1992. 234с.
19. Таунсенд К., Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ. — М.: Финансы и статистика, 1990.
20. Третьяков П.И. Управление школой по результатам. Практика педагогического менеджмента. – М.: Новая школа, 2009. – 288 с.
21. Убейко В.Н. Экспертные системы. — М.: МАИ, 1992. 543с.
22. Убейко, В.Н. Экспертные системы. – М.: МАИ, 1999.
23. Уотермен Д. Руководство по экспертным системам. — М.: Мир, 1980. 236с.
24. Уотермен, Д. Руководство по экспертным системам. – М.: Мир, 1990.
25. Ф.Хейес-Рот; Д. Уотерман; Д. Ленат. Построение экспертных систем. М.:Мир, 1987, 325с.
26. Элти Д., Кумбс М. Экспертные системы: концепции и примеры. — М.: Финансы и статистика, 1987. 402с.
27. Ясницкий, Л.Н. Введение в искусственный интеллект. – М.: Академия, 2005.