Введение в базы данных Birdstep: Моделирование данных с помощью сетевой и реляционной моделей

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

Будут рассмотрены следующие вопросы:

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

Краткое определение моделей данных

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

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

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

ОТДЕЛ → ВКЛЮЧАЕТ В СЕБЯ → СОТРУДНИК

Название "сетевая модель" объясняется тем, что несколько прямоугольников могут соединяться с другими прямоугольниками с помощью нескольких стрелок:

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

СОТРУДНИК

Фамилия Имя Номер социального страхования          Дата рождения Название отдела

ОТДЕЛ

Название отдела Подчиненность отдела

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

Пример для сравнения

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

Сетевая модель

"Сетью" отношений данных, которая может быть визуально представлена в естественном виде, является родословное дерево.  На рисунке ниже показана сетевая модель, изображенная в виде простой схемы.

ПОТОМОК

ЛИЦО

ГЕНЕТИЧЕСКАЯ МАТЬ

ГЕНЕТИЧЕСКИЙ ОТЕЦ

ОТНОШЕНИЕ ДЕТОРОЖДЕНИЯ

В данном примере показано, что ЛИЦО может быть или ГЕНЕТИЧЕСКОЙ МАТЕРЬЮ, или ГЕНЕТИЧЕСКИМ ОТЦОМ, с отсутствующими или с одним или несколькими ОТНОШЕНИЯМИ ДЕТОРОЖДЕНИЯ.  ОТНОШЕНИЯ ДЕТОРОЖДЕНИЯ могут привести к появлению одного или нескольких ЛИЦ, имеющих отношение ПОТОМОК.  На схеме показана форма данных, а не фактические данные.  Ниже дано визуальное представление данных, взятых в качестве примера, в форме такой схемы.  В данном примере показана часть родословного дерева для трех поколений.

Два типа записей и три типа наборов позволяют представить в базе данных любые наследственные отношения, включая детей от родителей из нескольких отношений.

Простая схема обеспечивает визуальное представление записей данных и их отношений друг к другу, как показано на примере выше.

Реляционная модель

Для сопоставления сетевой и реляционной моделей ниже показаны две реляционные таблицы - одна из них содержит данные о ЛИЦАХ, а другая - данные об ОТНОШЕНИЯХ ДЕТОРОЖДЕНИЯ.  Эти таблицы, вместе с соответствующими отношениями первичных/внешних ключей, представляют то же самое родословное дерево, что и показанное выше.

ЛИЦО

Отношения между строками таблиц устанавливаются через совпадение значений столбцов, часто называемых отношениями ПЕРВИЧНЫХ/ВНЕШНИХ КЛЮЧЕЙ.  В данном примере ИДЕНТИФИКАТОР ЛИЦА и ИДЕНТИФИКАТОР ОД - первичные ключи.  ПОТОМОК - внешний ключ ИДЕНТИФИКАТОРА ОД, а ГЕНЕТИЧЕСКИЙ ОТЕЦ и ГЕНЕТИЧЕСКАЯ МАТЬ - внешние ключи ИДЕНТИФИКАТОРА ЛИЦА

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

Сравнительное описание программирования приложений

В данном разделе предполагается, что читатель имеет определенное знакомство с языком 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 менее наглядно, более затруднительно для программирования и менее эффективно.

Заключение

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