Лекции / Глава 17.3 Entity Framework

§17.12 Понятие информационной системы

Информационная система, согласно ISO/IEC 2382:2015, — система,

предназначенная для хранения, поиска и обработки информации, и

соответствующие организационные ресурсы (человеческие, технические,

финансовые и т. д.), которые обеспечивают и распространяют информацию.

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

информационные массивы, базы данных и информационные услуги.

По степени распределённости отличают следующие виды информационных систем:

настольные (desktop), или локальные информационные системы,

вкоторых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

распределённые (distributed) информационные системы, в

которых компоненты распределены по нескольким компьютерам.

Распределённые информационные системы, в свою очередь, разделяют

на:

файл-серверные информационные системы (информационные системы с архитектурой «файл-сервер»);

клиент-серверные информационные системы

(информационные системы с архитектурой «клиент-сервер»).

Вфайл-серверных информационных системах база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

Вклиент-серверных информационных системах база данных и СУБД находятся на сервере, а на рабочих станциях находятся только клиентские приложения.

Вданной лабораторной работе будет рассматриваться разработка настольной (desktop) версии информационной системы.

§17.13 Формирование требований к системе

Предположим, что перед нами стоит задача разработать

информационную систему для поиска дипломных руководителей. В

первую очередь мы должны изучить предметную область и процессы,

происходящие в ней. Для этого мы опрашиваем преподавателей, студентов,

читаем документацию, изучаем формы заявлений и т.п.

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

1.Регистрация и авторизация пользователей;

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

3.Просмотр аннотации о предлагаемой теме дипломного проекта;

4.Просмотр информации о преподавателе;

5.Просмотр информации о студенте;

6.Изменение персональных данных (логина, пароля, номера группы,

информация о себе …) учетной записи;

7.Добавление темы дипломного проекта и аннотации к ней;

8.Редактирование темы дипломного проекта и аннотации к ней;

9.Удаление темы дипломного проекта;

10.Закрепление студента-дипломника за преподавателем;

11.Открепление студента-дипломника от преподавателя.

В данном методическом пособии будет представлена программная

реализация

§17.14 Распределение ролей пользователей в информационной системе

В разрабатываемой информационной системе можно выделить

следующие роли пользователей:

Администратор – это «суперпользователь» информационной системы, которому предоставляется возможность редактирование данные учетных записей пользователей, добавлять, удалять пользователей и изменять наполнение информационной системы;

Студент – это пользователь информационной системы, которому предоставляется возможность просмотра тем и аннотаций дипломных

проектов, предлагаемых преподавателями, просмотра информации о

преподавателе, изменения персональных данных;

Преподаватель – это пользователь информационной системы,

которому предоставляется возможность просмотра информации о студенте,

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

закрепление/открепления студента.

§17.15 Проектирование структуры базы данных

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

качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

Основные понятия ER-диаграмм

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

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

Примерами сущностей могут быть такие классы объектов как

«Поставщик», «Сотрудник», «Накладная».

Каждая сущность в модели изображается в виде прямоугольника с наименованием:

Рисунок 17.1 – Сущность «Сотрудник»

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

сущности.

Например, представителем сущности «Сотрудник» может быть

«Сотрудник Мингалиев».

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

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

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

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

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

Рисунок 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. Нажмем Добавить и нам откроется мастер создания модели.