Эта модель является неформальной моделью ПО и используется на этапе инфологического проектирования БД. Модель реализована в соответствии с положениями инфологического подхода, рассмотренного выше. Она позволяет моделировать объекты ПО, в которых применяются БнД, а также взаимоотношения этих объектов. Относительная простота, применение естественного языка и легкость понимания позволяют использовать эту модель как инструмент для общения с будущими пользователями с целью сбора информации о ПО для проектирования БД системы.
Основное назначение неформальной модели «сущность – связь» – семантическое описание ПО и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе. Существует несколько подходов к построению этой модели, однако общим для всех является использование трех основных конструктивных элементов для представления составляющих ПО – сущности, атрибута и связи. Информация о проекте суммируется с использованием графических диаграмм.
Составляющая «время» в составе конструктивных элементов в явном виде отсутствует. Время наступления событий может быть представлено в модели с использованием атрибутов, например: Год рождения, Дата поступления, Окончено в мае, Получено в декабре и т.п.
Сущность –это собирательное понятие, некоторая абстракция реально существующего объекта, процесса или явления, о котором необходимо хранить информацию в системе. В качестве сущностей могут рассматриваться как материальные (предприятие, изделие, сотрудники учреждения и т.п.), так и нематериальные объекты реальной действительности (описание некоторого явления, рефераты научных статей, описание применяемых в системе структур данных и т.д.). В модели ПО «сущность – связь» каждая конкретная сущность является узловой точкой сбора информации об этой сущности.
|
|
В модели используется также понятие «экземпляр сущности». Тип сущности определяет набор однородных объектов, а понятие «экземпляр сущности» относится к конкретному объекту в наборе. Каждый рассматриваемый в модели тип сущности должен быть поименован.
Для идентификации конкретных экземпляров сущностей в некотором типе сущности при ее описании используются специальные атрибуты, выполняющие роль идентификатора. Это может быть один или несколько атрибутов, значения которых позволяют однозначно отличать один экземпляр сущности от другого.
Атрибут – это поименованная характеристика сущности. Атрибут принимает значения из некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Например, для описания свойств сущности Книга могут быть использованы атрибуты Название, Фамилия автора, Год издания.
Для того чтобы задать атрибут в модели, необходимо присвоить ему наименование, привести смысловое описание атрибута, определить множество его допустимых значений и указать его роль, т.е. для чего он используется.
Основная роль атрибута – описание свойства сущности. Другой важной ролью атрибута является идентификация экземпляров сущностей. Например, атрибут Шифр детали, которому соответствует множество уникальных значений шифров деталей (т.е. каждая деталь имеет одно значение шифра), позволяет однозначно идентифицировать конкретные экземпляры сущности Деталь в соответствующем наборе. Атрибут используется и для представления связей (отношений) между сущностями, поскольку связь (отношение) характеризует именно те объекты, между которыми она существует (например, отношение Отец – характер родства), и поэтому может выступать в роли свойства, признака сущности.
|
|
Связь. В модели выступает в качестве средства, с помощью которого представляются отношения между сущностями, имеющие место в ПО. Тип связи рассматривается между типами сущностей, а конкретный экземпляр связи рассматриваемого типа существует между конкретными экземплярами рассматриваемых типов сущностей.
При анализе связей между сущностями могут встречаться бинарные связи (связи между двумя сущностями) и в общем случае n -арные связи. Наиболее общий случай (часто встречаемый), когда связь является бинарной. Приведем его классификацию.
Для определения характера взаимосвязей между парами связанных элементов используются отображения и ассоциации. Ассоциация – это односторонняя связь. Отображение представляет собой совокупность ассоциаций – прямой и инверсной, т.е. отображение – это двусторонняя связь. При определении взаимосвязей между элементами модели в одних случаях целесообразно задавать двусторонние связи (используются отображения), а в других – односторонние связи (используются ассоциации).
Наиболее часто встречаются бинарные связи. Рассмотрим классификацию бинарных связей.
|
|
Отображение 1:1 (связь один – к одному).Это отображение определяет такой тип связи между элементами А и В, когда каждому экземпляру элемента В соответствует один и только один экземпляр элемента А. Это означает, что один экземпляр элемента, от которого направлена связь, например А, идентифицирует один и только один экземпляр другого элемента В (к которому направлена связь), и наоборот. Идентификация экземпляров элементов уникальна в обоих направлениях для отображения 1:1.
Отображение 1: М (связь один – ко многим).Отображение 1 :М определяет такой тип связи между элементами А и В, когда одному экземпляру элемента А соответствует 0, 1 или несколько экземпляров элемента В. Но при этом каждый экземпляр элемента В связан только с одним экземпляром элемента А, т.е. идентификация экземпляров при отображении 1:М уникальна только в направлении от В к А.
Отображение М:1 (связь многие – к одному). Это отображение является обратным отображению 1: М.
Отображение М:М (связь многие – ко многим).Отображение М:М определяет тип связи между элементами А и В, при котором каждому экземпляру элемента А соответствует 0, 1 или несколько экземпляров элемента В и наоборот, т.е. с одним экземпляром А может быть связано либо несколько экземпляров элемента В, либо один, либо ни одного. И наоборот, с одним экземпляром элемента В также может быть связано либо несколько экземпляров элемента А, либо один, либо ни одного, т.е. идентификация экземпляров элементов является неуникальной в обоих направлениях.
Ассоциация типа 1 (простая).Ассоциация этого типа определяет однонаправленную связь от элемента А к элементу В, при которой одному и тому же экземпляру элемента А соответствует один и тот же экземпляр элемента В. При этом обратная связь не определена. Идентификация экземпляров элемента В экземплярами элемента А является уникальной (однозначной).
Ассоциация типа М (сложная).Ассоциация типа М определяет однонаправленную связь от элемента А к элементу В, при которой одному и тому же экземпляру элемента А соответствует 0, 1 или несколько экземпляров элемента В. При этом обратная связь не определена. Идентификация экземпляров элемента В экземплярами элемента А не является уникальной.
Иногда специально выделяют частный случай М-ассоциации – когда одному экземпляру элемента А соответствует только один или ни одного экземпляра элемента В. Такая ассоциация называется «условная» и обозначается как ассоциация типа С.
Связи (отношения) между сущностями специфицируются выражениями реляционного типа. В отношениях сущности всегда представлены своими идентифицирующими атрибутами (идентификаторами).
Во многих случаях бывает интересен не сам факт наличия отношения между сущностями, а свойства этого отношения. Для производственно-экономических областей эти свойства определяются некоторой числовой мерой. Отношение сущностей совместно с числовой мерой этого отношения определяют показатель – понятие, широко используемое в управленческой деятельности. В этих случаях можно рассматривать интересующий тип отношения как некоторый тип сущности (что не противоречит введенному понятию). Например, отношение
Деталь X размещена на складе 4
представляет собой объект, о котором хотят сохранить информацию, например, о количестве деталей, что и должно быть представлено соответствующим атрибутом Количество.
Или, например, отношение Экзамен между сущностями Студент, Дисциплина и Преподаватель само может рассматриваться как сущность и иметь, например, следующие описательные атрибуты: Оценка и Дата Экзамена.
Информацию о проекте суммируют составлением спецификаций по сущностям, атрибутам и отношениям с использованием графических диаграмм. Для этих диаграмм можно использовать следующие обозначения:
типы сущностей обозначать прямоугольниками;
атрибуты обозначать овалами, соединяя их с соответствующими типами сущностей ненаправленными ребрами;
связи (отношения) представлять ромбами, соединяя их с соответствующими типами сущностей, ненаправленными ребрами, за исключением бинарных связей, которые представляются направленными ребрами.
При выполнении моделирования применяют следующие общие правила:
используют только три типа конструктивных элементов сущность, атрибут, связь;
в каждом отдельном проектном представлении каждый компонент информации моделируют только одним конструктивным элементом (т.е. при моделировании представлений необходимо избегать избыточности в использовании конструктивных элементов).
Для моделирования ПО проектировщик разбивает ее на ряд локальных областей, в каждой из которых и выполняет моделирование. Затем модели объединяются.
Понятие модели данных
Развитие теории и практики проектирования и эксплуатации БД сопровождается интенсивным развитием МД. В предыдущих параграфах речь шла о моделях ПО: концептуальная инфологическая модель и внешние инфологические модели, традиционно получившие названия концептуальная, внутренняя и внешние модели базы данных. В настоящем же параграфе речь пойдет именно о моделях данных.
Каждая ЭВМ обладает хотя и относительно простой, но определенной моделью данных: это допустимые в ЭВМ форматы данных, команд и состав операций, выполняемых над ними. С помощью этой исходной модели данных могут быть построены другие, более сложные модели данных, т.е. может быть выполнен переход к некоторой абстрактной машине, обладающей удобной моделью данных для представления исходных данных и решения прикладных задач.
Модель данных, поддерживаемую некоторым языком программирования, характеризуют следующим образом:
1) идентифицируют типы логических структур данных, которые могут быть представлены в модели данных; считают, что две структуры следует рассматривать как структуры различного типа, если они имеют различные признаки, правила композиции или правила их обработки (правила манипулирования) процедурными операторами;
2) специфицируют признаки (характеристики) структур данного типа;
3) специфицируют правила композиции (составления) структур данного типа из логических структур других типов;
4) специфицируют правила обработки структур данного типа процедурными операторами.
В связи с функциональными требованиями БнД операторы описания и процедурные операторы разделены и оформлены в виде самостоятельных языков (соответственно ЯОД и ЯМД). Поэтому можно сказать, что совокупность этих языков определяет МД, поддерживаемую конкретной рассматриваемой СУБД. Эта МД представляет собой совокупность методов и средств, представляемых языками ЯОД и ЯМД данной СУБД, для определения логической структуры БД и динамического моделирования в БД состояний ПО.
Дополнительно к структурам данных СУБД создают их схемы. Схемой структуры данных называется описание структуры некоторого типа данных на формализованном языке. Эта схема задает совокупность свойств, присущих данному типу структуры данных. Реализацией схемы является конкретная структура данных соответствующего типа. Каждая конкретная реализация называется экземпляром схемы.
Выбор модели данных
Существование различных моделей данных обусловлено большим количеством разработанных к настоящему времени разнообразных СУБД.
Проектировщик БнД, выбирая для своей системы СУБД общего назначения, прежде всего сталкивается с проблемой выбора наиболее подходящей МД для своей прикладной области. В первую очередь он оценивает возможности рассматриваемой МД с точки зрения так называемого «прямого» моделирования понятий, сформулированных в инфологической модели ПО, только такими структурами данных, которые составляют понятийный базис данной модели.
Пример. Пусть рассматриваемая модель данных оперирует понятиями Поле, Запись, База данных, определяющими ее понятийный базис; Поле – поименованное элементарное данное; Запись – поименованная совокупность полей; База данных – поименованная совокупность записей. Тогда прямое моделирование может быть выполнено для следующих типов понятий инфологической модели ПО:
1) атрибут сущности будет смоделирован полем;
2) значение атрибута – значением поля;
3) тип сущности будет смоделирован типом записи.
Например, тип сущности Служащий, описываемый атрибутами Табельный номер, Фамилия, Год рождения и Образование, может быть смоделирован типом записи, схема которой имеет вид
Служащий (Табельный номер, Фамилия, Год рождения, Образование)
Или, если придерживаться символики, принятой в языках описания многих СУБД:
01 Служащий
02 Табельный номер;ШАБЛОН 9999;КЛЮЧ
02 Фамилия;ШАБЛОН А(25)
02 Год рождения;ШАБЛОН 9999
02 Образование;ШАБЛОН А(10),
где 9999 означает, что значение поля представляет собой число, состоящее из четырех десятичных цифр; А(25) означает, что значение поля будет символьное, длиной 25 символов; 01, 02 – номера уровней в схеме структуры (в данном случае в схеме структуры записи); КЛЮЧ означает, что данное поле является первичным ключом записи;
4) экземпляр сущности моделируется экземпляром записи;
5) набор экземпляров сущностей одного типа моделируется одной БД, например, БД Служащие, представляющей совокупность записей типа Служащий.
В рассмотренном примере нельзя выполнить прямое моделирование связей между сущностями, но это не означает, что связи вообще нельзя смоделировать с помощью структур, допустимых используемой в примере МД. Отсутствие в МД прямого двойника для рассматриваемого понятия означает, что моделировать нужно косвенным образом, используя допускаемые моделью типы структур данных.
Также в данном примере можно косвенным образом смоделировать связи между сущностями инфологической модели. Для этого можно отдельно рассматривать каждую связь как самостоятельную сущность, атрибутами которой являются идентифицирующие атрибуты сущностей, входящих в связь.
Например, связь Работает_в между сущностями Служащий и Отдел представим как самостоятельную сущность с атрибутами Шифр_отдела и Табельный_номер, которую можно смоделировать следующим типом записи:
01 Работает_в
02 Табельный_номер;ШАБЛОН 9999;КЛЮЧ
02 Шифр_отдела;ШАБЛОН 99;КЛЮЧ
А набор экземпляров сущностей этого типа будет смоделирован отдельной БД.
Косвенное моделирование данной связи можно также выполнить как атрибут сущностей Служащий, что отразится в соответствующем изменении схемы записи Служащий:
01 Служащий
02 Табельный_номер;ШАБЛОН 9999;КЛЮЧ
02 Шифр_отдела;ШАБЛОН 99
02 Фамилия;ШАБЛОН А(25)
02 Год_рождения;ШАБЛОН 9999
02 Образование;ШАБЛОН А(10)
Необходимо отметить, что в развитых МД число косвенных путей моделирования существенно возрастает.
Чем больше конструкций инфологической модели ПО может быть представлено прямым моделированием при датологическом проектировании БД, тем более удачной считается рассматриваемая модель данных.
Кроме анализа возможностей прямого моделирования проектировщик оценивает и такие свойства модели данных СУБД, как:
• сложность модели для изучения пользователями;
• простота и элегантность (возможность представления структуры
данных в наглядной форме);
• сложность и трудоемкость написания определении данных и программ для манипулирования структурами данных и пр.
Все многообразие существующих моделей данных конкретных СУБД можно подразделить на несколько типов моделей данных. Проектировщик БД, закончив первый вариант инфологического проектирования, подготавливает датологический проект для выбранного типа модели данных, а затем уже выбирает конкретную СУБД и заканчивает датологическое проектирование БД, используя уже модель данных этой конкретной СУБД.