<<
>>

Выбор модели данных

Существование различных моделей данных обусловлено большим количеством разработанных к настоящему времени разнообразных СУБД.

Проектировщик БнД, выбирая для своей системы СУБД общего назначения, прежде всего сталкивается с проблемой выбора наиболее подходящей МД для своей прикладной области.

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

Пример. Пусть рассматриваемая модель данных оперирует понятиями Поле, Запись, База данных, определяющими ее понятийный базис; Поле — поименованное элементарное данное; Запись — поименованная совокупность полей; База данных — поименованная совокупность записей. Тогда прямое моделирование может быть выполнено для следующих типов понятий инфологической модели ПО:

1) атрибут сущности будет смоделирован полем;

2) значение атрибута — значением поля;

3) тип сущности будет смоделирован типом записи.

Например, тип сущности Служащий, описываемый атрибутами Табельный номер, Фамилия, Год рождения и Образование, может быть смоделирован типом записи, схема которой имеет вид

Служащий (Табельный номер. Фамилия, Год рождения, Образование)

Или, если придерживаться символики, принятой в языках описания многих

СУБД:

1 Служащий

2 Табельный номер;ШАБЛОН 9999;КЛЮЧ 02 Фамилия;ШАБЛОН А(25)

02 Год рождения;ШАБЛОН 9999 02 Образование;ШАБЛОН А(10),

где 9999 означает, что значение поля представляет собой число, состоящее из четырех десятичных цифр; А(25) означает, что значение поля будет символьное, длиной 25 символов; 01, 02 — номера уровней в схеме структуры (в данном случае в схеме структуры записи); КЛЮЧ означает, что данное поле является первичным ключом записи;

4) экземпляр сущности моделируется экземпляром записи;

5) набор экземпляров сущностей одного типа моделируется одной БД, например, БД Служащие, представляющей совокупность записей типа Служащий.

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

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

Например, связь Работает_в между сущностями Служащий и Отдел представим как самостоятельную сущность с атрибутами Шифр отдела и Табельный номер, которую можно смоделировать следующим типом записи:

1 Работаете

2 Табельный_номер;ШАБЛОН 9999;КЛЮЧ 02 Шифр_отдела;ШАБЛОН 99;КЛЮЧ

А набор экземпляров сущностей этого типа будет смоделирован отдельной БД. Косвенное моделирование данной связи можно также выполнить как атрибут сущностей Служащий, что отразится в соответствующем изменении схемы записи Служащий:

1 Служащий

2 Табельный_номер;ШАБЛОН 9999;КЛЮЧ 02 Шифр_отдела;ШАБЛОН 99

02 Фамилия;ШАБЛОН А(25)

02 Год_рождения;ШАБЛОН 9999 02 Образование;ШАБЛОН А(10)

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

Чем больше конструкций инфологической модели ПО может быть представлено прямым моделированием при датологическом проектировании БД, тем более удачной считается рассматриваемая модель данных.

Кроме анализа возможностей прямого моделирования проектировщик оценивает и такие свойства модели данных СУБД, как:

• сложность модели для изучения пользователями;

• простота и элегантность (возможность представления структуры данных в наглядной форме);

• сложность и трудоемкость написания определений данных и программ для манипулирования структурами данных и пр.

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

2.1.

<< | >>
Источник: Григорьев Ю.А., Ревунков Г.И.. Банки данных. 2002

Еще по теме Выбор модели данных:

  1. Выбор линейного мышления - это выбор прожить жизнь в танце частиц.
  2. Выбор есть. Он существует всегда. Сознание - это выбор.
  3. Григорьев Ю.А., Ревунков Г.И.. Банки данных, 2002
  4. Модель личности журналиста: профессиональные, социально-гражданские, нравственные, психологические и социально-демографические характеристики. Модификация общей модели для разных специализаций (репортер, аналитик, расследователь, публицист, ведущий-модератор и т.п.).
  5. Оценка данных о личности.
  6. 18.4. Права субъекта персональных данных
  7. Банк данных
  8. 3.3.4. Методы обработки и анализа данных
  9. Анализ и интерпретация полученных данных
  10. Анализ и интерпретация полученных данных