<<
>>

Описательная модель предметной области

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

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

кой модели, описывающей сведения из предметной области, которые могут заинтересовать пользователей БД. Семантическая модель (semantic model) — представление совокупности о ПО понятий...

в виде графа, в вершинах которого расположены понятия, в терминальных вершинах — элементарные понятия, а дуги представляют отношения между понятиями.

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

Анализ информационных потребностей потенциальных пользователей имеет два аспекта:

¦ определение собственно сведений об объектах ПО\

¦ анализ возможных запросов к БД и требований по опе-ративности их выполнения.

Анализ возможных запросов к БД позволяет уточнить связи между сведениями, которые необходимо хранить.

Пусть, например, в БД по учебному процессу института хранятся сведения об учебных группах, читаемых курсах и кафедрах, а также связи “учебные группы—читаемые курсы” и “читаемые курсы—кафедры”. Тогда запрос о том, проводит ли некоторая кафедра занятия в конкретной учебной группе может быть выполнен только путем перебора всех читаемых в данной группе курсов.

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

Датологическое проектирование подразделяется на ло-гическое (построение концептуальной модели данных) и фи-зическое (построение физической модели) проектирование.

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

Задача физического проектирования (ФП) — выбор способа хранения данных на физических носителях и методов доступа к ним с использованием возможностей, предоставляемых СУБД.

Мифологическая модель “сущность—связь” (entity — relationship model; ER-model) П. Чена (P. Chen) представляет собой описательную (неформальную) модель ПО, семантически определяющую в ней сущности и связи [44].

Относительная простота и наглядность описания ПО по-зволяет использовать ее в процессе диалога с потенциальными пользователями с самого начала инфологического проек-тирования. Построение инфологической модели П. Чена, как и любой другой модели, является творческим процессом, ПОэтому единой методики ее создания нет. Однако при любом подходе к построению модели используют три основных конструктивных элемента:

¦ сущность;

¦ атрибут;

¦ связь.

Сущность — это собирательное понятие некоторого по-вторяющегося объекта, процесса или явления окружающего мира, о котором необходимо хранить информацию в системе.

Сущность может определять как материальные (например, ’’студент”, “грузовой автомобиль” и т. п.), так и нематериальные объекты (например, “экзамен”, “проверка” и т. п.). Главной особенностью сущности является то, что вокруг нее со-средоточен сбор информации в конкретной ПО. Тип сущности определяет набор однородных объектов, а экземпляр сущности — конкретный объект в наборе. Каждая сущность в модели Чена именуется. Для идентификации конкретного экземпляра сущности и его описания используется один или несколько атрибутов.

Атрибут — это поименованная характеристика сущности, которая принимает значения из некоторого множества значений [46]. Например, у сущности “студент” могут быть атрибуты “фамилия”, “имя”, “отчество”, “дата рождения”, “средний балл за время обучения” и т. п.

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

Связи должны быть поименованы; между двумя типами сущностей могут существовать несколько связей.

Наиболее распространены бинарные связи. Учитывая, что любую п-арную связь можно представить в виде нескольких бинарных, подробнее остановимся именно на таких связях между двумя типами сущностей, устанавливающими соответствие между множествами экземпляров сущностей.

Различают четыре типа связей:

¦ связь один к одному (1:1);

¦ связь один ко многим (1:М);

¦ связь многие к одному (М:1);

¦ связь многие ко многим (М:Ы).

Связь один к одному определяет такой тип связи между типами сущностей А и В, при которой каждому экземпляру сущности А соответствует один и только один экземпляр сущ-ности В, и наоборот. Таким образом, имея некоторый экземпляр сущности А, можно однозначно идентифицировать со-ответствующий ему экземпляр сущности В, а по экземпляру сущности В — экземпляр сущности А.

Например, связь типа 1:1 “имеет” может быть определена между сущностями “ав-томобиль” и “двигатель”, так как на конкретном автомобиле может быть установлен только один двигатель, и этот двигатель, естественно, нельзя установить сразу на несколько автомобилей.

Связь один ко многим определяет такой тип связи между типами сущностей А и В, для которой одному экземпляру сущности А может соответствовать 0, 1 или несколько экзем-пляров сущности В, но каждому экземпляру сущности В со-ответствует один экземпляр сущности А. При этом однозначно идентифицировать можно только экземпляр сущности А по экземпляру сущности В. Примером связи типа 1:М является связь “учится” между сущностями “учебная группа” и “студент”. Для такой связи, зная конкретного студента, можно однозначно идентифицировать учебную группу, в которой он учится, или, зная учебную группу, можно определить всех обучающихся в ней студентов.

Связь многие к одному по сути эквивалентна связи один ко многим. Различие заключается лишь в том, с точки зрения какой сущности (А или В) данная связь рассматривается.

Связь многие ко многим определяет такой тип связи между типами сущностей А и В, при котором каждому экземпляру сущности А может соответствовать 0, 1 или несколько экземпляров сущности В, и наоборот. При такой связи, зная экземпляр одной сущности, можно указать все экземпляры другой сущности, относящиеся к исходному, т. е. идентификация сущностей не уникальна в обоих направлениях. В качестве примера такой связи можно рассмотреть связь “изучает” между сущностями “учебная дисциплина” и “учебная группа”.

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

Различают простую и многозначную однонаправленные связи, которые являются аналогами связей типа 1:1 и 1:М с учетом направления идентификации. Так, для простой однонаправленной связи “староста” (“является старостой”) между сущностями “учебная группа” и “студент” можно, зная учебную группу, однозначно определить ее ста-росту, но, зная конкретного студента, нельзя сказать, является ли он старостой учебной группы. Примером многозначной однонаправленной связи служит связь между сущностями “пациент” и “болезнь”, для которой можно для каждого пациента указать его болезни, но нельзя выявить всех обладателей конкретного заболевания.

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

Графически типы сущностей, атрибуты и связи принято изображать прямоугольниками, овалами и ромбами соответ-ственно. Несмотря на то, что построение инфологической модели есть процесс творческий, можно указать два основополагающих правила, которыми следует пользоваться всем проектировщикам БД [15,44]:

¦ при построении модели должны использоваться только три типа конструктивных элементов: сущность, атрибут, связь;

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

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

Так, информация о том, что некоторый студент входит в состав учебной группы (УГ) можно в модели представить:

¦ как связь “входит в состав” для сущностей “студент” и “УГ”;

¦ как атрибут “имеет в составе “студента” сущности “УГ”;

¦ как сущность “состав УГ”.

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

При моделировании ПО следует обращать внимание на существующий в ней документооборот.

Именно документы, циркулирующие в ПО, должны являться основой для форму-лирования сущностей. Это связано с двумя обстоятельствами:

¦ эти документы, как правило, достаточно полно отражают информацию, которую необходимо хранить в БД, причем в виде конкретных данных;

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

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

Помимо идентифицирующих используются и описательные атрибуты, предназначенные для более полного определения сущностей. Число атрибутов (их тип) определяется единственным образом — на основе анализа возможных запросов пользователей. Существует ряд рекомендаций по “ра

боте с атрибутами” [15, 44], например, по исключению по-вторяющихся групп атрибутов Все они направлены на улучшение качества инфологической модели.

При определении связей между сущностями следует из-бегать связей типа М:Ы, так как они приводят к существенным затратам ресурсов ЭВМ. Устранение таких связей пре-дусматривает введение других (дополнительных) элементов — сущностей и связей.

В заключение приведем типовую последовательность работ (действий) по построению инфологической модели:

¦ выделение в ПО сущностей;

¦ введение множества атрибутов для каждой сущности и выделение из них ключевых;

¦ исключение множества повторяющихся атрибутов (при необходимости);

¦ формирование связей между сущностями;

¦ исключение связей типа М:Ы (при необходимости);

¦ преобразование связей в однонаправленные (по возмож-ности).?

Помимо модели Чена существуют и другие инфологические модели. Все они представляют собой описательные (неформальные) модели, использующие различные конструк-тивные элементы и соглашения по их использованию для представления в БД информации о ПО. Иными словами, первый этап построения БД всегда связан с моделированием предметной области.

<< | >>
Источник: В. Б. Уткин. Информационные системы в экономике. 2008

Еще по теме Описательная модель предметной области:

  1. По предметному признаку
  2. Эволюционно-симулятивная модель равновесия на фондовом рынке (модель «мм5»)
  3. Модель формирования финансовых потоков и разработка модели механизма принятия оптимального решения по выбору параметров страхования кредитного риска
  4. ПОЛОЖЕНИЕ О главе администрации края, области, города федерального значения, автономной области, автономного округа Российской Федерации
  5. Читинская область
  6. Модели продолжения тенденции
  7. Курганская область
  8. Другие модели разворота
  9. Вариации в типах моделей
  10. Владимирская область
  11. Оперативная постановка математической модели
  12. Министерство финансов Пензенской области