Содержание к диссертации
Введение
Глава 1 Задача проектирования модели данных и контроля качества данных при построении информационно- аналитических систем 12
1.1 Проектирование модели данных 12
1.1.1 Логическая модель данных 13
1.1.2 Физическая модель данных 16
1.1.3 Классификация технологий проектирования моделей данных 23
1.1.3.1 Разработка модели данных «с нуля» 23
1.1.3.2 Индустриальные модели данных 26
1.1.3.3 Универсальная модель данных 28
1.2 Обеспечение качества данных 30
1.2.1 Классификация существующих технологий контроля качества данных 31
1.2.1.1 Репозитории метаданных 32
1.2.1.2 Средства профилирования информации 33
1.2.1.3 Системы мониторинга данных 35
1.2.1.4 Средства очистки информации 36
1.2.1.5 Системы управления базами данных 38
1.2.1.6 Средства управления справочниками 39
1.3 Постановка задачи 42
1.3.1 Недостатки существующих технологий проектирования модели данных 43
1.3.2 Недостатки существующих средств повышения качества данных.44
1.3.3 Требования к разрабатываемой технологии 45
Глава 2 Формализация задачи и разработка автоматизированных методов проектирования модели данных и контроля качества информации 47
2.1 Автоматизация проектирования модели данных 47
2.1.1 Математическое моделирование модели данных 47
2.1.2 Возможность автоматизации разработки модели данных 48
2.1.3 Макроязык для определения правил генерации структуры базы данных 57
2.1.4 Шаблоны генерации структуры,базы данных 61
2.1.5 Использование шаблонов автоматической генерации структуры базы данных и автоматизированная разработка модели данных 65
2.2 Автоматизация контроля качества данных 67
2.2.1 Контроль качества данных атрибутов 68
2.2.2 Контроль качества данных фактов 71
2.2.3 Классы проверок качества данных 73
2.2.3.1 Контроль значений колонок таблицы 73
2.2.3.2 Контроль наличия в таблице всех необходимых значений 74
2.2.3.3 Контроль дубликатов 77
2.2.3.4 Контроль правила «З о» 78
2.2.3.5 Контроль качества информации с помощью прогнозирования...79
2.2.4 Контроль качества данных и ETL 81
2.2.5 Абсолютное качество данных 82
Глава 3 Разработка программного комплекса и анализ результатов применения разработанной технологии 84
3.1 Архитектура программного комплекса 84
3.2 Подсистема проектирования модели данных 85
3.3 Подсистема контроля качества данных 95
3.3.1 Использование системы контроля качества данных при разработке процедур ETL 98
3.4 Репозиторий метаданных 101
3.4 Производительность и расширяемость системы 102
3.5 Информационно-аналитическая система для анализа деятельности университета 104
3.6 Снижение трудозатрат при использовании разработанной технологии и программного комплекса при создании информационно-аналитических систем 111
Заключение 115
Библиографический список 116
Приложения 126
- Логическая модель данных
- Средства профилирования информации
- Математическое моделирование модели данных
- Подсистема проектирования модели данных
Введение к работе
Большинство организаций оперируют с большим объемом данных, которые необходимо правильно анализировать для получения полного представления о тенденциях, изменениях, других факторов, которые влияют или могут повлиять на деятельность организации. На сегодняшний-день разработан ряд программных средств, предназначенных для облегчения задачи анализа информации. Одним из классов таких программных средств являются информационно-аналитические системы.
Информационно-аналитические системы не являются готовыми продуктами, а состоят из набора интегрированных средств, выбор которых зависит от конкретной задачи.
Необходимая для анализа информация может содержаться в разных источниках: реляционных базах данных, текстовых файлах, документах html. Даже если работа предприятия управляется единой информационной системой, хранящей свою информацию в реляционной базе данных (такие базы называются оперативными), в большинстве случаев подобные системы не годятся для предоставления аналитической информации, так как оперативные системы и хранилища данных работают по разным принципам. Оперативные системы содержат текущую информацию, например, состояние банковского счета клиента, хранилище данных содержит историческую информацию, то есть в случае банковского счета хранится информация о средствах в разные моменты времени. Состояние оперативной системы все время изменяется, в ней происходит огромное количество небольших транзакций, на пример, перевод средств с одного счета на другой. Информация в,хранилище остается неизменной и лишь пополняется новыми данными- по определенному расписанию. Оперативные системы лежат в основе работы предприятия, в то время как хранилища данных помогают ответить на вопрос: «Как работает предприятие?» и используются при разработке стратегий, направленных на повышение эффективности работы предприятия.
Перед оперативными системами и хранилищами данных ставятся разт ные задачи, поэтому архитектуры их. также различаются. При построении-хранилища обычно используют,многомерную модель данных [44, 57].
Для; наполнения хранилища информацией используется программное обеспечение класса ETL (Extract Transfer Eoad) [56]. Программное обеспечение этого класса предназначено для извлечения, приведения к общему формату, преобразованию и загрузки данных в хранилище.
Информационно-аналитические системы должны включать в себя также инструменты анализа информации, содержащейся в хранилище данных, и средства представления ее в более удобном, для восприятия виде (графики, сводные таблицы, отчеты), позволяющем принимать обоснованные решения. С этой целью используют инструменты Business Intelligence.
На основе типовых задач, решаемых разработчиками, можно привести определение информационно-аналитической системы. Понятие информационно-аналитической системы определяется различными авторами по-разному. В настоящей работе используется определение, приводимое Р. Кимбаллом: «Информационно-аналитическая система - программный комплекс, предназначенный для извлечения, очистки, проверки и загрузки данных из источников в многомерное хранилище данных, а также предоставляющий средства извлечения и анализа содержащейся в хранилище информации, с целью помощи в принятии решений» [56].
Построение информационно-аналитических систем состоит из следующих этапов:
1. Проектирование модели данных.
2. Наполнение хранилища данных информацией с помощью процедур ETL.
3. Обеспечение качества данных.
4. Предоставление удобного доступа к информации пользователям и визуализация анализируемых данных.
Для задач 2 и 4 созданы специализированные универсальные программные средства, пригодные для использования в любом проекте по созданию информационно-аналитической системы, поэтому в данной работе эти задачи рассматриваться не будут. Задачи 1 и 3 являются уникальными для каждого проекта и решаются каждый раз заново [42, 69, 72]. Таким образом, ключевыми факторами, влияющими на успех проекта по созданию информационно-аналитической системы, являются задачи проектирования модели данных и обеспечения качества данных [26,66]. В результате этого, несмотря на опыт и методики, накопленные за более чем 30-летнюю историю, проекты по созданию информационно-аналитических систем остаются рискованными. Джек Олсон приводит неутешительную статистику: 37 % проектов прекра щаются, не получив каких-либо результатов;
50 % проектов доводятся до логического завершения, но при этом превышаются сроки или бюджет на 20 % и более; 13 % составляют успешные системы [66].
Высокий уровень рисков, связанный с проектами по созданию информационно-аналитических систем, а также постоянно увеличивающийся спрос на системы данного класса требуют поиска и разработки новых технологий проектирования модели данных и контроля,качества данных, что обусловливает актуальность представленной работы.
Цель и задачи исследования. Целью данной работы является разработка автоматизированной технологии проектирования модели данных и контроля качества данных, позволяющей сократить трудозатраты, необходимые для создания информационно-аналитических систем.
Для достижения поставленной цели решаются следующие задачи: 1) анализ существующих технологий в области построения информационно-аналитических систем, выявление существующих недостатков и определение требований к технологии разработки систем данного класса; 2) разработка методов проектирования модели данных и контроля качества данных при і построении информационно-аналитических систем, удовлетворяющих сформулированным требованиям; 3) разработка программного комплекса, предназначенного проектировать модель данных и осуществлять контроль качества данных при построении информационно-аналитических систем в рамках разработанных методов; 4) экспериментальная проверка разработанной техно логии с помощью макета информационно-аналитической системы для анализа деятельности вуза; 5) определение области применения разработанной технологии и возможности сокращения трудозатрат на основе анализа использования разработанной технологии для создания информационно-аналитических систем. •
Объект исследования: информационно-аналитические системы.
Предмет исследования: технология проектирования модели данных и контроля качества данных для построения информационно-аналитических систем.
Научная новизна. В диссертационной работе получены новые научные результаты:
1) технология разработки модели данных для информационно-аналитических систем, отличительной особенностью которой является декомпозиция общей задачи построения модели данных на независимые подзадачи разработки модели предметной области и описание правил формирования физической модели данных; такая особенность позволяет проводить решение указанной проблемы независимо специалистами в предметной области и по системам управления базами данных и средствам анализа данных, а также использовать «предыдущий опыт» и наработки предшествующих проектов для разработки данного проекта; а разработанный набор правил формирования физической модели данных позволяет автоматизировать получение ее, требуя лишь описание объектов предметной области;
2); методика автоматизированного контроля качества данных на всех этапах создания информационно-аналитической системы: в источниках данных, в приемнике, а также на всех промежуточных этапах;
3) программный комплекс, позволяющий автоматизировать решение задач проектирования модели данных и контроля качества информации и независимый от технологий, используемых при построении информационно-аналитической системы.
На защиту выносятся следующие основные положения:
1) технология проектирования модели данных для информационно-аналитических систем, дающая возможность автоматизировать получение физической модели данных;
2) методика контроля качества данных, позволяющая автоматизировать контроль качества информации на всех этапах создания информационно-аналитической системы;
3) структура программного комплекса, предназначенного для решения задач автоматизации проектирования модели данных и контроля- качества информации.
Практическая ценность работы заключается в снижении трудозатрат при разработке информационно-аналитических систем; в возможности использования опыта предыдущих проектов в разработке данного; в возможности разделения функций «универсального» специалиста на независимые функции специалиста предметной области и специалиста по системам управления базами данных и средствам анализа данных. Указанная технология по зволяет построить компьютерно-ориентированную автоматизированную систему.
Полученные в рамках диссертационной работы результаты были использованы в работе консалтинговой компании S&T International (г. Москва) при исследованиях и разработках в области информационно-аналитических систем. Разработанная технология и программный комплекс были успешно применены при разработке информационно-аналитических систем компаний Данон, Кампомос (обе - г. Москва), Балтийский банк (г. Санкт-Петербург) и М.Видео (г. Москва).
Апробация работы. Полученные результаты докладывались и обсуждались на третьей и четвертой ежегодных конференциях Business Intelligence (Москва, 2005 и 2006) [6, 16]; конференции «XI Державинские чтения» (Тамбов, 2006); Всероссийских конференциях «XII и XIII Державинские чтения» (Тамбов, 2007 и 2008) [8, 11], XVII Международной конференции-выставке «ИТО-2007» (Москва, 2007) [7] и в рамках публичных лекций для студентов и аспирантов в ходе мероприятий, посвященных 75-летию Института математики, физики и информатики ТГУ им. Г.Р. Державина. Результаты работы использовались в реализации совместного европейского проекта в ТГУ им. Г.Р. Державина по использованию информационных технологий в модернизации университетского управления - TEMPUS TACIS «Joint European Project on System Modernization of University Management (SMOOTH, UMJEP 24217-2003)».
Публикации. Основные положения диссертации опубликованы в 12 печатных работах [1, 6-16], в том числе 4 статьи опубликованы в двух журналах из Перечня рецензируемых научных журналов ВАК за 2006 г.: «Программные продукты и системы» (приложение к журналу «Проблемы теории и практики управления»), «Вестник Тамбовского университета. Серия: Естественные и технические науки».
Структура диссертационной работы. Диссертационная работа состоит из введения, трех глав и заключения, изложенных на 136 страницах, содержит 33 рисунка, 4 таблицы и библиографический список из 73 наименований.
Логическая модель данных
Логическая модель данных представляет собой набор объектов предметной области, которые анализируют пользователи, а также определение связей между этими сущностями. При построении логической модели данных информационно-аналитических систем обычно выделяют объекты следующих типов [57, 63]: факты; атрибуты; иерархии. Факты - числовые характеристики, обозначающие некоторое событие и которые можно агрегировать. Предмет Оценка и N І Семестр Студент Рисунок 2 - Факты и атрибуты Факты всегда окружены текстовым контекстом — атрибутами. На рис. 2 изображены три атрибута, в которых задается информация о студенте, названии предмета и семестра, в котором сдавался экзамен («студент», «семестр», «предмет»). Атрибуты логически группируются в иерархии. Например, на рис. 3 представлена иерархия «Организационная структура университета», состоящая из атрибутов «Факультет», «Курс», «Группа», «Студент». Факультет] KjfyR-l Группа] и( Студент Рисунок 3 - Иерархия «Организационная структура университета» В иерархии также определяется вид связи между атрибутами. Связи могут быть трех видов: Один-к-одному. Каждый элемент атрибута-родителя имеет ровно одного потомка, а каждый атрибут-потомок имеет ровно одного родителя. Один-ко-многим. Каждый элемент атрибута-родителя может иметь несколько потомков, но каждый атрибут-потомок имеет ровно одного родителя. Многие-ко-многим. Каждый атрибут-родитель может иметь много потомков, и каждый атрибут-потомок может иметь несколько родителей. На рис. 4 приведены примеры разных видов связей между атрибутами в иерархии студентов. Атрибуты «Студент» и «Номер паспорта» связаны отношением один-к-одному, так как паспорт однозначно идентифицирует студента. Атрибуты «Студент» и «Группа» связаны отношением один-ко-многим, так как группа состоит из множества студентов, но каждый студент входит лишь в одну группу. Атрибуты «Студент» и «Факультатив» связаны отношением многие-ко-многим, так как студент может посещать несколько факультативов, и каждый факультатив посещается несколькими студентами. Группа [ И Студент [ Номер паспорта JL Факультатив I Рисунок 4 — Иерархия студентов 1.1.2 Физическая модель данных Физическая модель данных определяет, в каких именно физических объектах реляционной базы данных будет храниться информация. Определение физической модели данных состоит из определения двух видов объектов: реляционные таблицы; колонки, из которых состоят таблицы. Различают таблицы трех типов: Таблицы фактов содержат информацию о фактах, например, таблица, содержащая информацию о стипендии студентов. Справочники атрибутов, например, список студентов. Таблицы связи, определяющие связь родитель-потомок между атрибутами, например, для связи атрибутов «Студент» - «Факультатив» требуется таблица связи, представленная на рис. 5, содержащая информацию о том, какие факультативы посещают студенты. Идентификатор студента Идентификатор факультатива Рисунок 5 - Таблица связи Физическая модель данных строится на основе логической и определяется следующими основными факторами: Рекомендации производителя средства анализа и визуализации данных [63, 64]. Рекомендации по степени нормализации по используемой системе управления базами данных [4, 60, 65].
При проектировании физической модели данных для таблиц фактов учитывают, в первую очередь, скорость полного сканирования таблиц, так как скорость большинства аналитических запросов определяется именно этой операцией [8, 54, 63]. Скорость сканирования определяется, в первую очередь, шириной таблицы фактов, то есть размером дисковой памяти, которую занимает одна запись таблицы [68, 70].
Главным недостатком «снежинки» является необходимость соединения большого количества таблиц при анализе информации в разрезе атрибутов высокого уровня. Например, для примера, изображенного на рис. 6, запрос информации о продажах в разрезе дивизиона (справочник LookupDi vision), региона (справочник LookupRegion) и года (справочник Lookup_Year) потребует соединить все 11 таблиц.
Данного недостатка лишена схема «Звезда», пример которой представлен на рис. 7. В данном случае каждая из иерархий хранится ровно в одной таблице, благодаря чему для получения данных в любом разрезе требуется соединить лишь таблицу фактов и необходимые таблицы иерархий. Схема «Звезда» Главным недостатком схемы «звезда» является невозможность воспользоваться агрегатными таблицами фактов. Агрегатные таблицы используются для увеличения производительности системы и содержат значения фактов, рассчитанные на более высоком уровне, нежели детальная информация. Например, факт «Стипендия» определен на уровне «Студент», «Месяц». Тем не менее, если пользователь будет запрашивать информацию на уровне «Факультет» и «Группа», то мы можем увеличить производительность системы, предварительно сохранив в агрегатной таблице значение, рассчитанное на уровне «Группа», «Месяц». Так как в такой таблице будет гораздо меньше записей, запрос к ней обрабатывается гораздо быстрее.
Использование в запросе агрегатных таблиц требует наличия справочников атрибутов, на уровне которых определена агрегатная таблица, так как соединение с таблицей, содержащей иерархию, приведет к удвоению записей и, следовательно, к неверному результату [63].
Чтобы избежать недостатков «звезды» и «снежинки», часто применяется гибридная схема «Денормализованная снежинка» (рис. 8). При использовании «денормализованной снежинки» для каждого атрибута используется отдельная таблица, но при этом в справочнике содержится ссылка не только на родительский атрибут, но на все атрибуты иерархии, находящиеся на уровне выше данного. Благодаря такому подходу появляется возможность использовать агрегатные таблицы и минимизировать количество соединений таблиц в запросах [49, 63].
Средства профилирования информации
Средства профилирования информации подразумевают использование аналитических методов для выявления структуры, содержания и качества данных. Средство профилирования информации - инструмент, используе-/ мый аналитиком, способный обрабатывать огромные объемы информации и выявлять некачественную информацию. Средства профилирования информации используются для периодических проверок данных, для определения, насколько полезными оказались действия разработчиков по повышению качества информации.
При профилировании данных могут быть использованы два метода: 1. Обнаружение. Система самостоятельно сканирует данные и обнаруживает аномалии, не прибегая к помощи аналитика. При этом используются метаданные и алгоритмы data mining. Помимо обнару жения некачественной информации данный способ позволяет определять неточности и ошибки в определении метаданных. 2. Тестирование. Аналитик указывает правила определения корректности информации, после чего система проверяет, насколько имеющиеся данные удовлетворяют заданным требованиям. Тестирование обычно применяется после обнаружения некачественной информации [66]. Примером программного средства профилирования информации является IBM WebSphere ProflleStage. В своей работе данная система использует два потока данных: проверяемые данные и метаданные, содержащие ограничения, определяющие корректность данных. Если метаданные определены корректно и в полном объеме, то системе потребуется лишь сравнить данные с метаданными и выявить некачественную информацию. Если же в определении метаданных есть неточности, данная операция позволит не только выявить некачественную информацию, но и определить недостатки в определении метаданных [66].
В работе [56] перечисляются задачи, связанные с контролем качества данных, возникающие при создании систем поддержки принятия решений, при решении которых оказывается полезным применение методики профилирования данных: определение проблем с качеством данных в системах-источниках данных; определение метаданных предметной области, структур данных и зависимостей между различными данными. Полученные таким способом метаданные крайне полезны при проектировании схемы хранилища данных и процедур ETL, так как позволяют избежать ряда архитектурных ошибок, которые могут привести к низкому качеству данных в разрабатываемой системе. Таким образом, средства профилирования информации оказываются очень полезным на начальных стадиях создания информационно-аналитической системы, а также при определении проблем с качеством информации в системах-источниках данных, но они не обеспечивают возможность контроля качества данных на всех этапах создания системы поддержки принятия решений, а потому не могут гарантировать качество информации, содержащейся в хранилище данных.
Системы мониторинга данных предназначены для отслеживания изменений базы данных, проводимых индивидуальными транзакциями. Целью работы систем данного класса является выявление транзакций, которые могут приводить к появлению некачественной информации. Для обеспечения эффективности работы система мониторинга должна быть встроена непосредственно в оперативную систему, контроль качества данных которой необходимо производить. Основным недостатком систем мониторинга данных является то, что они серьезно замедляют обработку проверяемой транзакции, что ограничивает использование данного способа контроля качества данных [66]. Системы мониторинга данных могут быть использованы лишь в программных комплексах, производительность которых не является критически важной. Кроме того, данный способ контроля качества данных оказывается неприменим при построении информационно-аналитических систем, так как системы мониторинга данных контролируют информацию на уровне транзакций, а в информационно-аналитических системах не происходит никаких транзакций. Информация, содержащаяся в хранилище данных, не изменяется, а лишь дополняется новыми данными, загружаемыми по расписанию.
Математическое моделирование модели данных
Автоматизация разработки модели данных подразумевает, что физическая модель данных строится-автоматически на основании логической модели данных и набора правил преобразования логической модели данных в физическую - шаблона генерации структуры базы данных.
Утверждение 1. Для произвольной логической модели данных и набора ограничений, накладываемых системой управления базами данных и средством визуализации данных, процесс построения физической модели данных для информационно-аналитической системы может быть автоматизирован.
Физическая модель данных для реляционных баз данных может быть определена любым реляционно-полным языком. Воспользуемся языком SQL, являющимся реляционно-полным [20]. Для определения реляционной модели данных необходимо определить множество таблиц (отношений).
Список фактов может быть определен автоматически как подмножество V множества V (множество объектов предметной области), отмеченное признаком S1 (факт).
Список ссылок на атрибуты может быть определен автоматически как подмножество V" множества V (множество объектов предметной области), для которых существует дуга vl-v2 типа К1 (факт-атрибут), соединяющая вершины vl є V и v2 є V". Таким образом, множество таблиц фактов может быть получено автоматически.
Список ссылок на атрибуты может быть определен автоматически как подмножество V множества V (множество объектов предметной области), для которых существует дуга vl—v2 типа К4 (многие-ко-многим), соединяющая вершины vl є V и v2 є Vі. Таким образом, множество таблиц связи может быть получено автоматически. Таблицы атрибутов могут быть разделены на 2 класса [52, 62]: 1) атрибуты, отношения между которыми изменяются с течением времени (медленно меняющиеся размерности); 2) атрибуты, отношения между которыми не изменяются. В случае атрибутов, отношения между которыми не меняются, определение таблицы для атрибутов состоит из столбцов идентификаторов атрибута, описательных столбцов и столбцов-родителей данного атрибута [63]. Таким образом, определение таблицы атрибутов, отношения между которыми не меняются, может быть представлено в виде: table definitions ::= CREATE TABLE table name ( attribute id column name data type [{ attribute id column name data type }] [{ attribute desc column name data type }]) [{ attribute parent column name data type }]) Список идентификаторов и описательных полей атрибутов может быть определен автоматически как подмножество V множества V (множество объектов предметной области), размеченные меткой S2 (атрибут).
Список столбцов родителей определяется на основании ограничений, накладываемых средством визуализации и анализа данных. В частности, при использовании программных продуктов Oracle и Microsoft рекомендуется использовать схему «звезда», то есть помещать в таблицу атрибута все столбцы (как идентификаторы, так и описательные) всех его родителей [31, 50], а при использовании MicroStrategy, напротив, рекомендуется использо 55 вать схему «снежинка», то есть помещать в таблицу атрибута ссылку на идентификатор родителя 1-го уровня [63].
Таким образом, для доказательства возможности автоматического построения таблиц атрибутов необходимо показать возможность автоматически определить список столбцов-ссылок на родителей атрибута, исходя из ограничений, накладываемых средством визуализации и анализа данных.
Рассмотрим произвольный атрибут и множество его родителей и потомков - иерархию данного атрибута - подграф G (V ,E ) графа G(V,E) - логической модели данных. Так как внутри иерархии не может быть циклов, то граф G является деревом [57, 61]. А для произвольного дерева существуют алгоритмы обхода его вершин, что позволяет получить для каждой вершины список ее родителей, удовлетворяющих произвольным условиям [5, 17]. Таким образом, показано существование алгоритма определения списка столбцов-ссылок на родителей атрибута, исходя из ограничений, накладываемых средством визуализации и анализа данных, что означает возможность автоматического построения множества таблиц атрибутов.
Таким образом, показано, что множество таблиц атрибутов может быть получено автоматически. Следовательно, множество таблиц физической модели данных может быть получено автоматически.
Подсистема проектирования модели данных
Архитектура подсистемы проектирования модели данных представлена на рис. 14 и состоит из 4 компонент: 1) редакторы объектов предметной области; 2) редактор шаблонов генерации структуры базы данных; 3) репозиторий метаданных; 4) генератор структуры базы данных. Генератор структуры базы данных Редактор шаблонов генерации структуры базы данных
Вначале определяются параметры соединения с используемыми базами данных, или с базами данных, где требуется провести контроль качества информации. Доступ к базам данных реализован с помощью протокола ODBC, поэтому необходимо ввести DSN, имя пользователя и пароль, а также определить имя источника данных. В примере, приведенном на рис. 15, были определены 5 источников данных, их имена: MS SQL Server, ORACLE lOg, IBM DB2 UDB, INFORMIX и SYBASE ASE. Также в редакторе определяются связи между атрибутами путем выбора родителей создаваемого атрибута, и определяется шаблон генерации структуры базы данных, с помощью которой будет автоматически создана физическая модель данных.
С помощью редактора шаблонов генерации структуры базы данных определяются правила, по которым будет создана структура хранилища данных. При создании шаблонов используется язык платформы, на которой создается хранилище данных. Например, при создании хранилища данных на базе Oracle используется PL-Sql, а в случае использования MS SQL Server ransact-Sql. При этом также используются макроподстановки, ссылающиеся на описанные объекты предметной области.
Созданные определения предметной области и шаблоны генерации структуры базы данных сохраняются в служебную базу данных - репозито-рий метаданных, после чего могут быть просмотрены в древовидном виде в основном окне приложения и при необходимости отредактированы.
Шаблоны генерации структуры базы данных После определения необходимых объектов предметной области и шаблонов генерации структуры базы данных запускается генератор структуры базы данных, указав ему подмножество объектов предметной области, для которых необходимо получить физическую модель данных (рис. 21). Генератор производит замену макроподстановок, используемых в шаблонах на соответствующие определения объектов предметной области.
Добавление сппявочников изменений указывается имя файла, содержащего ограничения. При выполнении процедур ETL происходит вызов необходимых проверок качества данных, результат выполнения которых определяет последующие действия процедур ETL (продолжение загрузки данных либо предупреждение администратора системы о проблемах с качеством данных). На рис. 24 представлен интер-ейс определения ограничений, накла дываемых на колонки таблиц. Необходимо выбрать таблицу, качество данных в которой требуется проверить, и записать выражение, определяющее корректность информации в таблице. На рис. 25 представлен интерфейс определения правила контроля дубликатов. Необходимо выбрать таблицу, качество данных в которой необходимо контролировать, и определить, какие из колонок являются фактами, а с помощью каких можно определить уникальность записи и, следовательно, по которым нужно группировать данные. Определения правила контроля качества данных с помощью прогнозирования возвращающий данные, которые планируется добавить в систему. При определении правила, основанного на прогнозировании, также указывается количество полных периодов в исторических данных и допустимое отклонение в процентах.
