24

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

• Содержание
• Введение
• 1. Анализ предметной области
• 1.1 Описание предметной области
• 1.2 Количественный анализ модели процесса
• 2. Концептуальное проектирование базы данных
• 2.1 Логический уровень концептуальной схемы
• 2.2 Физический уровень концептуальной схемы
• 2.3 Создание таблиц базы данных на языке SQL
• 2.4 Запросы SQL на манипулирование данными
• 2.5 Запросы SQL на выборку информации из базы данных
• 2.5.1 Простые запросы
• 3. Целостность и безопасность базы данных
• 3.1 Целостность данных
• 3.2 Стратегии безопасности базы данных
• Заключение
• Список использованных источников
• Приложение

Введение

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. Построить модель процессов предметной области;

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

3. Обеспечить ограничение целостности и безопасности для базы данных.

1. Анализ предметной области

1.1 Описание предметной области

Рассмотрим осуществление процесса учета результатов футбольного турнира (Рисунок 1). Процессы данной предметной области выполняются в соответствии с правилами Международной Футбольной Ассоциации, а так же в соответствии с регламентом, установленным со стороны организатора.

Процесс учета результатов футбольного турнира осуществляется с момента подготовки к турниру до отправки данных в спорткомитет и включает в себя следующие этапы: подготовка к турниру, проведение турнира и обработка результатов турнира (Рисунок 2).



Рассмотрим подробнее каждый этап. Процесс подготовки к турниру рисунок 3 включает в себя этапы утверждение мест проведения, составление расписания, а так же составление протокола матча.



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



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



1.2 Количественный анализ модели процесса

Анализ контекстной диаграммы A-0 «Организация футбольного турнира»

Количество блоков: 1

Уровень декомпозиции диаграммы: 0

Коэффициент сбалансированности:

Число стрелок, соединяющихся с блоком: 7

Анализ детализации процесса A0 «Организация футбольного турнира»

Количество блоков: 3

Уровень декомпозиции диаграммы: 1

Коэффициент сбалансированности:

Анализ детализация процесса A1 «Подготовка к турниру»

Количество блоков: 3

Уровень декомпозиции диаграммы: 2

Коэффициент сбалансированности:

Анализ детализация процесса A12 «Составление расписания»

Количество блоков: 3

Уровень декомпозиции диаграммы: 3

Коэффициент сбалансированности:

Анализ детализация процесса A3 «Обработка результатов турнира»

Количество блоков: 3

Уровень декомпозиции диаграммы: 3

Коэффициент сбалансированности:

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



2. Концептуальное проектирование базы данных

2.1 Логический уровень концептуальной схемы

Логический уровень концептуальной схемы процесса «Учет результатов футбольного турнира» представлен следующим набором сущностей (Рисунок 2.1): футболист, тренерский штаб, турнир, команда, матч.

Сущность «Команда» представляет собой набор атрибутов, который позволит хранить более подробную информацию о футболистах и тренерах. Ключевым атрибутом данной сущности является «Номер команды». К неключевым относятся следующие атрибуты: «Название», «Цвет формы», «Информация».

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



Неключевыми атрибутами данной сущности являются «Дата рождения», «Рост», «Вес», «Позиция», «ФИО» и мигрирующий ключ «Номер команды»,а для сущности «Тренерский штаб» ключевым атрибутом является «Номер тренера», а неключевыми «ФИО», «Дата рождения», «Профессия» и мигрирующий ключ «Номер команды».

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

Сущность «Матч» определяет набор атрибутов, которые описывают конкретный футбольный матч. В качестве ключевого атрибута данной сущности был введен ключ «Номер матча». К неключевым атрибутам данной сущности относятся атрибуты «Дата матча», «Результат матча» и мигрирующие ключи «Первая команда», «Номер турнира» и «Номер команды». Особенностью логического уровня концептуальной схемы является взаимосвязь сущностей «Команда» и «Матч» по средствам двух неидентифицирующих связей, т.к. для проведения матча необходимо в сущности «Матч» наличие двух команд. Связь между сущностью «Команда» и «Матч» «один ко многим»: одна команда может участвовать в нескольких матчах.

Из особенностей предметной области было выявлено, что команда может принять участие во множестве турниров. Кроме этого, один турнир включает в себя множество команд. Явно видно, что связь между сущностями «Команда» и «Турнир» типа «многие ко многим» (Рисунок 2.2).

Рисунок 2.2 - Связь типа «многие ко многим»

При таком типе связи трудно проследить, каким образом связаны таблицы базы данных. Введение ассоциативной сущности решает проблему связей таблиц. Тем самым тип связи «многие ко многим» преобразовывается к типу «один ко многим» (Рисунок 2.3).

Рисунок 2.3 - Преобразование к связи типа «один ко многим»



Данная связь между сущностями не допускает NULL?значения внешнего ключа «номер_команды», потому что у команды обязательно должен быть номер, по которому она включена в турнир. Кроме этого, ассоциативная сущность «Матч» имеет атрибуты «номер_команды», а также «номер_ турнира».

2.2 Физический уровень концептуальной схемы

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

Физический уровень концептуальной схемы процесса «Учет результатов футбольного турнира» разрабатывался с учетом особенности СУБД MySQL 5.1 (Рисунок 2.4). В физической модели используются следующие типы атрибутов сущностей: INTEGER, VARCHAR, CHAR, DECIMAL, DATE. Рассмотрим каждый из них подробнее.

Типу INTEGER принадлежат атрибуты:

«Номер футболиста» сущности «Футболист»,

«Номер тренера» сущности «Тренерский штаб»,

«Номер команды» сущности «Команда»,

«Номер турнира» сущности «Турнир»,

«Номер матча», «Первая команда» сущности «Матч».

Тип INTEGER в СУБД MySQL позволяет хранить 4-байтные целочисленные данные. Диапазон от -2³¹ (-2147483648) до 2³¹-1 (2147483647). Этот тип выбран для перечисленных полей потому, что все они должны иметь значения целочисленного типа. Кроме того, данные поля являются ключевыми. Применение данного типа к ключевым атрибутам позволяет однозначно идентифицировать каждую сущность. Атрибуты имеют отметку «NOT NULL».

Типу VARCHAR принадлежат атрибуты:

«Позиция», «ФИО» сущности «Футболист»,

«ФИО», «Профессия» сущности «Тренерский штаб»,

«Название», «Информация» сущности «Команда»,

«Результаты матча» сущности «Матч».

Тип VARCHAR выбран для данных атрибутов потому, что в соответствующих полях будут храниться символьные данные переменной длинны. Максимальная длина для переменной данного типа в СУБД MySQL 5.1 достигает 4000 символов. Однако для выше перечисленных атрибутов ИС будет достаточно длины в 255 символов.

Типу DECIMAL принадлежат атрибуты:

«Вес» сущности «Футболист»,

«Призовой фонд» сущности «Турнир»,

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

Типу DATE принадлежат атрибуты:

«Дата рождения» сущности «Футболист»,

«Дата старта», сущности «Турнир»,

«Дата матча» сущности «Матч»,

Данный тип позволяет устанавливать и хранить календарную дату. Диапазон этого типа от 1 января 100 года до 27 февраля 32768 года.

2.3 Создание таблиц базы данных на языке SQL

По разработанной концептуальной схеме логического и физического уровней в базе данных «Учёт результатов футбольного турнира» были созданы 5 таблиц (Приложение А).



Таблица 2.1 - Соответствие между объектами концептуальной схемы и базы данных

Сущность	Атрибуты	Таблица	Название полей
Футболист	Номер_футболиста Дата_рождения Рост Вес Позиция ФИО	PLAYER	PLAYER_NUMBER PLAYER_DATE ROST VES POSITION FIO
Тренерский штаб	Номер_тренера ФИО Дата_рождения Профессия	COACH	COACH_NUMBER FIO COACH_DATE PROFESSION
Команда	Номер_команды Название Цвет_формы Информация	TEAM	TEAM_NUMBER TEAM_NAME TEAM_COLOUR INFORMATION
Турнир	Номер_турнира Призовой_фонд Дата_старта Длительность	TURNIR	TURNIR_NUMBER PRIZE_FOND START_DATE DLITELNOST
Матч	Номер_матча Дата_матча Результат_матча	MATCH	MATCH_NUMBER MATCH_DATE RESULT_MATCH

2.4 Запросы SQL на манипулирование данными

После создания таблиц базы данных была произведена её актуализация ? заполнение. При заполнении таблиц базы данных использовалось особое подмножество языка SQL ? язык манипуляции данными (DML). Наиболее часто пришлось использовать оператор INSERT, который позволяет написать запрос на заполнение полей таблиц соответствующими значениями.

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



Рисунок 2.5 - Таблица «Команда»

Рисунок 2.6 - Таблица «Футболисты»

Рисунок 2.7 - Таблица «Тренеры»

Рисунок 2.8 - Таблица «Турнир»

Рисунок 2.9 - Таблица «Матч»



2.5 Запросы SQL на выборку информации из базы данных

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

2.5.1 Простые запросы

1. Вывести информацию о матчах, которые были сыграны в июне 2012 года:

SELECT *

FROM MATCH WHERE (MATCH_DATE > '31.05.2012') AND (MATCH_DATE <= '31.06.2012')

Рисунок 2.10 - Результат выполнения запроса 1

Формула РА:

р _{MATCH_NUMBER, MATCH_DATE, RESULT_MATCH, FIRST_TEAM_FK, TURNIR_NUMBER_FK, TEAM_NUMBER_FK} (у _{(MATCH_DATE > 31.05.2012)& (MATCH_DATE <=31.12.2011)} (MATCH));

Формула РИК:

{m | m `MATCH' & $--m (MATCH) & m (MATCH_DATE > '31.05.2012') & (MATCH_DATE <= '31.06.2012')}

2. Вывести информацию о футболистах, рост которых не менее, чем '180'

SELECT *

FROM PLAYER WHERE ROST >= '180'

Рисунок 2.11 - Результат выполнения запроса 2

Формула РА:

р_{, PLAYER_NUMBER, PLAYER_DATE, ROST, VES, POSITION, FIO, TEAM_NUMBER_FK} (у _{(ROST>='180')} (PLAYER))

Формула РИК:

{p | p `PLAYER' & $--p (PLAYER--) & p (ROST >= '180')}

3. Удалить тренеров дата рождения, которых позже, чем '01.01.1986'

DELETE FROM COACH

WHERE COACH_DATE > '01.01.1986'

Рисунок 2.12 - Результат выполнения запроса 3

Формула РА:

р _{COACH_NUMBER, FIO, COACH_DATE, PROFESSION, TEAM_NUMBER_FK} (у _{(COACH_DATE>'31.12.1986')} (COACH))



Формула РИК:

{c | c `COACH' & $--c ( COACH--) & c (COACH_DATE > '31.12.1986')}

4. Удалить турниры, призовой фонд которых меньше '80000'

DELETE FROM TURNIR

WHERE PRIZE_FOND < '80000'

Рисунок 2.13 - Результат выполнения запроса 4

Формула РА:

р _{TURNIR_NUMBER, PRIZE_FOND, START_DATE, DLITELNOST} (у _{(PRIZE_FOND<'80000')} (TURNIR))

Формула РИК:

{t | t `TURNIR' & $--t ( TURNIR--) & t (PRIZE_FOND < '80000')}

5. Вывести ФИО и дата рождения футболистов позиция которых полузащитник

SELECT FIO, PLAYER_DATE

FROM PLAYER WHERE POSITION='Полузащитник'

Рисунок 2.14 - Результат выполнения запроса 5



Формула РА:

р _{FIO, PLAYER_DATE} (у _{(POSITION<'Полузащитник}'₎ (PLAYER))

Формула РИК:

{p | p `PLAYER' & $--p ( PLAYER--) & p (POSITION = 'Полузащитник')}

6. Вывести матчи, которые проходят в 4 турнире

SELECT *

FROM MATCH WHERE TURNIR_NUMBER=4

Рисунок 2.15 - Результат выполнения запроса 6

Формула РА:

р _{MATCH_NUMBER, MATCH_DATE, RESULT_MATCH} (у _{(TURNIR_NUMBER=4)} (MATCH))

Формула РИК:

{m | m `MATCH' & $--m ( MATCH--) & m (POSITION = 'Полузащитник')}

7. Вывести турниры, длительность которых от 8 до 15 дней

SELECT *

FROM TURNIR WHERE (DLITELNOST>=8) AND (DLITELNOST <= 15)

Рисунок 2.16 - Результат выполнения запроса 7

Формула РА:

р _{TURNIR_NUMBER, PRIZE_FOND, START_DATE, DLITELNOST} (у _{(DLITELNOST >= 8)& ((DLITELNOST <= 8)} (TURNIR));

Формула РИК:

{t | t `TURNIR' & $--t ( TURNIR--) & t (DLITELNOST>=8) & (DLITELNOST <= 15)}

8. Вывести ФИО и дата рождения футболистов которые выступают за 'ЦСКА'.

SELECT FIO, PLAYER_DATE

FROM PLAYER WHERE TEAM_NUMBER_FK=1

Рисунок 2.17 - Результат выполнения запроса 8

Формула РА:

р _{FIO, PLAYER_DATE} (у _{(TEAM_NUMBER_FK=1)} (PLAYER))



Формула РИК:

{p | p `PLAYER' & $--p ( PLAYER--) & p (TEAM_NUMBER_FK=1)}

9. Вывести информацию о футболистах, родившихся в 1987 году

SELECT *

FROM PLAYER WHERE (PLAYER_DATE >'31.12.1986') AND (PLAYER_DATE < 01.01.1988)

Рисунок 2.18 - Результат выполнения запроса 9

Формула РА:

р_{, PLAYER_NUMBER, PLAYER_DATE, ROST, VES, POSITION, FIO, TEAM_NUMBER_FK} (у _{(PLAYER_DATE>= 31.12.1986) & (PLAYER_DATE < 01.01.1988)} (PLAYER))

Формула РИК:

{p | p `PLAYER' & $--p (PLAYER--) & p (PLAYER_DATE >'31.12.1986') & (PLAYER_DATE < 01.01.1988)}

10. Удалить футболистов выступающих за 'Реал'

DELETE FROM PLAYER

WHERE TEAM_NUMBER_FK=4



Рисунок 2.19 - Результат выполнения запроса 10

Формула РА:

р _{PLAYER_NUMBER, PLAYER_DATE, ROST, VES, POSITION, FIO, TEAM_NUMBER_FK} (у _{(TEAM_NUMBER=4)} (PLAYER))

Формула РИК:

{p | p `PLAYER' & $--p ( PLAYER----) & p (TEAM_NUMBER_FK=4)}



3. Целостность и безопасность базы данных

база данные запрос язык

3.1 Целостность данных

Нарушение целостности баз данных может привести к непредсказуемым, а порой и опасным последствиям. Поэтому одно из ведущих мест в разработке баз данных занимает их защита и сохранение целостности.

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

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

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

Целостность сущностей. Объект реального мира представляется в реляционной базе данных как кортеж некоторого отношения. Требование целостности сущностей заключается в следующем: каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).

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

Основные стратегии поддержания ссылочной целостности:

- RESTRICT - запрещающая;

- CASCADE - каскадная;

- SET NULL - задание значения NULL.

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

CASCADE (каскадная) - при удалении записи родителя подразумевает удаление всех потомков. При модификации в родительской таблице в потомках должны изменяться значения ссылочных полей на новые. Каскад на вставку подразумевает вставку хотя бы одного потомка.

SET NULL - при удалении родителя устанавливает значения ссылочных полей потомка в Null. При этом данная стратегия не применима для идентифицирующих связей, связей не допускающих null значений и категорий.

Стратегии для каждой связи представлены на рисунке 3.1.

Рассмотрим сущности «Команда» - «Футболист», «Команда» - «Тренерский штаб», «Команда» - «Матч», «Турнир» - «Матч» Между данными сущностями для родительских сущностей INSERT:NONE, DELETE:CASCADE, UPDATE:CASCADE. Т.е при вставке кортежа в родительскую таблицу ссылочная целостность не нарушается, при попытке удалить или модифицировать данные, возникнет ошибка ссылочной целостности. Для дочерних сущностей стратегия выглядит следующим образом: INSERT: RESTRICT, DELETE: NONE, UPDATE: RESTRICT. Таким образом, удаление кортежа из дочерней сущности не навредить ссылочной целостности, а при вставке и модификации она нарушится. Поэтому необходимо запретить вставку и модификацию значений полей внешних ключей.

Рисунок 3.1 - Стратегии целостности

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

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

Создадим представление, которое включает в себя ФИО футболиста и название команды, за которую он выступает:

CREATE VIEW TEAMPLAYER (FIO, TEAM_NAME) AS

SELECT FIO, TEAM_NAME FROM PLAYER P, TEAM T

WHERE ((P.TEAM_NUMBER = T.TEAM_NUMBER));

Созданное представление показано на рисунке 3.2.



Рисунок 3.2 - Представление «TEAMPLAYER»

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

CREATE PROCEDURE COACH (COACH_DATE1 DATE, COACH_DATE2 DATE)

RETURNS (FIO VARCHAR(255), TEAM_NAME VARCHAR(255))

AS BEGIN

FOR SELECT C.FIO, T.TEAM_NAME

FROM COACH C, TEAM T

WHERE ((C.TEAM_NUMBER = T.TEAM_NUMBER) AND (COACH_DATE BETWEEN :COACH_DATE1 AND :COACH_DATE2))

INTO :FIO, :TEAM_NAME

DO SUSPEND;

END;

Для демонстрации ее работы выведены ФИО тренеров и название команды для тренеров дата рождения которых с 01.01.1985 по 01.01.1988. Результаты вызова процедуры показаны на рисунке 3.3.

SELECT FIO,TEAM_NAME FROM COACH C, TEAM T

WHERE WHERE ((C.TEAM_NUMBER = T.TEAM_NUMBER) AND (COACH_DATE >'01.01.1985', COACH_DATE <'01.01. 1988');

Рисунок 3.3 - Работа хранимой процедуры «СOACH»

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

Пример создания триггера:

Создать триггер, который автоматически проставляет номер матча «MATCH_NUMBER» перед вставкой нового кортежа:

CREATE TRIGGER INS_MATCH_NUMBER FOR MATCH

BEFORE INSERT

AS

BEGIN

NEW.MATCH_NUMBER = GEN_MATCH_NUMBER(GEN,1);

END

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

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

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

Было выделено 3 основных пользователя «Администратор», «Организатор», «Участник» (Листинг 3.2):

CREATE USER administrator SET PASSWORD ' administrator ';

CREATE USER organizator SET PASSWORD ' organizator ';

CREATE USER uchastnik SET PASSWORD ' uchastnik ';

Установим права для каждого из пользователей, разрешив участнику только делать выборку из таблиц «Матч», «Турнир», «Команда», организатору будут доступны выборка, добавление, изменение информации всех таблиц, а администратору ? все действия над таблицами:

GRANT SELECT ON MATCH TO UCHASTNIK;

GRANT SELECT ON TURNIR TO UCHASTNIK;

GRANT SELECT ON TEAM TO UCHASTNIK;

GRANT SELECT,UPDATE,INSERT ON TURNIR TO ORGANIZATOR;

GRANT SELECT,UPDATE,INSERT ON MATCH TO ORGANIZATOR;

GRANT SELECT,UPDATE,INSERT ON TEAM TO ORGANIZATOR;

GRANT SELECT,UPDATE,INSERT ON COACH TO ORGANIZATOR;

GRANT SELECT,UPDATE,INSERT ON PLAYER TO ORGANIZATOR;

GRANT ALL ON TURNIR TO ADMINISTRATOR WITH GRANT OPTION;

GRANT ALL ON MATCH TO ADMINISTRATOR WITH GRANT OPTION;

GRANT ALL ON TEAM TO ADMINISTRATOR WITH GRANT OPTION;

GRANT ALL ON COACH TO ADMINISTRATOR WITH GRANT OPTION;

GRANT ALL ON PLAYER TO ADMINISTRATOR WITH GRANT OPTION;

Отменим право организатора модифицировать и заполнять таблицу «ORGANIZATOR»:

REVOKE INSERT,UPDATE

ON ORGANIZATOR

FROM COACH



Заключение

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

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

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

Список использованных источников

1. Когаловский М.Р. ЭНЦИКЛОПЕДИЯ ТЕХНОЛОГИЙ БАЗ ДАННЫХ; М.: Финансы и статистика, издание 2-е, 2002, 800 с.

2. Райордан Р. Основы реляционных баз данных/Пер, с англ. -- М.: Издательско-торговый дом «Русская Редакция», 2001. -- 384 с.

3. Майкл Дж. Хернандес, Джон Л. Вьескас SQL-запросы для простых смертных; К.: Диалектика; Издание 2-е, 1999. - 421 c.

4. Резниченко В. Язык запросов SQL. Учебный курс; К.: Диалектика; Издание 1-е, 2004. - 298 с.

5. Голицына, О.Л. Базы данных; Форум; Инфра-М, 2007. - 399 c.

6. Ролланд Ф. Основные концепции баз данных. : Пер. с англ. -- М.: Издательский дом "Вильяме", 2002. -- 256 с.

7. Кренке, Д. Теория и практика построения баз данных [текст] М.: Питер, издание 1-е, 2001, 800 с.

Приложение

Структура базы данных

CREATE TABLE PLAYER

(

PLAYER_NUMBER INTEGER NOT NULL,

PLAYER DATE DATE NOT NULL,

ROST INTEGER NOT NULL,

VES DEIMAL(18,4) NOT NULL,

POSITION VARCHAR(255) NOT NULL,

FIO VARCHAR(255) NOT NULL,

);

ALTER TABLE PASSPORT_DATE

ADD PRIMARY KEY (PLAYER_NUMBER);

ADD FOREIGN KEY (TEAM_NUMBER_FK) REFERENCES ORGANIZATOR (TEAM_NUMBER);

CREATE TABLE COACH

(

COACH_NUMBER INTEGER NOT NULL

FIO Varchar(255) NOT NULL,

COACH_DATE DATE NOT NULL,

PROFESSION Varchar(255) NOT NULL,

);

ALTER TABLE COACH

ADD PRIMARY KEY (COACH_NUMBER);

ADD FOREIGN KEY (TEAM_NUMBER_FK) REFERENCES ORGANIZATOR (TEAM_NUMBER);

CREATE TABLE TEAM

(

TEAM_NUMBER INTEGER NOT NULL,

TEAM_NAME VARCHAR(255) NOT NULL,

TEAM_COLOUR CHAR(18) NOT NULL,

INFORMATION VARCHAR(255) NOT NULL,

PRIMARY KEY (TEAM_NUMBER)

);

CREATE TABLE MATCH

(

MATCH_NUMBER INTEGER NOT NULL,

MATCH_DATE DATE NOT NULL,

RESULT_MATCH VARCHAR(255) NOT NULL,

PRIMARY KEY (MATCH_NUMBER)

);

ALTER TABLE COACH

ADD FOREIGN KEY (FIRST_TEAM_FK) REFERENCES ORGANIZATOR (FIRST_TEAM);

ADD FOREIGN KEY (TURNIR_NUMBER_FK) REFERENCES ORGANIZATOR (TURNIR_NUMBER);

ADD FOREIGN KEY (TEAM_NUMBER_FK) REFERENCES ORGANIZATOR (TEAM_NUMBER);

CREATE TABLE TURNIR

(

TURNIR_NUMBER INTEGER NOT NULL,

PRIZE_FOND VARCHAR(18,4) NOT NULL,

START_DATE DATE NOT NULL,

DLITELNOST DATETIME NOT NULL,

PRIMARY KEY (TURNIR_NUMBER)

);

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