Главная Обратная связь

Дисциплины:






Выявление и моделирование сущностей и связей



 

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

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

· присвоить этой сущности имя;

· выявить атрибуты сущности и присвоить им имя.

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

· при определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее:

· то, как экземпляр одной сущности связан с экземпляром другой сущности;

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

 

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

Источники информации:

Администраторы БД – на основе официальных документов и отчетностей формируют структуру БД, изменяя и дополняя ее.

Преподаватели – предоставляют информацию.

Студенты – предоставляют информацию.

Сотрудники, не занимающиеся преподавательской деятельностью – предоставляют информацию.

В процессе анализа предметной области ОБУЧЕНИЕ СТУДЕНТОВ (не забывая, что это учебный пример и весь процесс глубоко не рассматривается) выделяются отдельные сущности.

Поскольку вещи одного типа хранятся в отдельных объектных множествах, можем выделить следующие сущности: СПЕЦИАЛЬНОСТИ, ГРУППЫ, СТУДЕНТЫ, КАФЕДРЫ, ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ, УЧЕБНЫЙ ПРОЦЕСС, УСПЕВАЕМОСТЬ.

В контрольном примере рассматривается только часть бизнес-правил учебного процесса.

В соответствии с предметной областью система строится с учетом следующих особенностей. Например:

· студент не может учиться на двух специальностях и в двух группах одновременно;

· не может быть двух студентов с одинаковыми номерами зачетной книжки;

· на кафедре работает много преподавателей;

· не может быть двух кабинетов с одинаковыми номерами;

· у кафедры не может быть несколько заведующих кафедрой;

· у группы может быть только один староста;

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

· преподаватель может вести один и тот же предмет в нескольких группах или несколько разных предметов в одной группе;



· студенты сдают экзамены по предметам, которые они изучали;

· у группы может быть только один куратор;

· преподаватель может занимать только одну должность;

· преподаватель может иметь только одну ученую степень;

· не может быть двух одинаковых специальностей;

· не может быть двух одинаковых ученых степеней;

· не может быть двух одинаковых должностей;

· группа занимается только по одному учебному плану.

 

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

Между объектами ГРУППЫ и СТУДЕНТЫ существует отношение «один-ко-многим», поскольку одна группа включает много студентов, а один студент входит только в одну группу. Аналогично устанавливается связь между объектами КАФЕДРЫ и ПРЕПОДАВАТЕЛИ, которые также находятся в отношениях «один-ко-многим» (на одной кафедре работает много преподавателей, но каждый преподаватель работает на определенной кафедре). По каждому предмету проводится множество видов занятий в различных группах разными преподавателями. Это определяет отношения «многие-ко-многим» между множествами ГРУППЫ и ПРЕДМЕТЫ, ГРУППЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ВИДЫ_ЗАНЯТИЙ.

 

3.6 Пример построения подробной диаграммы «сущность – связь» для предметной области «Учебный процесс»

 

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

· Специальности (SPECIALITY). Атрибуты – номер, название специальности. Эта сущность необходима, т.к. студент поступает в ВУЗ на специальность, а потом распределяется по группам.

· Группы (GRUP). Атрибуты этой таблицы – номер, название, количество студентов, курс. Эта сущность отводится для хранения сведений о группах. Так как названия групп формируются в зависимости от факультета, кафедры, года поступления и будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Grup_ID – это ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования.

· Студенты (STUDENTS). Эта сущность отводится для хранения сведений о студентах. Атрибуты – номер, фамилия, имя, отчество, дата рождения, адрес, номер группы, студент-староста. Stud_ID (идентификационный номер студента – обычно номер зачетной книжки) выбран в качестве первичного ключа (PK). Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, поскольку может появиться несколько однофамильцев. Это же правило относится к сочетанию фамилия-имя (отчества может не быть вообще). А учитывая, что идентификаторы студентов будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера.

· Кафедры (CHAIR). Атрибуты - номер, название, телефон и адрес. Эта сущность вводится для хранения сведений о кафедрах вуза. Chair_ID – это целочисленное ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования автоматически.

· Преподаватели (TEACHER). Атрибуты – номер, фамилия, имя, отчество, должность, ученая степень и принадлежность к кафедре. Эта сущность отводится для хранения сведений о преподавателях. Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, а учитывая, что идентификаторы преподавателей будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Teach_ID – это ключевое поле, которое и будет идентификатором данной сущности.

· Предметы (SUBJECT). Атрибуты – номер, название, общее количество часов за семестр, лекционные часы, часы практикумов, лабораторные часы. Эта сущность отводится для хранения сведений о предметах. Атрибут Subj_ID – это ключевое поле, которое и будет идентификатором данной сущности. Атрибут Subj_NAME является текстовым типом данных для отображения названия предмета.

 

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

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

В процессе ER-моделирования системы учебного процесса был получен следующий набор бизнес-правил для сущностей и создания связей между ними (краткое перечисление), связи сущностей базируются на бизнес-правилах, построенных на основе подробного описания операций.

Бизнес-правило 1

Каждый студент поступает на одну специальность. На основе первого бизнес-правила мы получаем сегмент ER-модели, представленный на рис.1.2.

Рисунок 1.2 – ER–диаграмма бизнес-правила 1

Бизнес-правило 2

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

На основе Бизнес-правила 2 мы получаем следующий сегмент ER-модели.

Рисунок 1.3 – ER–диаграмма бизнес-правила2

Бизнес-правило 3

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

На основе Бизнес-правила 3 мы получаем следующий сегмент ER-Модели

Рисунок 1.4 – ER–диаграмма бизнес-правила 3

Бизнес-правило 4

Каждая группа (соответственно и студент в ней) изучает конкретное множество предметов, которые ведут преподаватели. Преподаватель может вести один и тот же предмет в нескольких группах и несколько разных предметов изучаются одной группой. Связь «многие-ко-многим» реализуем через ассоциативную таблицу, так как на сегодня ни одна СУБД такую связь не реализует.Сотрудники кафедры ведут занятия у нескольких групп, для этого таблицу «Учебный процесс» связываем с таблицей «Преподаватели» связью 1:М.

То есть появляется еще одна таблица «Учебный процесс».

· Учебный процесс (STUDY). Сущность включает атрибуты - номер группы, номер предмета, номер преподавателя, форма обучения, количество часов. Атрибут Grup_ID отображает в формате integer группу, участвующую в учебном процессе. Атрибут Subj_ID отображает в формате integer предмет, относящийся к данной группе. Атрибут Teach_ID – это целочисленное поле, хранящее информацию о преподавателе, ведущем данный предмет. Атрибут Kredit_count – символьное поле, характеризующее форму обучения. Атрибут Total_Hours является целочисленным типом данных для отображения общего количества часов. Атрибут Lection_Hours является целочисленным типом данных для отображения количества лекционных часов. Атрибут Practice_Hoursявляется целочисленным типом данных для отображения количества часов практикума. Атрибут Labor_Hours является целочисленным типом данных для отображения количества лабораторных часов.

На основе Бизнес-правила 4 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.5 – ER–диаграмма бизнес-правила 4

Бизнес-правило 5

Студенты сдают экзамены по предметам, которые они изучали. Например, если студент входит в группу 1, а этой группой в учебном процессе изучался предмет 2, то студент должен будет сдать данный предмет. Связь «многие-ко-многим» реализуется через ассоциативную таблицу «Успеваемость»:

Успеваемость (PROGRESS). Сущность включает атрибуты - код студента, код группы, код предмета, код преподавателя, дату сдачи, итоговую оценку. Данная сущность хранит данные об успеваемости каждого студента.

На основе Бизнес-правила 5 мы получаем следующий сегмент ER-Модели

 

Рисунок 1.6 –ER–диаграмма бизнес-правила 5

 

База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 1.6).

 

Рисунок 1.6 – Уточненная ER–диаграмма концептуальной модели учебного процесса

 

3.7 Преобразование концептуальной модели в реляционную модель

 

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

Преобразование объектных множеств и атрибутов. Объектное множество с атрибутами может быть преобразовано в реляционную таблицу с именем объектного множества в качестве имени таблицы и атрибутами объектного множества в качестве атрибутов таблицы. Если некоторый набор этих атрибутов может быть использован в качестве ключа таблицы, то он выбирается ключом таблицы. В противном случае в таблицу добавляется атрибут, значения которого будут однозначно определять объекты-элементы исходного объектного множества, и который, таким образом, может служить ключом таблицы. Преобразуем объектные множества ГРУППЫ, КАФЕДРЫ, ПРЕДМЕТЫ в реляционные таблицы с соответствующими названиями.

Каждое реляционное отношение соответствует одной сущности, и в него вносятся все атрибуты сущности. Для каждого отношения необходимо определить окончательно первичный ключ и внешние ключи (если они имеются). Отношения приведены в таблицах 2-8.

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

N – числовой (numeric);

C – символьный (char);

D – дата (различная стандартная длина для каждой СУБД, поэтому она не указывается).

В полях примечание первичные и внешние ключи также подразумеваются обязательными полями (NOT NULL).

 





sdamzavas.net - 2019 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...