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

 

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

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

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

Кафедра ЭВМ

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

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

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

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

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

г.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

.1Описание задачи

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

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

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

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

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

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

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

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

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

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

.4Каскадность

ЗАКЛЮЧЕНИЕ

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОД ИЗДАНИЯ

ФИО СТУДЕНТА

ДАТА ВЫДАЧИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключ: .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"CREATE PROCEDURE zapros1

@nazvanie varchar(100) Название, Тема, Автор, ГодИздания, Предмет, Кафедра

FROM ИЗДАНИЕНазвание = @ nazvanie;"

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

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

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

"CREATE PROCEDURE zapros2

@kafedra varchar(100) Название, Тема, Автор, ГодИздания, Предмет

FROM ИЗДАНИЯ

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

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

"EXEC zapros2 'ЭВМ'"

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

"CREATE PROCEDURE zapros3

@stud varchar(100)

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

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

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

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

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

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

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

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

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

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

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

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

AS

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

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

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

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

AS

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

FROM dbo.ИЗДАНИЕ

ORDER BY Название

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

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

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

CREATE TRIGGER DateInsertСТУДЕНТINSERT@curDate datetime,

@insDate datetimedateCur CURSORSELECT ДатаВыдачи FROM inserteddateCur@curDate = getdate()FROM dateCur INTO @insDate(@@FETCH_STATUS=0)@insDate > @curDate('Данная вставка запрещена',16,1);TRANSACTION;('Данные изменены');FROM dateCur INTO @insDatedateCurdateCur

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

CREATE TRIGGER DeleteInfoСТУДЕНТDELETE@retDate datetimedateCur CURSORSELECT ДатаВозврата FROM deleteddateCurFROM dateCur INTO @retDate(@@FETCH_STATUS=0)@retDate = null('Студент не вернул учебный материал',16,1);TRANSACTION;FROM dateCur INTO @retDatedateCurdateCur

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

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

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

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

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

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

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

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

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

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

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

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

@count int OUTPUT,

@fio nchar(100)@count= COUNT(@fio)СТУДЕНТФИО = @fio

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

DECLARE @count intИнфоСтудента @count output, 'Лакатош В.А.''Количество взятых книг ' + CONVERT(char(10), @count)

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

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

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

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

@year int,

@cur CURSOR VARYING OUTPUT@cur=CURSOR FORWARD_ONLY STATICНазвание, Автор, ГодИздания, ПредметИЗДАНИЕГодИздания = @year@cur

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

DECLARE @yearPubl CURSOR@nazv nchar(100)@auth nchar(100)@year int@subj nchar(40)ИзданиеГода @year='2007', @cur=@yearPubl OUTPUTNEXT FROM @yearPubl INTO @nazv, @auth, @year, subj@nazv, @auth, @year, subj(@@FETCH_STATUS=0)NEXT FROM @yearPubl INTO @nazv, @auth, @year, subj@nazv, @auth, @year, subj@yearPubl@yearPubl

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

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

) Добавление

CREATE PROCEDURE addStud

@fio nchar(100),

@nazv nchar(100),

@getDate date,

@retDate date = null@a int@b char(10), @c char(100)INTO СТУДЕНТ(ФИО, Название, ДатаВыдачи, ДатаВозврата)(@fio, @nazv, @getDate, @retDate)@a=@@ERROR@b=CONVERT(char(10),@a)@c='Код ошибки '+@b+'- дублирование ключа'(@a!=0)@c

Вызов

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

2) Удаление

CREATE PROCEDURE delStud

@fio nchar(100),

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

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

) Добавление

CREATE PROCEDURE addIzdan

@name nchar(100),

@type nchar(40),

@topic nchar(100),

@author nchar(100),

@year int,

@cath nchar(40),

@subj nchar(40)@a int@b char(10), @c char(100)INTO ИЗДАНИЕ(Название, ТипЛитературы, Тема, Автор, ГодИздания, Кафедра, Предмет)(@name, @type, @topic, @author, @year, @cath, @subj)@a=@@ERROR@b=CONVERT(char(10),@a)@c='Код ошибки '+@b+'- дублирование ключа'(@a!=0)@c

2) Удаление

CREATE PROCEDURE delIzdan

@nazv nchar(100)ИЗДАНИЕ WHERE Название=@nazv

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

) Добавление

CREATE PROCEDURE addPredm

@subj nchar(40),

@name nchar(100)@a int@b char(10), @c char(100)INTO ПРЕДМЕТ(Предмет, Преподаватель)(@subj, @name)@a=@@ERROR@b=CONVERT(char(10),@a)@c='Код ошибки '+@b+'- дублирование ключа'(@a!=0)@c

2) Удаление

CREATE PROCEDURE delPredm

@nazv nchar(40)ПРЕДМЕТ WHERE Предмет=@nazv

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

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

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

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

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

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

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

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

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

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

CREATE TRIGGER trDelPredm ON ПРЕДМЕТ@subj nchar(40)DELETE@subj = Предмет FROM deletedFROM ИЗДАНИЕ WHERE Предмет = @subj

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

CREATE TRIGGER trAddPredm ON ПРЕДМЕТ@subj nchar(40)UPDATE@subj = Предмет FROM insertedИЗДАНИЕ WHERE Предмет = @subj

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

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

CREATE TRIGGER trDelIzd ON ИЗДАНИЕ@nazv nchar(100)DELETE@nazv = Название FROM deletedFROM СТУДЕНТ WHERE @nazv = Название

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

CREATE TRIGGER trAddIzd ON ИЗДАНИЕ@nazv nchar(100)UPDATE@nazv = Название FROM insertedСТУДЕНТ WHERE @nazv = Название

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Министерство образования и науки молодежи и спорта Украины Харьковский национальный университет радиоэлектроники Факультет КИУ Кафедра ЭВМ

Больше работ по теме: