Разработка элементов информационной системы автоматизации документооборота в спортивной школе

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

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

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

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

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

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

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

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

Альтернативный ключ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр объекта. Например, для объекта «служащий», который имеет атрибуты «ИДЕНТИФИКАТОР», «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО», группа атрибутов «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО» может являться альтернативным ключом по отношению к атрибуту «ИДЕНТИФИКАТОР».

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

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

В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных, который «забраковывает» недопустимые значения. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Понятие домена может также характеризоваться как потенциальное множество допустимых значений одного типа. Необходимо также помнить о том, что в данном случае данные являются сравнимыми, если они относятся к одному домену [8].

Рисунок.2.2- Типы данных

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

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

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

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

Связи могут быть представлены пятью основными характеристиками [8]:

- тип связи (идентифицирующая, не идентифицирующая полная/неполная категория, неспецифическая связь);

- родительская сущность;

- дочерняя (зависимая) сущность;

- мощность связи;

- допустимость пустых значений.

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

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

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

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

Существует три основных типа связей [8].

1) Связи «один к одному»1:1. Это, пожалуй, самый простой тип связей. Связи «один к одному» между сущностями X и Y - это такие связи, при которых каждый экземпляр сущности X может быть связан только с одним экземпляром сущности Y. Хотя данный тип связей в реальном мире встречается довольно редко, в проектировании баз данных они широко используются, например, чтобы уменьшить число атрибутов в отношении, а также при моделировании подклассов сущностей;

2) Связи «один ко многим» 1:n. Наиболее распространена ситуация, когда один экземпляр сущности связан с одним или множеством экземпляров другой сущности;

3) Связи «многие ко многим» m:n. Данный тип связей часто встречается в реальном мире. Но в базе данных реализовать данный тип связи невозможно. При моделировании таких связей разработчики используют промежуточную связь «один ко многим» с каждым из отношений - участников связи «многие ко многим».

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

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

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

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

Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.

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

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

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

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

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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

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

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

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

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

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

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объектов. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.

Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях.

В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный - термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

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

Реляционная модель данных была разработана Коддом еще в 1969-70 годах на основе математической теории отношений и опирается на систему понятий, важнейшими из которых являются таблица (отношение), строка (кортеж), столбец (атрибут), первичный ключ, внешний ключ. Реляционная модель - множественное отношение, которое представляет собой подмножество декартова произведения списка доменов. Домен - это множество значений, из которого извлекаются значения для данного атрибута. Другими словами в основе реляционной модели лежат простые таблицы, которые удовлетворяют определенным ограничениям, а потому могут рассматриваться как математические отношения. Строки таких таблиц называют кортежами, имена столбцов - атрибутами. Значения атрибутов выбираются из множества допустимых значений, которое называется доменом. Следует отметить, что все кортежи различны, а порядок столбцов произволен. В отношении (таблице) выделяются несколько атрибутов, однозначно идентифицирующих кортежи и называемых ключами. Для того чтобы, гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности. Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблицы выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам. Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств, таких как правила, домены [8].

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

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

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

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

2.2 Формирование логической и концептуальной моделей структурирования данных с использованием CASE-средств

Модель «сущность-связь» описывается в терминах сущность, связь, значение. Сущность - понятие, которое может быть идентифицировано. Связь - соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграмма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность - это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа «многие ко многим» или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграмма - графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей - ромбом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа проектировщика существенно упрощается, если есть возможность изучить структуру сложной системы с помощью схемы, а не анализировать подробные текстовые описания спецификаций требований пользователей. Для представления сущностей и связей между ними обычно используются диаграммы «сущность-связь» (ER-диаграммы). Это позволяет всегда иметь под рукой наглядный образ моделируемой части предприятия [8].

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

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

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

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

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

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

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

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

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

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

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

Связь между двумя сущностями отображается с использованием механизма «первичный ключ/внешний ключ». При определении того, в каком отношении должен находиться атрибут (атрибуты) внешнего ключа, необходимо вначале выяснить, какая из сущностей, участвующих в связи, является родительской, а какая дочерней. Родительской называется сущность, которая передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования в качестве внешнего ключа [8].

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

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

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

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

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

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

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

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

- ERD (Entity Relationship Diagrams) - диаграммы «сущность-связь»;

- DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов.

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

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

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

Для проектирования описанных выше диаграмм используются CASE - средства (Computer Aided Software Engineering).

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

Для проектирования DFD используется программное средство BPwin, которое является ведущим инструментом визуального моделирования бизнес-процессов. BPwin дает возможность наглядно представить любую деятельность или структуру в виде модели.

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

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

Учебная группа - таблица, содержащая сведения о группе, обучающейся в спортивной школе (таблицу 2.1).

Тренера - преподаватели - таблица, содержащая данные о преподавателях (таблицу 2.2).

Ученики - таблица, содержащая индивидуальные данные об учащихся (таблицу 2.3).

Зачисление - таблица, содержащая информацию об состоянии учащегося школы (таблицу 2.4).

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

Таблица 2.1 - Сущность «Учебная группа»

Ключ	Атрибут	Имя в таблице «GROUP»	Тип данных
1	2	3	4
ь	Код Вид Спорта Тренер Этап Подготовки Код Этапа Наименование	ID VID_SPORTA TRENER ETAP_PODGOTOVKI ID_ETAPA NAIMENOVANIE	Числовой Текстовый Текстовый Текстовый Числовой Счетчик

Таблица 2.2 - Сущность «Тренеры»

Ключ	Атрибут	Имя в таблице «TRENERA»	Тип данных
1	2	3	4
ь	Код ФИО Образование Специальность Вид Спорта	ID_TRENERA FIO OBRAZOVANIE SPECIALNOST VID_SPORTA	Счетчик Текстовый Текстовый Текстовый Текстовый

Таблица 2.3 - Сущность «Ученики»

Ключ	Атрибут	Имя в таблице «UCHENIKI»	Тип данных
1	2	3	4
ь	Код ученика Группа Вид спорта Тренер Этап Подготовки Состояние Код Этапа ФИО Адрес Контактный телефон Дата Рождения Школа Класс Приказ Дата Изменения	ID_UCHENIKA GROUP VID_SPORTA TRENER ETAP_PODGOTOVKI SOSTOYANIE ID_ETAPA FIO ADDRESS PHONE DATE_ROZHDENIYA SCHOOL CLASS PRIKAZ DATE_IZMENENIYA	Счетчик Текстовой Текстовой Текстовый Числовой Текстовый Счетчик Текстовый Текстовый Числовой Дата/время Числовой Числовой Текстовый Дата/время

Таблица 2.4 - Сущность «Зачисление»

Ключ	Атрибут	Имя в таблице «ZACHISLENIE»	Тип данных
1	2	3	4
ь	Номер Код Вид Спорта Тренер Этап Подготовки Код Этапа Дата Проведен Наименование Группа	NOMBER ID VID_SPORTA TRENER ETAP_PODGOTOVKI ID_ETAPA DATE PROVEDEN NAIMENOVANIE GROUP	Числовой Счетчик Текстовый Текстовый Числовой Счетчик Дата/время Текстовый Текстовый Числовой

Структура разрабатываемой системы представлена на рисунке 2.3.

Рисунок 2.3 - Структурная схема базы данных.

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

Контекстная диаграмма с единственным процессом «Обучение» приведена на рисунке 2.4



Рисунок 2.4 - Контекстная диаграмма

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

Тренера - преподаватели осуществляют сам процесс обучения.

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

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

Рисунок 2.5 - DF-диаграмма первого уровня

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

3.1 Выбор языковых и программных средств реализации программного обеспечения

Для реализации дипломного проекта была выбрана система программирования Delphi, относящаяся к классу инструментальных средств ускоренной разработки программ (RAD).

Сокращение времени на разработку программ достигается за счет визуального конструирования форм и использования библиотеки визуальных компонентов (VCL).

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

Библиотека визуальных компонентов содержит большое количество компонентов, готовых к использованию. Компоненты уже содержат в себе необходимый программный код и данные.

Таким образом, использование компонентов позволяет сократить время разработки программы и снижает вероятность ошибок.

Язык программирования Delphi был создан на базе языка Паскаль. Delphi отличает мощность и гибкость, имеется возможность делать вставки на Assembler. При этом язык имеет очень простой и ясный синтаксис.

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

Структурной единицей визуального программирования, основным «строительным элементом» для программы является компонент.

Компонент - это разновидность класса, который представлен пиктограммой на палитре компонентов Delphi, может быть визуально перенесен в программу и имеет набор свойств, которые можно определять, не изменяя текста программ. В этом суть визуального программирования. (В отличие от языка Turbo-Pascal, классом в Delphi называется объектовый тип переменных, а объектом называется экземпляр класса. Например, тип Student - это класс, а студент Иванов - конкретный объект, экземпляр класса).

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

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

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

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

Каждая форма представлена двумя файлами - файлом визуального описания формы (бинарный файл с расширением .dfm) и модулем с исходным текстом на языке Pascal (текстовый файл с расширением .pas), содержащим обработчики событий для компонентов этой формы.

Формы и модули объединены в проект. Проект - это совокупность файлов, из которых Delphi создает приложение. Проект оформляется в виде головной программы на Паскале, содержащей ссылки на файлы всех форм и модулей. Файл проекта имеет расширение .dpr.

В качестве средств разработки специального программного обеспечения была выбрана система Delphi 7. Выбор обуславливается тем, что с ее помощью можно в кратчайшие сроки разработать быстрое, компактное и полноценное Windows-приложение, работающее с базами данных и приложениями электронной почты. На сегодня Delphi является одним из самых распространенных средств создания приложений баз данных для корпоративных применений. Эти средства позволяют создавать прикладные программы, предназначенные для работы на ПЭВМ IBM PC AT под управлением оболочки Windows XP и других версий, а так же операционной системы Windows NT и использующие общепринятые для Windows элементы пользовательского интерфейса. Предпочтение было отдано системе Borland Delphi 7 Enterprise благодаря тому, что она позволяет программисту очень быстро и удобно разрабатывать пользовательский интерфейс [9]. Это свойство особенно ценно из-за того, что, как показывает практика, работа над интерфейсом занимает большую часть времени создания программного продукта. Еще одним преимуществом выбранной системы является высокая (по сравнению со многими другими средствами программирования) эффективность генерируемого компилятором кода, что весьма существенно для данного проекта.

3.2 Модульная структура программного обеспечения

Программное обеспечение имеет модульную структуру, которая представлена на рисунке 3.1.



Рисунок 3.1 - Модульная структура программного обеспечения

Главным модулем является управляющая программа, которая передает управление подсистемам более низкого уровня иерархии.

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

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

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

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

Схема функционирования программного обеспечения изображена на рисунке 3.2. в виде алгоритма.

Рисунок 3.2 - Схема функционирования программного обеспечения

3.3 Организация пользовательского интерфейса информационной системы автоматизации документооборота в спортивной школе

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

Пользовательский интерфейс созданной программы содержит четыре формы (т.е. стандартных окна системы Windows).

Главное окно программы изображено на рисунке 3.3. Окно служит для доступа к другим окнам и управления приложением. Для этой цели на форме были размещены 7 кнопок (компонентов Delphi BitBtn). Три из них открывают соответственно окно форм, окно запросов, окно отчетов. Кнопка «Помощь» открывает справочную систему. Кнопка «Защита» позволяет сменить пароль доступа к программе. Кнопка «Свернуть» сворачивает все приложение. После нажатия на «Выход» закроются все окна программы, и она завершит работу.

Рисунок 3.3 - Главное окно программы

Окно «Формы» (рисунок 3.4) служит для редактирования таблиц базы данных. Пользователю не очень удобно работать с приложением, которое открывает большое количество окон. Поэтому для редактирования каждой из четырех таблиц не создавалось отдельное окно. Вместо этого окно «Формы» содержит четыре вкладки (Группы, Тренеры, Спортсмены и Расписание)



Рисунок 3.4 - Окно «Формы»

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

Визуализация данных осуществляется с помощью компонентов DBGrid, DBEdit и DBComboBox. DBGrid - это сетка (таблица), в которой отображаются все данные. Для нее было установлено свойство ReadOnly, тем самым редактирование записей стало возможно только через другие компоненты. DBEdit - это поле редактирования, которое настраивается на конкретное поле таблицы базы данных. DBComboBox - раскрывающийся список. Он заполняется значениями из другой таблицы, поэтому например, в поле «Тренер» можно указать только того тренера, который присутствует в соответствующей таблице. Для навигации, вставки и удаления записей базы данных служит компонент DBNavigator, представляющий панель кнопок.