(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

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

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

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

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

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

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

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

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

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

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

СОТРУДНИК

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

ОТДЕЛ

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

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

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

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

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

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

ПОТОМОК

ЛИЦО

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

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

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

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

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

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

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

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

ЛИЦО

Идентификатор лица

Имя

Пол

Потомок

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

Заключение

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

Ссылки по теме


 Распечатать »
 Правила публикации »
  Обсудить материал в конференции Birdstep »
Написать редактору 
 Рекомендовать » Дата публикации: 14.01.2008 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
FastReport VCL 6 Standard Edition Single License
go1984 pro
ESET NOD32 Smart Security - продление лицензии на 1 год на 3ПК, Ключ
ABBYY Business Card Reader 2.0 for Windows (download), электронный ключ
NauDoc Enterprise 10 рабочих мест
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Утиль - лучший бесплатный софт для Windows
Проект mic-hard - все об XP - новости, статьи, советы
 
Статьи по теме
 
Новинки каталога Download
 
Обсуждения в форумах
RDM Server (1)
При установке данного ПО в журнале событий появляется вот такое уведомление: Не найдено...
 
Delphi 2007: первые впечатления (3)
Новая версия каждые полгода - это круто!!! Конечно при таком темпе когда ее доделать до...
 
конфликт Windows 2003 Terminal Server и Rdm Server от Birdstep (3)
Здравствуйте! Есть проблема с RDM Birdstep. Если установлены Terminal Services в Windows 2003 ,...
 
Raima соединение DLEPHI (1)
Обращаюсь с вопросом по поводу Raima Database. Есть реальный локальный сервер на базе RedHat...
 
Работа с базами в RT (1)
Привет всем! Я имею опыт работы с SQL реляционными базами данных, для которых разрабатывал и...
 
 
 



    
rambler's top100 Rambler's Top100