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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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