База данных горнолыжного курорта

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

«МУРМАНСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНЫЙ УНИВЕРСИТЕТ»

(ФГБОУ ВПО МГГУ)

Факультет физико-математического образования, информатики и программирования

Кафедра математики и математических методов в экономике

К У Р С О В А Я Р А Б О Т А

База данных горнолыжного курорта

Выполнил студент: Малахов И.Д.,

Бизнес-информатика, очная, 2 курс

Научный руководитель Пышкина Т.В.

Мурманск 2014



Содержание

Введение

1. Анализ предметной области

2. Разработка информационно-логической схемы базы данных

2.1 Выделение объектов и информационных процессов в данной области

2.2 Разработка реляционной модели

3. Разработка интерфейса пользователя

3.1 Создание форм

3.2 Создание отчетов для базы данных

3.3 Запросы в базу данных

Заключение

Источники и литература



Введение

В состав пакета Microsoft Office Professional входит приложение Microsoft Access, предназначенное для работы с базами данных. Под базой данных Microsoft Access понимает совокупность данных и объектов, относящихся к определенной задаче. База данных Microsoft Access может содержать таблицы, запросы, формы, отчеты, макросы, модули и ярлыки страниц доступа к данным. Ядро базы данных Microsoft Jet управляет данными, которые содержатся в таблицах, находящихся в базе данных. Данные в связанных таблицах могут содержаться в другой базе данных Access, во внешнем источнике данных, таком как базы данных dBASE или электронная таблица Microsoft Excel, а также в источнике данных ODBC, таком как Microsoft SQL Server.

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



1. Анализ предметной области

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

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

К этому комплексу относится и различная экипировка для спортсменов, которой присвоен свой код, время проката, цена и т.п.

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

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

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



2. Разработка информационно-логической схемы базы данных

2.1 Выделение объектов и информационных процессов в данной области

Рисунок 2.1 Схема данных в СУБД Access

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

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

Таблица «Главная» включает в себя такие поля как: Код операции; Услуга; Время работы.

Таблица «Прокат (прокат)» включает в себя такие поля как: Наименование; Стоимость руб/ч.; Код услуги (прокат); Код операции.

Таблица «Склоны» включает в себя такие поля как: Название; Уровень сложности; Номер подъемника; Состояние трассы; Номер склона.

Таблица «Инструкторы» включает в себя такие поля как: ФИО; Стаж; Стоимость; Код услуги (инструктор); Код операции; Возраст.

Таблица «Услуга (трансфер)» включает в себя такие поля как: Услуга; Трансфер; Уровень комфорта; Стоимость; Код услуги (трансфер); Код операции.

Таблица «Прокат (экипир)» включает в себя такие поля как: Наименование; Стоимость руб/ч.; Код услуги (экипировка); Код операции.

Таблица «Подъемник» включает в себя такие поля как: Номер подъемника; Тип подъемника; Номер склона; Стоимость подъема (руб/ч.); Код услуги (подъемник); Код операции.

Таблица «Код операции» включает в себя такие поля как: Код заказа; Код карты; Код услуги (прокат); Код услуги (экипир); Код услуги (инструктор); Код услуги (подъемник).

Таблица «Склон-Трансфер» включает в себя такие поля как: Номер склона; Код услуги (трансфер).

Таблица «Клиенты» включает в себя такие поля как: ФИО клиента; Номер телефона; Возраст; Код карты.

Для каждой сущности выбран ключ - атрибут, значения которого однозначно идентифицируют кортеж:

1) Таблица «Главная» - ключевое поле «Код операции»

2) Таблица «Прокат (прокат)» - ключевое поле «Код услуги (прокат)»

3) Таблица «Склоны» - ключевое поле «Номер склона»

4) Таблица «Инструкторы» - ключевое поле «Код услуги инструктор»

5) Таблица «Услуга (трансфер)» - ключевое поле «Код услуги (трансфер)»

6) Таблица «Прокат (экипир)» - ключевое поле «Код услуги (экипировка)»

7) Таблица «Подъемник» - ключевое поле «Код услуги (подъемник)»

8) Таблица «Код операции» - ключевое поле «Код заказа»

9) Таблица «Склон-Трансфер» - ключевое поле «Номер склона»

10) Таблица «Клиенты» - ключевое поле «Код карты»

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

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

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

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

Остальные таблицы лишь информационные и содержат информацию либо об отдельной услуге, операции или о клиентах.

Предполагается также решение следующих задач:

- получение информации об определенной услуге;

- получение информации о персонале;

- получение информации о клиентах;

- получение информации об совершенных сделках;

- ввод данных в таблицы;

- удаление данных из таблиц.

2.2 Разработка реляционной модели базы данных

Реляционная база данных - это набор нормализованных отношений, которые различаются по именам.

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

Эти отношения обладают следующими характеристиками:

- отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;

- каждая ячейка отношения содержит только одно элементарное (неделимое) значение;

- каждый атрибут имеет уникальное имя;

- значения атрибута берутся из одного и того же домена;

- каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;

- порядок следования атрибутов не имеет значения;

- теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним);

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

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

- поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.

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

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

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

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

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

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

Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает "продажи".

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

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

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

Базовые отношения - это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.

Целостность по ссылкам основана на понятии внешнего ключа.

Пусть даны отношения R1 и R2. Пусть k1, - это первичный ключ отношения R1.

Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 - это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.

Достоинствами реляционного подхода являются:

1. Наличие простого, и в тоже время мощного математического аппарата.

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

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

Итак, условия первой нормальной формы:

- Определить требуемые элементы данных, потому что они становятся столбцами в таблице. Поместить связанные элементы данных в таблицу.

- Гарантировать отсутствие повторяющихся групп данных.

- Гарантировать наличие первичного ключа.

- Значение всех атрибутов атомарны.

- Информационная система находится в первой нормальной форме.

Условия второй нормальной формы:

- Отношение в первой нормальной форме.

- Независимость первичных ключей и столбцов

- Информационная система находится во второй нормальной форме.

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

Условия третьей нормальной формы:

- Отношение во второй нормальной форме.

- Все поля, не входящие в первичный ключ, зависят от первичного ключа.

- Информационная система находится в третьей нормальной форме.

Таким образом, нормализация отношений успешно достигнута.

После нормализации отношений было создано 7 таблиц. Проиллюстрируем эти таблицы в режиме конструктора:

Рисунок 2.2 Главная таблица в режиме конструктора

Рисунок 2.3 Таблица «Инструкторы» в режиме конструктора

Рисунок 2.4 Таблица «Клиенты» в режиме конструктора

Рисунок 2.5 Таблица «Код операции» в режиме конструктора

Рисунок 2.6 Таблица «Подъемник» в режиме конструктора

Рисунок 2.7 Таблица «Прокат (прокат)» в режиме конструктора

Рисунок 2.8 Таблица «Прокат (экипировка)» в режиме конструктора

Рисунок 2.9 Таблица «Склон - Трансфер» в режиме конструктора

Рисунок 2.10 Таблица «Склоны» в режиме конструктора

Рисунок 2.11 Таблица «Услуга (трансфер)» в режиме конструктора



3. Разработка интерфейса пользователя

3.1 Создание форм

Дизайн разработан на основе понятия о “диалоговых окнах". Существует главное окно, или так называемая “Главная кнопочная форма". Открыв ее, пользователю предлагаются следующие действия:

- посмотреть отчеты;

- ввести информацию в таблицы;

- выйти из кнопочной формы.

На рисунке ниже предоставлено диалоговое окно Главной кнопочной формы:

Рисунок 3.1 Окно «Главная кнопочная форма»

Переход по вкладке «Отчеты»:

Рисунок 3.2 Просмотр отчетов

Если перейти по вкладке «Отчеты», то откроется диалоговое окно, в котором будет две другие вкладки: «Список инструкторов» и «Отчет по стоимости услуг». При переходе на вкладку «Список инструкторов» открывается диалоговое окно со списком инструкторов, упорядоченном по фамилиям. Продемонстрирую работу формы:

Рисунок 3.3 Переход к отчету «Список инструкторов»

При переходе на вкладку «Отчет по стоимости услуг» открывается диалоговое окно со списком инструкторов, упорядоченном по фамилиям.

Рисунок 3.4 Переход к отчету по стоимости услуг

Рисунок 3.5 Кнопочная форма в таблице Switcboard Items

В таблице «Switcboard Items» отображены все данные о создании кнопочной формы.

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

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

Рисунок 3.6 Форма «Идентификационный код заказа клиента»

Рисунок 3.7 Форма в режиме конструктора

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

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

Рисунок 3.8 Форма «Склоны»

Теперь посмотрим создание данной формы в режиме конструктора (Рисунок 3.9). С помощью дополнительной формы (Склон-Трансфер) и таблицы «Склоны» (Рисунок 2.10) была создана данная форма:

Рисунок 3.9 Форма «Склоны» в режиме конструктора

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

3.2 Создание отчетов для базы данных

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

Демонстрацию отчетов можно посмотреть в первом пункте третьей главы (Рисунок 3.3, Рисунок 3.4). С данными отчетами в режиме конструктора можно ознакомиться по рисункам, представленным ниже:

Рисунок 3.10 Отчет по стоимости услуг в режиме конструктора

Отчет по стоимости услуг был создан в режиме конструктора. С помощью взаимодействия строк из трех таблиц «Инструкторы», «Главная» и «Код операции» (Рисунок 2.3, Рисунок 2.2, Рисунок 2.5 соответственно) был создан данный отчет. В заголовке отчета прописано два условия (=Date(),=Time()) для вывода даты и времени просмотра отчета. Для того, чтобы узнать на какую букву начинается фамилия следовало прописать в заголовке группы ФИО условие (=Left([ФИО];1). В данном отчете вычисляется суммарная стоимость услуги за час (вычисление суммарной стоимости вычисляется с помощью формулы =Sum([Оклад])) и средняя стоимость услуги за час (вычисление средней стоимости вычисляется с помощью формулы =Avg([Оклад])).

Рисунок 3.11 Отчет «Список инструкторов» в режиме конструктора

Данный отчет не особенно отличается от предыдущего. Данные были взяты так же из трех таблиц «Инструкторы», «Главная» и «Код операции» (Рисунок 2.3, Рисунок 2.2, Рисунок 2.5 соответственно). Данный отчет нужен для просмотра реально работающих инструкторов в горнолыжном комплексе.

3.3 Запросы в базу данных

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

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

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

Рисунок 3.12 Запрос «Клиенты на букву «М»»

Благодаря условию отбора (Like “M”) ФИО клиентов отображается только с условием, что все фамилии начинаются на букву «М».

Рисунок 3.13 Запрос «Клиенты на букву «М»» в режиме конструктора

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

Рисунок 3.14 Запрос «Инструктор-Клиент»

Запрос «Инструктор-Клиент» был создан с помощью использования логических взаимосвязей. С данным запросом в режиме конструктора можно ознакомиться ниже:

Рисунок 3.15 Запрос «Инструктор-Клиент» в режиме конструктора

В Access при обращении к БД также применяется язык SQL (Access изнутри организован по системе «клиент-сервер»). Любой запрос, построенный с помощью мастера или конструктора, имеет соответствующее представление на языке SQL. Конструктор - лишь визуальное средство для создания запросов. В Access имеется возможность редактировать запросы непосредственно в режиме SQL. Причем, не всякий составленный на SQL запрос, может быть отображен в режиме конструктора - SQL имеет более широкие возможности, чем визуальный конструктор.

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

Рисунок 3.7 Запрос «Количество клиентов»

Запрос был создан с помощью синтаксиса SQL. Продемонстрирую запрос «Количество клиентов» в режиме SQL:

Рисунок 3.5 Режим SQL

Заключение

Принято считать, что использование концепции баз данных позволяет:

- повысить надежность, целостность и сохранность данных;

- сохранить затраты интеллектуального труда;

- обеспечить простоту и легкость использования данных;

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

- обеспечить достоверность данных;

- обеспечить требуемую скорость доступа к данным;

- стандартизовать данные в пределах одной предметной области;

- автоматизировать реорганизацию данных;

- обеспечить защиту от искажения и уничтожения данных;

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

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

- создать предпосылки для создания распределенной обработки дaнныx.

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

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

В данной работе использовались такие объекты, как: таблицы, запросы, формы, отчеты, макросы. Но программа Microsoft Office Access 2003 намного обширней, разнообразней и имеет больше возможностей. Например, для создания запросов можно использовать структурированный язык SQL, можно подготовить данные для Интернета и т.п. Поэтому, конкретный вывод о применимости Access можно сделать только после ее всестороннего анализа, что выходит за рамки данной курсовой работы.

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



Источники и литература

1. Вейкас Д. Эффективная работа с Microsoft Access 2/: Перев. с англ. СПб.: Питер, 1995. 864 с.

2. Карпова Т.С. Базы данных: модели, разработка, реализация/: СПб.: Питер, 2001. 304 с.

3. Манфред Х., Шпильман К. Access: сотни полезных рецептов/: пер. с нем. К.: BHV, 1997. 400 с.

4. Аблязов В.И., Редько С.Г. Проектирование баз данных в среде Microsoft Office Access 2003. Методические указания по выполнению лабораторных работ/: - Москва: Астрель, 2008. 49 с.

5. Гончаров А.Ю., Access 2003. Самоучитель с примерами/: Электронная версия. Кудиц-образ: 2004. 272 с.

6. Симонович С. В., Евсеев Г. А., Специальная информатика: Учебное пособие/: М.: АСТ-ПРЕСС: Инфорком-Пресс: 2000. 163 с.

7. Мейер М.Н., Теория реляционных баз данных/: М.: Мир: 1987. 145 с.

8. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем/: М.: Финансы и статистика: 1989. 251 с.

9. Бакаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2002/: СПб.: БХВ-Петербург: 2002. 276 с.

10. Григорьев В.А., Ревунков В.И. Банки данных. Учебник для вузов/: М., МВТУ им.Баумана: 2002. 304 с.

Размещено на Allbest.ru