Моделирование данных - процесс представления реальных данных и их отношений в форме, максимально подходящей для использования в компьютерных программах. Выбор метода эффективного моделирования данных и их отношений - одно из ключевых решений, принимаемых разработчиком при разработке управляемой данными системы. В настоящее время доступно множество методов моделирования данных, но чаще всего используются два - сетевая и реляционная модели. Данная статья представляет собой краткое сопоставление наглядного процесса моделирования данных на примере сравнения этих двух методов моделирования.
Будут рассмотрены следующие вопросы:
- процесс моделирования данных с помощью различных моделей данных;
- процесс написания программ и его зависимость от модели данных;
- сопоставление процедурных и непроцедурных способов доступа к данным.
Краткое определение моделей данных
Сначала необходимо указать, что одни и те же отношения можно представить и в сетевой, и в реляционной модели. Они должны сравниваться с точки зрения того, насколько естественно соответствующей структурой базы данных моделируются реальные данные, которые в ней хранятся, и насколько естественными являются поиск и изменение данных, хранящихся в базе данных.
В сетевой модели данные и отношения обычно представляются в виде рисунков, содержащих прямоугольники и стрелки. Каждый прямоугольник представляет собой тип записи , а каждая стрелка - тип отношения . Тип записи будет содержать поля , которые используются для хранения отдельных значений, которые в совокупности представляют определяющую информацию о реальном объекте, представленном данной записью.
Например, если необходимо хранить в базе данных информацию о сотрудниках, целесообразно определить тип записи сотрудник , содержащий, например, поля фамилия, имя, номер социального страхования, дата рождения и так далее. Если сотрудники некоторой компании группируются по отделам, необходимо также определить тип записи отдел , чтобы хранить информацию об одном или нескольких отделах. Отношение между отделами и сотрудниками можно назвать включает в себя. Это отношение типа "один-множество", согласно которому один отдел может включать в себя несколько сотрудников, а каждый сотрудник (по крайней мере, в данном примере моделирования) может быть включен только в один отдел. Ниже приведен соответствующий рисунок:
ОТДЕЛ → ВКЛЮЧАЕТ В СЕБЯ → СОТРУДНИК
Название "сетевая модель" объясняется тем, что несколько прямоугольников могут соединяться с другими прямоугольниками с помощью нескольких стрелок:
В реляционной модели данные представляются в виде таблицы, в которой каждая строка представляет объект какого-либо типа, а каждый столбец представляет определяющий признак объекта. Столбцы таблиц сотрудник и отдел в реляционной модели могут выглядеть следующим образом:
СОТРУДНИК
Фамилия Имя Номер социального страхования Дата рождения Название отдела
ОТДЕЛ
Название отдела Подчиненность отдела
Приблизительно, строка - то же самое, что запись, а столбец - то же самое, что поле. Реляционная модель не показывает в явном виде отношения между строками, но позволяет установить отношения через сравнение значений столбцов. В приведенном ниже примере таблица сотрудник содержит столбец название отдела , в котором должен указываться отдел, включающий в себя данного сотрудника. В таком случае, там, где название отдела для какого-либо сотрудника соответствует названию отдела для какого либо отдела, можно установить отношение между данным сотрудником и данным отделом.
Пример для сравнения
В данном разделе приводится довольно простая модель данных, как в виде сетевой, так и в виде реляционной модели. Одни и те же данные показаны в том виде, в котором они обычно показываются для обеих моделей. В следующем разделе приведен псевдокод, чтобы продемонстрировать, как программист мог бы использовать данные модели в приложениях.
Сетевая модель
"Сетью" отношений данных, которая может быть визуально представлена в естественном виде, является родословное дерево. На рисунке ниже показана сетевая модель, изображенная в виде простой схемы.
ПОТОМОК
ЛИЦО
ГЕНЕТИЧЕСКАЯ МАТЬ
ГЕНЕТИЧЕСКИЙ ОТЕЦ
ОТНОШЕНИЕ ДЕТОРОЖДЕНИЯ
В данном примере показано, что ЛИЦО может быть или ГЕНЕТИЧЕСКОЙ МАТЕРЬЮ, или ГЕНЕТИЧЕСКИМ ОТЦОМ, с отсутствующими или с одним или несколькими ОТНОШЕНИЯМИ ДЕТОРОЖДЕНИЯ. ОТНОШЕНИЯ ДЕТОРОЖДЕНИЯ могут привести к появлению одного или нескольких ЛИЦ, имеющих отношение ПОТОМОК. На схеме показана форма данных, а не фактические данные. Ниже дано визуальное представление данных, взятых в качестве примера, в форме такой схемы. В данном примере показана часть родословного дерева для трех поколений.
Два типа записей и три типа наборов позволяют представить в базе данных любые наследственные отношения, включая детей от родителей из нескольких отношений.
Простая схема обеспечивает визуальное представление записей данных и их отношений друг к другу, как показано на примере выше.
Реляционная модель
Для сопоставления сетевой и реляционной моделей ниже показаны две реляционные таблицы - одна из них содержит данные о ЛИЦАХ, а другая - данные об ОТНОШЕНИЯХ ДЕТОРОЖДЕНИЯ. Эти таблицы, вместе с соответствующими отношениями первичных/внешних ключей, представляют то же самое родословное дерево, что и показанное выше.
ЛИЦО
|
Идентификатор лица |
Имя |
Пол |
Потомок |
|
1 |
Сью |
Ж |
|
|
2 |
Рон |
М |
|
|
3 |
Мэри |
Ж |
|
|
4 |
Джо |
М |
1 |
|
5 |
Боб |
М |
2 |
|
6 |
Мэг |
Ж |
2 |
|
7 |
Эл |
М |
|
|
8 |
Майк |
М |
|
|
9 |
Эми |
Ж |
3 |
|
10 |
Кэрол |
Ж |
4 |
|
ОТНОШЕНИЕ ДЕТОРОЖДЕНИЯ | |||
|
Идентификатор ОД |
Описание |
Генетический отец |
Генетическая мать |
|
1 |
Связь |
2 |
1 |
|
2 |
Брак |
2 |
3 |
|
3 |
Сожительство |
7 |
6 |
|
4 |
Сожительство |
8 |
6 |
Отношения между строками таблиц устанавливаются через совпадение значений столбцов, часто называемых отношениями ПЕРВИЧНЫХ/ВНЕШНИХ КЛЮЧЕЙ. В данном примере ИДЕНТИФИКАТОР ЛИЦА и ИДЕНТИФИКАТОР ОД - первичные ключи. ПОТОМОК - внешний ключ ИДЕНТИФИКАТОРА ОД, а ГЕНЕТИЧЕСКИЙ ОТЕЦ и ГЕНЕТИЧЕСКАЯ МАТЬ - внешние ключи ИДЕНТИФИКАТОРА ЛИЦА
Такое представление, "дружественное для компьютера", не слишком полезно для программиста, который работает, с помощью схем и алгоритмов, с мысленными образами, которые являются пространственными. Родословное дерево в реальной жизни выглядит обычно как сеть людей и их отношений друг с другом. Их сведение в таблицу для представления в базе данных затрудняет программисту работу с ними.
Сравнительное описание программирования приложений
В данном разделе предполагается, что читатель имеет определенное знакомство с языком SQL.
Рассмотрим, как в прикладной программе может быть получен ответ на вопрос " Кто известные предки Эми? "
База данных с сетевой моделью будет иметь интерфейс программирования API, позволяющий программисту "перемещаться" по записям и наборам в базе данных.
К базе данных с реляционной моделью обычно обращаются, указывая необходимые данные с помощью языка наподобие SQL. Как уже провозглашено, лучше установить, что необходимо от базы данных, чем как найти это в базе данных. В таком случае, СУБД принимает решения о том, как расположить данные, и предоставляет программисту полный ответ. Это называется непроцедурным доступом к базе данных. Однако для данной статьи преднамеренно выбран пример, для которого в языке SQL не существует стандартного способа для указания результатов с помощью непроцедурного доступа. Рекурсивная иерархия данного примера не является редкой структурой базы данных.
Переход по иерархиям в таких таблицах возможен с помощью последовательности операторов SELECT, или с помощью расширений SQL, например START WITH и CONNECT BY, поддерживаемых СУБД Oracle.
Ниже приведена реализация ответа на заданный выше вопрос с помощью сетевой модели. Псевдокод воспроизводит действия интерфейса программирования API сетевой модели, однако является упрощенным. Интерфейс API позволяет перемещаться между записями с помощью соединения их наборов с единственным вызовом.
main() {
find "Amy" record; /* "Amy" становится "текущей" записью */
if found
find_ancestors(0); }
find_ancestors(level) {
print NAME from current record, indent level*3 spaces;
find parent of OFFSPRING set;
if found {
find parent of GENETIC_FATHER set;
if found {
find_ancestors(level+1);
} find parent of GENETIC_MOTHER set;
if found {
find_ancestors(level+1);
}
}
}
Ниже представлена реализация ответа на данный вопрос с помощью реляционной модели. Реализация является процедурной , хотя многие аргументы в пользу реляционной модели связаны с возможностью непроцедурного подхода. Однако для данного примера в языке SQL нет способа выразить вопрос одним оператором (если не используются расширения фирмы-поставщика, которые можно найти в Oracle). При реализации воспроизводится сетевая модель во время перехода по базе данных, но, так как необходимы синтаксический анализ и оптимизация каждого оператора SELECT, его выполнение никак нельзя ускорить. И практическая реализация, учитывая, что в качестве интерфейса API используется интерфейс ODBC, представляет собой гораздо большее число строк программного кода, чем практическая реализация с помощью сетевой модели.
main() {
/* поиск записи "Эми" */
SELECT name, offspring FROM person
WHERE person-id = "Amy";
if found
if offspring not null
find_ancestors(name, offspring, 0);
}
find_ancestors(name, var_offspring, level) {
print name, indent level*3 spaces;
SELECT genetic-father, genetic-mother FROM procreative-rel
WHERE procreative-rel.pr-id = var_offspring;
if found {
/* поискгенетическогоотца */
if generic-father not null {
SELECT name, offspring FROM person
WHERE person-id = genetic-father;
if found
if offspring not null
find_ancestors(name, offspring, level + 1);
}
/* поискгенетическойматери */
if generic-mother not null {
SELECT name, offspring FROM person
WHERE person-id = genetic-mother;
if found
if offspring not null
find_ancestors(name, offspring, level + 1);
}
}
}
Необходимо заметить, что приведенная выше реализация, естественно, подобна реализации для сетевой модели. Однако если перед составлением данной программы недоступно представление с помощью сетевой модели, а перед программистом - только две таблицы, данная реализация была бы крайне затруднена и неестественна для изучения.
Еще одним вопросом может быть вопрос " Каковы имена потомков Рона? "
Реализация ответа на данный вопрос с помощью сетевой модели будет выглядеть следующим образом:
main() {
find "Ron" record;
find_descendents(0);
}
find_descendents(level) {
print NAME from current record, indent level*3 spaces;
for ( find first PROCREATIVE-RELATIONSHIP member;
status is FOUND;
find next member of PROCREATIVE-RELATSIONSHIP ) {
for ( find first PERSON member through OFFSPRING set;
status is FOUND;
find next PERSON member through OFFSPRING set ) {
find_descendents(level+1);
}
}
}
Какой была бы реализация ответа на данный вопрос с помощью реляционной модели? Опять-таки, это аналогичный алгоритм, но более сложный из-за необходимости использовать оператор SELECT для перехода по иерархиям.
Краткие выводы
По вопросам, рассмотренным в данной статье, можно сделать следующие краткие выводы:
- Отношения данных могут моделироваться различными способами, позволяющими фиксировать одни и те же отношения.
- От визуального представления данных зависит их наглядность, позволяющая программисту создавать программный код для перехода от одних данных к другим.
- Язык SQL, несмотря на то, что он предназначен для непроцедурного указания запросов базы данных, неспособен выполнять свое предназначение для распространенного класса структур баз данных. В такой ситуации использование языка SQL менее наглядно, более затруднительно для программирования и менее эффективно.
Заключение
В примерах, подобных приведенным выше, когда отношения данных фактически содержат одну или несколько иерархий, сетевая модель обеспечивает лучшие методы визуализации и перебора для представления и обработки данных. Результатом являются наглядные программные реализации, малые по объему и эффективные.