Нижегородский государственный университет им. Н.И.Лобачевского
Опубликован: 04.06.2009 | Доступ: свободный | Студентов: 15901 / 4925 | Оценка: 4.34 / 4.09 | Длительность: 14:55:00
Лекция 6:

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

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >

6.2.3. Реляционная модель данных

Учитывая отмеченные в предыдущих разделах недостатки сетевых и иерархических моделей, можно сформулировать желательные требования к модели данных:

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

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

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

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

Рассмотрим пример записи ER-диаграммы (см. рис. 5.2.) в терминах реляционных баз данных.

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

Таблица СТУДЕНТ

Код Фамилия Дата рождения Место рождения

Таблица ФАКУЛЬТЕТ

Номер Название

Таблица СПЕЦИАЛЬНОСТЬ

Номер Название

Представим таблицы, описывающие связи.

Таблица "Студент учится на факультете"

Код студента Номер факультета

Таблица "Студент учится по специальности"

Код студента Номер специальности

Таблица "На факультете имеются специальности"

Номер факультета Номер специальности

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

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

Код студента Фамилия Дата рождения Место рождения

могут иметь разное смысловое значение и, соответственно, разное содержание (в одной таблице содержатся сведения о всех студентах факультета, в другой таблице сведения только о старостах факультета). Для устранения неоднозначной интерпретации в случае отсутствия указания доменов используют имя таблицы (СТУДЕНТ; СТАРОСТА)

Для формального описания таблицы используется теоретико-множественное понятие отношения.

Схемой отношения R называется перечень имен атрибутов отношения (соответствующих столбцам таблицы) с указанием доменов этих атрибутов и обозначается R(A_{1}, A_{2}, \dots , A_{n});  \{ A_{i}\}  \subseteq  D_{i}, где {Ai} – множество значений, принимаемых атрибутом Ai(i=1,n).

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

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

Необходимо отметить, что большинство СУБД для персональных ЭВМ поддерживают именно реляционную модель данных. В качестве примеров таких наиболее распространенных СУБД можно указать все dBase-подобные системы, DB2, Paradox, Access, FoxPro, Oracle, MS SQL Server.

Более подробно реляционная модель данных будет рассмотрена в "Формализация реляционной модели" .

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.

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >
Александра Каева
Александра Каева
Карина Максутова
Карина Максутова