Информационная система для поддержки учебной деятельности ДЮСШ

Введение

Темой дипломной работы является разработка информационно-справочной системы для ДЮСШ №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НФ, НФБК.

Определение 1.

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

Определение 2

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

Определение 3

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

Определение 4

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

Определение 5

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

Определение 6

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

Определение 7

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

Определение 8

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

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

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

 

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

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

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

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

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

Этапы проектирования.

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

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

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

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

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

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

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

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

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

– универсальное отношение

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

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

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