Загрузил The Ssora

КУРСОВАЯ РАБОТА по дисциплине «Базы данных» на тему: «Разработка базы данных «Университет»

Реклама
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФГАОУ ВО «СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ И ТЕЛЕКОММУНИКАЦИЙ
КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ
КУРСОВАЯ РАБОТА
по дисциплине
«Базы данных»
на тему:
«Разработка базы данных «Университет»
Выполнил:
Студент(ка) 3 курса группы ПИН-б-з-16-1
Направления подготовки
09.03.03 Прикладная информатика
заочной формы обучения
________________________
(подпись)
Руководитель работы:
________________________
(ФИО, должность, кафедра)
Работа допущена к защите___________________
__________________
(подпись руководителя)
(дата)
Работа выполнена и
защищена с оценкой______________________ Дата защиты_______________
Члены комиссии:________________ _______________
_____________
(должность)
(подпись)
________________
________________
________________
_______________
_______________
_______________
Ставрополь, 2018 г.
(И.О. Фамилия)
______________
______________
______________
УТВЕРЖДАЮ
Зав. кафедрой ПИ
________________
Институт информационных технологий и телекоммуникаций
Кафедра прикладной информатики
Направление подготовки 09.03.03 Прикладная информатика
Направленность (профиль) Прикладная информатика в экономике
ЗАДАНИЕ
на курсовую работу
студента Самвелян Артем Мгырович
по дисциплине «Базы данных»
1. Тема работы: Разработка базы данных «Университет»
2.Цель: ____________________________________________________________
3. Задачи: __________________________________________________________
4. Перечень подлежащих разработке вопросов:
а) по теоретической части: ___________________________________________
б) по практической части: ___________________________________________
5. Исходные данные:
а) по литературным источникам: _____________________________________
б) по вариантам, разработанным преподавателем:
_________________________________________________________________
6. Список рекомендуемой литературы: _______________________________
7. Контрольные сроки представления отдельных разделов курсовой работы:
25 % -___________________________________“___” ___________ 20_ г.
50 % -___________________________________“___” ___________ 20_ г.
75 % -___________________________________“___” ___________ 20_ г.
100 % -___________________________________“___” ___________ 20_ г.
8. Срок защиты студентом курсовой работы“___” ___________ 20_ г.
Дата выдачи задания “___” ___________ 20_ г.
Руководитель курсовой работы
__________________________________________________________
(ученая степень, звание) (личная подпись) (инициалы, фамилия)
Задание принял(а) к исполнению студент(ка) заочной формы обучения 3 курса
группы ПИН-б-з-16-1
__________
_________________
(личная подпись)
(инициалы, фамилия)
2
Введение
Ошибка! Закладка не определена.
1. Теоретическая часть
1.1. Общие понятия распределенных СУБД.
1.2. Функции и архитектура распределенных СУБД.
1.3 Средства для работы с распределенными данными
5
5
8
16
2. Практическая часть
18
2.1. Постановка задачи
18
2.2. Выбор СУБД
18
2.3. Построение отношения в 1НФ
19
2.4. Формирование минимального множества функциональных зависимостей
19
2.5. Определение потенциальных ключей, определение первичного ключа отношения 20
2.6. Получение 2НФ
21
2.7. Перевод всех отношений в 3НФ и НФБК
21
2.8. ER-диаграмма предметной области
22
2.9. Создание базы данных
22
2.10. Создание диаграммы БД. Определение правила поддержания ссылочной
целостности системы...
24
2.11. Наполнение БД тестовыми данными
25
2.12. Создание ограничения
25
2.13. Создание триггера на таблицу
27
2.14. Создание представления
28
2.15. Создание хранимых процедур
29
2.15.1 По коду преподавателя вернуть всех студентов, кому он назначен научным
руководителем.
29
2.15.2. Вывести список преподавателей, которые когда-либо были научными
руководителями студентов указанной специальности. Решить задачу с
использованием 1) операции соединения и 2) подзапроса
29
2.15.3. Вывести отсортированный список преподавателей с указанием числа
студентов, для которых он является научным руководителем
30
2.15.4. Модифицируйте предыдущую ХП, чтобы в указанном списке остались только
те преподаватели, которые осуществляют руководство более чем над N студентами. 31
2.15.5. Вывести список преподавателей, которые хотя бы однажды были научными
руководителями студентов указанной специальности.
31
Заключение
32
Список литературы
33
3
Введение
В настоящее время жизнь человека зависит от различного рода
информации, для управления которой требуются создания огромного количества
баз и банков данных различного назначения.
Понятие базы данных (БД) можно применять к любой связанной между по
определенному признаку информации, хранимой и ограниченной особым
образом- что выполняется в СУБД MS ACCESS в виде таблиц. По сути БД- это
некоторое подобие картотеки, электронного хранилища данных, которые
хранятся в компьютере в виде одного или нескольких файлов.
Системы баз данных сегодня являются основой построения большинства
информационных систем и используются при автоматизации практически всех
сфер человеческой деятельности. Например, доступ к базе данных необходим
при работе с библиотечной информационной системой, содержащей сведения
обо всех книгах, имеющихся в библиотеке, ее читателях, заявках на
бронирование книг и т.д. В ней обычно содержатся средства, позволяющие
читателям находить нужную им книгу по названию, фамилиям авторов или
указанной тематике. С помощью такого рода систем организуется учет движения
книг,
другие
операции,
необходимые
в
библиотечной
деятельности.
В ВУЗе могут существовать базы данных с информацией о студентах,
профессорско-преподавательском составе, факультетах и кафедрах, др. данные,
необходимые
для
функционирования
так
называемых
комплексных
информационно-аналитических систем и их подсистем (учета кадров,
бухгалтерской, документооборота, информационного обеспечения учебной
деятельности и т.п.).
4
1 Теоретическая часть
1.1 Общие понятия распределенных СУБД
РаСУБД – комплекс программ, предназначенный для управления
распределенной БД и позволяющий сделать распределенность информации
«прозрачной» для конечного пользователя. Из определения РаСУБД следует, что
для конечного пользователя должен быть полностью скрыт тот факт, что
распределенная БД состоит из нескольких фрагментов, которые могут
размещаться на нескольких компьютерах, расположенных в сети и к ней
возможен параллельный доступ нескольких пользователей. Назначение
обеспечения «прозрачности» состоит в том, чтобы распределенная система
внешне вела себя точно так же, как и централизованная. Такое распределение
данных позволяет, например, хранить в узле сети те данные, которые наиболее
часто используются в этом узле. Такой подход облегчает и ускоряет работу с
этими данными и оставляет возможность работать с остальными данными БД,
хотя для доступа к ним требуется потратить некоторое время на передачу данных
по сети.
Распределенная
база
данных
(DDB–DistributedDataBase)
–
это
совокупность множества взаимосвязанных БД, распределенных в компьютерной
сети. БД распределена физически, но логически едина (имеет общую схему
данных).
В системах с распределенными БД используются разные технологии
распределения данных по узлам сети – фрагментация и тиражирование.
При использовании фрагментации единая логическая БД разбивается на
составные части (фрагменты), хранящиеся в разных узлах сети. Разбиение может
проводиться по территориальному, функциональному и временному критериям.
При использовании тиражированияв нескольких узлах сети создаются и
5
поддерживаются в согласованном состоянии (синхронизируются) копии всей БД
или ее фрагментов. Копия БД называетсярепликой.
В системах с централизованной БД (много клиентов/один сервер)
проблемы управления БД решаются просто, поскольку вся она хранится на
сервере. В системах с распределенной БД проектирование, реализация запросов
и управление представляют собой сложные задачи. Однако такие системы
обеспечивают большую гибкость, надежность и быстродействие. Технологии
распределения данных видоизменяют преимущества и недостатки систем. Одно
из преимуществ БД – сокращение дублирования – теряется при использовании
тиражирования. При этом сохраняются возможности контроля целостности
данных для всей системы.
Ведущими поставщиками СУБД сформулированы следующие свойства
идеальной системы управления распределенными БД:
 прозрачность относительно расположения данных – СУБД должна
представлять все данные так, как если бы они были локальными;
 гетерогенность системы – СУБД должна работать с данными,
которые хранятся в системах с различной архитектурой и
производительностью;
 прозрачность относительно сети – СУБД должна одинаково работать
в условиях разнородных сетей;
 поддержка распределенных запросов –пользователь должен иметь
возможность объединять данные из любых баз, даже размещенных в
разных системах;
 поддержка распределенных изменений –пользователь должен иметь
возможность изменять данные в любых базах, на доступ к которым
у него есть права;
 поддержка распределенных транзакций – СУБД должна выполнять
транзакции, выходящие за рамки одной вычислительной системы, и
6
поддерживать целостность БД при возникновении отказов как в
системах, так и в сети;
 безопасность
–
СУБД
должна
обеспечивать
защиту
всей
распределенной БД от несанкционированного доступа;
 универсальность доступа – СУБД должна обеспечивать единую
методику доступа ко всем данным.
Системы
распределенной
обработки
данных
базировались
на
многопользовательских операционных системах с БД на центральном
компьютере. Клиентские места реализовались в виде терминалов, не имеющих
собственных
ресурсов.
Развитие
сетевых
технологий,
распространение
персональных ЭВМ и стандартов открытых систем привело к появлению систем
распределенных БД, размещенных в сети разнотипных компьютеров. Система
состоит из узлов, каждый из которых является СУБД. БД любого узла доступна
пользователю (таблица 1).
Таблица 1 - Преимущества и недостатки распределенных СУБД
Преимущества
Недостатки
Отображение структуры организации
Повышение сложности
Разделяемость и локальная
Увеличение стоимости
автономность
Повышение доступности данных
Проблемы защиты
Повышение надежности
Усложнение контроля за
целостностью данных
Повышение производительности
Отсутствие стандартов
Экономические выгоды
Недостаток опыта
Модульность системы
Усложнение процедуры разработки
базы данных
7
1.2 Функции и архитектура распределенных СУБД
СУРБД должна предоставлять следующий набор функциональных
возможностей:
 расширенные службы установки соединений должны обеспечивать доступ
к удаленным сайтам и позволять передавать запросы и данные между
сайтами, входящими в сеть;
 расширенные средства ведения каталога, позволяющие сохранять
сведения о распределении данных в сети;
 средства обработки распределенных запросов, включая механизмы
оптимизации запросов и организации удаленного доступа;
 расширенные функции управления параллельностью, позволяющие
поддерживать целостность реплицируемых данных;
 расширенные функции восстановления, учитывающие возможность
отказов в работе отдельных сайтов и отказов линий связи.
Архитектура распределённых СУБД имеет многоуровневую архитектуру
(5 уровней). Верхние 4 уровня: процессоры – пользовательский, глобальный
логический, фрагментный и распределённый. Они входят в сетевую СУБД. 2
часть. Нижний уровень – процессор узлового уровня. Относят к локальной
СУБД.
Каждый из этих уровней поддерживает различные представления базы
данных. Каждый уровень взаимодействует только с непосредственно смежными
уровнями представления. Самым верхним уровнем структуры является
интерфейс прикладной программы или интерфейс процессора запроса. Второй
уровень дает глобальное представление базы данных.
Существование
3
и
4-го
уровней
представления
объясняется
распределённой природой базы данных и решением использовать управляемую
избыточность. Третий уровень представления – фрагментное представление.
Используя это представление, АБД определяет несвязанное подмножество базы
8
данных, называемые логическими фрагментами, каждый из которых является
подмножеством строк в таблице.
Рисунок 1 - Архитектура распределённых СУБД
Учитывая, что одним из основных показателей эффективности сетевой
обработки данных является время обслуживания запроса, рассмотрим различные
модели архитектуры распределенной обработки на примере, когда прикладная
программа работы с базой данных, расположенной на сервере, загружена на
рабочую станцию, и пользователю необходимо получить все записи,
удовлетворяющие некоторым поисковым условиям.
Архитектура «файл-сервер». В данной архитектуре, схема которой
представлена на рис. 2, средства организации и управления базой данных (в том
числе и СУБД) целиком располагаются на машине клиента, а база данных,
представляющая собой обычно набор специализированных структурированных
файлов, на машине-сервере. В этом случае серверная компонента представлена
даже не средствами СУБД, а сетевыми составляющими операционной системы,
обеспечивающими удаленный разделяемый доступ к файлам. Таким образом,
«файл-сервер» представляет собой вырожденный случай клиент-серверной
архитектуры.
9
Взаимодействие между клиентом и сервером происходит на уровне команд
ввода-вывода файловой системы, которая возвращает запись или блок данных.
Запрос к базе, сформулированный на языке манипулирования данными,
преобразуется самой СУБД в последовательность команд ввода-вывода, которые
обрабатываются
операционной
системой
машины-сервера.
Рисунок 2 - Архитектура «файл-сервер»
Достоинство - возможность обслуживания запросов нескольких клиентов.
Недостатки:
 высокая загрузка сети и машин-клиентов, т.к. обмен идет на уровне единиц
информации файловой системы – физических записей, блоков или даже
файлов, из которых на машине клиента будут выбраны и представлены
необходимые для приложения элементы данных;
 низкий уровень защиты данных, т.к. доступ к файлам БД управляется
общими средствами ОС сервера;
 низкий уровень управления целостностью и непротиворечивостью
информации,
т.к.
бизнес-правила
функциональной
обработки,
сосредоточенные на клиентской части, могут быть противоречивыми и
несинхронизированных.
10
В среде файлового сервера программа управления данными, которая
выполняется на машине-клиенте, должна осуществить запрос каждой записи
базы, после чего она может определить, удовлетворяет ли запись поисковым
условиям, лишь после этого передать для функциональной обработки. Очевидно,
что для этой схемы характерно наибольшее суммарное время обработки
информации.
В архитектуре сервера базы данных, схема которой представлена на рис. 3,
средства управления базой данных и база данных размещены на машине-сервере.
Взаимодействие между клиентом и сервером происходит на уровне команд
языка
манипулирования
данными
СУБД
(обычно
SQL),
которые
обрабатываются СУБД на машине-сервере. Сервер базы данных осуществляет
поиск записей и анализирует их. Записи, удовлетворяющие условиям, могут
накапливаться на сервере и после того, как запрос будет целиком обработан,
пользователю на клиентскую машину передаются все логические записи
(запрашиваемые элементы данных), удовлетворяющие поисковым условиям.
Рисунок 3 - Архитектура «выделенный сервер базы данных»
Достоинства:
 возможность обслуживания запросов нескольких клиентов;
 снижение нагрузки на сеть и машины сервера и клиентов;
 защита данных осуществляется средствами СУБД, что позволяет
блокировать не разрешенные пользователю действия;
 сервер реализует управление транзакциями и может блокировать попытки
одновременного изменения одних и тех же записей.
11
Недостатки:
 бизнес-логика функциональной обработки и представление данных могут
быть одинаковыми для нескольких клиентских приложений и это увеличит
совокупные потребности в ресурсах при исполнении – повторение части
кода программ и запросов;
 низкий уровень управления непротиворечивостью информации, т.к.
бизнес-правила
функциональной
обработки,
сосредоточенные
на
клиентской части, могут быть противоречивыми.
Данная технология позволяет снизить сетевой трафик и повысить общую
эффективность обработки за счет оптимизации и буферизации ввода-вывода.
Т.о., сервер может осуществить поиск и обрабатывать запросы даже быстрее,
чем, если бы они обрабатывались на рабочей станции.
Архитектура «активный сервер баз данных».
Для того чтобы устранить недостатки, свойственные архитектуре сервера
базы данных необходимо, чтобы непротиворечивость бизнес-логики и
изменения базы данных контролировались на стороне сервера. Причем
некоторые, заранее специфицированные состояния могли бы изменять
последовательность взаимодействия приложения с базой данных.
Для этого функции бизнес-логики разделяются между клиентской и
серверной частью. Общие или критически значимые функции оформляются в
виде хранимых процедур, включаемых в состав базы данных. Кроме этого,
вводится механизм отслеживания событий БД – триггеров, также включаемых в
состав базы. При возникновении соответствующего события (обычно изменения
данных), СУБД вызывает для выполнения хранимую процедуру, связанную с
триггером, что позволяет эффективно контролировать изменение базы данных.
Хранимые процедуры и триггеры могут быть использованы любыми
клиентскими приложениями, работающими с базой данных. Это снижает
дублирование программных кодов и исключает необходимость компиляции
каждого запроса (рисунок 4).
12
Недостатком такой архитектуры становится существенно возрастающая
загрузка сервера за счет необходимости отслеживания событий и выполнения
части бизнес-правил.
Такую
архитектуру
организации
взаимодействия
(а
также
рассматриваемый далее сервер приложений) иногда называют моделью с
«тонким клиентом», в отличие от предыдущих архитектур, называемых моделью
с «толстым клиентом», где на стороне клиента выполняется большинство
функций.
Рисунок 4 - Архитектура «активный сервер баз данных»
В определении РСУБД утверждается, что система должна обеспечить
прозрачность распределенного хранения данных для конечного пользователя.
Под прозрачностью понимается сокрытие от пользователей деталей реализации
системы. Например, в централизованной СУБД обеспечение независимости
программ от данных также можно рассматривать как одну из форм прозрачности
– в данном случае от пользователя скрываются изменения, происходящие в
определении и организации хранения данных. Распределенные СУБД могут
обеспечивать различные уровни прозрачности. Однако в любом случае
преследуется одна и та же цель: сделать работу с распределенной базой данных
совершенно аналогичной работе с обычной централизованной СУБД. Все виды
прозрачности, которые мы будем обсуждать ниже, очень редко можно найти в
какой-либо одной СУРБД. Мы выделим четыре основных типа прозрачности,
которые могут иметь место в системе с распределенной базой данных:
13
1. Прозрачность распределенности. Прозрачность распределенности базы
данных позволяет конечным пользователям воспринимать базу данных как
единое логическое целое. Если СУРБД обеспечивает прозрачность
распределенности, то пользователю не требуется каких-либо знаний о
фрагментации данных (прозрачность фрагментации)или их размещении
(прозрачность расположения).
2. Прозрачность
фрагментации
является
самым
высоким
уровнем
прозрачности рас­пределенности. Если РСУБД обеспечивает прозрачность
фрагментации, то пользова­телю не требуется знать, как именно
фрагментированы данные. В этом случае доступ к данным осуществляется
на основе глобальной схемы и пользователю нет необходи­мости
указывать имена фрагментов или расположение данных.
3. С прозрачностью расположения очень тесно связан еще один тип
прозрачности — прозрачность репликации. Он означает, что пользователю
не требуется иметь сведе­ния о существующей репликации фрагментов,
Под
прозрачностью
репликации
под­разумевается
прозрачность
расположен копий.
Это самый низкий уровень прозрачности распределенности. При
наличии в сис­теме прозрачности локального отображения пользователю
необходимо указывать как имена используемых фрагментов, так и
расположение соответствующих элементов данных.
4. Прозрачность использования СУБД позволяет скрыть от пользователя тот
факт, что на разных сайтах могут функционировать различные локальные
СУБД. Данный тип прозрачности является самым сложным, и применим
только для гетерогенных распределенных систем.
Двенадцать правил Дейта:
1. Локальная автономность. Узлы в распределенной системе должны быть
автономными. В данном контексте автономность означает следующее:
14
a. локальные
данные
принадлежат
локальным
владельцам
и
сопровождаются локально;
b. все локальные операции остаются сугубо локальными;
c. все операции на заданном узле контролируются только этим узлом;
2. Отсутствие зависимости от центрального узла. В системе не должно быть
ни одного узла, без которого она не могла бы функционировать. Это
означает, что в системе не должно существовать центральных серверов
таких служб, как управление транзакциями, выявление взаимоблокировок,
оптимизация запросов и управление глобальным системным каталогом.
3. Непрерывное функционирование. В идеальном случае в системе никогда
не должна возникать потребность в плановом прекращении ее
функционирования для выполнения следующих операций:
a. добавление или удаление узла из системы;
b. динамическое создание или удаление фрагментов из одного или
нескольких УЗЛОВ.
4. Независимость от местонахождения. Независимость от местонахождения
эквивалентна прозрачности местонахождения. Пользователь должен
получать доступ к базе данных с любого из узлов. Более того, пользователь
должен получать доступ к любым данным таким образом, как если бы они
хранились на его узле, независимо от того, где они физически находятся.
5. Независимость от фрагментации. Пользователь должен получать доступ к
данным независимо от способа их фрагментации.
6. Независимость от репликации. Пользователь не должен нуждаться в
сведениях о наличии копий данных. Это означает, что пользователь не
должен обращаться непосредственно к конкретной копии элемента данных
и заботиться об обновлении всех имеющихся копий элемента данных.
7. Обработка распределенных запросов. Система должна поддерживать
обработку запросов, ссылающихся на данные, расположенные на
нескольких узлах.
15
8. Обработка распределенных транзакций. Система должна поддерживать
выполнение транзакций как единицы восстановления. Система должна
гарантировать,
что
глобальные
и
локальные
транзакции
будут
выполняться с сохранением четырех основных свойств транзакций:
неразрывности, согласованности, изолированности и устойчивости.
9. Независимость от типа оборудования. Распределенная СУБД должна
функционировать на оборудовании с различными вычислительными
платформами.
10.Независимость
предыдущего
от
операционной
правила
является
системы.
требование,
Прямым
следствием
согласно
которому
распределенная СУБД должна функционировать под управлением
различных операционных систем.
11.Независимость от сетевой архитектуры. Распределенная СУБД должна
функционировать в среде самых различных сетей связи.
12.Независимость от базы данных. Должна быть предусмотрена возможность
создавать распределенную СУБД на основе локальных СУБД различных
типов, функционирование которых может быть даже основано на
поддержке разных моделей данных. Другими словами, распределенная
СУБД должна поддерживать разнородную архитектуру.
1.3 Средства для работы с распределенными данными
Фрагментация – это разбиение целостного объекта глобального типа на
несколько частей, называемых фрагментами. Размещение – это отображение
каждого фрагмента на одну или более ЭВМ. Конфигурация и эксплуатационные
характеристики РБД существенно зависят от размещения фрагментов данных по
ЭВМ сети. Размещение объектов может быть избыточным и безызбыточным. В
последнем случае каждый фрагмент отображается точно на одну ЭВМ, а в
первом – на одну или более ЭВМ.
16
Словарь данных, описанный в Словаре вычислений от IBM (IBM
Dictionary of Computing) как «центральное хранилище информации о данных,
такой как значение, взаимосвязи с другими данными, их источник, применение
и формат.»
В базах данных и обработке транзакций двухфазная блокировка (2PL) —
это метод управления параллелизмом, который гарантирует сериализуемость.
Это также имя результирующего набора графиков транзакций базы данных
(истории). Протокол использует блокировки, применяемые транзакцией к
данным, которые могут блокировать (интерпретировать как сигналы для
остановки) другие транзакции от доступа к тем же данным в течение жизни
транзакции.
17
2 Практическая часть
2.1 Постановка задачи
Университет (от нем. Universität, которое, в свою очередь, произошло от
лат. universitas — совокупность, общность) — высшее учебное заведение, где
готовятся специалисты по фундаментальным и многим прикладным наукам. Как
правило,
осуществляет
современные
и
университеты
научно-исследовательскую
действуют
как
работу.
Многие
учебно-научно-практические
комплексы. Университеты объединяют в своём составе несколько факультетов,
на которых представлена совокупность различных дисциплин, составляющих
основы научного знания.
Университет ведет учет научных руководителей студентов. Требуется
обеспечить хранение и обработку следующих данных:
●
Информация о персональных данных студентов и преподавателей с
указанием, как минимум, ФИО, даты рождения, пола и т.п.
●
По каждому преподавателю известны его должность и период
трудового контракта.
●
По каждому студенту известны его специальность и научный
руководитель. У студента может быть только один научный руководитель, либо
не быть вообще.
2.2 Выбор СУБД
В качестве СУБД был выбран MS SQL. т.к. Microsoft SQL — система
управления реляционными базами данных (РСУБД), разработанная корпорацией
Microsoft. Основной используемый язык запросов — Transact-SQL, создан
совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта
ANSI/ISO по структурированному языку запросов (SQL) с расширениями.
18
Используется для работы с базами данных размером от персональных до
крупных баз данных масштаба предприятия; конкурирует с другими СУБД в
этом сегменте рынка.
2.3 Построение отношения в 1НФ
Отношение находится в первой нормальной форме (сокращённо 1НФ),
если все его атрибуты атомарны, то есть если ни один из его атрибутов нельзя
разделить на более простые атрибуты, которые соответствуют каким-то другим
свойствам описываемой сущности.
Таблица 2 – Таблица «Студент»
Код
ФИО
Дата рождения Пол
Петров Николай Федорович
1995.05.22
студента
1
Мужской
Таблица 3 – Таблица «Преподаватель»
Код
ФИО
преподават
Дата
Пол
рождения
еля
1
Феденко
1975.01.01
Мужской
Дата
Дата
начала
окончания
контракта
контракта
2015.01.01
2020.01.01
Александр
Иванович
2.4 Формирование минимального множества функциональных
зависимостей
Множество функциональных зависимостей S называется минимальным в
том и только в том случае, когда оно удовлетворяет следующим свойствам:
19
* правая часть любой ФЗ из S является множеством из одного атрибута
(простым атрибутом);
* детерминант каждой ФЗ из S обладает свойством минимальности; это
означает, что удаление любого атрибута из детерминанта приводит к изменению
замыкания S+, т. е. порождению множества ФЗ, неэквивалентного S);
* удаление любой ФЗ из S приводит к изменению S+, т. е. порождению
множества ФЗ, неэквивалентного S.
В нашем случае минимальное множество функциональных зависимостей
выглядит следующим образом:
S{
Код преподавателя → ФИО преподавателя,
Код преподавателя → Дата рождения преподавателя,
Код преподавателя → Пол преподавателя,
Код преподавателя → Дата начала контракта,
Код преподавателя → Дата окончания контракта,
Код преподавателя → Должность,
Код студента → ФИО студента,
Код студента → Дата рождения студента,
Код студента →
Пол студента,
Код студента → Специальность,
Код студента → Руководитель
}
2.5 Определение потенциальных ключей, определение первичного ключа
отношения
Первичным
ключом
отношения
“Преподавателя”,
будет
“Код
преподавателя”, а отношения “Студент”, “Код студента”. Потенциальными
ключами могу стать “Код специальности” и “Код должности”.
20
2.6 Получение 2НФ
1НФ, также может обладать избыточностью. Для её устранения
предназначена вторая нормальная форма. Переменная отношения находится во
второй нормальной форме тогда и только тогда, когда она находится в первой
нормальной форме и каждый неключевой атрибут неприводимо зависит от
(каждого) её потенциального ключа.
Для реализации второй нормальной формы, отделим от отношения
“Студенты” атрибут “Специальность” в отдельное отношение.
Таблица 4 - Специальность
Код специальности
Название
1
Программист
А для отношения “Преподаватель” выделим отношение “Должность”.
Таблица 5 - Должность
Код должности
Название
1
Зав. кафедры
2.7 Перевод всех отношений в 3НФ и НФБК
Переменная отношения находится в третьей нормальной форме тогда и
только тогда, когда она находится во второй нормальной форме, и отсутствуют
транзитивные
функциональные
зависимости
неключевых
атрибутов
от
ключевых. Так как транзитивных зависимостей нет, то все таблицы находятся в
3НФ. Так же все отношения находятся в НФБК, так как они имеют по одному
потенциальному (первичному) ключу.
21
2.8 ER-диаграмма предметной области
Проектирование структуры базы данных будем выполнять с помощью метода
«сущность-связь».
Рисунок 5 – ER диаграмма предметной области
2.9 Создание базы данных
После установки СУБД MS SQL создадим новую базу данных с именем
“University”.
Рисунок 6 - Создание новой базы данных
22
Создадим 4 таблицы которые, мы определили ранее (Листинг 1-4):
use University
create table Student (
Id bigint primary key not null,
FIO varchar(100),
BirthDate date,
Sex varchar(10),
tId bigint,
sId bigint
)
Листинг 1. – Создание таблицы “Student”
use University
create table Teacher(
Id bigint primary key not null,
FIO varchar(100),
BirthDate date,
Sex varchar(10),
ContractPeriodFrom date,
ContractPeriodTo date,
pId bigint
)
Листинг 2. – Создание таблицы “Teacher”
23
use University
create table Position(
Id bigint primary key not null,
Name varchar(100)
)
Листинг 3. – Создание таблицы “Position”
use University
create table Specialty(
Id bigint primary key not null,
Name varchar(100)
)
Листинг 4. – Создание таблицы “Specialty”
2.10 Создание диаграммы БД. Определение правила поддержания
ссылочной целостности системы ключей
Ссылочная целостность (англ. referential integrity) — необходимое
качество реляционной базы данных, заключающееся в отсутствии в любом её
отношении внешних ключей, ссылающихся на несуществующие кортежи.
Связи между данными, хранимыми в разных отношениях, в реляционной
БД устанавливаются с помощью использования внешних ключей — для
установления связи между кортежем из отношения A с определённым кортежем
отношения B в предусмотренные для этого атрибуты кортежа отношения A
записывается значение первичного ключа (а в общем случае значение
потенциального ключа) целевого кортежа отношения B.
24
Рисунок 7 – Диаграмма базы данных
2.11 Наполнение БД тестовыми данными
Для заполнения табличных данных будет использоваться оператор
INSERT.
insert into Specialty(Id, Name) values (2, 'Дизайнер')
Листинг 5. – Пример добавление данных
Таким же образом заполняем оставшиеся таблицы значениями.
2.12 Создание ограничения
Создадим ограничение, запрещающее назначать научным руководителем
преподавателя с неактуальным в настоящий момент трудовым контрактом.
Для создания ограничения будет использоваться оператор CHECK и
скалярная функция.
25
Для начала создадим функцию.
create function _Check(@id bigint)
returns int as begin
if(@id in (select id from teachers where ContractPeriodTo > GETDATE()))
return 1
return 0
end
Листинг 6. – Скалярная функция для ограничения
Далее создадим ограничение.
alter table Students
with check add constraint cc1
check(dbo._Check(Students.tId) = 1)
Листинг 7. – Ограничение
Добавим преподавателя без даты контракта
Рисунок 8 - Новый преподаватель
Затем попробуем добавить нового студента с кодом руководителя, у
которого отсутствует дата контракта.
Рисунок 9 - Ошибка добавления
26
2.13. Создание триггера на таблицу
Создадим триггер на таблицу с преподавателями: при обновлении полей
срока трудового контракта поле "С" должно быть менее поля «До» либо иметь
неопределенные значения. С помощью триггера запретим обновление, если
условия не выполнены
create TRIGGER _trigger
ON Teachers
after UPDATE
AS
if((select ContractPeriodFrom from inserted) >= (select ContractPeriodTo from
inserted))
begin
RAISERROR ('Начало даты контракта не может быть меньше или равно его
концу', 16, 10);
rollback
end
Листинг 8. – триггер на таблицу “Teachers”
Попробуем обновить данные в таблице
Рисунок 9 - Срабатывание триггера и откат обновления
27
2.14 Создание представления
Создадим
представление
по
результатам
назначения
научных
руководителей с указанием сведений о студентах и преподавателях.
create view _View
as
select
t.FIO, t.ContractPeriodFrom, t.ContractPeriodTo, t.BirthDate,t.Sex, --Информация о
преподавателе
p.pName, --Должность
s.FIO 'Student Fio',s.BirthDate'Student Birthdate',s.Sex 'Student Sex', --Информация
о студенте
sp.Name –Специальность
from Teachers t
left join Students s on s.tId = t.Id
left join Specialty sp on sp.Id = s.sId
left join Positions p on p.Id = t.pId
Листинг 9. – Создание представления
Рисунок 10 - Результат выборки из представления
28
2.15 Создание хранимых процедур
2.15.1 По коду преподавателя вернуть всех студентов, кому он назначен
научным руководителем.
alter function _StudentsByTeacher(@TeacherId bigint)
returns table
as
return
(
Select s.FIO,s.BirthDate,s.Sex,sp.Name from Students s
left join Teachers t on t.Id = s.tId
left join Specialty sp on sp.Id = s.sId
where t.Id = @TeacherId
);
Листинг 10. – Поиск студентов по коду преподавателя
Рисунок 11. - Результат выполнения функции
2.15.2. Вывести список преподавателей, которые когда-либо были
научными руководителями студентов указанной специальности. Решить
задачу с использованием 1) операции соединения и 2) подзапроса
create function _TeachersWasTeachers_1(@SpecialtyId bigint)
returns table
as
return
(
Select distinct t.FIO,t.BirthDate,t.Sex from Teachers t
29
left join Students s on t.Id = s.tId
where s.sId = @SpecialtyId
);
Листинг 11. – Список преподавателей через соединение
Рисунок 11. - Результат выполнения функции
create function _TeachersWasTeachers_2(@SpecialtyId bigint)
returns table
as
return(
Select distinct t.FIO,t.BirthDate,t.Sex from Teachers t
where (t.Id in (select tId from Students where sId = @SpecialtyId)) );
Листинг 12. – Список преподавателей через подзапрос
Рисунок 12. - Результат выполнения функции
2.15.3. Вывести отсортированный список преподавателей с указанием
числа студентов, для которых он является научным руководителем
create function _TeachersWithStudentsCount()
returns table
as
return
(
Select t.FIO,t.BirthDate,t.Sex,count(s.Id)'Students count' from Teachers t
left join Students s on s.tId = t.Id
group by t.FIO,t.BirthDate,t.Sex
);
30
Листинг 13. – Список преподавателей и количество студентов
Рисунок 13. - Результат выполнения функции
2.15.4. Модифицируйте предыдущую ХП, чтобы в указанном списке
остались только те преподаватели, которые осуществляют руководство
более чем над N студентами.
alter function _TeachersWithStudentsCount()
returns table
as
return
(
Select t.FIO,t.BirthDate,t.Sex,count(s.Id)'Students count' from Teachers t
left join Students s on s.tId = t.Id
group by t.FIO,t.BirthDate,t.Sex
having count(s.Id) > 0
);
Листинг 14. – Список преподавателей и количество студентов
(модифицировано)
Рисунок 14. - Результат выполнения функции
2.15.5. Вывести список преподавателей, которые хотя бы однажды были
научными руководителями студентов указанной специальности.
create function _TeachersWasTeachers_1(@SpecialtyId bigint)
returns table
31
as
return
(
Select distinct t.FIO,t.BirthDate,t.Sex from Teachers t
left join Students s on t.Id = s.tId
where s.sId = @SpecialtyId
);
Листинг 15. – Список преподавателей через соединение
Рисунок 15. - Результат выполнения функции
32
Заключение
В результате выполнения курсовой работы была разработана база данных
университета. Был создано несколько отношений, а также была установлена
связь между ними.
Для создания хороших условий пользования базой данных были
разработаны триггеры и ограничения на ввод, обновление и удаления данных из
таблиц. Затем для объединения данных отдельных таблиц и их дальнейшего
просмотра были созданы представления. Так же были реализованы хранимые
процедуры. Они нужны для быстрого доступа к сортированным данным с
определенными условиями выборки.
Как
правило,
интегрировать
приходится
неоднородные
БД,
распределенные в вычислительной сети. Это в значительной степени усложняет
реализацию. Дополнительно к собственным проблемам интеграции приходится
решать
все
проблемы,
присущие
распределенным
СУБД:
управление
глобальными транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно
добиться эффективности.
При курсовом проектировании достигнуты поставленные в начале работы
цели, а именно исследование распределенных баз данных.
33
Список литературы
1. https://ru.wikipedia.org/wiki/
2. https://studfiles.net/
3. https://www.google.com
4. Алан Бьюли «Изучаем SQL» (2007)
5. Крис Фиайли «SQL» (2013)
6. Энтони Молинаро «SQL. Сборник рецептов» (2009)
7. Алекс Кригель и др. «SQL. Библия пользователя», 2-е издание (2010)
34
Скачать