Информационная система спортивной школы

Обновлено: 06.07.2024

Темой дипломной работы является разработка информационно-справочной системы для ДЮСШ №1 г. Алапаевска. Вопрос автоматизации и информационной поддержки учебного процесса в школе до сих пор остается открытым, то есть не используется никакая информационная система. Подобных информационных систем для спортивных школ на рынке ИС найти не удалось.

Информационная система (ИС) должна обеспечивать руководителя, тренеров, методиста оперативной информацией для контроля учебного процесса и анализа его результатов

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

Информационная система должна отвечать следующим требованиям:

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

– В ИС должна быть предусмотрена генерация и печать необходимых текущих отчетных, аналитических и др. документов.

– ИС должна обладать удобным и простым для восприятия интерфейсом и справочной системой.

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

2. Спроектировать логическую модель данных для РБД.

3. Реализовать проект средствами СУБД Microsoft Access 2003.

4. Спроектировать и реализовать необходимые запросы.

5. Разработать и реализовать простой и удобный пользовательский интерфейс.

1. Основные сведения из теории реляционных баз данных 1.1 Определение основных понятий

Сущность – это любой отличимый объект, информацию о котором мы хотим хранить в БД.

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

Экземпляр сущности – каждый конкретный элемент набора (типа сущности).

Атрибут – это поименованная характеристика типа сущности, т.е. свойство, общее для всех экземпляров данного типа.

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

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

Один из возможных ключей выбирается в качестве первичного ключа (РК – Primary Кеу)

Из определения РК вытекают следующие его ограничения (свойства):

– Уникальность. Это означает, что в произвольный момент времени ни у каких двух экземпляров сущностей не допускается одинаковых значений ключа.

– Не допускается, чтобы какой-либо из атрибутов, входящий в РК, принимал для какого-либо экземпляра сущности неопределенное (или NULL) значение, так как последнее означало бы, что такой экземпляр невозможно идентифицировать. Это свойство называют целостностью по сущностям.

Связь – это связывание между собой двух или более сущностей.

1.2 Классификация сущностей и связей по К. Дейту

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

Рассмотрим такую классификацию для связей между двумя типами сущностей.

Пусть А и В-типы сущностей, тогда возможны четыре вида связей:

а) Один-к-одному (1:1). Это означает, что в каждый момент времени каждый экземпляр сущности А связывается не более чем с одним экземпляром сущности В. Это самый простой и довольно редкий вид связи.

б) Один-ко-многим (1:М), М/0. Связь (1:1) фактически входит сюда как частный случай. Здесь с одним экземпляром сущности А связывается М/0 экземпляров сущности В.

в) Многие-к-одному (N:1), N/1. N экземпляров сущности А связываются с одним экземпляром сущности В

г) Многие-ко-многим (N:M), N/1, M/0. Это наиболее общий вид связи, его обычно называют ассоциацией, а числа M и N степенями связи.

Характеристика – это чаще всего связь типа (1:М), либо (1:1), имеющая записимое от цели существование. Это означает, что при удалении экземпляра целевой сущности, на которую ссылается экземпляр характеристики, последний тоже должен прекратить свое существование, т.е. быть удален.

Обозначение – это обычно связь типа (N:1), N/1, имеющая независимое от цели существование, т.е. фактически должно быть запрещено удаление экземпляра цели, если у него есть связанные записи.

Ассоциация – связь типа (N:M), и она может иметь как зависимое, так и независимое от целей существование.

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

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

Для описания инфологической модели используются ER-диаграммы и специальные языки инфологического моделирования – ЯИМ.

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

Если сущность А связывает сущности Е1 (с первичным ключом PK1) и Е2 (с первичным ключом PK2) и является ассоциацией, то в состав ее атрибутов должны входить внешние ключи (FК1, FК2), соответствующие первичным ключам целевых сущностей Е1 и Е2. Совокупность внешних ключей должна входить в состав ключа ассоциации.

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

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

1. неопределенное значение (NULL)

2. действие удаления ограничивается (RESTRUCT);

3. действие удаления распространяется или каскадируется (CASCADE).

1.3 Основы теории нормализации Э. Кодда

Рассмотрим общую идею нормализации. Причиной, которая может привести к нарушению целостности данных, является избыточность. Э. Кодд исследовал и установил причины, порождающие избыточность, а именно наличие в таблице нежелательных зависимостей между атрибутами. Он предложил способы для избавления от этих зависимостей и, следовательно, от избыточности данных. Кодд ввел понятия функциональных зависимостей между атрибутами и нормальных форм для реляционных таблиц: 1НФ, 2НФ, 3НФ, 4НФ, 5НФ, НФБК.

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

Поле В (может быть составным) таблицы находится в полной ФЗ от составного поля А той же таблицы, если оно функционально зависит от А (А à В) и не зависит функционально ни от какого подмножества А. Обозначение: А => В.

Если существует ФЗ между не ключевыми атрибутами (F1 à F2), то такая зависимость называется транзитивной.

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

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

Таблица находится в третьей нормальной форме (ЗНФ) тогда и только тогда, когда она находится в 2НФ и в ней нет транзитивных зависимостей.

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

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

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

1.4 Этапы проектирования базовых таблиц РБД

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

Методология проектирования логических моделей данных делится на два уровня:

– инфологическое проектирование или построение инфологической модели данных;

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

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

1. Сбор и анализ информационных требований к БД.

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

2. Сбор информации об использовании данных.

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

Имеет смысл информацию об использовании данных разделить на два вида:

– Информация, связанная с основными производственными функциями.

– Информация, связанная с функциями управления.

3. Первоначальное структурирование собранной информации.

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

– домены всех атрибутов

– ограничения модели по отношению к предметной области

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

Раздел: Информатика, программирование
Количество знаков с пробелами: 63437
Количество таблиц: 2
Количество изображений: 33

Для чего спортивной школе нужна информационная система?

Расписание занятий - самая востребованная функция информационной системы

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

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

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

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

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

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

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

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

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

Объект, предмет, практическая значимость, новизна
Объект исследования: автоматизация и
подготовки воспитанников спортивной школы.
защита
системы
учета
Предмет исследования: создание защищенной информационной
системы учета подготовки воспитанников спортивной школы.
Практическая
значимость:
применение
защищенной
информационной системы позволит повысить надежность хранения
информации о студентах, сохранность этой информации, оперативность
и безопасность доступа к ней заинтересованными сотрудниками
спортивной школы в соответствии с политикой информационной
безопасности, а также сократить время формирования необходимых
документов и отчётов.
Новизна:
- разработана модель рабочего процесса учета подготовки
воспитанников спортивной школы в нотации BPMN 2.0 с применением
специализированного CASE-средства Bizagi Modeler;
- в нотации IDEF1X, с применением CASE-средства ERWin Data
Modeler, выполнено проектирование модели данных спортивной школы.
Модель данных реализована в реляционной СУБД Microsoft SQL Server
2019. Выполнена защита созданной БД.
3

Требования к защищённой информационной системе учета
подготовки воспитанников спортивной школы
Функциональные требования:
1. хранение всей информации о сотрудниках, студентах в единой реляционной базе данных;
2. наличие многопользовательского режима работы с базой данных;
3. автоматизация процесса коммуникации студентов и сотрудников;
4. автоматизация работы тренера.
Не функциональные требования:
Требования к серверной части:
1. Сетевая операционная система Microsoft Windows Server 2012;
2. СУБД Microsoft SQL Server 2012 и выше;
Требования по информационной безопасности:
1. идентификация и аутентификация пользователей для входа в операционные системы своих АРМ с использованием
двухфакторной аутентификации;
2. идентификация и аутентификация пользователей для работы с СУБД;
3. разграничение доступа пользователей к информации в соответствии с установленной производственной
необходимостью пользователя системы;
4. контроль использования интерфейсов ввода/вывода средств вычислительной техники, подключения внешних
программно-аппаратных устройств и конкретных съемных машинных носителей информации;
5. реализация криптографической защиты данных с использованием встроенных механизмов СУБД;
6. применение антивирусной защиты данных;
7. регистрация действий пользователей и событий безопасности.
8. Безопасность данных включает их целостность и защиту. Целостность данных – устойчивость хранимых данных к
разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и
ошибочными действиями пользователей. Она предполагает:
9. отсутствие двух одинаковых записей об одном и том же факте;
10. защиту от ошибок при обновлении БД;
11. невозможность удаления порознь (каскадное удаление) связанных данных и таблиц;
12. не искажение данных при работе в многопользовательском режиме и в распределенных базах данных;
13. сохранность данных при сбоях техники (восстановление данных).
8

Модель данных защищенной информационной системы
спортивной школы
(стандарт моделирования IDEF1X)
Полная атрибутивная модель БД спортивной школы
12

Модель данных защищенной информационной системы
спортивной школы
(стандарт моделирования IDEF1X)
Трансформационная модель БД банка
13

Защита базы данных
Создание имени пользователя
Создание регистрационного имени
Создание роли
базы данных
Создание новой роли базы данных и
добавление сотрудников
14

Защита базы данных
USE master
go
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'gFhJkMLKZdrh'
GO
select*from sys.key_encryptions
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEC Certificate'
GO
SELECT*FROM SYS.certificates
USE Sport_School
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCertс
GO
ALTER DATABASE Sport_School
SET ENCRYPTION ON
GO
SELECT DB_NAME(database_id), * FROM
SYS.dm_database_encryption_keys
BACKUP CERTIFICATE MyServerCertс TO FILE = 'J:\MyServerCertс' ;
GO
Иерархия (архитектура) ключей SQL-сервера
Защита базы данных
15

Читайте также: