Учет и обработка данных об учебной литературе кафедры

Размещено на http://www.allbest.ru/

Министерство образования и науки молодежи и спорта Украины

Харьковский национальный университет радиоэлектроники

Факультет КИУ

Кафедра ЭВМ

курсовой ПРОЕКТ

пояснительная ЗАПИСКА

Учет и обработка данных об учебной литературе кафедры

Студент КИ-10-3 Лакатош В.А.

Руководитель проекту проф. Танянский С.С.

2012 г.



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание задачи

1.2 Ограничения ведения базы данных

1.3 Неформальная постановка задачи

2. ПРОЕКТИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ

2.1 Определение функциональных зависимостей

2.2 Разработка структуры базы данных

2.3 Организация запросов к базе данных

3. РАЗРАБОТКА СРЕДСТВ ПОДДЕРЖКИ ДАННЫХ

3.1 Разработка представлений

3.2 Использование триггеров для поддержки данных в актуальном состоянии

3.3 Разработка хранимых процедур и функций

3.4 Каскадность

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ



Введение

Проектирование информационных систем с использованием реляционных баз данных (РБД) становится доминирующей с начала 70-х годов. Однако отсутствие надежных методик и способов автоматизации проектирования логической схемы не приводило к эффективному результату. Научной основой разработки современных средств автоматизации является теория РБД.

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

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

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

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Описание задачи

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

КАФЕДРА (Название кафедры, которой принадлежит учебная литература)

ПРЕДМЕТ (Название предмета)

ПРЕПОДАВАТЕЛЬ (ФИО преподавателя)

ТИП ЛИТЕРАТУРЫ (Поле, которое содержит значения: книга, периодическое издание, конспект лекций и др.)

ТЕМА (Тема учебного материала)

НАЗВАНИЕ (Название учебного материала)

АВТОР (ФИО автора)

ГОД ИЗДАНИЯ

ФИО СТУДЕНТА

ДАТА ВЫДАЧИ

ДАТА ВОЗВРАТА

В результате анализа предметной области выделим в качестве первичного ключа атрибуты ФИО студента, НАЗВАНИЕ, так как предполагается, что полных однофамильцев не бывает, но один и тот же студент может взять несколько учебных материалов, таким образом, в составной ключ необходимо включить атрибуты НАЗВАНИЕ и ФИО СТУДЕНТА.

Таким образом, база данных, полученная на основании заданных атрибутов, будет иметь схему, представленную на рисунке 1, где подчеркнутые атрибуты являются первичным ключом.

Кафедра	Предмет	Преподаватель	Тип литературы	Тема	Название	Автор	Год издания	ФИО Студента	Дата выдачи	Дата возврата

Рисунок 1 - Схема БД

1.2 Ограничения ведения базы данных

В процессе ведения БД необходимо поддерживать соответствия (целостность) между введенными данными на основе требований обусловленных предметной областью.

Для рассмотренной задачи определим соответствия между атрибутами:

1. Название однозначно должно определять тему, тип, автора, год издания, предмет и кафедру

2. Предмет однозначно должен определять преподавателя

3. ФИО студента, название должны однозначно определять дату выдачи и дату возврата

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

Кроме этого, хранение данных в одной таблицы при заданных ограничениях является избыточной.

1.3 Неформальная постановка задачи

Проведенный анализ предметной области показал, что ведение данных в одной таблице не отвечает некоторым требованиям, предъявляемым к реляционным БД по причине, описанным в предыдущем разделе.

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

Например, информация о выдаче литературы студенту (ФИО, название, дата выдачи, дата возврата), об учебной литературе, о предмете. При этом БД должна представлять собою целостную систему, то есть пользователь должный иметь возможность в любой момент времени получить всю (любую) информацию, которая хранится в БД.

Таким образом, в курсовом проекте решаются следующие задачи:

- проанализировать методы проектирования баз данных;

- из описания предметной области выделить множество атрибутов, необходимых для хранения данных;

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

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

- используя метод нормализации структуры отношения, построить третью нормальная форма схемы БД;

- разработать и реализовать статические запросы к БД в виде представлений;

- реализовать расширенную поддержку целостности, с использованием триггеров;

- реализовать дополнительные функции администрирования БД (с использованием хранимых процедур и функций);



2. ПРОЕКТИРОВАНИЕ СТРУКТУРЫ БАЗЫ ДАННЫХ

2.1 Определение функциональных зависимостей

На основании рассмотренных требований к БД (раздел 1.2) и поставленной задачи (раздел 1.3) формализуем ограничения на данные в виде функциональных зависимостей.

1. Название тема, тип, автор, год издания

2. Название предмет, кафедра

3. Предмет преподаватель

4. ФИО студента, название дата выдачи, дата возврата

2.2 Разработка структуры базы данных

база данные запрос триггер

Для исключения возможных аномалий описанных в разделе 1.2 необходимо нормализовать БД, то есть привести ее к нормальной форме. Заданные ограничения в виде функциональных зависимостей (раздел 2.1.) позволяют построить третью нормальную форму (3НФ), которая устранит нежелательные свойства ведения БД.

Очевидно, что представленный набор атрибутов (рисунок 1) соответствует первой нормальной форме (1НФ). Воспользуемся определением неполной функциональной зависимости [1,2] и построим вторую нормальную форму (2НФ).

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

Исходное отношение: .

Ключ: - сложный.

Функциональные зависимости:

- зависимость всех атрибутов от ключа отношения.

- зависимость некоторых атрибутов от части составного ключа.

Декомпозированные отношения:

- остаток от исходного отношения. Ключ .

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

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

Среди заданных функциональных зависимостей неполной является зависимость Название тема, тип, автор, год издания, предмет, кафедра. Для построения 2НФ необходимо вынести её в отдельные таблицу “ИЗДАНИЯ”.

Таким образом, БД будет иметь вид, представленный на рисунке 2:



“СТУДЕНТ” “ИЗДАНИЯ”

ФИО Студента	1	Название
Название		Тип литературы
Дата выдачи		Тема
Дата возврата		Автор
		Год издания
		Предмет
		Преподаватель
		Кафедра

Рисунок 2 - Структура БД во 2НФ

При этом функциональные зависимости будут соответствовать таблицам, следующим образом:

1. таблице “СТУДЕНТ” соответствуют функциональные зависимости

ФИО студента, название дата выдачи, дата возврата

2. таблице “ИЗДАНИЯ” соответствуют функциональные зависимости

Название тема, тип, автор, год издания, предмет, кафедра

Предмет преподаватель

Для дальнейшей нормализации необходимо исключить из множества транзитивные зависимости [1,2]. Определим понятие транзитивной зависимости.

Пусть X,Y,Z - три атрибута некоторого отношения. При этом X --> Y и Y-->Z, но обратное соответствие отсутствует, т.е. Z-/-> Y-/-> X. Тогда Z транзитивно зависит от X.

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

Исходное отношение: .

Ключ: .

Функциональные зависимости:

- зависимость всех атрибутов от ключа отношения.

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

Декомпозированные отношения:

- остаток от исходного отношения. Ключ .

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

Среди множества зависимостей таблицы «ИЗДАНИЯ» можно выделить зависимость “ Предмет Преподаватель”, в которой атрибут “Преподаватель” транзитивно зависит от атрибута “Название”. Таким образом, для построения 3НФ необходимо вынести эту зависимость в отдельную таблицу “ПРЕДМЕТ”.

При этом БД будет иметь структуру, представленную на рисунке ниже.

“СТУДЕНТ”		“ИЗДАНИЕ”		“ПРЕДМЕТ”
ФИО студента		Название		Предмет
Название		Тип литературы		Преподаватель
Дата выдачи		Тема
Дата возврата		Предмет
		Автор
		Год издания
		Кафедра

Рисунок 3 - Структура БД в 3НФ

Функциональные зависимости будут соответствовать таблицам, следующим образом:

1. таблице “СТУДЕНТ” соответствуют функциональные зависимости

ФИО студента, название дата выдачи, дата возврата

2. таблице “ИЗДАНИЯ” соответствуют функциональные зависимости

Название тема, тип, автор, год издания, предмет, кафедра

3. таблице “ПРЕДМЕТ” соответствуют функциональные зависимости

Предмет преподаватель

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

Для определения схемы БД определим свойства атрибутов:

Свойства атрибутов БД

Таблица: “СТУДЕНТ”

Имя атрибута	Свойства
ФИО	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Да - Первичный ключ
Название	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Нет - Первичный ключ - Внешний ключ таблицы “ИЗДАНИЕ”
ДатаВыдачи	- Тип данных: Время - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Нет
ДатаВозврата	- Тип данных: Время - Обязательное поле: Нет - Пустые значения: Нет - Индексированное поле: Нет

Таблица: “ИЗДАНИЕ”

Имя атрибута	Свойства
Название	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые строки: Нет - Индексированное поле: Да - Первичный ключ
ТипЛитературы	- Тип данных: Текстовый - Размер поля: 40 символов - Обязательное поле: Да - Пустые строки: Нет - Индексированное поле: Нет
Тема	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Да
Автор	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Да
ГодИздания	- Тип данных: Целочисленный - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Нет
Кафедра	- Тип данных: Текстовый - Размер поля: 40 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Нет
Предмет	- Тип данных: Текстовый - Размер поля: 40 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Да - Внешний ключ таблицы “ПРЕДМЕТ”

Таблица: “ПРЕДМЕТ”

Имя атрибута	Свойства
Предмет	- Тип данных: Текстовый - Размер поля: 40 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Да - Первичный ключ
Преподаватель	- Тип данных: Текстовый - Размер поля: 100 символов - Обязательное поле: Да - Пустые значения: Нет - Индексированное поле: Нет

Теоретически проект базы данных готов. Следующим этапом является ее создание. Для создания БД использовался Microsoft SQL Server 2008 R2. После создания БД и определения типа всех полей я получил такую схему:

Рисунок 5 - Схема БД в MS SQL Server



2.3 Организация запросов к базе данных

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

1. Вывести информацию о заданной литературе.

"CREATE PROCEDURE zapros1

@nazvanie varchar(100)

AS

SELECT Название, Тема, Автор, ГодИздания, Предмет, Кафедра

FROM ИЗДАНИЕ

WHERE Название = @ nazvanie;"

Вызов процедуры:

"EXEC zapros1 'Программирование баз данных'"

2. Получить информацию об изданиях кафедры

"CREATE PROCEDURE zapros2

@kafedra varchar(100)

AS

SELECT Название, Тема, Автор, ГодИздания, Предмет

FROM ИЗДАНИЯ

WHERE Кафедра = @kafedra;"

Вызов процедуры:

"EXEC zapros2 'ЭВМ'"

3. Вывести учебные материалы, которые брал студент.

"CREATE PROCEDURE zapros3

@stud varchar(100)

AS

SELECT a.Название, a.ДатаВыдачи, a.ДатаВозврата, b.Предмет FROM СТУДЕНТ AS a INNER JOIN ИЗДАНИЯ AS b ON a.Название = b.Название

WHERE a.ФИО = @stud;"

Вызов процедуры:

"EXEC zapros3 'Иванов И.И.'"



3. РАЗРАБОТКА СРЕДСТВ ПОДДЕРЖКИ БАЗЫ ДАННЫХ

3.1 Разработка представлений

Для обеспечения корректности и ограничения доступа к данным при многопользовательском режиме работы с БД для рассматриваемой задачи разработаны два представления, отражающие частичную информацию из БД [3, 4].

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

SELECT dbo.СТУДЕНТ.ФИО, dbo.СТУДЕНТ.Название, dbo.СТУДЕНТ.ДатаВыдачи, dbo.СТУДЕНТ.ДатаВозврата, dbo.ИЗДАНИЕ.Предмет

FROM dbo.ИЗДАНИЕ INNER JOIN dbo.СТУДЕНТ ON dbo.ИЗДАНИЕ.Название = dbo.СТУДЕНТ.Название

ORDER BY dbo.СТУДЕНТ.ФИО, dbo.СТУДЕНТ.Название

2) Представление “Преподаватели” отражает список всех преподавателей, кафедру, на которой они работаю и предмет, который ведут. Программный фрагмент, реализующий представление “Преподаватели” можно описать следующим образом:

CREATE VIEW Преподаватели

AS

SELECT dbo.ПРЕДМЕТ.Предмет,dbo.ПРЕДМЕТ.Преподаватель, dbo.ИЗДАНИЕ.Кафедра

FROM dbo.ИЗДАНИЕ INNER JOIN dbo.ПРЕДМЕТ ON dbo.ИЗДАНИЕ.Предмет = dbo.ПРЕДМЕТ.Предмет

3) Представление “Литература” отображает названия всей зарегистрированной литературы, тему, год издания и автора. Программный фрагмент, реализующий представление “Литература” можно описать следующим образом:

CREATE VIEW Литература

AS

SELECT Название, Тема, Автор, ГодИздания

FROM dbo.ИЗДАНИЕ

ORDER BY Название

3.2 Использование триггеров для поддержки данных в актуальном состоянии

Обеспечение дополнительных ограничений на данные организуется с помощью триггеров. Необходимость использования триггеров обуславливается следующими требованиями рассматриваемой задачи [3, 4]:

1) Дата выдачи не может быть позже текущей

CREATE TRIGGER DateInsert

ON СТУДЕНТ

AFTER INSERT

AS

BEGIN

DECLARE @curDate datetime,

@insDate datetime

DECLARE dateCur CURSOR

FOR SELECT ДатаВыдачи FROM inserted

OPEN dateCur

SET @curDate = getdate()

FETCH FROM dateCur INTO @insDate

WHILE (@@FETCH_STATUS=0)

BEGIN

IF @insDate > @curDate

BEGIN

RAISERROR ('Данная вставка запрещена',16,1);

ROLLBACK TRANSACTION;

END

ELSE

PRINT('Данные изменены');

FETCH FROM dateCur INTO @insDate

END

CLOSE dateCur

DEALLOCATE dateCur

END

2) Нельзя удалять информацию о выдаче книги, если поле ДатаВозврата отсутствует

CREATE TRIGGER DeleteInfo

ON СТУДЕНТ

AFTER DELETE

AS

BEGIN

DECLARE @retDate datetime

DECLARE dateCur CURSOR

FOR SELECT ДатаВозврата FROM deleted

OPEN dateCur

FETCH FROM dateCur INTO @retDate

WHILE (@@FETCH_STATUS=0)

BEGIN

IF @retDate = null

BEGIN

RAISERROR ('Студент не вернул учебный материал',16,1);

ROLLBACK TRANSACTION;

END

FETCH FROM dateCur INTO @retDate

END

CLOSE dateCur

DEALLOCATE dateCur

END

3.3 Разработка хранимых процедур

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

· хранение в исполняемом формате (перед выполнением хранимой процедуры SQL Server генерирует для нее план исполнения, выполняет ее оптимизацию и компиляцию);

· поддержка модульного программирования (позволяют разбивать большие задачи на самостоятельные, более мелкие и удобные в управлении части);

· могут вызывать другие хранимые процедуры и функции;

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

· выполняются быстрее, чем последовательность отдельных операторов;

· уменьшает размер запроса.

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

1) Процедура “ИнфоСтудента” возвращает количество книг, которые брал студент

Хранимая процедура организована следующим образом:

CREATE PROCEDURE ИнфоСтудента

@count int OUTPUT,

@fio nchar(100)

AS

SELECT @count= COUNT(@fio)

FROM СТУДЕНТ

WHERE ФИО = @fio

Вызов процедуры и обработка выходных данных.

DECLARE @count int

EXEC ИнфоСтудента @count output, 'Лакатош В.А.'

PRINT 'Количество взятых книг ' + CONVERT(char(10), @count)

2) Процедура “ИзданияГода” находит издания, выпущенные в заданном году.

Так как данные запросы возвращают множество строк (т.е. таблицу) реализуем процедуру в виде смешенного курсора.

Хранимая процедура организована следующим образом:

CREATE PROC ИзданиеГода

@year int,

@cur CURSOR VARYING OUTPUT

AS

SET @cur=CURSOR FORWARD_ONLY STATIC

FOR

SELECT Название, Автор, ГодИздания, Предмет

FROM ИЗДАНИЕ

WHERE ГодИздания = @year

OPEN @cur

Вызов процедуры и вывод на печать данных из выходного курсора

DECLARE @yearPubl CURSOR

DECLARE @nazv nchar(100)

DECLARE @auth nchar(100)

DECLARE @year int

DECLARE @subj nchar(40)

EXEC ИзданиеГода @year='2007', @cur=@yearPubl OUTPUT

FETCH NEXT FROM @yearPubl INTO @nazv, @auth, @year, subj

SELECT @nazv, @auth, @year, subj

WHILE (@@FETCH_STATUS=0)

BEGIN

FETCH NEXT FROM @yearPubl INTO @nazv, @auth, @year, subj

SELECT @nazv, @auth, @year, subj

END

CLOSE @yearPubl

DEALLOCATE @yearPubl

Для добавления и удаления данных в таблицы создадим для каждой таблица по процедуре на добавление и удаление.

Для таблицы СТУДЕНТ

1) Добавление

CREATE PROCEDURE addStud

@fio nchar(100),

@nazv nchar(100),

@getDate date,

@retDate date = null

AS

DECLARE @a int

DECLARE @b char(10), @c char(100)

BEGIN

INSERT INTO СТУДЕНТ(ФИО, Название, ДатаВыдачи, ДатаВозврата)

VALUES (@fio, @nazv, @getDate, @retDate)

SET @a=@@ERROR

SET @b=CONVERT(char(10),@a)

SET @c='Код ошибки '+@b+'- дублирование ключа'

if(@a!=0)

PRINT @c

END

Вызов

EXEC addStud 'Лакатош В.А.','MS SQL Server','21.10.2012'

2) Удаление

CREATE PROCEDURE delStud

@fio nchar(100),

@nazv nchar(100)

AS

BEGIN

DELETE СТУДЕНТ WHERE ФИО=@fio and Название=@nazv

END

Для таблицы ИЗДАНИЕ

1) Добавление

CREATE PROCEDURE addIzdan

@name nchar(100),

@type nchar(40),

@topic nchar(100),

@author nchar(100),

@year int,

@cath nchar(40),

@subj nchar(40)

AS

DECLARE @a int

DECLARE @b char(10), @c char(100)

BEGIN

INSERT INTO ИЗДАНИЕ(Название, ТипЛитературы, Тема, Автор, ГодИздания, Кафедра, Предмет)

VALUES (@name, @type, @topic, @author, @year, @cath, @subj)

SET @a=@@ERROR

SET @b=CONVERT(char(10),@a)

SET @c='Код ошибки '+@b+'- дублирование ключа'

if(@a!=0)

PRINT @c

END

2) Удаление

CREATE PROCEDURE delIzdan

@nazv nchar(100)

AS

BEGIN

DELETE ИЗДАНИЕ WHERE Название=@nazv

END

Для таблицы ПРЕДМЕТ

1) Добавление

CREATE PROCEDURE addPredm

@subj nchar(40),

@name nchar(100)

AS

DECLARE @a int

DECLARE @b char(10), @c char(100)

BEGIN

INSERT INTO ПРЕДМЕТ(Предмет, Преподаватель)

VALUES (@subj, @name)

SET @a=@@ERROR

SET @b=CONVERT(char(10),@a)

SET @c='Код ошибки '+@b+'- дублирование ключа'

if(@a!=0)

PRINT @c

END

2) Удаление

CREATE PROCEDURE delPredm

@nazv nchar(40)

AS

BEGIN

DELETE ПРЕДМЕТ WHERE Предмет=@nazv

END

3.4 Разработка процедур, отражающих ошибки манипулирования данными

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

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

· Обновление кортежа в базовом отношении.

· Удаление кортежа в базовом отношении.

· Вставка кортежа в зависимое отношение.

· Обновление кортежа в зависимом отношении.

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

Для поддержки целостности в таблице ПРЕДМЕТ создадим два триггера:

1) на каскадное удаление

CREATE TRIGGER trDelPredm ON ПРЕДМЕТ

DECLARE @subj nchar(40)

FOR DELETE

AS

BEGIN

SELECT @subj = Предмет FROM deleted

DELETE FROM ИЗДАНИЕ WHERE Предмет = @subj

END

2) на каскадное добавление

CREATE TRIGGER trAddPredm ON ПРЕДМЕТ

DECLARE @subj nchar(40)

FOR UPDATE

AS

BEGIN

SELECT @subj = Предмет FROM inserted

UPDATE ИЗДАНИЕ WHERE Предмет = @subj

END

Для поддержки целостности в таблице ИЗДАНИЕ создадим два триггера:

1) на каскадное удаление

CREATE TRIGGER trDelIzd ON ИЗДАНИЕ

DECLARE @nazv nchar(100)

FOR DELETE

AS

BEGIN

SELECT @nazv = Название FROM deleted

DELETE FROM СТУДЕНТ WHERE @nazv = Название

END

2) на каскадное добавление

CREATE TRIGGER trAddIzd ON ИЗДАНИЕ

DECLARE @nazv nchar(100)

FOR UPDATE

AS

BEGIN

SELECT @nazv = Название FROM inserted

UPDATE СТУДЕНТ WHERE @nazv = Название

END



ЗАКЛЮЧЕНИЕ

В ходе выполнения данной работы были получены следующие навыки:

1. Навыки проектирования баз данных.

2. Навыки работы с СУБД Microsoft SQL Server 2008 R2.

В результате выполнения курсового проекта была разработанная структура БД учета литературы, определены свойства атрибутов и целостности данных. Полученная структура обеспечивает независимое хранение и ведение данных об изданиях, предмете, взятой литературе и т. д.

Предлагаемая структура обеспечивает исключения ряда аномалий, таких как избыточность, добавление и удаление различных данных независимо друг от друга. Это подтверждается тем, что структура разработана на основании алгоритма нормализации и приведена к 3НФ.

В качестве основных результатов контрольной работы можно выделить следующее:

1. Проанализирована предметная область и сформулированы основные требования для разработки БД.

2. Определены ограничения ведения данных в виде функциональных зависимостей между атрибутами.

3. Разработанная структура БД и приведена к 3НФ на основании заданных функциональных зависимостей и алгоритма нормализации.

4. Определены основные свойства атрибутов для каждой таблицы БД.

5. Предложенное описание и структура БД может быть использована для практической реализации для учёта данных о тестировании.



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Дейт К. Введение в системы баз данных. М.: “Вильямс” 2001.

2. Т. Коннолли, К. Бегг, А. Страчан Базы данных: проектирование, реализация и сопровождение. Терия и практика, 2-е изд.: Пер. с англ.: Уч. Пос. - М.: Издательский дом “Вильямс”, 2000.

3. Д.Грофф, П.Вайнберг. SQL: полное руководство. - BHV-Киев, 1999.

4. Ю. Тихомиров MS SQL Server в подлиннике. - СПб.: БХВ, 2000.

5. Л. Шкарина Язык SQL: учебный курс. - СПб.: Питер, 2001.

Размещено на Allbest.ru