База данный "Хозяйственный учет футбольного клуба"

База данный "Хозяйственный учет футбольного клуба"

Федеральное агентство по образованию

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

‹‹Курский государственный технический университет››

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

КУРСОВАЯ РАБОТА

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

на тему ‹‹Хозяйственный учет футбольного клуба››

Специальность 230105 Программное обеспечение вычислительной техники и автоматизированных систем

Авторы работы _______________________

(инициалы, фамилия) (подпись, дата)

Группа ПО - 71

Руководитель работы В. Г. Белов ______________________

(инициалы, фамилия) (подпись, дата)

Работа защищена __________________

(дата)

Оценка____________________

Председатель комиссии

______________________ ______________________

(инициалы, фамилия) (подпись, дата)

Члены комиссии

________________________ _________________________

(инициалы, фамилия) (подпись, дата)

Курск, 2010 г.

Федеральное агентство по образованию

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

‹‹Курский государственный технический университет››

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

ЗАДАНИЕ НА КУРСОВУЮ РАБОТУ

Студент шифр 347011 группа ПО - 71

1. Тема Хозяйственный учет футбольного клуба

2. Срок предоставления работы (проекта) к защите ‹‹ ›› 2010 г

3. Исходные данные

Неформальное описание предметной области и документы, которые в ней используются

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

• Введение
• 1 Техническое задание
• 1.1 Основание для разработки
• 1.2 Назначение разработки
• 1.3 Стандарты
• 1.4 Требования к программе или программному изделию
• 1.4.2 Носители информации
• 1.4.3 Требования к составу и параметрам технических средств
• 2 Технический проект
• 2.1 Описание предметной области
• 2.2 Словарь понятий и терминов
• 2.3 Определение функциональных зависимостей
• 2.4 Синтез схемы базы данных на основании функциональных зависимостей
• 2.4.1 Построение неизбыточного покрытия
• 2.4.2 Построение леворедуцированного покрытия
• 2.4.3 Построение праворедуцированного покрытия
• 2.4.4 Построение классов эквивалентности
• 2.4.5 Построение редуцированного минимального кольцевого покрытия
• 2.5 ER-схема базы данных
• 2.6 Построение запросов на SQL
• 2.6.1 Построение первого запроса
• 3 Рабочий проект
• 3.1 Связи таблиц
• 3.2 Внешний вид формы
• 3.3 Функциональные тесты
• 3.3.1 Тест 1
• Заключение
• Список использованных источников
• Приложение А
• Приложение Б
• Реферат
• Объем данного курсового проекта равен 56 страницам. В курсовом проекте содержится два приложения, в которых приведены ER-схемы базы данных, код программы. Также в КП содержится постановка задачи.
• Ключевые слова:
• База данных, ER-схема, сущность, атрибут, ключ, связь, функциональная зависимость, система функциональных зависимостей.
• Объект разработки:
• Объектом исследования в данной работе является проектирование базы данных в соответствии с заданным вариантом.
• Цель работы:
• Спроектировать базу данных «Хозяйственный учет футбольного клуба».
• Метод проведения работы:
• Использование ER-диаграмм, минимизация зависимостей, построение запросов.
• Summary
• This termpaper contains 56 pages. It contains two enclosures, which contain ER-diagrams. Also it contains target setting.
• Object of development is design of the database according to specified variant.
• The aim of work is design of the database, describing « the Economic account of football club ».
• It is necessary to make ER-diagram, to minimize functional dependences, to write and minimize SQL queries.
• Определения
• В данной работе применены следующие термины с соответствующими определениями:
• база данных: Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД.
• er-диаграмма: Схема базы данных, спроектированная с помощью программы ERWin.
• сущность: Любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.
• атрибут: Поименованная характеристика сущности.
• ключ: Минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.
• связь: Ассоциирование двух или более сущностей.
• Обозначения и сокращения
• В данной работе применены следующие сокращения:
• БД: База данных
• СУБД: Система управления базами данных
• ФЗ: Функциональная зависимость

Введение

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

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

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

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

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

1 Техническое задание

1.1 Основание для разработки

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

1.2 Назначение разработки

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

1.3 Стандарты

Данная работа оформлена в соответствии со стандартом СТУ 04.02.030.-2008.

1.4 Требования к программе или программному изделию

Спроектировать базу данных для спортивной базы футбольного клуба. Описать предметную область, разработать словарь понятий и терминов, построить систему функциональных зависимостей. Синтезировать схему базы данных на основании функциональных зависимостей (построение неизбыточного покрытия, построение леворедуцированного неизбыточного покрытия, построение праворедуцированного неизбыточного покрытия, построение классов эквивалентностей, построение минимального покрытия). Построить уточненную концептуальную модель в виде ER-диаграммы, запросы предметной области. Записать минимизированные запросы на языке SQL.

1.4.1 Результирующие компоненты изделия

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

1.4.2 Носители информации

Продукт должен размещаться в виде файлов на CD дисках. В процессе работы могут использоваться Flash, CD-R/-RW, DVD-R/RW или другие носители информации.

1.4.3 Требования к составу и параметрам технических средств

Программный комплекс должен корректно работать на компьютере со следующими техническими характеристиками:

? процессор Pentium V 2200 МГц;

? оперативная память объемом 1024 Мб;

? жесткий диск Seagate Barracuda, объемом 120 Гб;

? видеоадаптер SVGA;

? клавиатура;

? манипулятор типа “мышь”;

устройство удаленного доступа к сети: модем или сетевая карта.

2 Технический проект

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

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

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

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

Для инвентаря и техники хранится информация о фирме-изготовителе и модели товара. Для мебели должна быть отражена информация о фирме-производителе, цвете, габаритных размерах (длина, ширина, высота).

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

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

Инвентарь, техника и мебель могут быть списаны, при этом хранится дата списания.

2.2 Словарь понятий и терминов

Словарь понятий и терминов приведен в таблицах 2.1 - 2.12.

Таблица 2.1 - Общая информация

Таблица 2.2 - Игроки

Таблица 2.3 - Помещение

Таблица 2.4 - Комната

Таблица 2.5 - Спортивный зал

Таблица 2.6 - Поступление объектов

Таблица 2.7 - Спортивный инвентарь

Таблица 2.8 - Техника

Таблица 2.9 - Мебель

Таблица 2.10- Мяч

Таблица 2.11 - Футбольные ворота

Таблица 2.12 - Тренажер

Таблица 2.13 - Телевизор

Таблица 2.14 - Холодильник

Таблица 2.15 - Пылесос

Таблица 2.16 - Кровать

Таблица 2.17 - Шкаф

Таблица 2.18 - Стол

Таблица 2.19 - Размещение спортивного инвентаря по залам

Таблица 2.20 - Расселение людей по комнатам

Таблица 2.21 - Инвентарные номера спортивного инвентаря

Таблица 2.22 - Инвентарные номера техники

Таблица 2.23 - Инвентарные номера мебели

Таблица 2.24 - Списанный спортивный инвентарь

Таблица 2.25 - Списанная техника

Таблица 2.26 - Списанная мебель

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

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

Fam, Im, Otch, pol, dateborn, datevidachi, kemvidan, country, city, street, numstreet, numflat, dolgnost -> sp, np.

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

sp_pl, np_pl -> sp, np -> date, rost, ves, staff, number, status -> Fam, Im, Otch, dateborn, country, city, street, numstreet, numflat.

Футболист не может играть в команде определенного состава одновременно под разными номерами в разном качестве.

sp_pl, np_pl -> date, staff, number, status.

В определенном составе под одним номером не могут играть два футболиста.

sp_pl, np_pl -> staff, number, status.

Один человек не может одновременно жить в двух комнатах.

num_room -> sp, np.

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

square, naznachenie -> num_p.

Номер помещения однозначно определяет номер комнаты.

room -> num_room.

Спортивный зал не может одновременно относиться к разным типам. type_zal -> num_zal.

Объект в одно и то же время поступает в определенном количестве по определенной цене. kol, date, balance -> code_obj.

Инвентарь производится определенной фирмой и относится к определенной модели. firm_inv, model_inv -> code_inv.

Техника производится определенной фирмой и относится к определенной модели, потребляет определенную мощность. firm_tec, model_tec -> code_tec.

Мебель изготавливается из определенного материала, определенной длины, ширины, высоты, цвета. firm_meb, dlina, width, height, color -> code_meb.

Единица спортивного инвентаря не может относиться к двум объектам. code_inv-> inv_number_INV .

Единица техники не может относиться к двум объектам. code_tec -> . inv_number_TEC.

Единица мебели не может относиться к двум объектам. code_meb -> inv_number_MEB.

Единица спортивного инвентаря не может быть списана дважды. date_out_inv -> inv_number_INV_out.

Единица техники не может быть списана дважды. date_out_tec -> inv_number_TEC_out.

Единица мебели не может быть списана дважды date_out_meb -> . inv_number_MEB_out.

Единица спортивного инвентаря не может одновременно находиться в нескольких спортивных залах. num_zal -> inv_number_INV, date_IinZal.

Единица техники не может одновременно находиться в нескольких помещениях. num_р -> inv_number_TEC, date_TecInP.

Единица мебели не может одновременно находиться в нескольких помещениях. num_р -> inv_number_MEB, date_MebInP.

Мяч не может иметь разные характеристики. material -> code_balls.

Одни и те же ворота не могут иметь разные характеристики. height_gate, shirina, kind -> code_gate.

Тренажер не может быть одновременно двух видов. type -> code_trenager.

Телевизор не может иметь разные характеристики. diagonal, screen -> code_TV.

Холодильник не может иметь разные характеристики. height_ref, widht_ref, depht_ref, sum_sq_polok, com_volume, user_volume -> code_refreg.

Пылесос не может иметь разные характеристики. moshnost_v -> code_vacuum.

Кровать не может иметь разные характеристики. type_bed -> code_bed.

Стол не может иметь разные характеристики. type_table, material_table > code_table.

Шкаф не может иметь разные характеристики. type_shkaf -> code_shkaf.

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

Рисунок 2.1 - Исходные функциональные зависимости

2.3.2 Функциональные зависимости сохраняющие иерархию

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

Спортивным залом не может быть несуществующее помещение. num_zal -> num_p.

Не поступавшая партия объектов не может быть зарегистрирована как инвентарь. code_inv -> code_obj.

Не поступавшая партия объектов не может быть зарегистрирована как техника. code_tec -> code_obj.

Не поступавшая партия объектов не может быть зарегистрирована как мебель. code_meb -> code_obj.

Незарегистрированная единица инвентаря не может быть списана. inv_number_INV_out -> inv_number_INV.

Незарегистрированная единица техники не может быть списана.

inv_number_TEC _out -> inv_number_TEC.

Незарегистрированная единица мебели не может быть списана. inv_number_MEB_out -> inv_number_MEB.

Незарегистрированная партия инвентаря инвентаря не может быть партией мячей.

code_balls -> code_inv.

Одна и та же партия ворот не может поступить дважды.

code_gate -> code_inv.

Одна и та же партия тренажеров не может поступить дважды.

code_trenager -> type.

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

code_TV -> diagonal, screen.

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

code_refreg -> height_ref, widht_ref, depht_ref, sum_sq_polok, com_volume, user_volume.

Функциональные зависимости сохраняющие иерархию представлены на рисунке 2.2.

Рисунок 2.2 - Функциональные зависимости, сохраняющие иерархию

2.4 Синтез схемы базы данных на основании функциональных зависимостей

2.4.1 Построение неизбыточного покрытия

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

Страницы: 1, 2, 3