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

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Стерлитамакская государственная педагогическая академия

им. Зайнаб Биишевой»

Институт математики и естественных наук

Кафедра информатики и вычислительной техники

Выпускная квалификационная (дипломная) работа

Автоматизированное рабочее место администратора фитнес-клуба

Выполнила:

Студентка 5 курса, гр. МИ-51

Хакимова Регина Ришатовна

Научный руководитель:

к. ф.-м. н., доцент кафедры ИВТ

Хусаинова Гузель Ядкаровна

Стерлитамак 2013

Содержание

• Введение
• Глава 1. Аналитическая часть
• 1.1 Понятия и характеристика баз данных
• 1.2 Анализ предметной области «Автоматизированное рабочее место администратора фитнес-клуба»
• 1.2.1 Должностная инструкция администратора фитнес-клуба
• 1.2.2 Особенности автоматизации работы фитнес-клуба
• Глава 2. Проектная часть
• 2.1 Инфологическое проектирование. Создание ER-диаграммы
• 2.2 Логическое проектирование
• 2.3 Нормализация таблиц реляционной базы данных
• 2.4 Применение CASE-средства ERwin для информационного проектирования
• Глава 3. Разработка и реализация приложения
• 3.1 Выбор средств создания интерфейса
• 3.2 Разработка интерфейса
• 3.3 Программирование работы приложения в среде Borland Delphi 7
• Заключение
• Список литературы
• Приложения

Введение

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

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

Автоматизированное рабочее место объединяет программно-аппаратные средства, обеспечивающие взаимодействие человека с компьютером, предоставляет возможность ввода информации (через клавиатуру, компьютерную мышь, сканер и пр.) и её вывод на экран монитора, принтер, графопостроитель, звуковую карту -- динамики или иные устройства вывода. Как правило, автоматизированное рабочее место является частью автоматизированной системы управления. [20]

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

· обеспечивать получение общих и/или детализированных отчетов по итогам работы;

· позволять легко определять тенденции изменения важнейших показателей;

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

· выполнять точный и полный анализ данных.

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

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

Объектом исследования является рабочее место администратора фитнес-клуба.

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

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

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

· Проанализировать предметную область;

· Составить ЕR-диаграмму и логическую схему;

· Составить структуру таблиц с использованием case-технологий;

· Нормализовать получившиеся таблицы до третьей нормальной формы;

· Создать базу данных для сбора, хранения и обработки необходимой информации;

· Разработать удобный, интуитивно понятный интерфейс для ввода и обработки информации в среде Borland Delphi 7.

Для решения поставленных задач мною были самостоятельно изучены, а затем использованы в качестве программного средства разработки Borland Delphi 7.

Данная дипломная работа состоит из 3-х глав. В первой главе рассматриваются основные понятия темы «Базы данных», анализируется предметная область «Автоматизированное рабочее место администратора фитнес-клуба». Во второй главе описывается проектирование базы данных «Фитнес-клуб». И в третьей главе дипломной работы реализуется интерфейс приложения в среде Borland Delphi 7.

Глава 1. Аналитическая часть

1.1 Понятия и характеристика баз данных

В основе решения многих задач лежит обработка информации. Для обработки информации служат информационные системы.

Информационной системой называют совокупность взаимосвязанных аппаратно-программных средств для автоматизации обработки информации. В информационную систему данные поступают от источника информации. Эти данные отправляются на хранение либо претерпевают в системе некоторую обработку и затем передаются потребителю. [1]

Автоматизированными называют информационные системы, в которых применяются технические средства.

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

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

· базы данных;

· системы управления системами данных;

· словаря данных;

· администратора;

· вычислительной техники;

· обслуживающего персонала.

Под базой данных (БД) понимают совокупность хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Целью создания баз данных, как разновидности информационной технологии и формы хранения данных, является построение системы данных, не зависящих от принятых алгоритмов (программного обеспечения), применяемых технических средств и физического расположения данных в ЭВМ; обеспечивающих непротиворечивую и целостную информацию при нерегламентируемых запросах. БД предполагает многоцелевое ее использование (несколько пользователей, множество форм документов и запросов одного пользователя). [18]

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

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

Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям:

1. Корректность схемы БД, т.е. база должна быть гомоморфным образом моделируемой предметной области, где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу - адекватные процедуры обработки данных.

2. Обеспечение ограничений (на объёмы внешней и оперативной памяти и другие ресурсы вычислительной системы).

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

4. Защита данных (от аппаратных и программных сбоев и несанкционированного доступа).

5. Простота и удобство эксплуатации.

6. Гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.

Этапы проектирования базы данных:

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

· обследование предметной области, изучение ее информационной структуры;

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

· моделирование и интеграция всех представлений.

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

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

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

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

В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:

· представление предметной области в том виде, как она реально существует;

· как ее воспринимает человек (имеется в виду проектировщик базы данных);

· как она может быть описана с помощью символов. [4]

Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.

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

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

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

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

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

Модели данных

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

· иерархические,

· сетевые

· реляционные.

Соответственно, речь идет об иерархических, сетевых, реляционных СУБД.

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

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

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

В реляционных базах данных вся информация представляется в виде прямоугольных таблиц. Реляционная модель была разработана Э.Ф. Коддом в начале 70-х годов. С ее созданием начался новый этап в эволюции СУБД. [7]

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

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

1.2 Анализ предметной области «Автоматизированное рабочее место администратора фитнес-клуба»

1.2.1 Должностная инструкция администратора фитнес-клуба

Рассмотрим общие положения должностной инструкции администратора фитнес-клуба:

1. Администратор фитнес-клуба относится к категории специалистов.

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

3. Назначение на должность администратора и освобождение от нее производится приказом директора фитнес-клуба.

4. Администратор фитнес-клуба должен знать:

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

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

4.3. Правила и методы организации процесса обслуживания посетителей.

4.4. Виды оказываемых услуг.

4.5. Основы маркетинга и организации рекламы.

4.6. Принципы планировки и оформления помещений, витрин.

4.7. Основы эстетики, этики и социальной психологии.

4.8. Основы экономики, организации труда и управления.

4.9. Законодательство о труде и охране труда Российской Федерации.

4.10. Правила внутреннего трудового распорядка.

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

5. Администратор фитнес-клуба подчиняется непосредственно директору фитнес-клуба.

6. На время отсутствия администратора фитнес-клуба (отпуск, болезнь, пр.) его обязанности исполняет лицо, назначенное в установленном порядке, которое приобретает соответствующие права и несет ответственность за надлежащее исполнение возложенных на него обязанностей. [21]

Должностными обязанностями администратора фитнес-клуба являются:

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

2. Осуществляет контроль за сохранностью материальных ценностей.

3. Консультирует посетителей по вопросам наличия имеющихся услуг.

4. Принимает меры к предотвращению и ликвидации конфликтных ситуаций.

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

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

7. Обеспечивает чистоту и порядок в помещениях и на прилегающих к ним или зданию территориях.

8. Контролирует соблюдение работниками организации трудовой и производственной дисциплины, правил и норм охраны труда, техники безопасности, требований производственной санитарии и гигиены.

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

10. Осуществляет контроль за исполнением работниками указаний руководства фитнес-клуба.

11. Выполняет отдельные служебные поручения своего непосредственного руководителя. [21]

Администратор фитнес-клуба имеет право:

1. Знакомиться с проектами решений руководства фитнес-клуба, касающимися его деятельности.

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

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

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

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

6. Требовать от руководства фитнес-клуба оказания содействия в исполнении своих должностных прав и обязанностей.

Администратор фитнес-клуба несет ответственность:

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

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

3. За причинение материального ущерба - в пределах, определенных действующим трудовым и гражданским законодательством Российской Федерации [21].

1.2.2 Особенности автоматизации работы фитнес-клуба

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

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

Прежде всего, это необходимость индивидуального подхода к клиенту. Если, к примеру, на горнолыжной трассе система может просто регулировать проход к подъёмнику, не требуя персонализации, то в фитнес-клуб клиент идет за определенной процедурой, и даже к определенному тренеру. Посетитель фитнес-клуба оплачивает услуги и рассчитывает получить за эти деньги индивидуальное обслуживание, рассчитанное именно на его потребности. Ему важно время оказания услуги, место, специалист, оказывающий услугу, а не просто «доступ» к тренажеру. Во-вторых, здесь важна возможность забронировать услугу. В третьих, фитнес-клубы постоянно расширяют спектр предлагаемых услуг: групповые спортивные, силовые, танцевальные занятия, водные программы, услуги тренажерного зала, персональные тренировки и прочее. Это требует от программы автоматизации большой гибкости и возможности настройки в процессе эксплуатации. Наконец, фитнес-клубы работают с клиентами в течение, как правило, длительного времени. Причем, чем больше период действия клубной карты, и выше процент продления, тем услуга выгоднее для клуба. Поэтому сегодня, стараясь закрепить клиентов, фитнес-клубы предлагают большой выбор услуг ? утренние, годовые, полугодовые карты, абонементы, месячные и т.д. И это тоже система должна учитывать, как на программном, так и на аппаратном уровне.

Возможности автоматизации фитнес-клуба включают в себя:

· Учет клиентов, идентификация клиентов по карте

· Учет посещений, обслуживания клиентов; ведение клубных карт, абонементов и разовых посещений

· Учет времени действия клубной карты, контроль предоставления оплаченных услуг, оперативный мониторинг загрузки клуба

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

· Учет оплаты услуг, организация различных форм оплаты, учет бесплатных услуг

· Тарификация по событию: время суток, календарная дата, будни/выходные

· Управление тарифами, просмотр «истории» тарифных планов

· «Заморозка» клубных карт, блокировка клубных карт

· Формирование и печать оперативных отчетов, автоматизация финансового анализа деятельности клуба. [21]

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

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

Глава 2. Проектная часть

2.1 Инфологическое проектирование. Создание ER-диаграммы

В базе данных отображается информация об определенной предметной области - это часть реального мира.

Инфологическая модель (ИМ) предметной области - это описание предметной области, выполненной без ориентации на используемые в дальнейшем программные и технические средства. Содержит исходную информацию о предметной области. Этап создания ИМ называется инфологическим проектированием. [8]

Требования, предъявляемые к инфологической модели:

Адекватное отображение (язык для представления ИМ должен обладать достаточными выразительными возможностями)

Непротиворечивость (не должна допускаться неоднозначная трактовка модели)

Легко расширяемость (обеспечение ввода новых данных без изменения ранее определенных)

Гибкий язык (язык должен быть применим как при ручном, так и при автоматизированном проектировании)

- Понятность всем пользователям

Цель инфологического моделирования - создать точное и полное отображение реального мира, используемое в дальнейшем в качестве источника информации для построения БД. [9]

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

Основные концепции ER - моделирования могут быть сведены к следующим:

1. Мир состоит из объектов.

2. Объекты образуют типы. Каждый объект является экземпляром некоторого типа. Объекты одного типа обладают общими свойствами.

3. Каждый объект обладает некоторым особым свойством (набором свойств), которые служат для его же идентификации.

4. Каждый объект может быть связан с другими объектами с помощью отношений.

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

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Карты», «Клиенты», «Залы». Каждая сущность в модели изображается в виде прямоугольника с наименованием.

Атрибут (свойства) - именованный элемент информации, описывающий сущность. Атрибут может иметь только одно значение в каждый момент. [18]

Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Например, атрибутами сущности «Карты» являются: «NКарты», «ВидID», «Активна», «Выдана», «ДействуетДо».

Сущности можно разделить на сильные и слабые.

Сильные (стержневые) - существуют объективно и их существование не зависит от какой-либо другой сущности.

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

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

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

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

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

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

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

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

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

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

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

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

Каждая связь может иметь один из следующих типов связи:

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

2. Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Примером является связь между отношениями «Карты» и «ВидыКарт».

3. Связь типа многие-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи многие-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности. Примером является связь между отношениями «Карты» и «Клиенты». [16]

После исследования предметной области и анализа структуры системы были выделены сущности. Перечень сущностей предметной области представлен в таблице 2.1.

Таблица 2.1. Перечень сущностей предметной области

№	Название и обозначение сущности	Ключ сущности и его обозначение	Атрибуты сущности и их обозначение
1	ВидыКарт	ID	Вид Стоимость Срок ВидСкидки Скидка ВремяС ВремяПо Пн Вт Ср Чт Пт Сб Вс
2	Карты	NКарты	ВидID Активна Выдана ДействуетДо
3	Клиенты	ID	Фамилия Имя Отчество ДатаРождения Телефоны Адрес Договор Фото КолвоВизитов Активен
4	Посещения	Дата Время КлиентID	ЗалID NКлюча Комментарий
5	ПредвЗапись	Дата Время КлиентID	ЗалID Комментарий
6	Залы	ID	Зал
7	КартыКлиента	КлиентID NКарты

Таким образом, схемы сущностей имеют вид:

ВидыКарт (ID, Вид, Стоимость, Срок, ВидСкидки, Скидка, ВремяС, ВремяПо, Пн, Вт, Ср, Чт, Пт, Сб, Вс).

Карты (NКарты, ВидID, Активна, Выдана, ДействуетДо).

КартыКлиента (КлиентID, NКарты).

Клиенты (ID, Фамилия, Имя, Отчество, ДатаРождения, Телефоны, Адрес, Договор, Фото, КолвоВизитов, Активен).

Посещения (Дата, Время, КлиентID, ЗалID, NКлюча, Комментарий).

ПредвЗапись (Дата, Время, КлиентID, ЗалID, Комментарий).

Залы (ID, Зал).

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

2.2 Логическое проектирование

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

Правила отображения ER-диаграммы на логическую схему:

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

В нашем случае появляются 3 отношения: Карты (NКарты - первичный ключ), Клиенты (ID - первичный ключ), Залы (ID - первичный ключ).

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

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

· Связь типа «многие-ко-многим» становится отношением, идентификатор связываемых сущностей становится составным первичным ключом отношения для связи, а характеристики становятся атрибутами отношений для связи. [19]

Для примера рассмотрим связь «многие-ко-многим» между сущностями «Карты» и «Клиенты». Итак, появляется отношение «Получение» с составным первичным ключом «КлиентID» и «NКарты».

Описание входной информации.

Таблица 2.2.1

Структура таблицы «ВидыКарт»

Имя поля	Тип
ID (ключ)	Счетчик
Вид	Текстовый
Стоимость	Денежный
Срок	Числовой
ВидСкидки	Логический
Скидка	Числовой
ВремяС	Дата/время
ВремяПо	Дата/время
Пн	Логический
Вт	Логический
Ср	Логический
Чт	Логический
Пт	Логический
Сб	Логический
Вс	Логический

Таблица 2.2.2

Структура таблицы «Карты»

Имя поля	Тип	Подстановка
NКарты (ключ)	Счетчик
ВидID	Числовой	SELECT [ВидыКарт].[ID], [ВидыКарт].[Вид] FROM ВидыКарт;
Активна	Логический
Выдана	Логический
ДействуетДо	Дата/время

Таблица 2.2.3

Структура таблицы «КартыКлиента»

Имя поля	Тип	Подстановка
КлиентID (ключ)	Числовой	SELECT [Клиенты].[ID], [Клиенты].[Фамилия], [Клиенты].[Имя], [Клиенты].[Отчество] FROM Клиенты;
NКарты (ключ)	Числовой	SELECT [Карты].[NКарты] FROM Карты;

Таблица 2.2.4

Структура таблицы «Клиенты»

Имя поля	Тип
ID (ключ)	Счетчик
Фамилия	Текстовый
Имя	Текстовый
Отчество	Текстовый
ДатаРождения	Дата/время
Телефоны	Текстовый
Адрес	Текстовый
Договор	Текстовый
Фото	Поле объекта OLE
КолвоВизитов	Числовой
Активен	Логический

Таблица 2.2.5

Структура таблицы «Посещения»

Имя поля	Тип	Подстановка
Дата (ключ)	Дата/время
Время (ключ)	Дата/время
КлиентID (ключ)	Числовой	SELECT [Клиенты].[ID], [Клиенты].[Фамилия], [Клиенты].[Имя], [Клиенты].[Отчество] FROM Клиенты;
ЗалID	Числовой	SELECT [Залы].[ID], [Залы].[Зал] FROM Залы;
NКлюча	Числовой
Комментарий	Текстовый

Таблица 2.2.6

Структура таблицы «ПредвЗапись»

Имя поля	Тип	Подстановка
Дата (ключ)	Дата/время
Время (ключ)	Дата/время
КлиентID (ключ)	Числовой	SELECT [Клиенты].[ID], [Клиенты].[Фамилия], [Клиенты].[Имя], [Клиенты].[Отчество] FROM Клиенты;
ЗалID	Числовой	SELECT [Залы].[ID], [Залы].[Зал] FROM Залы;
Комментарий	Текстовый

Таблица 2.2.7

Структура таблицы «Залы»

Имя поля	Тип
ID (ключ)	Счетчик
Зал	Текстовый

Таким образом, получаем завершенную модель данных (см. Приложение 2).

2.3 Нормализация таблиц реляционной базы данных

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

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

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

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

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

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

Первая нормальная форма (1НФ)

· запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);

· запрещает множественные столбцы (содержащие значения типа списка и т.п.);

· требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку. [19]

Отношение, в котором на пересечении строк и столбцов находятся только скалярные значения называется нормализованным или находящимся в 1НФ, т.е. каждый его элемент имеет атомарное значение. [16]

Недостатки 1НФ:

- избыточность,

- аномалии.

Для приведения таблицы к 1НФ обычно требуется разбить таблицу на несколько отдельных таблиц. (Таблица 2.3.1)

Таблица 2.3.1

Карты

NКарты	ВидID	Активна	Выдана	ДействуетДо
2	Полугодовая	ь	ь	27.05.2011
3	Полугодовая	ь	ь	30.04.2011
8	Месячная	ь	ь	30.03.2011

Вторая нормальная форма (2НФ)

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

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

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

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

Таблица 2.3.2

Карты

NКарты	Активна	Выдана	ДействуетДо
2	ь	ь	27.05.2011
3	ь	ь	30.04.2011
8	ь	ь	30.03.2011

Таблица 2.3.4

ВидыКарт

ID	Вид
2	Полугодовая
3	Месячная

Таблица 2.3.5

Номер_Вид_Карты

NКарты	ID(вид)
2	2
3	2
8	3

Третья нормальная форма (3НФ)

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

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

Таблица 2.3.6

КартыКлиента

КлиентID	NКарты
Петров	8
Иванов	2

Таблица 2.3.7

Карты

NКарты	ВидID
8	Месячная
2	Полугодовая

Таблица 2.3.8

ВидыКарт

ID	Вид
2	Полугодовая
3	Месячная

Таблица 2.3.9

Номер_Вид_Карты_Клиента

КлиентID	NКарты	ID(вид)
Петров	8	3
Иванов	2	2

Нормальная форма Бойса-Кодда.

Между третьей и четвертой формами существует еще одна разновидность - нормальная форма Бойса-Кодда (НФБК). Все зависимые от первичного ключа атрибуты должны быть потенциальными ключами отношения. Если это условие не выполняется для них создаётся отдельное отношение. Чтобы сущность соответствовала НФБК, она должна находиться в третьей нормальной форме. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в НФБК.

Четвертая нормальная форма (4НФ)

Отношение находится в 4НФ, если оно разбито на 2 декомпозиции, по которым естественным соединением по первичному ключу может быть восстановлено исходное значение.

То есть, таблица находится в 4НФ, если все ее многозначные зависимости являются функциональными.

Пятая нормальная форма (5НФ)

Таблица находится в 5НФ, если она находится в 4НФ и любая многозначная зависимость соединения в ней является тривиальной.

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

Пятая нормальная форма в большей степени является теоретическим исследованием, и практически не применяется при реальном проектировании баз данных. [18]

2.4 Применение CASE-средства ERwin для информационного проектирования

Программно-технологические средства специального класса - СASE-средств (Computer Aided Software Engineering), реализующих CASE-технологию создания и сопровождения ИС в настоящее время получили достаточно широкое распространение, позволяя системно подойти к разработке программного обеспечения АИС различного назначения на всех этапах жизненного цикла. Данные методики проведения информационного обследования профессиональной деятельности и построения информационных моделей объектов автоматизации являются полезными с точки зрения понимания сущности автоматизируемой деятельности и более полного использования возможностей современных средств автоматизации проектирования АИС (в частности, CASE-средств). [14]

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

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

1) мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

2) интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

3) использование специальным образом организованного хранилища проектных метаданных (репозитория). [14]

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

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

2) графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

3) средства разработки приложений, включая языки 4GL и генераторы кодов;

4) средства конфигурационного управления;

5) средства документирования;

6) средства тестирования;

7) средства управления проектом;

8) средства реинжиниринга.

Классификация CASE-средств по типу:

- средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

- средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

- средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

- средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

- средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)). [5]

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

Vantage Team Builder (Westmount I-CASE);

Designer/2000;

Silverrun;

ERwin+BPwin;

S-Designor;

CASE.Аналитик.

ERwin - CASE-средство проектирования баз данных от фирмы Computer Associates. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД. [5]

ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ODBC. Так, в текущей версии ERwin встроена поддержка 23 СУБД, среди которых: Oracle; Microsoft SQL Server и т.п. Заметим лишь, что речь идет только о реляционных СУБД.

Процесс построения информационной модели в ERwin состоит из следующих шагов:

* определение сущностей;

* определение зависимостей между сущностями;

* задание первичных и альтернативных ключей;

* определение атрибутов сущностей;

* приведение модели к требуемому уровню нормальной формы;

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

* задание триггеров, процедур и ограничений;

* генерация базы данных.

ERwin создаёт визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения части документации, необходимой в цикле разработки. Также ERwin автоматически создаёт базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Основную часть пространства программы занимает рабочая область, в которой и создается ER-диаграмма. ERwin имеет два уровня моделирования: логический и физический.

На логическом уровне данные представляются так, как они выглядят в реальном мире. Объектами логического уровня являются сущности и атрибуты. Модель логического уровня является универсальной и не связана с конкретной базой данных. [5]

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

Для автоматизированного рабочего места администратора фитнес-клуба в оболочке ER-win была создана модель, которая также имеет логический уровень (см. Приложение 3).

Глава 3. Разработка и реализация приложения

3.1 Выбор средств создания интерфейса

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

Система Borland Delphi7 предлагает несколько способов соединения с базами данных разных видов. В данной дипломной работе опробован новый механизм доступа к данным - технология ADO (ActiveX Data Objects), построенная на использовании интерфейсов OLE DB (Object Linking and Embedding Data Base - связывание и внедрение объектов баз данных). Приложение, работающее по технологии ADO, может использовать данные, представляющие собой либо таблицы Microsoft Access, либо серверные БД Microsoft SQL, Oracle, либо XML - файлы и т.п. [2]

Для работы с базой данных «Фитнес-клуб» был выбран формат Microsoft Access. Эта СУБД может использоваться во взаимодействии со средой Borland Delphi7 через имеющиеся в ней специальные компоненты. Для создания приложения, работающего по технологии ADO, компания Borland предлагает компоненты TADOConnection, TADOCommand, TADODataSet, TADOTable, TADOQuery и TADOStoredProc. В качестве провайдера данных используется Microsoft Jet OLE DB Provider, который обеспечивает соединение с данными СУБД Microsoft Access. [3]

3.2 Разработка интерфейса

Главная кнопочная форма программы имеет следующий вид (рис. 3.2.1.):

Рис 3.2.1

Нажав на кнопку «Клиенты» перед вами появится новая форма (рис. 3.2.2.), в которой представлена вся информация о клиентах фитнес-клуба. На данной форме возможен поиск по фамилии и отбор по активности посещений фитнес-клуба.

Рис. 3.2.2

На данной форме имеется возможность просмотра, добавления и удаления информации о клиентах. На форме находятся кнопка «Печать», при нажатии на которую автоматически происходит переход в программу Microsoft Office Excel, в которую перебрасываются все данные клиентов в виде таблицы для печати. Закрытие формы осуществляется при нажатии кнопки «Выход».

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