Система ведения статистики секции Дзюдо

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

Курсовая работа

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

на тему: «Система ведения статистики секции Дзюдо»



Введение

Разрабатываемый в рамках курсовой работы программный продукт «Система ведения статистики секции Дзюдо» предназначен для учета и ведения статистики о достижениях тех, кто занимается в секции “Дзюдо”.

Данный программный продукт разрабатывается для секции “Дзюдо” г. Усть-Кута. На данный момент все данные о спортсменах хранятся на бумажных носителях. Из этого вытекает актуальность и цель проекта - написание программного продукта, который позволит осуществлять весь «документооборот» в электронном виде.

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

· Концептуальное и логическое проектирование БД;

· Физическое проектирование БД;

· Формирование SQL-запросов;

· Разработка пользовательского интерфейса и написание кода продукта;

· Тестирование продукта.

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

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

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

1.1 Анализ существующего программного обеспечения

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

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

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

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

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

В процессе разработки ER-диаграммы были определены:

* типы сущностей;

* типы связей;

* атрибуты;

* домены атрибутов;

* потенциальные ключи;

* первичные ключи.

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

В таблице 1.1 показаны все существующие сущности базы данных, их описания, псевдонимы и типы.

Таблица 1.1 Сведения о типах сущностей

Имя сущности	Описание	Псевдоним	Тип
Список групп	Список групп, на которые делятся спортсмены	TblGroup	Сильный
Спортсмены	Информация о спортсменах	TblPersons	Слабый
Список улиц	Список улиц, на которых проживают спортсмены	TblStreetTitle	Сильный
Домашний адрес	Домашний адрес конкретного спортсмена	TblHomeAddress	Слабый
Список учебных заведений	Список учебных заведений	TblSchoolTitle	Сильный
Учебные заведения	Список уч. зав., в которых обучался спортсмен	TblSchool	Слабый
Период обучения	Даты начала и окончания посещения секции	TblTeachingPeriod	Слабый
Данные о родителях	ФИО родителей	TblParents	Слабый
Контроль организма	Пульс\вес до после тренировки	TblOrganismControl	Слабый
Соревнования по ОФП	Результаты соревнований по ОФП	TblPTCompetition	Слабый
Антропометрические данные	Данные о контрольном взвешивании и измерении роста	TblAnthropometry	Слабый

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

Кардинальность:

1. Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.

2. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи.

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

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

Сведения об имеющихся типах связей для разрабатываемой базы данных представлены в таблице 1.2.

Таблица 1.2 Сведения о типах связей

Тип сущности	Тип связи	Тип сущности	Кардинальность	Показатель участия
Спортсмены	Состоят	Список групп	M:1	T:P
Спортсмены	Проживают	Домашний адрес	1:1	P:T
Спортсмены	Обучаются	Учебные заведения	1:M	P:T
Спортсмены	Тренируются	Период обучения	1:M	P:T
Спортсмены	Имеют	Данные о родителях	1:M	P:T
Спортсмены	Контролируются	Контроль организма	1:M	P:T
Спортсмены	Выступают с результатами	Соревнования по ОФП	1:M	P:T
Спортсмены	Контролируются	Антропометрические данные	1:M	P:T
Домашний адрес	Берётся	Список улиц	M:1	T:P
Учебные заведения	Берутся	Список учебных заведений	M:1	T:P

Связи между сущностями в базе данных приведены на Рис. 1.1.

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

Рис. 1.1 ER-диаграмма базы данных

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

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

Карта транзакций базы данных представлена на Рис. 1.2.

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

Рис. 1.2 Карта транзакций

Тренер добавляет или изменяет уже имеющиеся данные спортсменах



1.3 Логическое проектирование базы данных

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

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

Данные об атрибутах и доменах атрибутов представлены в таблице 1.3.

Таблица.1.3 Атрибуты и домены атрибутов

Сущность	Атрибут сущности	Домен атрибута	Ограничение целостности
Список групп	Id названия группы	Числовой	-
	Название группы	Текстовый	Обязательное поле
Спортсмены	Id спортсмена	Числовой	-
	Фамилия	Текстовый	Обязательное поле
	Имя	Текстовый	Обязательное поле
	Отчество	Текстовый	Обязательное поле
	Дата рождения	Дата	Обязательное поле
	Id названия группы	Числовой	Ссылочная целостность
Список улиц	Id названия улицы	Числовой	-
	Название улицы	Текстовый	Обязательное поле
Домашний адрес	Id домашнего адреса	Числовой	-
	Id названия улицы	Числовой	Ссылочная целостность
	Номер дома	Текстовый	Обязательное поле
	Номер квартиры	Текстовый	Обязательное поле
	Id спортсмена	Числовой	Ссылочная целостность
Список учебных заведений	Id названия заведения	Числовой	-
	Название заведения	Текстовый	Обязательное поле
Учебные заведения	Id заведения	Числовой	-
	Id названия заведения	Числовой	Ссылочная целостность
	Класс	Текстовый	Обязательное поле
	Id спортсмена	Числовой	Ссылочная целостность
Период обучения	Id периода	Числовой	-
	Дата поступления	Дата	Обязательное поле
	Дата зачисления	Дата	-
	Номер приказа	Числовой	-
	Дата окончания	Дата	-
	Выбыл	Логический	-
	Id спортсмена	Числовой	Ссылочная целостность
Данные о родителях	Id родителя	Числовой	-
	Фамилия	Текстовый	Обязательное поле
	Имя	Текстовый	Обязательное поле
	Отчество	Текстовый	Обязательное поле
	Id спортсмена	Числовой	Ссылочная целостность
Контроль организма	Id	Числовой	-
	Дата	Дата	Обязательное поле
	Пульс утром лежа	Числовой	-
	Пульс утром сидя	Числовой	-
	Пульс до тренировки	Числовой	-
	Пульс после тренировки	Числовой	-
	Вес до тренировки	Числовой	-
	Вес после тренировки	Числовой	-
	Отсутствовал	Логический	Обязательное поле
	Id спортсмена	Числовой	Ссылочная целостность
Соревнования по ОФП	Id	Числовой	-
	Дата	Дата	Обязательное поле
	Пресс результат	Числовой	Обязательное поле
	Пресс очки	Числовой	Обязательное поле
	Вис результат	Вещественный	Обязательное поле
	Вис очки	Числовой	Обязательное поле
	Прыжок результат	Вещественный	Обязательное поле
	Прыжок очки	Числовой	Обязательное поле
	Кросс результат	Вещественный	Обязательное поле
	Кросс очки	Числовой	Обязательное поле
	Сумма очков	Числовой	-
	Id спортсмена	Числовой	Ссылочная целостность
Антропометрические данные	Id	Числовой	-
	Дата	Дата	Обязательное поле
	Рост	Вещественный	-
	Вес	Вещественный	-
	Id спортсмена	Числовой	Ссылочная целостность

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

Рисунок 1.3 Логическая схема базы данных

1.4 Выбор целевой СУБД и среды разработки клиентского приложения

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

Microsoft SQL Server.

Microsoft SQL Server - одна из наиболее мощных СУБД архитектуры клиент - сервер. Эта СУБД позволяет удовлетворять такие требования, предъявляемые к системам распределенной обработке данных, как тиражирование данных, параллельная обработка, поддержка больших баз данных на относительно не дорогих аппаратных платформах при сохранении несмежного управления.

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

Microsoft SQL Server предназначен исключительно для поддержки систем, работающих в среде клиент-сервер. Он поддерживает широкий спектр средств разработки и максимально прост в интеграции с приложениями, работающими на ПК.

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

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

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

Встроенные запросы LINQ (Language Integrated Query) позволяют разработчикам вместо использования SQL-запросов обращаться к данным из программ на управляемых языках, например C# или VB.NET.

Недостатком SQL Server является то, что он функционирует только на платформе Windows.

MySQL.

MySQL -- свободная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей.

MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7.

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Firebird.

Firebird - компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах.

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

Firebird используется в различных промышленных системах (складские и хозяйственные, финансовый и государственный сектора) с 2001 г. Это коммерчески независимый проект C и C++ программистов, технических советников и разработчиков мультиплатформенных систем управления базами данных, основанный на исходном коде, выпущенном корпорацией Borland 25 июля 2000 года в виде свободной версии Interbase 6.0.

Среди недостатков: отсутствие кеша результатов запросов, полнотекстовых индексов.

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

Рассмотрев указанные СУБД и, взвесив их плюсы и минусы (табл. 1.4), выбор пал на СУБД MySQL, т.к. она проста в использовании, имеет достаточно низкие системные требования и бесплатна.

Таблица 1.4 Сводная таблица оценок СУБД

СУБД	Microsoft SQL Server	MySQL	Firebird
Стоимость	3	5	5
Надежность	5	5	5
Простота разработки	4	5	3
Средства поддержки целостности данных	5	5	5
Интерфейс для языков 3 поколения	4	5	4
Требуемая операционная система	2	5	5



В качестве среды разработки была выбрана среда Lazarus. Программный продукт написан на языке программирования Object Pascal.

Преимущества Lazarus:

1) быстрота разработки приложения;

2) высокая производительность разработанного приложения;

3) низкие требования разработанного приложения к ресурсам компьютера;

4) бесплатность;

5) кроссплатформенность.

1.5 Физическое проектирование базы данных

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

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

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

* создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

* определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

* разработка средств защиты создаваемой системы.

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

Таблица 1.5 Список группы (TblGroup)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
GId	Id группы	Числовой	4				ключ
Title	Название группы	Текстовый	20			NOT NULL	индекс	Обязательное поле

Таблица 1.6 Список улиц (TblStreetTitle)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
STId	Id улицы	Числовой	4				ключ
Title	Название улицы	Текстовый	30			NOT NULL	индекс	Обязательное поле

Таблица 1.7. Список учебных заведений (TblSchoolTitle)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
STId	Id уч. заведения	Числовой	4				ключ
Title	Название уч. завед-я	Текстовый	30			NOT NULL	индекс	Обязательное поле



Таблица 1.8. Домашний адрес (TblHomeAddress)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
HAId	Id дом. адреса	Числовой	4				ключ
STId	Id улицы	Числовой	4			NOT NULL		Обязательное поле
BuildingNumber	№ дома	Текстовый	6			NOT NULL		Обязательное поле
FlatNumber	№ квартиры	Текстовый	6			NOT NULL		Обязательное поле
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле

Таблица 1.9. Учебные заведения (TblSchool)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
SId	Id уч. зав.	Числовой	4				ключ
STId	Id уч. заведения	Числовой	4			NOT NULL		Обязательное поле
Class	Класс	Текстовый	2			NOT NULL		Обязательное поле
Year	Год	Числовой	6			NOT NULL		Обязательное поле
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле



Таблица 1.10. Список спортсменов (TblPersons)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
PId	Id спортсмена	Числовой	4				ключ
Surname	Фамилия	Текстовый	20			NOT NULL	индекс	Обязательное поле
Name	Имя	Текстовый	20			NOT NULL	индекс	Обязательное поле
Patronymic	Отчество	Текстовый	20			NOT NULL	индекс	Обязательное поле
GId	Id группы	Числовой	4			NOT NULL		Обязательное поле

Таблица 1.11. Родители спортсменов (TblParents)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
ParId	Id родителя	Числовой	4				ключ
Surname	Фамилия	Текстовый	20			NOT NULL	индекс	Обязательное поле
Name	Имя	Текстовый	20			NOT NULL	индекс	Обязательное поле
Patronymic	Отчество	Текстовый	20			NOT NULL	индекс	Обязательное поле
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле



Таблица 1.12. Период Обучения (TblTeachingPeriod)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
TPId	Id периода	Числовой	4				ключ
Enterday	Дата поступления	Дата	3			NOT NULL	индекс	Обязательное поле
Takeday	Дата зачисления	Дата	3		NULL
OrderNumber	№ приказа	Дата	3		NULL
Finishday	Дата окончания	Числовой	8		NULL
IsOut	Выбыл?	Логический	1			NOT NULL		Обязательное поле
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле

Таблица 1.13. Контроль организма (TblOrganismControl)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
OCId	Id	Числовой	4				ключ
Date	Дата	Дата	3			NOT NULL		Обязательное поле
IsAbsent	Пропуск?	Логический	1		False	NOT NULL		Обязательное поле
PulseMornLying	Пульс утром лежа	Числовой	2		NULL
PulseMornSitting	П. Утром сидя	Числовой	2		NULL
PulseBefTrain	П. до тренировки	Числовой	2		NULL
PulseAftTrain	П. после тренировки	Числовой	2		NULL
WeightBefTrain	Вес до тренировки	Вещественный	4	3	NULL
WeightAftTrain	В. После тренировки	Вещественный	4	3	NULL
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле



Таблица 1.14. Соревнования по ОФП (TblPTCompetition)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
PTCId	Id	Числовой	4				ключ
Date	Дата	Дата	3			NOT NULL		Обязательное поле
PressRes	Пресс результат	Числовой	2			NOT NULL		Обязательное поле
PressScore	П. очки	Числовой	2			NOT NULL		Обязательное поле
HangeRes	Вис рез-ат	Вещественный	8	3		NOT NULL		Обязательное поле
HangeScore	Вис очки	Числовой	2			NOT NULL		Обязательное поле
JumpRes	Прыжок рез-ат	Вещественный	8	3		NOT NULL		Обязательное поле
JumpScore	П. очки	Числовой	4			NOT NULL		Обязательное поле
CrossRes	Кросс рез-ат	Вещественный	8	3		NOT NULL		Обязательное поле
CrossScore	К. очки	Числовой	2			NOT NULL		Обязательное поле
Score	Сумма очков	Числовой	4			NOT NULL		Обязательное поле
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле

Таблица 1.15. Антропометрические данные (TblAnthropometry)

Наименование поля	Содержание поля	Тип поля	Размерность	Кол-во знаков после запятой	Значение по умолчанию	Условие на значение	Ключ или индекс	Сообщение об ошибке
AnthId	Id	Числовой	4				ключ
Date	Дата	Дата	3			NOT NULL		Обязательное поле
Height	Рост	Вещественный	4	3	NULL
Weight	Вес	Вещественный	4	3	NULL
PId	Id спортсмена	Числовой	4			NOT NULL		Обязательное поле



Рис. 1.4 Физическое проектирование базы данных

• 2. Разработка программного продукта
• пользовательский интерфейс информация спортсмен
• 2.1 Структура программного продукта
• Структура меню приложения
• 1) Файл
• a. Выход
• 2) Редактировать
• a. Список групп
• b. Занимающиеся
• c. Список улиц
• d. Домашний адрес
• e. Список учебных заведений
• f. Учебные заведения
• g. Период обучения
• h. Данные о родителях
• i. Контроль организма
• j. Соревнования по ОФП
• k. Антропометрические данные
• 3) Отчет
• a. Занимающиеся
• b. Антропометрические данные
• c. Посещаемость
• 4) Визуализация
• a. Антропометрия: Рост
• b. Антропометрия: Вес
• c. Пульс до/после тренировки
• d. Вес до/после тренировки

• 2.2 Реализация бизнес-правил
• Бизнес-правила - набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия (или клиента).
• Клиенты формулируют правила, определяя все возможные и допустимые условия делового события, а также условия, которые недопустимы или нежелательны.
• Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл.
• Важной частью моделирования процессов функционирования предприятия является выделение и учет всех (без исключения) существующих в нем бизнес-правил.
• В программном продукте бизнес-правила реализуются с помощью SQL запросов для таблиц, имеющий слабый тип:
• 1) Формирование представления «Спортсмены» на основании таблиц «Список группы», «Спортсмены». Для отражения представления выбираются столбцы: PId, Surname, Name, Patronymic, Bithday, GId, Title. SQL запрос:
• SELECT p.*, g.Title
• FROM TblPersons AS p, TblGroup AS g
• WHERE p.GId=g.GId
• 2) Формирование представления «Домашний адрес» на основании таблиц «Спортсмены», «Список улиц», «Домашний адрес». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, HAId, Title, STId, BuildingNumber, FlatNumber, PId. SQL запрос:

• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, mi.*, st.Title
• FROM TblHomeAddress AS mi, TblPersons AS p, TblStreetTitle AS st
• WHERE (mi.PId=p.PId) AND (mi.STId=st.STId)
• 3) Формирование представления «Учебные заведения» на основании таблиц «Спортсмены», «Список учебных заведений», «Учебные заведения». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, SId, Title, STId, Year, Class, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, s.*, st.Title
• FROM TblPersons AS p, TblSchool AS s, TblSchoolTitle AS st
• WHERE (p.PId=s.PId) AND (s.STId=st.STId)
• 4) Формирование представления «Период обучения» на основании таблиц «Спортсмены», «Период обучения». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, TPId, Enterday, Takeday, OrderNumber, Finishday, IsOut, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, tp.*
• FROM TblPersons AS p, TblTeachingPeriod AS tp
• WHERE p.PId=tp.PId
• 5) Формирование представления «Родители» на основании таблиц «Спортсмены», «Родители». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, ParId, Surname, Name, Patronymic, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, par.*
• FROM TblPersons AS p, TblParents AS par
• WHERE p.PId=par.PId
• 6) Формирование представления «Контроль организма» (TblOrganismControlView) на основании таблиц «Спортсмены», «Контроль организма». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, OCId, Date, PulseMornSitting, PulseMornLying, PulseBefTrain, PulseAftTrain, WeightBefTrain, WeightAftTrain, IsAsent, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, oc.*
• FROM TblPersons AS p, TblOrganismControl AS oc
• WHERE p.PId=oc.PId
• 7) Формирование представления «Соревнования по ОФП» на основании таблиц «Спортсмены», «Соревнования по ОФП». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, PTCId, Date, PressRes, PressScore, HangeRes, HangeScore, JampRes, JampScore, CrossRes, CrossScore, Score, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, ptc.*
• FROM TblPersons AS p, TblPTCompetition AS ptc
• WHERE p.PId=ptc.PId
• 8) Формирование представления «Антропометрические данные» на основании таблиц «Спортсмены», «Антропометрические данные». Для отражения представления выбираются столбцы: Surname, Name, Patronymic, AnthId, Date, Height, Weight, PId. SQL запрос:
• SELECT CONCAT(p.Surname,'' '',p.Name,'' '',p.Patronymic) AS SNP, a.*
• FROM TblPersons AS p, TblAnthropometry AS a
• WHERE p.PId=a.PId
• 9) Формирование отчета «Посещаемость». SQL запрос:
• SELECT SNP, IsAbsent,Date,PId
• FROM TblOrganismControlView
• ORDER BY SNP, Date ASC
• 2.3 Руководство программиста
• 1) Назначение и условия применения программы
• Программный продукт предназначен для автоматизации хранения и обработки информации о спортсменах и их достижениях.
• Функции:
• - хранение данных о спортсменах
• - добавление и изменение данных
• - фильтрация данных по нескольким полям
• - формирование отчетов
• - построение графиков
• Условия для выполнения программы
• - процессор с тактовой частотой 1 ГГц и выше
• - 50 МБ оперативной памяти
• - 15 МБ свободного места на жестком диске;
• - операционная система Microsoft Windows XP/Vista/7
• - СУБД MySQL версии 5.5.28
• 2) Характеристики программы
• - время загрузки 2-3 секунды
• - режим работы: запуск по мере необходимости.
• 3) Обращение к программе вход осуществляется с помощью исполняемого модуля
• 4) Входные и выходные данные
• Входные:
• - данные о спортсменах, которые вводит тренер
• Выходные:
• - отчеты
• - графики
• 5) Сообщения
• - перед удалением записи отображается диалог для подтверждения или отмены удаления.
• 2.4 Руководство оператора
• 1) Назначение программы
• Программный продукт предназначен для автоматизации хранения и обработки информации о спортсменах и их достижениях.
• 2) Условия выполнения программы
• - процессор с тактовой частотой 1 ГГц и выше
• - 50 МБ оперативной памяти
• - 15 МБ свободного места на жестком диске;
• - операционная система Microsoft Windows XP/Vista/7
• - СУБД MySQL версии 5.5.28
• 3) Выполнение программы
• Запуск программы осуществляется с помощью исполняемого файла CourseProject.exe, после чего откроется главное окно приложения (Рис. 2.1).

• Рис. 2.1 Главное окно приложения
• Тренер может добавлять и изменять данные о спортсменах. Для этого ему нужно в меню Редактировать выбрать нужную таблицу (Рис. 2.2).
• Рис. 2.2 Меню Редактировать
• Для добавления новой записи нужно нажать комбинацию клавиш Ctrl+N, в результате отобразятся поля, в которые следует ввести данные.
• Для изменения текущей записи - Ctrl+E, в результате отобразятся поля, в которых следует редактировать данные.
• Для сохранения введенных данных используется комбинация Ctrl+Enter, а для отмены Ctrl+Space.
• Для удаления - Ctrl+Delete.
• Навигация по записям осуществляется с помощью стрелок (вверх, вниз, влево, вправо).
• Для перехода к первой записи - Ctrl+Home, к последней - Ctrl+End.
• Для фильтрации данных следует нажать комбинацию Ctrl+F, в результате отобразятся поля для фильтрации, в которые следует ввести данные, по которым она будет.
• В меню Отчет тренер может выбрать интересующий его отчет (Рис. 2.3).
• Рис. 2.3 Меню Отчет
• В меню Визуализация тренер может выбрать интересующий его график (Рис. 2.4.).
• Рис. 2.4.Меню Визуализация
• Примеры отчетов и графиков приведены в Приложении 2.
• 4) Сообщения оператору
• - перед удалением записи отображается диалог для подтверждения или отмены удаления
• - ошибка при вводе или редактировании данных приведет к отображению стандартного сообщения для MySQL сообщения об ошибке, это приведет к потере введенных данных.

• 2.5 Тестирование программного продукта
• Тестирование программного обеспечения -- процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта. Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов -- это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых. Качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
• - надёжность
• - сопровождаемость
• - практичность
• - эффективность
• - мобильность
• - функциональность
• Тестирование работоспособности программного продукта прошло успешно. Выявленные недочеты были устранены. Тестирование показало корректность выполнения всех функций:
• - хранение данных о спортсменах
• - добавление и изменение данных
• - фильтрация данных по нескольким полям
• - формирование отчетов
• - построение графиков
• При вводе некорректных данных пользователю будет показано сообщение с указанием ошибки.
• Внештатное прерывание работы программного продукта во время добавления или редактирования приведет к потере введенных/измененных данных, т.е. новая запись не будет добавлена или данные не будут изменены.

• Выводы
• Первым этапом был анализ предметной области, который выявил отсутствие программ подобного рода (ввиду специфичности обрабатываемых данных).
• На концептуальном этапе проектирования базы данных были установлены типы сущностей, связей, построена ER-диаграмма и карта транзакций.
• На этапе логического проектирования были определены атрибуты сущностей и их домены. Концептуальная модель данных преобразована в логическую модель данных, которая стала учитывать особенности выбранной модели организации данных в целевой СУБД. Спроектирована логическая схема базы данных.
• На следующем этапе был произведен анализ СУБД, в результате которого предпочтение было отдано СУБД MySQL. Также была определена среда разработки - Lazarus.
• На этапе физического проектирования была разработана структура программного продукта, определены основные функции и описаны бизнес-правила.
• Заключительным этапом стала разработка программного продукта и его тестирование, составление руководства пользователя и программиста.
• В ходе выполнения курсового проекта были достигнуты поставленные цели и задачи, доказательством чего является разработанный программный продукт «Система ведения статистики секции Дзюдо», предназначенный для автоматизации ведения журнала о спортсменах в секции “Дзюдо” г. Усть-Кута. Программа включает в себя набор основных функций, которые необходимы для ведения такого журнала.

• Приложение 1
• Техническое задание на разработку программного продукта
• Разрабатываемый программный продукт предназначен для оптимизации процесса учета и ведения статистики о достижениях тех, кто занимается в секции “Дзюдо”.
• 1. Основания для разработки
• Учебный план СибГАУ.
• 2. Назначение разработки
• Программный продукт предназначен для учета и ведения статистики о достижениях спортсменов.
• 3. Требования к программе
• 4.1. Требования к функциональным характеристикам
• 4.1.1. Функции
• - хранение данных о спортсменах
• - добавление и изменение данных
• - фильтрация данных по нескольким полям
• - формирование отчетов
• - построение графиков
• 4.1.1. Временные характеристики
• Нет требований.
• 4.2. Требования к надежности
• Программа должна проводить проверку корректности вводимых данных. В случае некорректных данных должна выводить сообщение об ошибке. Нештатные ситуации не должны приводить к потере данных.
• 4.3. Условия эксплуатации
• Нет требований.
• 4.4. Требования к составу и параметрам технических средств
• - процессор с тактовой частотой 1 ГГц и выше
• - 50 МБ оперативной памяти
• - 15 МБ свободного места на жестком диске;
• 4.5. Требования к информационной и программной совместимости
• - операционная система Microsoft Windows XP/Vista/7
• - СУБД MySQL версии 5.5.28
• 4.6. Требования к маркировке и упаковке
• Нет требований
• 4.7. Требования к программной документации
• Нет требований
• 5. Стадии и этапы разработки
• - концептуальное проектирование БД
• - логическое проектирование БД
• - физическое проектирование БД
• - создание основной части программы
• - реализация механизма построения отчетов и графиков
• - тестирование программы

• Приложение № 2
• Графики и отчеты
• Рисунок 1. Отчет «антропометрические данные»
• Рисунок 2. Отчет «Посещаемость»

• Рисунок 3. График «Антропометрия: Рост»
• Рисунок 4. График «Антропометрия: Вес»

• Рисунок 5. График «Пульс до/после тренировки»
• Рисунок 6. График «Вес до/после тренировки»
• Размещено на Allbest.ur