Материал: Глава 17.3 Entity Framework

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

Связи позволяют по одной сущности находить другие сущности,

связанные с нею.

Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».

Графически связь изображается линией, соединяющей две сущности:

Рисунок 17.4 – Связь между сущностями «Сотрудник» и «Ребенок»

Каждая связь имеет два конца и одно или два наименования.

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

Каждая связь может иметь один из следующих типов связи:

Рисунок 17.5 – Типы связей

Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Эта связь имеет еще один подвид, который называется ноль-или-один-к-одному

(zero-or-one-to-one). При этом виде связи, в зависимой таблице необязательно указывать связанную строку, т.е. одной строке в главной таблице, может соответствовать ноль или одна строка в зависимой таблице.

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности

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

дочерней. Характерный пример такой связи приведен на рисунке 17.4.

Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности,

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

временным типом связи, допустимым на ранних этапах разработки модели. В

дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-

многим путем создания промежуточной сущности.

Пример разработки ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1.Список сущностей предметной области.

2.Список атрибутов сущностей.

3.Описание взаимосвязей между сущностями.

ER-диаграммы удобны тем, что процесс выделения сущностей,

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

являются сами ER-диаграммы.

Ранее, во втором параграфе, мы выделили все требования к разрабатываемой информационной системе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты:

Пользователь - явный кандидат на сущность.

Студент - явный кандидат на сущность.

Преподаватель - явный кандидат на сущность.

Дипломная работа - явный кандидат на сущность.

Сразу возникает очевидная связь между сущностями – «Студент является Пользователем», «Преподаватель является Пользователем», «Преподаватель является дипломным руководителем студентом» и «Преподаватель предлагает темы дипломных работ». Первый вариант диаграммы выглядит так:

Рисунок 17.6 – Диаграмма сущностей

Определим набор атрибутов сущностей. Анализируя предметную область, мы выяснили следующее:

Каждый пользователь информационной системы имеет логин,

пароль и роль для авторизации.

Каждый студент имеет фамилию, имя, отчество, номер группы,

персональные данные о себе, личную фотографию.

Каждая преподаватель имеет фамилию, имя, отчество, должность,

персональные данные о себе, личную фотографию, список предлагаемых им тем дипломных работ.

Каждая дипломная работа имеет тему и аннотацию.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

Фамилия/имя/отчество – можно объединить в единый атрибут ФИО, который будет являться явной характеристикой студента и преподавателя.

Логин – явная характеристика пользователя.

Пароль – явная характеристика пользователя.

Роль – явная характеристика пользователя.

Авторизация – процесс предоставление определённому лицу или группе лиц прав на использование возможностей системы. Не является характеристикой.

Номер группы – явная характеристика студента.

Персональные данные о себе – явная характеристика студента и преподавателя.

Личная фотография – явная характеристика студента и преподавателя.

Предлагаемые темы дипломных работ – явная характеристика преподавателя.

Тема дипломной работы – явная характеристика дипломной

работы.

Аннотация к дипломной работе – явная характеристика дипломной работы.

Теперь можно внести все это в диаграмму:

Рисунок 17.7 - ER-диаграмма

Данный пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД.

Построение физической модели базы данных

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

Итак, создадим новый проект по типу Приложение Windows Forms. И

затем добавим в проект новый элемент. Нажмем правой кнопкой мыши на проект в окне Обозреватель решений и в появившемся списке выберем

Добавить → Создать элемент. И затем в окне добавления нового элемента выберем Модель ADO.NET EDM:

Рисунок 17.8 – Добавление нового элемента Модель ADO.NET EDM

Модель назовем EntityModel. Нажмем Добавить и нам откроется мастер создания модели.