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

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Новосибирский государственный технический университет»

Кафедра экономической информатики

КУРСОВОЙ ПРОЕКТ

по дисциплине: Базы данных

Тема: Проектирование базы данных тренера спортивной команды

Выполнил: студент: Скорин А.Ю.

Группа: ФББ-52

Проверил: преподаватель Каржавых Л.В.

Балл: _______ ECTS _______

Оценка __________________

Новосибирск 2017

Содержание

• Введение
• 1. Описание предметной области
• 2. Выбор средств/методологии проектирования
• 3. Построение концептуальной модели предметной области
• 4. Проектирование логической структуры базы данных
• 5. Выявление полного перечня ограничений целостности, присущего данной области
• 6. Проектирование физической структуры базы данных
• 7. Организация ввода данных в БД
• 8. Организация корректировки БД
• 9. Реализация запросов
• 10. Разработка интерфейса
• 11. Реализация проекта в среде конкретной СУБД
• Заключение
• Список использованных источников
• Приложение

Введение

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

Объект исследования - деятельность тренера спортивной команды.

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

- системный анализ предметной области;

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

- выбор СУБД;

- логическое проектирование базы данных;

- физическое проектирование

Задачи проектирования базы данных (требования):

- обеспечение хранения в базе данных всей необходимой информации;

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

- обеспечение целостности БД.

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

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

Спроектированная база данных будет хранить следующие сущности:

1) тренер;

2) тренировки;

3) спортсмены;

4) соревнования;

5) команда;

6) достижения;

Каждый ТРЕНЕР характеризуется следующими параметрами:

- ID тренера;

- ФИО;

- гражданство;

- дата рождения;

- код команды (R1).

Каждые ТРЕНИРОВКИ, характеризуется следующими параметрами:

- ID тренировки;

- ID тренера (R4);

- ID команды;

- дата тренировки;

- время тренировки;

- продолжительность тренировки.

Каждые СПОРТСМЕНЫ обладает следующими параметрами:

- ID спортсмена;

- ФИО;

- гражданство;

- дата рождения;

- rод команды (R2).

Каждые СОРЕВНОВАНИЯ обладают следующими параметрами:

- ID соревнования;

- ID команды;

- соперник;

- результат;

- дата проведения.

Каждая КОМАНДА обладает параметрами:

- ID команды;

- название.
Каждые ДОСТИЖЕНИЯ обладают параметрами:

- ID достижения;

- ID соревнования;

- результат.

Один и тот же спортсмен может заниматься несколькими видами спорта, и по одному виду спорта может тренироваться сразу у нескольких тренеров.

Все спортсмены объединяются (по виду спорта) в спортивные команды.

2. Выбор средств/методологии проектирования

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

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

Существует очень большое число СУБД. По функциональным возможностям СУБД бывают настольные (такие как MS Access, Paradox) и корпоративные (MS SQL Server, MySQL, Oracle). Сравнивая настольные и корпоративные СУБД, следует отметить, что настольные СУБД просты в использовании и стоимость их эксплуатации дешевле. В свою очередь корпоративные СУБД имеют возможности администрирования, работы в Интернете, а также они поддерживают большой объём данных и быстродейственны.

Для построения самой базы в данной работе была выбрана СУБД MS Access 2016. Microsoft Access является наиболее популярной системой управления базами данных для операционной системы Windows. Возможности разработчиков программного обеспечения, а также методы и технологии решения этих задач постоянно изменяются и совершенствуются.

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

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

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

3. Построение концептуальной модели предметной области

В качестве семантической модели данных воспользуемся неформальной моделью “Сущность - Связь” (Entity-Relationship - ER-модель). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Связи были формализованы, ключи выбраны.

На рисунке 1 ниже изображена ER-модель тренера спортивной команды.

Рисунок 1 - ER-модель

4. Проектирование логической структуры базы данных

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

Ниже в таблице 1 представлено описание таблиц базы данных.

Таблица 1 - описание таблиц базы данных

Создаем таблицу	КОМАНДА (ID команды* числовой, Название текстовый)
Первичный ключ	(ID команды*)
Внешний ключ	-
Ограничения	1. Значения атрибута ID команды* должны быть уникальны.
Индексы	Уникальный, кластеризованный для первичного ключа ID команды*, некластеризованный для атрибута Название.
Создаем таблицу	СОРЕВНОВАНИЯ (ID соревнования* числовой, Дата проведения* дата/время, ID команды числовой, Соперник текстовый, Результат логический)
Первичный ключ	(ID соревнования*, Дата проведения*)
Внешний ключ	(ID команды из таблицы КОМАНДА. Null-значения недопустимы. Удаление из таблицы КОМАНДА ограничивается, обновление КОМАНДА, ID команды каскадируется).
Ограничения	1. Значения атрибута ID соревнования* и Дата рождения* должны быть уникальны. 2. Значения поля ID команды должны принадлежать набору значений из таблицы КОМАНДА. 3. Значения атрибута Результат должны принимать значения “ДА” или “НЕТ”.
Индексы	Уникальный кластеризованный для первичного ключа (ID соревнования*, Дата проведения*) некластеризованный для атрибута Соперник.
Создаем таблицу	ТРЕНИРОВКИ (ID тренировки* числовой, ID тренера* числовой, ID команды числовой, Дата тренировки дата/время, Время тренировки дата/время, Продолжительность числовой)
Первичный ключ	(ID тренировки*, ID тренера*)
Внешний ключ	(ID тренера из таблицы ТРЕНЕР. Null-значения недопустимы. Удаление из таблицы ТРЕНЕР ограничивается, обновление ТРЕНЕР, ID тренера каскадируется).
Ограничения	Значения атрибута ID тренировки* и ID тренера* должны быть уникальны. Значения поля ID тренера должны принадлежать набору значений из таблицы ТРЕНЕР.
Индексы	Уникальный, кластеризованный для первичного ключа (ID тренировки*, ID тренера*). Некластеризованный для атрибута ID команды.
Создаем таблицу	ТРЕНЕР (ID тренера* числовой, ФИО текстовый, Гражданство текстовый, Дата проведения дата/время, ID команды числовой)
Первичный ключ	(ID тренера*)
Внешний ключ	(ID команды из таблицы КОМАНДА. Null-значения недопустимы. Удаление из таблицы КОМАНДА ограничивается, обновление КОМАНДА, ID команды каскадируется).
Ограничения	1. Значения атрибута ID тренера* должны быть уникальны. 2. Значения поля ID команды должны принадлежать набору значений из таблицы КОМАНДА.
Индексы	Уникальный, кластеризованный для первичного ключа ID тренера*, некластеризованный для атрибута ФИО
Создаем таблицу	СПОРТСМЕНЫ (ID спортсмена* числовой, ФИО текстовый, Гражданство текстовый, Дата рождения дата/время, ID команды числовой)
Первичный ключ	(ID спортсмена*)
Внешний ключ 1	(ID команды из таблицы КОМАНДА. Null-значения недопустимы. Удаление из таблицы КОМАНДА ограничивается, обновление КОМАНДА, ID команды каскадируется).
Ограничения	1. Значения поля ID спортсмена* должны быть уникальны. 2. Значения поля ID команды должны принадлежать набору значений из таблицы КОМАНДЫ.
Индексы	Уникальный, кластеризованный для составного первичного ключа (ID спортсмена*), некластеризованный для ФИО.
Создаем таблицу	ДОСТИЖЕНИЯ (ID достижения* числовой, ID соревнования* числовой, Результат логический)
Первичный ключ	(ID достижения*, ID соревнования*)
Внешний ключ	(ID соревнования* из таблицы СОРЕВНОВАНИЯ Null-значения недопустимы. Удаление из таблицы СОРЕВНОВАНИЯ ограничивается, обновление СОРЕВНОВАНИЯ, ID соревнования* каскадируется)
Ограничения	1. Значения поля (ID достижения*, ID соревнования*) должны быть уникальны. 2. Значения атрибута ID соревнования* должны принадлежать набору значений из таблицы СОРЕВНОВАНИЯ. 3. Значения атрибута Результат должны принимать значения “ДА” или “НЕТ”.
Индексы	Уникальный, кластеризованный для первичного ключа (ID достижения*, ID соревнования*), некластеризованный для Результата

Схема базы данных спортивных организаций города в MS Access представлена в приложении (рис. 1)

5. Выявление полного перечня ограничений целостности, присущего данной области

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

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

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

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

6. Проектирование физической структуры базы данных

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

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

Разработанные таблицы (рис. 2-7) представлены в приложении.

7. Организация ввода данных в БД

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

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

· через раздел СУБД «Таблицы», производя действия по изменению, добавлению или удалению непосредственно в таблице;

· через раздел СУБД «Формы», выполняя необходимые действия в таблице через интерфейс формы;

· через раздел СУБД «Запросы», выполняя запросы на обновление, добавление или удаление данных.

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

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

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

Для удобства работы с базой данных спортивных организаций города мы реализовали специальные формы, эмулирующие работу базы данных спортивных организаций города. Формы расположены в приложении (рис. 8-12).

8. Организация корректировки БД

Корректировка подразумевает изменение, добавление, удаление данных в таблицах. Корректировка данных в базе данных может осуществляться путем корректировки данных в форме. В основных таблицах данной БД, а именно «Тренировки», «Соревнования», «Тренер», «Спортсмены», «Достижения», «Команда» осуществляется корректировка через экранные формы, упомянутые в пункте «Организация ввода данных в БД» (рис. 8 - 12). В данных формах имеются специальные кнопки «Удалить», «Добавить», «Сохранить».

9. Реализация запросов

Запросы упрощают просмотр, добавление, удаление или изменение данных в базе данных Access. Среди других целей использования запросов можно отметить:

· быстрый поиск определенных данных путем фильтрации с применением определенных критериев (условий);

· вычисление или сведение данных;

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

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

В данной курсовой работе было реализовано 11 запросов:

1) запрос получения перечня спортсменов указанного типа в целом или удовлетворяющих заданным характеристикам (например, гражданство). Запрос изображён на рисунке 15 в приложении;

2) Получить список всех тренировок, по номеру тренера проводящего тренировку либо по продолжительности тренировки. Данный запрос изображён на рисунке 16:

Рисунок 16 - Экранная форма запроса №2

3) запрос получения списка всех тренировок, по продолжительности тренировки. Запрос изображён на рисунке 17 в приложении;

4) запрос получения списка команд в которых играет указанный спортсмен. Запрос изображён на рисунке 18 в приложении.

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

6) Получить список тренеров указанного гражданства. Запрос реализован на рисунке 20:

Рисунок 20 - Экранная форма запроса №6

7) запрос получения перечня всех спортсменов, с определенным кодом команды или по определенному гражданству - рисунок 21 в приложении.

8) Получить перечень тренировок, по коду тренера проводящего тренировку или начала тренировки. Запрос изображён на рисунке 22 в приложении.

9) запрос получения списка достижений по результату игры - рисунок 23 в приложении.

Получение отчётов.

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

· отображение или распространение сводки данных;

· архивирование моментальных снимков данных;

· предоставление сведений об отдельных записях;

· создание надписей.

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

10. Разработка интерфейса

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

Работа с нашей базой данных начинается с главной формы (рис. 26).



Рисунок 26 - Главная форма

При нажатии кнопки “Спортсмены” мы попадаем в следующее меню:

Рисунок 27 - Форма “Команды”

Мы можем выбрать между формой “Информация о спортсменах” и отчётом “Сведения о спортсменах”. Затем вернёмся в главную форму (рис. 26).



Рисунок 28 - Отчёт “Спортсмены”

При возврате в основную форму и нажатии кнопки “Тренеры” нам выпадает следующее меню:

Рисунок 29 - Форма “Тренеры”

Мы можем выбрать между формой “Информация о тренерах” и отчётом “Сведения о тренерах”:



Рисунок 30 - Отчёт “Сведения о тренерах”

11. Реализация проекта в среде конкретной СУБД

Реализация проекта разработки базы данных тренера спортивной команды в среде СУБД MS Access является многоступенчатым трудоемким процессом, основные этапы которого были подробно рассмотрены выше. На основе ER-модели, было осуществлено моделирование предметной области. В процессе создания базы данных было построено 8 взаимосвязанных таблиц. Следующим важнейшим этапом реализации проекта была разработка пользовательского интерфейса. Были созданы все необходимые для обеспечения полноценной навигации по базе данных элементы, включая главное меню и различные подменю. Все экранные формы создавались нами в режиме конструктора.

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

Заключение

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

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

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

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

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

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

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

1) Гурвиц Г. А. Г95 Microsoft® Access 2007. Разработка приложений на реальном примере. - СПб.: БХВ-Петербург, 2007. -- 672 с.: ил. + CD-ROM -- (Профессиональное программирование);

2) Справка и обучение по Office [Электронный ресурс] - Режим доступа: https://support.office.com/

Приложение

На рисунке 1 изображена схема базы данных тренера спортивной команды в MS Access:

Рисунок 1 - Схема базы данных

На рисунке 2 изображена таблица “Команда”

Рисунок 2 - Таблица “Команда”

На рисунке 3 изображена таблица “Спортсмены”



Рисунок 3 - Таблица “Спортсмены”

На рисунке 4 изображена таблица “Тренировки”

Рисунок 4 - Таблица “Тренировки”

На рисунке 5 изображена таблица “Соревнование”

Рисунок 5 - Таблица “Соревнование”

На рисунке 6 изображена таблица “Достижения”

Рисунок 6 - Таблица “Достижения”

На рисунке 7 изображена таблица “Тренеры”

Рисунок 7 - Таблица “Тренеры”

На рисунке 8 изображена форма “Информация о достижениях”

Рисунок 8 - Форма "Информация о клубах"

На рисунке 9 изображена форма “Информация о достижениях”

Рисунок 9 - Форма "Информация о спортсменах"

На рисунке 10 изображена форма “Информация о соревнованиях”

Рисунок 10 - Форма "Информация о соревнованиях"

На рисунке 11 изображена форма “Информация о тренерах”

Рисунок 11 - Форма "Информация о тренерах"

На рисунке 12 изображена форма “Информация о тренировках”

Рисунок 12 - Форма "Тренировки"

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

Рисунок 15 - Экранная форма запроса №1

На рисунке 17 изображен запрос получения списка всех тренировок, по продолжительности тренировки:

Рисунок 17 - Экранная форма запроса №3

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

Рисунок 18 - Экранная форма запроса №4

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

Рисунок 19 - Экранная форма запроса №5

На рисунке 21 изображен запрос получения перечня всех спортсменов, с определенным кодом команды или по определенному гражданству:

Рисунок 21 - Экранная форма запроса №7

На рисунке 22 изображен запрос Полученияить переченя тренировок, по коду тренера проводящего тренировку или начала тренировки:

Рисунок 22 - Экранная форма запроса №8

На рисунке 23 изображен запрос получения списка достижений по результату игры:



Рисунок 23 - Экранная форма запроса №9

На рисунке 24 изображен отчет “Сведения о соперниках”



Рисунок 24 - Отчёт “Сведения о вместимости соперниках”

На рисунке 25 изображен отчет “Сведения о спортсменах”



Рисунок 25 - Отчёт “ Сведения о спортсменах”

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