Метод Баркера

Появление и развитие метода. Современное состояние.

Данная модель была впервые предложена Питером Ченом в 1976 году. Ее предназначение – концептуальное моделирование предметной области.

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

Но с 1976 года рынок СУБД изменился и доминирующее положении на нем заняли именно реляционные СУБД. Соответственно, методы построения концептуальной модели тоже трансформировались, и многие возможности, которые не могут быть напрямую реализованы средствами реляционной СУБД, из них исчезли. В каком-то смысле, это неплохо – раз их все равно придется исключить на этапе даталогического проектирования, то возможно, не стоит дважды тратить время – сначала на их добавление в концептуальную модель, а затем на преобразование к структуре реляционной базы данных. Так или иначе, доступные на сегодня программные средства для построения моделей оперируют как раз такими, упрощенными подходами, поэтому в данном конспекте мы не будем рассматривать начальный вариант. Интересующиеся всегда могут обратиться к литературе, довольно хорошее описание приведено в [].

Можно также отметить, что подход анализу предметной области, реализованный в модели «сущность-связь», послужил одним из источников для методов объектно-ориентированного анализа, а сами сущности напоминают классы (правда, классы, помимо атрибутов, обладают еще и поведением).

Метод Баркера является одной из вариаций модели «сущность-связь» (Entity-Relationship model, ER-model).

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

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

Рис. 4.1 Графическое изображение сущности

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

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

· сущность обладает одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

· сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;

· каждая сущность может обладать любым количеством связей с другими сущностями модели.

В качестве имени сущности следует выбирать существительное в единственном числе и в именительном падеже.!!! Если для именования сущности используется несколько различных существительных, их также следует зафиксировать в словаре терминов предметной области. Если у наименование имеется один синоним, можно указывать его на диаграмме вместе с основным наименованием через косую черту, например «Автомобиль / Автомашина».

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

Это подчеркивается и обозначением атрибутов в методе Баркера. Атрибуты перечисляются внутри блока сущности, ниже наименования. Например – рис. 4.2.

Рис. 4.2 Обозначение атрибутов.

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

Каждая сущность обязательно должна иметь первичный ключ, то есть, один или несколько атрибутов, значения которых позволяют однозначно идентифицировать конкретный экземпляр сущности. Атрибуты, входящие состав первичного ключа обозначаются знаком «#». На приведенном примере видно, что для сущности «Студент» первичным ключом выступает номер зачетной книжки.

Также мы может пометить часть атрибутов как обязательные, то есть, каждый экземпляр сущности должен обладать ими. Когда база данных будет создана, в ней будет установлено требование обязательного заполнения полей таблицы, в которых хранятся значения обязательных атрибутов. В нашем примере обязательными являются атрибуты «Фамилия», «Имя» и «Отчество», которые помечены знаком «*». Мы предполагаем, что каждый студент обязательно имеет фамилию, имя и отчество и требуем обязательного занесения этих данных в базу данных.

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

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