Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Зубрилина Т.В., Юрьев В.Н. Базы данных. Проектирование реляционных баз и хранилищ данных с использованием CASE-технологий: Учебное пособие - файл 1.doc


Зубрилина Т.В., Юрьев В.Н. Базы данных. Проектирование реляционных баз и хранилищ данных с использованием CASE-технологий: Учебное пособие
скачать (848.5 kb.)

Доступные файлы (1):

1.doc849kb.08.12.2011 19:21скачать

содержание
Загрузка...

1.doc

Реклама MarketGid:
Загрузка...
УДК 681.3(075.8)

Зубрилина Т.В., Юрьев В.Н. Базы данных. Проектирование реляционных баз и хранилищ данных с использованием CASE-технологий:

Учеб. пособие. СПб.: Изд-во Политехи, ун-та, 2007. 44с.

Пособие соответствует государственному образовательному стандарту дисциплин ОПД.Ф.03 "Базы данных" и ОПД.Ф.06 "Информационные технологии" направления бакалаврской подготовки 080100 "Экономика".

Изложены вопросы проектирования структур баз данных и структур хранилищ данных с использованием CASE-технологий. В доступной форме представлены основные сведения о реляционных базах данных и хранилищах данных, вводные сведения о CASE-технологиях; рассмотрены модель проектирования структуры реляционной базы данных IDEF1X и процесс моделирования в среде CASE-средства All Fusion Data Modeler. Приведены примеры построения структуры базы данных и структур хранилищ данных для выбранной предметной области. Рассмотрены также вопросы, являющиеся вводными для изучения OLAP-технологии.

Предназначено для студентов факультета экономики и менеджмента.

Табл. 5. Ил. 21. Библиогр.: 6 назв.

Печатается по решению редакционно-издательского совета Санкт-Петербургского государственного политехнического университета.


Оглавление

Введение 4

1. Основные понятия и определения 5

Понятие о базах данных 5

Реляционная модель данных. Основные положения 8

Хранилище данных как необходимый компонент ИС 14

Многомерная модель данных 15

Понятие о CASE-технологий и CASE-средствах 16

2. Использование CASE-средств при проектировании
реляционных баз данных 18

Концептуальная, логическая и физическая модели предметной области 18

Логическая модель IDEFIX. 19
Сущности и атрибуты 20

Типы связей 21

Пример логической модели 27

Физическая модель IDEF1X 30

Таблицы и колонки 30

Связи между таблицами 32

Пример физической модели 33

3. Использование CASE-средств при проектировании
структуры хранилища данных 36

3.1. Структура хранилища данных 36

Таблица фактов 36

Таблицы измерений 37

Схемы хранилищ данных 38

3.2. Примеры моделей хранилища данных 40

Заключение 42

Библиографический список 43


© Санкт-Петербургский государственный политехнический университет, 2007


ВВЕДЕНИЕ
Создание современной информационной системы (ИС) представляет собой сложнейшую задачу, решение которой требует применения специальных методов и инструментов. Основными компонентами ИС являются:

база данных (БД);

средства доступа к данным базы;

хранилище данных и предоставляемые аналитикам средства оперативного и интеллектуального анализа данных;

средства реинжиниринга ИС.

База данных занимает центральное место в любой информационной системе, поскольку для любого вида деятельности необходимы хранение и обработка соответствующих данных. БД предназначены для того, чтобы помогать пользователям выполнять повседневную работу. Совокупность записей, накопленных в БД за несколько лет, может стать источником дополнительной ценной информации, а именно - сведений о закономерностях, тенденциях или взаимозависимостях между какими-либо данными. Это вызвало необходимость создания хранилищ данных, включающих в себя собственно средства хранения данных, средства их пополнения и средства их извлечения и просмотра, а также средства поиска закономерностей. Средства извлечения и просмотра предназначены для аналитиков, задача которых - находить закономерности в больших массивах данных. Для анализа данных и представления результатов этого анализа в виде, удобном для восприятия и принятия решений, используются средства оперативной аналитической обработки данных (Online Analytical Processing -OLAP). Для поиска закономерностей используется Data Mining интеллектуальный анализ данных.

Для проектирования столь сложных систем в целом и их компонентов применяется модельный подход, суть которого в широком смысле в том, что исследуемый объект заменяется его моделью, т.е. некоторым другим объектом, сохраняющим основные свойства реального объекта, но более удобным для исследования или использования. При этом наиболее широкое распро­странение при проектировании и реинжиниринге (перепроектировании, переработке) с использованием модельного подхода получила CASE-технология (Computer Aided System Engineering (CASE)- компьютерная поддержка разработки систем). Разработчик при использовании CASE-технологии описывает предметную область; входящие в нее объекты, их свойства; связи между объектами. В результате создается модель, определяющая основных участников системы, их взаимодействие и информационные потоки. В ходе создания модели формируется электронная версия проекта, которая сохраняется и может быть использована при реинжиниринге проекта.

В пособии в доступной форме представлены основные сведения о реляционных БД и о хранилищах данных, которые стали в последнее время столь же необходимым компонентом ИС, как и БД. Рассмотрены вопросы построения логической и физической моделей IDEF1X, а также размерной модели хранилища данных и приведены примеры моделей в среде CASE-средства AllFusion Data Modeler (входящего в AllFusion Modeling Suite). Представлены также сведения, которые можно рассмат­ривать как вводные для изучения средств Business Intelligence (интеллектуального бизнеса).
^ 1. ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ

1.1. Понятие о базах данных

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

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

Например, файл заказов состоит из записей о заказах, файл клиентов - из записей о клиентах и т.п. Каждая запись состоит из данных, которые разделены на





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

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

Так, например, для финансового отдела нужно создать приложение, в котором будет использоваться файл записей о клиентах с полями Момер счета, £умма на счете. Если в отделе продаж вводится система обработки заказов, то для приложения потребуется файл обработки счетов, в котором тоже нужны поля Номер счета, £умма на счете.

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

В базах данных файлы не привязаны к конкретным приложениям. Напротив, они объединены таким образом, чтобы содержащиеся в них данные могли использоваться множеством приложений. В идеале все данные записываются один раз, хотя и обрабатываются множеством приложений. Физически БД представляют собой файлы, доступ к которым осуществляется приложениями не непосредственно, а путем обращения к системе управления базами данных (СУБД). В файлах базы данных хранятся не только сами данные, но и описания их структур.

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

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

Так, в простейшей БД ЗАКАЗ могут быть созданы две таблицы: Заказ и Клиент, связанные между собой (табл. 1 и 2). К ним смогут обращаться все необходимые приложения (в рассматриваемом примере - для финансового отдела и отдела продаж), а также, используя средства СУБД, квалифицированные пользователи.

Таблица 1

В современных БД, помимо взаимосвязанных таблиц, сохраняются такие объекты, как запросы, а также объекты приложений: формы, отчеты, страницы, макросы и модули. Запросы создаются пользователями для выборки необходимых данных из таблиц, и результатом выполнения каждого такого запроса является таблица. Используя запросы, можно также добав­лять, редактировать, удалять данные в таблицах и создавать новые таблицы. Формы предназначены для ввода и редактирования данных, отчеты – для формирования выходных документов и вывода их на печать. Страницы доступа к данным являются интерактивными Web-страницами, которые позволяют просматривать, редактировать и вводить данные в БД, используя Web-браузер. Макросы и модули - это программы обработки данных, создаваемые пользователями на встроенном языке СУБД.

Представление таблиц и связей между ними отображается схемой данных (рис. 1). Схема данных соответствует физической модели IDEF1X в среде выбранной СУБД (см. подразд. 2.3).


1.2. Реляционная модель данных. Основные положения
О
пределение: модель данных - это совокупность взаимосвязанных структур данных, операций над ними и множества ограничений для хранимых данных.

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

Для реляционной модели данных описание отображаемой предметной области базируется на гипотезе о том, что моделируемую область можно рассматривать как совокупность нескольких множеств, между элементами которых существуют некоторые отношения. Основными элементами модели являются реляционные таблицы1 и связи между ними. В каждой таблице содержатся сведения об одной сущности. В исходных таблицах, из которых данные вводятся в таблицы базы данных, столбцы должны иметь уникальные имена, содержать данные только одного типа (либо числа, либо текст и т.п.), быть неделимыми и не иметь пустых и повторяющихся строк. Структура таблицы определяется составом и последовательностью ее полей с указанием типа элементарных данш>|1*? размещаемых в каждом поле. Основными типами данных являются: числовой, текст, дата/время, логический. Содержание таблицы заключено в ее записях/Каждая запись содержит данные о конкретном экземпляре сущности. Для однозначного определения каждой записи таблица должна иметь уникальный ключ (ключевое поле или совокупность нескольких полей), называемый первичным ключом.


1 Для реляционной модели используется терминология, введенная Э.Коддом: отношение, кортеж, атрибут, домен. Однако для упрощения использованы понятия баз данных: таблица, запись, поле, тип и размер данных поля.

Так в таблице Заказ (см. табл. 2) ключевым полем может быть Номер заказа, если нумерация не зависит от даты заказа, и Номер заказа+Дата заказа, если каждый день вводится новая нумерация (1,2, ..., N).

По значению ключа отыскивается единственная запись.

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

Например, при связывании таблиц Клиент и Заказ (см. рис.1, табл.1 и 2) одной записи со значением поля Код клиента, равным 1251, может соответствовать несколько записей с таким же значением поля Код клиента 1251 в



сотрудников. Очевидно, что поле Должность функционально зависит от поля ФИО

таблице Заказ (один клиент может сделать несколько заказов); т.е. связь каждой пары таблиц обеспечивается по одинаковым значениям поля - ключа связи, являющегося первичным ключом главной таблицы и вторичным ключом подчиненной таблицы.

Связь вида многие-ко-многим (M:N) между двумя исходными таблицами преобразуется введением еще одной таблицы-связки в две связи вида один-ко-многим. При этом ключ таблицы-связки будет составным, т.е. совокупностью ключей исходных таблиц.

Операции, производимые над реляционными таблицами, разделяются на традиционные операции над множествами: объединение, пересечение, вычитание, Декартово произведение; операции реляционной алгебры: выбор, проекция и соединение.

Выбор - это представление таблицы в таком виде, когда в нее входят только те записи, которые имеют заданные значения в заданных полях. Например, из таблицы Клиент выбираются только те записи, в которых поле Город имеет значение Москва.

Проекция - это представление таблицы в таком виде, когда в нее включаются не все, а только заданные поля. Например, из таблицы Заказ выбираются только поля Номер заказа, Дата заказа и поле Оплачено.

Соединение - это операция над двумя связанными таблицами. Результатом является новая таблица, представляющая собой комбинацию из двух таблиц. Она формируется путем сопоставления значений записей из главной и подчиненной таблиц таким образом, что каждая' строка из главной таблицы объединяется со строками из подчиненной, для которых выполняется условие равенства значений ключа связи.

Для рассматриваемого примера при соединении таблиц Клиент и Заказ результирующая таблица может отображать список клиентов и сделанных ими заказов.

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

Например, в таблице Должность (табл.3), состоящей из полей ФИО сотрудника и Должность, каждому сотруднику соответствует одна должность, но одна и та же должность (например, экономист) может быть у нескольких

Некоторые виды функциональной зависимости могут приводить к избыточности данных в базе. Для ее устранения (минимизации) при проектировании реляционных БД используется нормализация - процесс преобразования данных от одной нормальной формы к другой, более- высокой. Нормальные формы формируются последовательно по возрастанию (ШФ, 2НФГ ЗНФ), и чем больше номер, тем больше ограничений на хранимые значения должно соблюдаться в соответствующей реляционной таблице. Любая реляционная таблица находится в первой нормальной форме (1НФ).

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

Так, например, в таблице Булочная (табл.4) составным ключом будет совокупность полей Хлебозавод + Продукт. Если при этом цена на одинаковые продукты разных хлебозаводов назначена одной и той же, то поле Цена будет зависеть только от части ключа - от поля Продукт. Для устранения неполной функциональной зависимости необходимо разделить исходную таблицу на две. В первой будут поля Хлебозавод, Продукт (ключ - Хлебозавод + Продукт) и Количество, а во второй - Продукт (ключ) и Цена.



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

(транзитивно), что приводит к избыточности. Например, в таблице Сотрудник (табл.5) с ключом Сотрудник (полагается, что среди сотрудников нет однофамильцев) существует такая зависимость. Поле Должность зависит от поля Сотрудник, а Оклад - от Должности для данного сотрудника, т.е. Оклад зависит от поля Сотрудник через неключевое поле Должность.

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

Так, в первой таблице будут поля Сотрудник (ключ) и Должность, а во второй — Должность (ключ) и Оклад.



Для обеспечения целостности данных в реляционных БД должны выполняться определенные правила. Так, для любой таблицы первичный ключ должен быть уникальным и не пустым (иметь определенное значение). Для связанных таблиц все связи должны быть реальными, т.е. каждый вторичный ключ в подчиненной таблице должен ссылаться на действующий первичный ключ в главной таблице. В примере Клиент — Заказ (см. рис.1 и табл. 1.2) это означает, что если есть записи в таблице Заказ с номером клиента 1274, то должна быть запись в таблице Клиент с таким номером клиента.

Для связанных таблиц правила ссылочной целостности предусмат­ривают действия, которые должны выполняться при вставке, обновлении и удалении записей в одной из таблиц. Так, например, правило Каскад требует при удалении (или обновлении) записи в главной таблице удаления (или обновления) всех соответствующих записей в подчиненной таблице. В нашем примере это означает, что если удаляется запись с номером клиента 1251 в таблице Клиент, то в таблице Заказ будут удалены все записи с заказами, сделанными этим клиентом. Правила ссылочной целостности устанавливаются при проектировании БД.

Возможности ускоренного поиска данных в реляционной базе обеспечиваются созданием индексов, в которые выносятся упорядоченные значения (по возрастанию или убыванию) ключа и номера записей исходной таблицы, соответствующие этим значениям. Индексы позволяют при поиске использовать не последовательный просмотр записей до нахождения требуемой, а специальные алгоритмы, простейшим из которых является алгоритм помещения указателя в середину индекса и сравнения ближайшего значения ключа с искомым. Если ближайшее значение ключа в индексе больше искомого значения, то указатель перемещается в середину «верхней» половины таблицы, меньше - f середину «нижней», и опять производится сравнение. Если в таблице N записей, то при самом неблагоприятном варианте - искомое значение ключа будет в последней записи - придется проделать N шагов. Для рассмотренного простейшего алгоритма максимальное число шагов при поиске определяется как LOG2 N.

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

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

1.3. Хранилище данных как необходимый компонент ИС
Определение: хранилище данных— это предметно-ориентированное, интегрированное, привязанное ко времени и упорядоченное собрание данных, предназначенное для поддержки принятия управленческих решений различными группами пользователей. Данные поступают из оперативных (обычных) БД, из внешних источников и могут иметь разнородный характер.

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

Ральф Кимбалл, один из авторов концепции хранилищ данных, сформулировал и основные требования к хранилищам:

полнота и достоверность хранимых данных;

поддержка внутренней непротиворечивости данных;

наличие удобных утилит просмотра данных в хранилище;

поддержка высокой скорости получения данных из хранилища;

возможность получения и сравнения срезов данных;

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

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

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


1.4. Многомерная модель данных
Эта модель была предложена Эдгаром Коддом, автором реляционной модели данных, в 1993 году. В многомерной модели данные представляются в виде гиперкубов, используя которые, можно получать различные срезы при аналитической обработке данных. Оси гиперкуба содержат параметры, а ячейки — зависящие от них агрегатные данные. Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных.


Осями многомерной системы координат служат основные атрибуты анализируемого бизнес-процесса. Например, для продаж это могут быть товар, регион, тип покупателя, менеджер по продажам и т.п. В качестве одного из измерений, как правило, используется время. На пересечениях осей измерений находятся данные, количественно характеризующие процесс, -меры. Это могут быть объемы продаж (в штуках или в денежном выражени^, остатки на складе, издержки и т.п. Пример гиперкуба для трех измерений приведен на рис. 2. В качестве мер использованы суммы продаж, а в качестве измерений - время (месяц), город и менеджер по продажам.

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


1.5. Понятие о CASE-технологии и CASE-средствах
Определение: CASE-технология представляет собой методологию проектирования информационных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область (бизнес-процесс), анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

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

Большинство существующих CASE-средств основано на методологиях структурного или объектно-ориентированного анализа и проектирования, представляющих систему как совокупность взаимосвязанных диаграмм и текстовых описаний.

Методология структурного моделирования SADT была разработана Дугласом Россом в 1970-е годы. Она включала в себя совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель

SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Компьютерная реализация данной методологии получила название IDEF (Integrated DEFinition) и появилась как основная часть программы 1С AM (Интеграция компьютерных и промышленных технологий). Методология IDEF насчитывает более десяти моделей, основными из которых являются модели процессов IDEF0 и IDEF3 и модель данных IDEF 1X.

IDEF0 - это методология функционального моделирования, представляющая систему как последовательность взаимосвязанных работ. Как правило, IDEF0 используется на самом начальном этапе моделирования ИС. Для описания ситуаций, в которых работы могут выполняться в определенной последовательности либо выполняться параллельно, совмест­но с IDEF0 применяется IDEF3. Модель данных IDEF IX предназначена для построения модели реляционной БД »

Объектно-ориентированный анализ и проектирование предназначены для создания объектных моделей бизнес-процессов с использованием унифицированного языка моделирования UML (Unified Modeling Language). Идея, лежащая в основе объектно-ориентированного подхода^такова: система представляется в виде множества самостоятельных сущностей (объектов), взаимодействующих друг с другом. Каждая сущность сама отвечает за хранение информации, необходимой для ее жизни, и, кроме того, она имеет (реализует) свое собственное поведение. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования как программ, так и проектов. Основной диаграммой этой модели является диаграмма классов. Класс, по определению, - это описание множества объектов, которых характеризуют одинаковые свойства, операции и семантика (смысл).

В данном пособии рассматриваются только вопросы использования CASE-средств, поддерживающих информационную модель IDEF IX, с примерами, полученными в CASE-средстве AllFusion Data Modeler (ERwin), входящем в пакет AllFusion Modeling Suite и предназначенном специально для разработки реляционных БД.

Следует отметить, что при проектировании ИС с использованием структурного подхода первоначально производится построение модели

процессов (IDEF0 совместно с IDEF3) средствами AllFusion Process Modeler (BPwin), а затем, после принятия решения о создании реляционной БД, — построение модели данных IDEF IX средствами AllFusion Data Modeler (ERwin). При применении объектно-ориентированного подхода создается модель классов, как правило, в среде CASE-средства Rational Rose, на основании которой, при принятии решения о необходимости получения структуры реляционной БД, создается модель IDEF IX либо с использованием встроенного модуля, либо средствами AllFusion Data Modeler (ERwin).


^ 2. ИСПОЛЬЗОВАНИЕ CASE-СРЕДСТВ ПРИ ПРОЕКТИРОВАНИИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
2.1. Концептуальная, логическая и физическая модели предметной области
Предметная область представляет собой часть реального мира, которая исследуется или используется ИС. Это может быть «Учебный процесс», «Изготовление изделий на заказ», «Сбыт», «Экспорт продукции» и др. Из-за сложности предметной области охватить ее аспекты в одноуровневой модели не представляется возможным, поэтому использ>н>тся три уровня: концептуальный (понятийный), логический и физический.

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

Логический уровень является промежуточным, на котором производится формализация модели. На этом уровне налагается ограничение на модель данных безотносительно к используемой СУБД. Логическая модель лежит в основе построения БД, в том числе и с использованием CASE-средств. В логической модели предметная область отображается в виде информационных объектов (сущностей) и связей между ними. Процесс выделения сущностей и установления связей предполагает либо традиционный подход к проектированию БД, либо анализ IDEF-моделей бизнес-процессов, либо использование диаграммы классов на языке UML. При построении логической модели с использованием CASE-средства полагается, что уже определено, какие данные будут храниться в конкретных сущностях, и сделаны предположения о связях между сущностями.

Физический уровень определяет способ реализации модели в среде выбранной СУБД. Одной логической модели предметной области может соответствовать несколько физических моделей (для разных СУБД). В CASE-средствах осуществляется автоматическое преобразование логической модели в физическую для выбранной конкретной СУБД. Элементами физической модели являются таблицы, соответствующие будущим таблицам БД, и колонки, соответствующие будущим полям таблиц. Между таблицами физической модели устанавливаются связи, полностью соответствующие связям между таблицами БД. На основе физической модели осуществляется проектирование структуры базы данных. С использованием CASE-средств этот процесс происходит автоматически и называется прямым проектированием. CASE-средства позволяют также на основе существующей БД создавать физическую, а затем и логическую модели (обратное проектирование). Это полностью относится и к AllFusion Data Modeler (ERwin), предназначенному для проектирования структур БД в 20 реляционных СУБД, в том числе серверной MS SQL Server и настольной MS Access.

Любое CASE-средство, поддерживающее модель данных IDEF IX, позволяет создавать два уровня представления модели: логический и физический.
2.2. Логическая модель IDEF1X
При проектировании реляционной БД первоначально создается логическая модель, основными модельными элементами которой являются: сущности, атрибуты и связи между сущностями. Поскольку IDEF-технология подразумевает использование соответствующих

программных средств, детали модели IDEF1X рассматриваются рименительно к AHFusion Data Modeler (ERwin).







2.2.7. Сущности и атрибуты

Сущность в IDEF1X может быть определена как объект, событие или концепция, информация о которых должна была сохранена. Каждая сущность должна иметь имя (существительное в единственном числе), уникальное в рамках модели, например, Продукт, Предприятие, Заказ и т.п. Каждая сущность включает в себя множество экземпляров. Так, экземплярами сущности Продукт являются данные о каждом продукте.

Атрибут выражает определенное свойство объекта. Имя атрибута -существительное в единственном числе, уникальное в рамках модели (а не только сущности), например, НаименПрод (сокращенное от Наименование Продукта) в сущности Продукт. На логическом уровне можно задать для каждого атрибута один из четырех типов данных, пригодных для всех СУБД:

String - символьный, или текстовый;

Number - числовой;

DateTime - дата/время*,

Blob (Binary Large Objects) - аналог поля Memo.

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

Условное обозначение сущности и пример приведены на рис 3.

В IDEF1X различают независимые и зависимые сущности. Сущности, не зависящие при идентификации от других объектов в модели, называются независимыми и в IDEF1X представлены в виде прямоугольников. Сущности же, зависящие при идентификации от других объектов, являются зависимыми и изображаются в виде прямоугольников со скругленными углами (см. рис. 6, а).

Модель IDEF1X предполагает не только графическое отображение, но и текстовое описание сущности. Это описание содержит:

• определение сущности;

• дополнительные замечания, не отраженные в определении;

примеры запросов, которые могут быть использованы по отношению к сущности;

примеры данных для этой сущности;

свойства, определяемые пользователем.

Каждая сущность на логическом уровне должна быть нормализована, т.е. должна находиться в ЗНФ. ERwin не содержит средств автоматической нор­мализации сущностей, однако такие установки, как запрет на присвоение неуни­кальных в рамках модели имен атрибутов и использование имен ролей для внеш­них ключей (см. подразд. 2.2.2), облегчают построение нормализованной модели.

В модели допускаются разные уровни отображения сущности: уровень атрибутов (см. рис. 3), уровень первичного ключа (рис. 4,а) и уровень сущности (рис. 4,6).





2.2.2. Типы связей

Связи определяют логические соотношения между сущностями. Имя каждой связи - глагол или глагольная фраза. На логическом уровне можно устанавливать между сущностями связи один-ко-многим (1 :М) и многие-ко-многим (M:N). Для связи 1:М указывается имя, характеризующее

отношение главной сущности к подчиненной. Для связи M:N указываются два имени, определяющие отношение первой сущности ко второй и второй к первой (рис. 5).
поставляет/

а)

: Предприятие Р°ИЗВОдт* Изделие | Регион Производится*
б)

Рис. 5. Обозначения связей
Связь один-ко-многим может быть идентифицирующей или неидентифицирующей. Идентифицирующая связь устанавливается между главной и подчиненной сущностями в том случае, когда первичный ключ подчиненной сущности при связывании однозначно не идентифицирует экземпляры этой сущности, и уникальность каждого экземпляра обеспечивается только введением составного ключа, включающего в себя первичный ключ подчиненной сущности и первичный ключ главной сущности (ключ связи, или внешний ключ (FK)). При этом подчиненная сущность является зависимой. На рис. 6 приведена идентифицирующая связь между двумя сущностями; при этом в примере сделано допущение, что один и тот же вид изделия может производиться несколькими производителями, каждый из которых может устанавливать на него свою цену.







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

В ERwin при установлении связи внешний ключ автоматически мигрирует в ключевую (для идентифицирующей) или неключевую (для неидентифицирующей) облает подчиненной сущности с указанием обозначения внешнего ключа (FK).






Для связи один-ко-многим в модели указывается мощность связи -отношение числа экземпляров главной сущности к соответствующему числу экземпляров подчиненной. В общем случае одному экземпляру главной сущности соответствуют 0,1 или М (много) экземпляров подчиненной. Можно внести уточнение, исключив значение 0; либо установить связь один-к-одному, при которой одному экземпляру главной сущности соответствует 0 или 1 экземпляр подчиненной; либо указать точное соответствие одного экземпляра главной сущности заранее заданному (например, 10) числу экземпляров подчиненной сущности.

Связь между сущностями должна быть дополнена текстовым описанием - полным определением связи.

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

RESTRICT - ограничение, запрет;

NONE - отсутствие какого-либо действия;

CASCADE - каскад;

SET DEFAULT - установка значения по умолчанию.

При создании связи в Erwin ей автоматически присваивается значение ссылочной целостности, предусмотренное по умолчанию. Так, например, для вставки экземпляра в подчиненную сущность предусмотрено правило RESTRICT, а для вставки экземпляра в главную - NONE (и для идентифицирующей, и для неидентифицирующей связи).

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

Все сущности (и предок, и потомки) имеют одинаковые ключи. Таким образом, связь предок-потомок для любого потомка - это связь один-к-одному. Обозначение полной иерархии категорий приведено на рис. 8,а. Потомок 1 . содержит L специфических атрибутов, Потомок2 - К специфических атрибутов, ПотомокР - ни одного. Пример иерархии категорий для двух потомков приведен на рис. 8, б.







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







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

Связь многие-ко-многим (M:N) может быть использована только на логическом уровне. При этом должны быть указаны два имени, определяющие отношение первой сущности ко второй и наоборот. Обозначение и пример связи приведены на рис. 10.




На логическом уровне связь многие-ко-многим может быть преобразована введением сущности-связки в две идентифицирующие связи один-ко-многим (рис. 11).

Решение о преобразовании связи многие-ко-многим на логическом уровне принимается разработчиком.




2.2.3. Пример логической модели

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




На рис.12 представлен вариант 1 модели, в котором использованы связи многие-ко-многим между сущностями Производитель - Товар (один производитель может выпускать несколько товаров, один и тот же товар может производиться несколькими производителями) и сущностями Заказ -Товар (в одном заказе может содержаться несколько товаров, один и тот же товар может повторяться в нескольких заказах).

Связи многие-ко-многим могут быть использованы разработчиком для упрощения восприятия модели заказчиком (пользователем). Эти связи будут преобразованы на физическом уровне, поскольку ни одна из реляционных СУБД не поддерживает связи многие-ко-многим.

На рис.13 приведен вариант 2 модели, в котором связи многие-ко-многим разбиты на идентифицирующие связи один-ко-многим с использованием объектов-связок: сущностей ПредлагаемаяПоставка и Строка Заказа.


Создаются представления с использованием инструкций языка структурированных запросов SQL (Structured Query Language).




В обоих вариантах в сущности ГруппаТоваров использована рекурсивная связь для создания иерархической структуры групп товаров (Класс - это имя роли). Остальные связи в модели - неидентифицирующие обязательные.

Логическая модель позволяет получить формализованное описание предметной области практически для любых СУБД, использующих одну и ту же модель данных (в настоящее время реляционную). CASE-средство AllFusion Data Modeler (ERwin) поддерживает более 20 распространенных СУБД (Oracle, Informix, MS SQL Server, Access и др.). Логическая модель создается при участии заказчика (пользователя), предоставляющего описание выделенных разработчиком сущностей, и этот уровень модели должен быть понятен пользователю. '

Преобразование логической модели в физическую в CASE-средствах (в том числе и в ERwin) производится автоматически, а все необходимые изменения и уточнения физической модели осуществляются разработчиком.


2.3. Физическая модель 1DEF1X
Физическая модель IDEF IX формируется в результате автоматического преобразования логической модели и определяется свойствами выбранной СУБД. Одной логической модели может соответствовать несколько физических - для разных СУБД. На физическом уровне основными элементами модели являются таблицы, колонки и связи между таблицами.
2.3.1. Таблицы и колонки

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

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

Колонкам на физическом уровне по умолчанию устанавливается запрет на пустые значения (NOT NULL) для ключевых колонок и NULL -для всех остальных. Каждой колонке присваивается тип данных, соответствующий для данной СУБД обобщенному типу соответствующего атрибута на логическом уровне, Однако установленные типы данных могут уточняться разработчиком.

Например, в ERwin для СУБД Access для колонки Цена типу данных Number (на логическом уровне) соответствует Long Integer (на физическом), но он заменяется разработчиком на Currency или Single.

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




На физическом уровне могут быть созданы представления (view table) - временные таблицы, содержащие результаты запросов к одной таблице или нескольким связанным таблицам. Прямоугольники, обозначающие представления, и связи представлений с таблицами изображаются пунктирными линиями. В ERwin имя представления -V/Порядковый номер на диаграмме (при удалении представления его порядковый номер сохраняется) (рис. 14).

2.3.2. Связи между таблицами

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

2.3.3. Пример физической модели

Рассмотрим в качестве примера физические модели для двух СУБД, соответствующие логической модели второго варианта (см. рис. 13). Одной логической модели соответствуют в нашем примере две физические модели, в которых изменены имена некоторых колонок в сравнении с логической моделью, а также указаны разные типы данных полей КодСтраны и КодРегиона в физических моделях для СУБД Access и СУБД MS SQL Server. Эти изменения никак не отражаются на логической модели.



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

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


Прямое проектирование означает переход от логической модели к физической и генерацию структуры (схемы) новой БД в среде выбранной СУБД. Так, на основании физической модели на рис.16 в СУБД Access будут созданы все таблицы и поля с указанными типами данных и размерами, а также установлены связи один-ко-многим для всех таблиц. При этом разработчику доступен для просмотра и изменения скрипт на языке SQL (или встроенном языке СУБД), содержащий инструкции, описывающие все действия, которые будут производиться CASE-средством
при генерации схемы БД. Аналогично на основании физической модели ( рис. 17) может быть создана схема данных в СУБД MS SQL Server.

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

Так, для каждой таблицы будут созданы уникальные индексы на основе первичного ключа и всех указанных альтернативных ключей, а также неуникальные индексы для всех внешних ключей и указанных инверсионных входов (неуникальных полей, часто используемых при обращении к таблице). Создаваемым индексам присваиваются имена по шаблонам на основании имен соответствующих сущностей и условных обозначений типов ключей. В Eftwin имя индекса начинается с X, далее обозначение типа ключа (для первичного - РК), а затем - имя таблицы. Например, для первичного ключа таблицы Производитель создается индекс с именем ХРКПроизводитель. В версии 7.1 имя индекса включает в себя имя индексируемого поля и имя таблицы.

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

CASE-средства, как правило, могут осуществлять не только генерацию серверной части БД, но и генерацию клиентского приложения в поддер­живаемых средах разработки. Для этого при разработке физической модели каждой колонке присваиваются расширенные атрибуты, содержащие информацию о свойствах объектов клиентского приложения. На основе этой информации генерируются экранные формы.

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

Прямое и обратное проектирование осуществляются всеми CASE-средствами, предназначенными для проектирования реляционных БД.

В то время как обычные реляционные БД нацелены на хранение данных по принципу один факт - в одном месте, хранилища данных содержат заведомо избыточные данные с целью обеспечения высокой производительности при выполнении аналитических запросов.


^ 3. ИСПОЛЬЗОВАНИЕ CASE-СРЕДСТВ ПРИ ПРОЕКТИРОВАНИИ СТРУКТУРЫ ХРАНИЛИЩА ДАННЫХ
Для проектирования структуры хранилища данных в CASE-средствах, предназначенных для проектирования БД, на физическом уровне предусмотрена специальная размерная модель. В размерном моделировании основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).


3.1. Структура хранилища данных
3.1.1. Таблица фактов

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

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

• факты, связанные с транзакциями (transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата);

факты, связанные с "моментальными снимками" (snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например, на конец дня. Типичными примерами таких фактов являются объем продаж за день и дневная выручка;

факты, связанные с элементами документа (line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки);

факты, связанные с событиями или состоянием объекта (event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).

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


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

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

однозначной идентификации члена измерения. Обязательным измерением является время.

Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на "родителя" данного члена в этой иерархии. Нередко таблица измерений может содержать поля, указывающие на "прародителей" и иных "предков" в данной иерархии, а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной БД (например, адреса и телефоны покупателей). Скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую производимые изделия, осуществляется только при появлении нового изделия, не производившегося ранее.

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

Если каждое измерение содержится только в одной таблице, то такая схема хранилища данных носит название Звезда (star schema). Все связи в этой модели идентифицирующие. Условный пример приведен на рис. 18.

Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название Снежинка (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в отношении один-ко-многим к таблице измерений, соответствующей нижнему уровню иерархии, называются консольными таблицами. Условный пример приведен на рис. 19.

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

Следует отметить, что не все хранилища данных проектируются по двум приведенным выше схемам. Так, например, аналитическими средствами СУБД MS SQL Server 2000 возможно проектирование хранилища данных только при использовании одной из приведенных схем, а в MS SQL Server 2005 это ограничение снимается.






3.2. Примеры моделей хранилища данных
При создании модели хранилища данных первоначально определяется цель оперативного анализа хранимых данных. Разработчик выделяет главный запрос (или запросы) и на их основании определяет состав таблицы фактов и таблиц измерений.

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

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

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

таблицы фактов. Эта схема может быть выбрана при относительно небольшом предполагаемом размере БД и небольшом количестве измерений.

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

Приведение моделей хранилищ данных к двум рассмотренным схемам не является обязательным в ряде СУБД (или в разных версиях одной СУБД), но позволяет наглядно представить структуру хранилища.


Заключение
CASE-технология является в настоящее время основной технологией анализа и проектирования экономических информационных систем. В пособии детально рассмотрено построение логической и физической моделей IDEF1X при проектировании реляционной базы данных, приведены примеры этих моделей в среде CASE-средства AllFusion Data Modeler (входящего в AUFusion Modeling Suite). Для хранилища данных, предназначенного для обеспечения возможности оперативного и интеллектуального анализа данных, рассмотрено построение размерной модели и приведены примеры схем хранилищ.

Следует отметить, что использование CASE-средств, под­держивающих модель IDEF1X, для проектирования реляционных баз данных наиболее эффективно в случае возможной замены СУБД при реинжиниринге информационной системы. Для разработки хранилищ данных и использования технологий OLAP и Data Mining в последних версиях СУБД вводятся системы интеллектуального бизнеса.

^ БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Дейт К. Дж. Введение в системы баз данных,б-£изд. М.' СПб.; Киев:
Вильяме, 2000.

2. Мишенин А.И. Теория экономических информационных систем.
4-е язд. М.: Финансы и статистика, 2002.

3. Маклаков СВ. BPwin и ERwin. CASE-средства разработки
информационных систем. М.: Диалог - МИФИ, 2000.

4. Роланд Ф.Д. Основные концепции баз данных: Пер. с англ. М.:

Вильяме, 2002.

http://www.interface.ru.

http://www.erwin.ru.





Скачать файл (848.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации