Создание Базы Данных Института

Автор: z******************@mail.ru, 27 Ноября 2011 в 08:25, курсовая работа

Описание работы

Целью данной курсовой работы является разработка базы данных института и создание удобного для пользователя интерфейса для работы с ней.
Объектом исследования является кафедра «Гражданско-правовые дисциплины» Астраханского Государственного Технического Университета.
Предметом исследования является информационные процессы кафедры «Гражданско-правовые дисциплины» Астраханского Государственного Технического Университета.
Основной же идеей создания БД является упрощение работы коллектива, за счет систематизации всех основной информации.

Работа содержит 1 файл

курсач переделанный.doc

— 2.71 Мб (Скачать)

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

     Между выделенными сущностями можно установить следующие связи:

  • В «Группе» учатся «Студенты» (связь 1:М)
  • «Студенты» изучают «Предметы»  (связь М:М)
  • «Преподаватели» преподают «Предметы» (связь 1:М)
  • К «Кафедре» относятся «Преподаватели» (связь 1:М)

    Связь между сущностями «Группа» и «Студент»  устанавливается в соответствии с рисунком 6. 
     
     
     
     

 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 6Моделирование связи между сущностями «Студент» и «Группа»

     Данная  связь относится к типу «один-ко-многим», так как в одну группу входят несколько студентов. Связь является обязательной с обеих сторон.

     Связь между сущностями «Студент» и  «Предмет» устанавливается в соответствии с рисунком 7.

       
 
 
 
 
 
 
 
 
 
 
 
 

Рисунок 7 - Моделирование связи между сущностями «Студент» и «Предмет»

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

     Связь между сущностями «Предмет» и  «Преподаватель» устанавливается в соответствии с рисунком 8.

       
 
 
 
 
 

     Рисунок 8 - Моделирование связи между сущностями «Предмет» и «Преподаватель»

     Данная  связь относится к типу «один-ко-многим», так как один преподаватель преподает  несколько предметов. Связь является обязательной с обеих сторон.

      Связь между сущностями «Преподаватель»  и «Кафедра» устанавливается  в соответствии с рисунком 9. 
 

                                                                                                                                        Рисунок 9 - Моделирование связи между сущностями «Кафедра» и «Преподаватель»

     Данная  связь относится к типу «один-ко-многим», так как к одной кафедре  относятся несколько преподавателей. Связь является обязательной с обеих сторон.

     После определения связей между сущностями составляется общая схема связи всех сущностей инфологической модели БД кафедры в соответствии с рисунком 10.

     

Рисунок 10 - Общая схема связей всех сущностей  БД кафедры.

     Таким образом, предметная область БД кафедры представляет собой взаимодействие следующих сущностей: в «Группах» учатся «Студенты», которые изучают «Предметы», преподаваемые «Преподавателями», которые относятся к «Кафедре».

    3 Проектирование базы  данных и интерфейса  пользователя БД КАФЕДРЫ

    3.1 Построение таблиц и нормализация базы данных кафедры

     Следующий этап проектирования – построение даталогической модели. Задача этого типа – преобразование ER-диаграммы в реляционную схему.

     В реляционных БД даталогическое или  логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализ корректности схемы являются так называемый функциональные зависимости между атрибутами БД [11].

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

     Получение реляционной схемы из ER-диаграммы осуществляется путем последовательного выполнения определенных операций.

     Каждая  простая сущность превращается в  таблицу (отношение). Имя сущности становится именем таблицы.

     Каждый  атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут. Если атрибут является множественным, то для него строится отдельное отношение.

     Компоненты  уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

     Связи «многие-к-одному» и «один-к-одному»  становятся внешними ключами. То есть создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.

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

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

     Если  в концептуальной схеме присутствуют подтипы, то возможны два варианта.

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

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

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

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

     Для разрешения связей ER-диаграммы существует шесть простых правил генерации  отношений.

     Правило 1.

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

     Правило 2.

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

     Правило 3.

     Если  степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является обязательным, то необходимо использовать три таблицы: по одной для каждой сущности (ключи сущностей служат в качестве первичных в соответствующих таблицах), и одной для связи. Среди своих атрибутов таблица, выделяемая для связи, будет иметь по одному ключу каждой сущности.

     Правило 4.

     Если  степень бинарной связи равна 1:M и класс принадлежности M-связной сущности является обязательным, то достаточным является использование двух таблиц (по одной на каждую сущность), при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы. Помимо этого, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, отводимую n-связной сущности.

     Правило 5.

     Если  степень бинарной связи равна 1:M и класс принадлежности M-связной сущности является необязательным, то необходимо формирование трех таблиц – по одной для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующей таблицы, и одной таблицы для связи. Связь должна иметь среди своих атрибутов ключи обеих сущностей.

     Правило 6.

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

     Рассмотрим все бинарные связи типа 1:M обязательного класса принадлежности M-связной сущности: между сущностями «Группа» и «Студент», между сущностями «Кафедра» и «Преподаватель», между сущностями «Преподаватель» и «Предмет» ER-диаграммы «Учебный процесс». Разрешим эти связи согласно правилу 4. Создаем две таблицы (по одной на каждую сущность), при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы. Помимо этого, ключ односвязной сущности должен быть добавлен как атрибут в таблицу, отводимую М-связной сущности, в соответствии с рисунками 11-13.

     

     Рисунок 11 – Разрешение связи «Группа» и «Студент»

     

     Рисунок 12 – Разрешение связи «Кафедра» и «Преподаватель»

     

     Рисунок 13 – Разрешение связи «Преподаватель» и «Предмет»

     Рассмотрим бинарную связь типа M:M между сущностями «Студент» и «Предмет». Разрешим ее введением специального дополнительного отношения согласно изложенному правилу 6. Создаем три таблицы: для сущностей «СТУДЕНТ» и «ПРЕДМЕТ» и таблица для связи «СТУДЕНТ-ПРЕДМЕТ», в которой в качестве атрибутов присутствуют ключи обеих сущностей, в соответствии с рисунком 14.

     

     Рисунок 14 – Разрешение связи «Студент» и «Предмет»

     В результате выполнения операций по разрешению связей ER-диаграммы была получена ER-модель БД кафедры в соответствии с рисунком 15.

Информация о работе Создание Базы Данных Института