В. И. Швецов Базы данных
 Скачать 8.45 Mb.
|
6.2.4. Многомерная модель данныхВернемся к понятию «сущность» концептуальной модели. Сущность – это то, о чем накапливается информация в информационной системе. Часто оказывается, что информация об определенной сущности зависит еще от ряда параметров. Рассмотрим, например, сущность УСПЕВАЕМОСТЬ СТУДЕНТОВ со следующими атрибутами: число двоек, число троек, число четверок, число пятерок. Значение атрибутов зависит от параметров «курс», «учебный год». Если использовать для описания соответствующей концептуальной схемы реляционную модель, то необходимо вводить множество таблиц УСПЕВАЕМОСТЬ СТУДЕНТОВ по каждому году для каждого курса. Так, при 5 курсах и необходимости анализировать данные за 10 лет число таблиц будет равно пятидесяти. Дублируются аналогичные структуры всех таблиц, достаточно сложна обработка данных, связанная с анализом однотипных данных при изменении значения одного из параметров и т.д. Наиболее подходящей моделью данных для этого случая является так называемая многомерная модель, используемая в технологии OLAP (OnLine Analytical Processing – оперативная аналитическая обработка). Отметим, что многомерность модели данных означает здесь многомерное логическое представление структуры информации и, вообще говоря, не связана с многомерностью визуализации. Многомерные структуры представляются как гиперкубы данных. Каждая грань куба является размерностью. Основными понятиями, используемыми в многомерных моделях данных, являются «измерение» (dimension) и «ячейка» (cell). Измерение – упорядоченный набор значений, принимаемых конкретным параметром, соответствующий одной из граней гиперкуба. Для нашего примера можно указать в качестве измерений: учебный год – 2006-2007, 2007-2008, 2008-2009; курсы – 1,2,3 и т.д. Ячейка или показатель – это поле, соответствующее атрибуту сущности, значение которого однозначно определяется фиксированным набором значений параметров (значениями «измерений», например, 2008-2009 учебный год, первый курс). В многомерной модели данных определяется ряд дополнительных операций, среди которых можно выделить операции «формирование среза» и «агрегация». При формировании среза пользователю по его запросу предоставляется некоторое подмножество гиперкуба, полученное в результате фиксаций пользователем одного или нескольких значений параметров. Операция «агрегация» обеспечивает переход к более общему представлению информации из гиперкуба пользователю, например суммируя значения показателей по всем значениям одного из параметров, допустим, по всем курсам. Такая модель позволяет легко сравнивать данные при разных значениях параметров, строить графики зависимости значений конкретных атрибутов от значений определенных параметров (например, изменение атрибута по годам) и т.п. Поэтому основное назначение технологии OLAP – обработка информации для проведения анализа и принятия решения. Массовое использование СУБД, поддерживающих многомерную модель данных, только начинается. В качестве наиболее известных СУБД такого типа можно указать Oracle Express Server. Oracle Express Server и Cache. 6.3. Средства автоматизированного проектирования концептуальной модели Средства автоматизированного проектирования концептуальной модели привлекают к себе в настоящее время большой интерес и используются в процессе создания структуры базы данных и интерфейса пользователя для доступа к данным. Причина применения этих средств состоит в использовании в подавляющем большинстве реальных разработок баз данных спиральной модели жизненного цикла программного обеспечения, что предусматривает последовательное создание нескольких версий программного обеспечения. Каждая следующая версия включает в себя предыдущую (возможно, не полностью) и является ответом на замечания пользователя, полученные в результате тестирования предыдущей версии. Напомним, что альтернативным способом является каскадная схема разработки программного обеспечения. Каскадный подход хорошо подходит для тех задач, для которых в самом начале разработки можно достаточно полно и точно сформулировать все требования заказчика. В случае построения баз данных каскадный подход является неприемлемым. При создании баз данных первая модель программного обеспечения, к сожалению, очень редко является удачной. Чаще всего заказчик отвергает первую версию, так как она недостаточно полно отвечает его требованиям. Причина такой ситуации заключается в том, что заказчик не может сразу, до создания начальной версии программы, четко и полно сформулировать свои требования. Обычно после получения первого варианта программного обеспечения заказчик выдвигает дополнительные требования, которые нельзя реализовать в рамках созданной базы данных. Это вынуждает разработчиков вносить изменения в структуру базы данных, а также, соответственно, в интерфейс пользователя для доступа к базе данных. Таких итераций может быть несколько до момента получения решения, адекватного запросам заказчика. Но даже после получения удовлетворительного решения процесс разработки базы данных не завершается. Жизнь не стоит на месте, и запросы заказчика меняются с течением времени. Часть этих изменений можно реализовать без изменения структуры базы данных, изменяя только интерфейс пользователя, другие же требуют изменения и интерфейса, и структуры базы данных. Надо заметить, что подобные изменения являются очень болезненными – работа по их внесению может оказаться трудоемкой и, что самое неприятное, потребовать замены большого количества отлаженного программного кода. Иными словами, замененный код был написан впустую, на самом деле его не нужно было писать. Таким образом, создание работоспособной базы данных можно условно разделить на три этапа – проектирование базы данных, в процессе которого создаются рабочие прототипы, кодирование – создание структур баз данных и законченного интерфейса пользователя и сопровождение готовой базы данных. Основная идея применения средств автоматизированного проектирования баз данных заключается в том, что процесс ручного кодирования начинается только после окончания процесса проектирования. На стадии проектирования схема базы данных и интерфейс пользователя для доступа к базе данных создаются автоматически, исходя из описания концептуальной модели, с помощью так называемых CASE-средств (Computer Aided Software/System Engineering). Конечно, созданный таким образом интерфейс не является законченным программным продуктом, однако он позволяет заказчику оценить возможности конечного продукта и внести свои коррективы. Только после одобрения заказчиком рабочего прототипа разработчики приступают к ручному кодированию – созданию законченного приложения. При сопровождении все повторяется, за тем исключением, что генерируется не все приложение целиком, а только часть, которую надо изменять. На практике чаще всего CASE-средства используются для создания схемы базы данных в виде ER-диаграмм и генерации структур баз данных для конкретной СУБД. После получения от заказчика изменений разработчики вносят соответствующие исправления в диаграмму «сущность – связь» и заново генерируют структуры баз данных. Средства автоматической генерации интерфейсов используются реже. В настоящее время практически каждый производитель СУБД предлагает собственный программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Desinger (Sybase) и другие. Демонстрационные версии данных программных продуктов можно загрузить с соответствующих сайтов (www.oracle.com, www.sybase.com). Кроме того, на рынке представлены решения третьих фирм, не производящих СУБД. Одними из самых распространенных являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler и AllFusion Process Modeler (ранее – BPwin) и другие. На российском рынке данные программы предлагает фирма Interface Ltd. (www.interface.ru). Программа AllFusion Process Modeler предназначена для моделирования бизнес-процессов. Результатами ее работы могут быть не только диаграммы, но и сгенерированный для различных сред код для доступа к базам данных. Для этого, однако, необходимо еще сСоздатьние диаграммы «сущность – связь» осуществляется с помощью AllFusion ERwin Data Modeler, дальнейшее моделирование, включая генерациюпрограммного кода создания базы данных производится с помощью программы AllFusion Process Modeler. Поскольку данный учебный курс не предполагает знакомства со средствами описания бизнес-процессов, мы рассмотрим только ERwin Data Modeler – программный продукт, непосредственно использующийся при создании баз данных. По данным Interface Ltd. AllFusion ERwin Data Modeler (ранее – ERwin) позволяет проектировать, документировать и сопровождать базы данных, хранилища данных и витрины данных (data marts). Создав наглядную модель базы данных можно оптимизировать структуру БД и добиться её полного соответствия требованиям и задачам организации. Визуальное моделирование повышает качество создаваемой базы данных, продуктивность и скорость её разработки. На сайте Interface Ltd. доступна для загрузки демонстрационная версия AllFusion ERwin Data Modeler, которая представляет собой полнофункциональную версию, ограниченную по времени. Основные характеристики AllFusion ERwin Data Modeler: Поддержка различных способов записи диаграмм «сущность – связь» (нотаций). Например, при использовании программы MS Visio в качестве основной используется так называемая реляционная нотация. В данной системе обозначений связи обозначаются стрелками между сущностями и названия связей не пишутся. Название сущности выделяется цветом, поля, входящие в первичный ключ, отделяются чертой от остальных атрибутов. Обязательные атрибуты отображаются с помощью полужирного шрифта. Кроме того, слева от атрибута указывается, входит ли данный атрибут в первичный ключ, а также является ли атрибут внешним ключом. Поддержка проектирования информационных хранилищ. Поддержка совместного проектирования. Поддержка триггеров, хранимых процедур и шаблонов. Развитые средства проверки корректности моделей данных Reverse Engineering (генерация модели данных на основе анализа существующей базы данных), включая восстановление связей по индексам. Автоматическая генерация SQL DDL для создания баз данных. Полная совместимость и поддержка двадцати типов СУБД. Приведем в качестве примера использования данного CASE-средства диаграмму «сущность – связь» фрагмента базы данных студентов. В сущности СТУДЕНТ (STUDENT) сохраняются анкетные данные о студентах. Помимо этой сущности на диаграмме приведены сущности-справочники: виды предшествующего образования (ОБРАЗОВАНИЕ-EDUCATION), данные о гражданстве (ГРАЖДАНСТВО- CITIZENSHIP), а также данные о специальности по которой он обучается (СПЕЦИАЛЬНОСТЬ-PROGRAM).). Сущности связаны между собой. Напомним, что мы выделяем две стадии процесса концептуального моделирования базы данных: - построение обобщенной концептуальной модели, не зависящей от деталей реализации; - отображение обобщенной концептуальной модели средствами модели данных выбранной конкретной СУБД. На рисунках 28 и 29 приведены диаграммы «сущность – связь», представляющие концептуальную модель на первой и второй стадиях.. Демонстрация разных представлений концептуальной модели используется в ERwin для удобства разных категорий пользователей (специалистов предметной области и программистов). двух видах. Еще раз заметим, что это разное представление одной модели. .  Рис. 28 Общая ER-диаграмма, не зависящая от деталей реализации Это представление позволяет сконцентрироваться на описании бизнес-правил, а следующее представление – на представлении модели в конкретной СУБД. В частности, на разных уровнях могут отличаться названия полей. В нашем примере в СУБД используются английские названия полей, а на пкрвом представлении мы определяем русские названия.  Рис. 29. Концептуальное представление, специфицированное к конкретной СУБД На второй стадии диаграмма будет выглядеть по-разному в зависимости от того, для какого сервера баз данных будет использоваться данная модель и, соответственно, какие типы данных есть в данной СУБД. Приведенная на рисунке 29 диаграмма построена для СУБД Oracle 8.0. После создания модели мы можем сгенерировать с помощью CASE-средства соответствующую структуру баз данных. Генерация осуществляется с помощью выполнения автоматически создаваемого скрипта. Краткие итоги. В лекции рассмотрены вопросы, тносящиеся ко второй стадии концептуального проектирования – представлениию концептуальной модели в терминах модели данных определенной СУБД. Дано описание общего представления о модели данных (основные используемые понятия - элемент, запись, файл; основные составляющие описания). Рассмотрены модели данных СУБД как инструмент представления концептуальной модели (сетевая модель данных, иерархическая модель данных, реляционная модель данных, многомерная модель данных и OLAP-технология). Приведены примеры записи концептуальной модели в терминах конкретной модели данных СУБД. Приводятся сведения о с редствах автоматизированного проектирования концептуальной модели. Вопросы данной лекции рассматриваются в [1-8]. Контрольные тесты к лекции 6 Задача 1. Общие представления о модели данных? Вариант 1. Что такое модель данных СУБД? + ð+ способ структурирования данных в СУБД + ð+ виды и типы данных, поддерживаемые СУБД + ð+ инструмент представления концептуальной модели в конкретной СУБД концептуальная модель, специфицированная к конкретной СУБД Вариант 2. Какие понятия используются при описании данных в терминах модели данных? атрибут сущность ð+ +поле + ð+ запись строка + ð+ экземпляр записи + ð+ файл Вариант 3. . Какие формы используются для представления группового отношения? + ð+ графовая ð+ +табличная строковая столбцовая ð+ +реляционная Задача 2. Что входит в описание модели данных СУБД? Вариант 1. Как описываются структуры данных в модели данных СУБД? + ð+ представляются конкретные типы данных и их характеристики предлагается описать любые типы данных и их характеристики + ð+ определены способы составления структур более общего вида из структур простых видов предлагается описать способы составления структур более общего вида из структур простых видов ð+ +представляются конкретные средства реализации связей предлагается описать необходимые способы реализации связей Вариант 2. Какие возможные действия входят в описание модели данных СУБД? + ð+ элементарные операции над данными + ð+ обобщенные операции над данными (процедуры) + ð+ средства контроля ограничений целостности операции по анализу данных действия, реализуемые прикладными программами типы и характеристики структур данных операции над данными Задача 3.Как концептуальная модель специфицируется в терминах модели данных СУБД? .Вариант 1. Как представляются сущности ER-диаграммы при отображении обобщенного представления средствами модели данных СУБД? записями атрибутами файлами ð+ таблицами Вариант 2. . Как представляются атрибуты ER-диаграммы при отображении обобщенного представления средствами модели данных СУБД? + ð+ полями с указанием выбранного типа данных СУБД и характеристики данных полями с указанием задаваемыми пользователем типом данных и характеристики данных экземплярами записей конкретными значениями Вариант 3. Как представляются связи, изображенные на ER-диаграмме при отображении обобщенного представления средствами модели данных СУБД? с помощью стрелок с помощью указателей + ð+ с помощью понятий, описанных в выбранной СУБД с помощью терминов, определенных пользователем с помощью понятий ER-диаграммы Задача 4. Что такое сетевая модель данных? Вариант 1. Как представляется сущность в сетевой модели? записью графом строкой таблицы ð+ +вершиной графа Вариант 2. Как представляется групповое отношение (связь) в сетевой модели? + ð+ указателем + ð+ дугой дополнительным файлом записью Вариант 3. Основные особенности сетевой модели.: простота алгоритмов поиска поиск начинается с корневой вершины + ð+ удобство представления любой концептуальной модели добавление новых сущностей и связей не требует изменения всей структуры базы данных + ð+ высокая трудоемкость программирования |