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

Автор: Пользователь скрыл имя, 05 Апреля 2012 в 16:58, дипломная работа

Описание работы

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

Содержание

Введение
Глава 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
Заключение
Список литературы
Приложения

Работа содержит 1 файл

Дипломная работа Хакмовой Р.Р..doc

— 2.79 Мб (Скачать)

Комплекс задач этого этапа состоит из выявления общих информационных объектов и связей между ними. Результаты инфологического проектирования могут быть выражены в виде инфологической или концептуальной модели, которая представляет структуру данных. Для построения концептуальной модели используется метод моделирования «Сущность - связь» или 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 (ключ)

Счетчик

Вид

Текстовый

Стоимость

Денежный

Срок

Числовой

ВидСкидки

Логический

Скидка

Числовой

ВремяС

Дата/время

ВремяПо

Дата/время

Пн

Логический

Вт

Логический

Ср

Логический

Чт

Логический

Пт

Логический

Сб

Логический

Вс

Логический

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