Разработка ИС торогового предприятия

2. Определение объектов базы данных

Анализ  определенных выше задач позволяет  выделить сущности (объекты) проектируемой базы данных и, построить ее инфологическую модель на языке "Таблицы-связи". В результате анализа были определены следующие объекты базы данных:

1. Студенты (Номер студента, Тип_студента, Фамилия, Имя, Отчество, Дата_рождения, Пол, Гражданство, Национальность, Образование, Семейное_положение, Социальное_положение, Дата_поступления, Курс, Группа, Подгруппа, Изучаемый_язык, Специализация, Место_жительства, Телефон, Состав_семьи, Адрес_родителей).

Эта сущность отводится для хранения основных сведений о студентах. Сведения могут быть как неизменяемые за весь период обучения (имя отчество, дата рождения, пол и т.д.) так и изменяемые один раз или многократно в течения периода обучения (курс, группа, подгруппа, место жительства). Очевидно, что даже в пределах одной группы могут быть однофамильцы или даже люди с одинаковыми фамилиями и именами, поэтому однозначно определить записи по фамилии студентов не возможно. Поэтому здесь введён атрибут Номер_Студента – уникальный числовой идентификатор присваиваемый обучаемому студенту. В принципе этот идентификатор нет необходимости знать для работы с базой данных и он может быть скрыт от пользователей, он служит только для внутренних целей.

Отдельно  необходимо сказать про атрибут  Тип_Студента. Он был введён для удобной реализации всех задач, выполняемых деканатом, по группировке студентов и может принимать такие значения как Отчисленный, Находящийся_в_академическом_отпуске, Обычный, Востановившийся и т. д. Это освобождает от необходимости заводить отдельную таблицу, например, на отчисленных студентов, а также упрощает операции обратного зачисления в число студентов, если он решил восстановиться. Таким образом исключается дублирование записей. Информация обо всех студентах хранится в одном месте, что упрощает задачу сохранения целостности базы данных.  

2. Дисциплины (Номер_дисциплины, Название, Тип_дисциплины).

Данная  сущность отводится для хранения списка дисциплин участвующих в  формировании учебного плана, по которому производится обучение в группах  и, соответственно, оценка успеваемости каждого студента. Как и для предыдущей сущности для каждую дисциплину однозначно определяет её номер идентификатор, который автоматически увеличивается на единицу с вводом каждой новой дисциплины. Атрибут Тип_дисциплины определяет классификацию дисциплин и может принимать такие значения как: гуманитарная, техническая, общеобразовательная и т. д.

3. ПланНаСеместр (Номер_дисциплины, Семестр, Лекции, Семинары, Лабораторные_работы, Форма_контроля).

Данная  сущность представляет собой расписание дисциплин по семестрам т.е. учебный план. Первичный ключ этой сущности состоит из двух атрибутов. Номер_дисциплины – тот самый уникальный идентификатор, который определяет каждую запись в таблице “Дисциплины”. Атрибут Семестр  является просто номером семестра в котором планируется читать данную дисциплину (на физическом факультете существует только дневная форма обучения и весь период обучения занимает 10 семестров). Атрибуты Лекции, Семинары, Лабораторные_работы определяют комплекс мероприятий, который планируется проводить при  обучении: они могут присутствовать или нет и дают только исключительно дополнительную информацию. Атрибут Форма_контроля может принимать значения зачет или экзамен. Сущность также позволяет отобразить тот факт, что дисциплина может преподаваться  в течении нескольких семестров, причём в разных формах (лекции, семинары, лабораторные работы) и их комбинациях с разными формами контроля знаний по данной дисциплине в конце семестра.

4. ПланДляГруппы (Номер_дисциплины, Семестр, Номер_группы, Номер_подгруппы).

Данная  сущность отражает распределение дисциплин  по группам (или, если это необходимо, даже по подгруппам). Поэтому все  четыре атрибута данной сущности входят в состав первичного ключа. Здесь  как и для сущности ПланНаСеместр  атрибуты Номер_дисциплины и Семестр однозначно определяют какая дисциплина в данном семестре будет введена в программу обучения. Атрибуты Номер_группы и Номер_подгруппы вносят сведения о том, в каких группах данная дисциплина будет преподаваться. Эффективность такого распределения дисциплин по группам проявляется на третьем курсе, когда происходит распределение студентов по специальностям и идёт формирование отдельных планов обучения для разных групп специализаций.

5. Экзамены (Номер_студента, Номер_дисциплины, Семестр, Результат).

Сущность  отражает успеваемость студентов по дисциплинам указанных в учебном  плане. Атрибут Номер_студента –  уникальный номер студента присвоенный  ему в сущности “Студенты”. Атрибут  Номер_дисциплины указывает на дисциплину определённую в таблице “Дисциплины”. Третий атрибут первичного ключа – Семестр – введён для случая, когда дисциплина читается в течение нескольких семестров и следовательно знания должны быть оценены во всех семестрах согласно учебному плану. Атрибут Результат представляет оценку по данной дисциплине, которая может быть как числом (2,3,4,5), так и строкой (зачёт, незачёт).

6. Аттестация (Номер_студента, Номер_дисциплины, Семестр, Номер_атестации, Результат).

Сущность  отражает успеваемость студентов по аттестациям, которые проводятся в течении семестра. Назначение атрибутов первичного ключа Номер_студента, Номер_дисциплины, Семестр точно такое же, как и для сущности “Экзамены”, только сюда введён дополнительный атрибут Номер_атестации, который определяет номер аттестации. Количество аттестаций в принципе не ограничено и определяется лишь учебным планом. На физическом факультете в течение каждого семестра проводиться лишь две аттестации.

7. Приказы (Номер_студента, Номер_приказа, Тип_приказа, Дата_приказа, Причина).

Данная  сущность отводится для хранения информации о приказах, на основании которых производятся отчисления или восстановление  студентов, а также предоставления академического отпуска и возврат из него. Первичный ключ составляет четыре атрибута. Атрибут Номер_приказа, уникальный номер приказа, который приходит из отдела кадров студентов. Атрибут Тип_Приказа может принимать такие значения как: отчисление, восстановление, предоставление А/0, возврат из А/О. Поскольку на практике могут встречаться такие случаи, что один и тот же студент может быть несколько раз быть отчисленным, а затем восстановленным и к тому же может взять академический отпуск, то для хранения достоверной информации в состав первичного ключа введен атрибут Дата_Приказа, отражающий всю хронологию подобных случаев. Атрибут Причина носит дополнительную информацию о причине по которой производиться отчисление или предоставляется академический отпуск.

3. ER-диаграмма  базы данных

На рис. 17  приведена схема инфологической модели базы данных на языке "Таблицы-связи".

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

дисциплины. Сущность ПланДляГруппы позволяет  формировать учебный план индивидуально  для групп и подгрупп, что имеет  место на практике на третьем году обучения на физическом факультете. К этому времени общеобразовательные дисциплины для всех групп уже в основном пройдены и идёт формирование индивидуальных учебных планов для групп, которые распределены по специализациям. Студент, будучи включённым в какую-нибудь группу и подгруппу, автоматически получает учебный план определённый для данной группы и т.о. автоматически можно получить список дисциплин по которым знания студента должны быть оценены. Это позволяет судить о том, справился или нет студент с учебным планом, что может быть использовано для автоматического определения списка неуспевающих студентов или подсчёта среднего бала и прочей статистики.

Подчинённость сущности “ПланНаСеместр” по отношению  к сущности “Дисциплины” позволяет определить преподавание дисциплины на несколько семестров, что довольно часто имеет место на практике.

Аналогично  подчинённая структура типа “один-ко-многим” для пары сущностей “Студенты”®”Приказы” позволяет производить несколько раз для студентов операции отчисления, восстановления, предоставления академического отпуска и т. д. Что также встречается на практике. При этом информация о студентах не удаляется из базы данных. Студент лишь переводится в другую категорию, например “отчисленные”, и вся информация храниться в базе данных до тех пор пока не будет востребована или не будет принято решение о её удалении.

Подчинённая структура  сущностей базы данных налагает требования по заполнению базы данных информацией. Например, прежде должны быть заполнены главные таблицы “Студенты” и “Дисциплины”, составлен учебный план,  а только потом согласно учебному плану можно заполнять информацией таблицы “Экзамены” и “Аттестация”. Эта особенность должна быть отражена в интерфейсе взаимодействия базы данных с конечным пользователем.

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

4. Даталогическая  модель базы данных

В качестве даталогической модели базы данных была выбрана реляционная модель, поскольку  именно реляционная модель является результатом более развитых представлений  о формировании и ведении баз  данных, на которые наложен строгий математический аппарат. Реляционные модели наиболее логично и наглядно отражают структуру хранимой информации и внутренних связей, что позволяет более полно анализировать структуру базы данных при разработке. Это привело к тому, что именно реляционные модели баз данных наиболее распространены в настоящее время и являются стандартом, на который переводятся все существовавшие ранее базы данных с иерархической и сетевой моделью. Ещё одним веским доводом в пользу выбора реляционной модели является тот факт, что подавляющее большинство предоставляемых средств для разработки баз данных ориентированны исключительно на реляционную модель. Кроме того, реляционные базы данных в последствии легче расширять и интегрировать, что является неотъемлемой частью дальнейшего развития баз данных, с увеличением возлагаемых на них задач.

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

Если  проанализировать значения полей таблицы  “Студенты”, то видно, что некоторые поля, такие как, Тип_студента, Образование, Семейное_положение, Социальное_положение, принимают некоторые значения из ограниченного набора, кроме того, эти значения представляют собой текстовые константы, которые могут быть довольно большие по длине. Аналогичными свойствами обладают поля Тип_дисциплины, Форма_контроля, Тип_приказа других таблиц. Такие значения лучше всего хранить в отдельной таблице со своими уникальными номерами, а вместо этих длинных строк подставлять значение уникальных номеров, которые назначены каждой строке. Это позволит сократить дисковое пространство для хранения данных. Пользователь, таким образом, может выбрать некоторые значения этих полей из предложенного в списке, что несколько ускорит процесс заполнения базы данных, поскольку освобождает его от набора длинной последовательности одних и тех же строк.

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

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