![](/user_photo/71077_gtxyM.jpg)
Лекции / Глава 17.3 Entity Framework
.pdfГЛАВА 17.3 ENTITY FRAMEWORK |
|
Оглавление |
|
§17.12 Понятие информационной системы.......................................................... |
1 |
§17.13 Формирование требований к системе ....................................................... |
2 |
§17.14 Распределение ролей пользователей в информационной системе ........ |
3 |
§17.15 Проектирование структуры базы данных................................................. |
4 |
§17.16 Создание интерфейса приложения.......................................................... |
20 |
§17.117.1 TableLayoutPanel .................................................................................. |
20 |
§17.117.2 Разработка форм приложения .......................................................... |
22 |
§17.117.2.1 Форма авторизации.......................................................................... |
22 |
§17.117.2.2 Форма регистрации .......................................................................... |
23 |
§17.117.2.3 Форма профиля студента ............................................................... |
24 |
§17.117.2.4 Форма настройки профиля студента............................................ |
25 |
§17.117.2.5 Форма информации о преподавателе............................................. |
26 |
§17.117.2.6 Форма профиля преподавателя....................................................... |
27 |
§17.117.2.7 Форма информации о студентах.................................................... |
28 |
§17.117.2.8 Форма профиля администратора .................................................. |
29 |
§17.17 Разработка функционала приложения .................................................... |
30 |
§17.17.1 Регистрация пользователя ................................................................... |
30 |
§17.17.2 Авторизация пользователя ................................................................... |
37 |
§17.17.3 Просмотр списка преподавателей ...................................................... |
39 |
§17.17.4 Добавление темы дипломной работы ................................................. |
44 |
§17.17.5 Редактирование темы дипломной работы ........................................ |
47 |
§17.17.6 Удаление темы дипломной работы..................................................... |
48 |
§17.17.7 Просмотр информации о студентах .................................................. |
48 |
§17.12 Понятие информационной системы
Информационная система, согласно ISO/IEC 2382:2015, — система,
предназначенная для хранения, поиска и обработки информации, и
соответствующие организационные ресурсы (человеческие, технические,
финансовые и т. д.), которые обеспечивают и распространяют информацию.
Информационная система предназначена для своевременного обеспечения пользователей приложения надлежащей информацией, то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция — документы,
информационные массивы, базы данных и информационные услуги.
По степени распределённости отличают следующие виды информационных систем:
настольные (desktop), или локальные информационные системы,
вкоторых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;
распределённые (distributed) информационные системы, в
которых компоненты распределены по нескольким компьютерам.
Распределённые информационные системы, в свою очередь, разделяют
на:
файл-серверные информационные системы (информационные системы с архитектурой «файл-сервер»);
клиент-серверные информационные системы
(информационные системы с архитектурой «клиент-сервер»).
Вфайл-серверных информационных системах база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.
Вклиент-серверных информационных системах база данных и СУБД находятся на сервере, а на рабочих станциях находятся только клиентские приложения.
Вданной лабораторной работе будет рассматриваться разработка настольной (desktop) версии информационной системы.
§17.13 Формирование требований к системе
Предположим, что перед нами стоит задача разработать
информационную систему для поиска дипломных руководителей. В
первую очередь мы должны изучить предметную область и процессы,
происходящие в ней. Для этого мы опрашиваем преподавателей, студентов,
читаем документацию, изучаем формы заявлений и т.п.
После этапа выявления требований нами были определены следующие функциональные возможности, которые должна предоставлять разрабатываемая информационная система:
1.Регистрация и авторизация пользователей;
2.Просмотр тем дипломных проектов, предлагаемых преподавателями;
3.Просмотр аннотации о предлагаемой теме дипломного проекта;
4.Просмотр информации о преподавателе;
5.Просмотр информации о студенте;
6.Изменение персональных данных (логина, пароля, номера группы,
информация о себе …) учетной записи;
7.Добавление темы дипломного проекта и аннотации к ней;
8.Редактирование темы дипломного проекта и аннотации к ней;
9.Удаление темы дипломного проекта;
10.Закрепление студента-дипломника за преподавателем;
11.Открепление студента-дипломника от преподавателя.
В данном методическом пособии будет представлена программная
реализация
§17.14 Распределение ролей пользователей в информационной системе
В разрабатываемой информационной системе можно выделить
следующие роли пользователей:
Администратор – это «суперпользователь» информационной системы, которому предоставляется возможность редактирование данные учетных записей пользователей, добавлять, удалять пользователей и изменять наполнение информационной системы;
Студент – это пользователь информационной системы, которому предоставляется возможность просмотра тем и аннотаций дипломных
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr4x1.jpg)
проектов, предлагаемых преподавателями, просмотра информации о
преподавателе, изменения персональных данных;
Преподаватель – это пользователь информационной системы,
которому предоставляется возможность просмотра информации о студенте,
изменения персональных данных, добавление или редактирования темы дипломного проекта и аннотации к ней, удаления темы дипломного проекта,
закрепление/открепления студента.
§17.15 Проектирование структуры базы данных
При проектировании структуры базы данных часто применяются метод семантического моделирования. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В
качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Основные понятия ER-диаграмм
Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Примерами сущностей могут быть такие классы объектов как
«Поставщик», «Сотрудник», «Накладная».
Каждая сущность в модели изображается в виде прямоугольника с наименованием:
Рисунок 17.1 – Сущность «Сотрудник»
Экземпляр сущности - это конкретный представитель данной
сущности.
Например, представителем сущности «Сотрудник» может быть
«Сотрудник Мингалиев».
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr5x1.jpg)
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Рисунок 17.2 – Сущность «Сотрудник» с атрибутами
Ключ сущности - это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушается его уникальность.
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Рисунок 17.3 – Сущность «Сотрудник» с ключом «Табельный номер»
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr6x1.jpg)
Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.
Связи позволяют по одной сущности находить другие сущности,
связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».
Графически связь изображается линией, соединяющей две сущности:
Рисунок 17.4 – Связь между сущностями «Сотрудник» и «Ребенок»
Каждая связь имеет два конца и одно или два наименования.
Наименование обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи:
Рисунок 17.5 – Типы связей
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Эта связь имеет еще один подвид, который называется ноль-или-один-к-одному
(zero-or-one-to-one). При этом виде связи, в зависимой таблице необязательно указывать связанную строку, т.е. одной строке в главной таблице, может соответствовать ноль или одна строка в зависимой таблице.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности
(правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») -
дочерней. Характерный пример такой связи приведен на рисунке 17.4.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности,
и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является
временным типом связи, допустимым на ранних этапах разработки модели. В
дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-
многим путем создания промежуточной сущности.
Пример разработки ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной области:
1.Список сущностей предметной области.
2.Список атрибутов сущностей.
3.Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей,
атрибутов и связей является пошаговым. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед,
являются сами ER-диаграммы.
Ранее, во втором параграфе, мы выделили все требования к разрабатываемой информационной системе.
Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты:
Пользователь - явный кандидат на сущность.
Студент - явный кандидат на сущность.
Преподаватель - явный кандидат на сущность.
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr8x1.jpg)
Дипломная работа - явный кандидат на сущность.
Сразу возникает очевидная связь между сущностями – «Студент является Пользователем», «Преподаватель является Пользователем», «Преподаватель является дипломным руководителем студентом» и «Преподаватель предлагает темы дипломных работ». Первый вариант диаграммы выглядит так:
Рисунок 17.6 – Диаграмма сущностей
Определим набор атрибутов сущностей. Анализируя предметную область, мы выяснили следующее:
Каждый пользователь информационной системы имеет логин,
пароль и роль для авторизации.
Каждый студент имеет фамилию, имя, отчество, номер группы,
персональные данные о себе, личную фотографию.
Каждая преподаватель имеет фамилию, имя, отчество, должность,
персональные данные о себе, личную фотографию, список предлагаемых им тем дипломных работ.
Каждая дипломная работа имеет тему и аннотацию.
Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:
Фамилия/имя/отчество – можно объединить в единый атрибут ФИО, который будет являться явной характеристикой студента и преподавателя.
Логин – явная характеристика пользователя.
Пароль – явная характеристика пользователя.
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr9x1.jpg)
Роль – явная характеристика пользователя.
Авторизация – процесс предоставление определённому лицу или группе лиц прав на использование возможностей системы. Не является характеристикой.
Номер группы – явная характеристика студента.
Персональные данные о себе – явная характеристика студента и преподавателя.
Личная фотография – явная характеристика студента и преподавателя.
Предлагаемые темы дипломных работ – явная характеристика преподавателя.
Тема дипломной работы – явная характеристика дипломной
работы.
Аннотация к дипломной работе – явная характеристика дипломной работы.
Теперь можно внести все это в диаграмму:
Рисунок 17.7 - ER-диаграмма
Данный пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД.
Построение физической модели базы данных
![](/html/71077/47/html_9s5Db8v2mz.0cZf/htmlconvd-ATEjtr10x1.jpg)
Для создания базы данных, которая будет взаимодействовать с нашим приложением, используем подход Model First. Суть данного подхода состоит в том, что сначала делается модель, а потом по ней создается база данных.
Итак, создадим новый проект по типу Приложение Windows Forms. И
затем добавим в проект новый элемент. Нажмем правой кнопкой мыши на проект в окне Обозреватель решений и в появившемся списке выберем
Добавить → Создать элемент. И затем в окне добавления нового элемента выберем Модель ADO.NET EDM:
Рисунок 17.8 – Добавление нового элемента Модель ADO.NET EDM
Модель назовем EntityModel. Нажмем Добавить и нам откроется мастер создания модели.