Люди приезжают отдыхать на горнолыжные курорты и тратят свои деньги на проживание, на еду и на развлечения различного рода. Мало кто из них задумывается над тем, какой связью связаны те или иные гостиничные комплексы. Им не нужно задумываться, так как об этом должны думать другие люди, которые вместо того, чтобы сейчас кататься на склоне, они заняты сейчас на своем рабочем месте.
Хотелось бы рассмотреть самостоятельно структуру небольшого горнолыжного комплекса и создать связную с ней базу данных. Соответственно, эта базы данных будет состоять из таких сущностей взаимоотношений, как клиенты (потребители услуг), сами услуги и обслуживающий персонал.
К этому комплексу относится и различная экипировка для спортсменов, которой присвоен свой код, время проката, цена и т.п.
Так, например, главная таблица содержит в себе информацию о всех услугах, предоставляемых горнолыжной базой (прокат экипировки, инструкторы, трансфер и т.п.).
После того как клиент получает свою индивидуальную карточку, он может начинать выбирать для себя интересующие его развлечения, либо услуги. В память этой карты вносятся услуги (код услуги) и подсчитывается совокупная стоимость заказанных услуг.
Невозможно управлять горнолыжным комплексом без четко функционирующей базы данных. Ведь с помощью неё можно заметно облегчить себе работу т.к. в правильно созданной базе данных с удобным интерфейсом можно достаточно быстро найти, либо исправить, нужные данные.
Рисунок 2.1 — Схема данных в СУБД Access
Существует некоторый горнолыжный комплекс, занимающийся предоставлением услуг. Услуги имею определенные характеристики, такие как: наименование, единица измерения, время пребывания, количество и т.п. Предоставленная услуга имеет свою номинальную стоимость и сама база имеет свои ресурсы.
Концептуальная модель базы данных имеет следующий вид:
- Таблица «Главная» включает в себя такие поля как: Код операции; Услуга; Время работы.
Таблица «Прокат (прокат)» включает в себя такие поля как: Наименование; Стоимость руб/ч.; Код услуги (прокат); Код операции.
Таблица «Склоны» включает в себя такие поля как: Название; Уровень сложности; Номер подъемника; Состояние трассы; Номер склона.
Разработка базы данных для предметной области «Музей»
... для ввода данных, отчетов, запросов Автоматизация работы с созданной БД Решение этих задач предусматривает создание базы данных музея. На основе ... поля разных записей образуют столбец таблицы. Создав одну таблицу, вы уже получаете полноценную базу данных. Однако в реальной жизни структуры баз данных, ... сущности. В данном курсовом проекте ER-модель имеет связь типа один-ко-многим. Таблица 1 - Объекты ...
Таблица «Инструкторы» включает в себя такие поля как: ФИО; Стаж; Стоимость; Код услуги (инструктор); Код операции; Возраст.
база горнолыжный курорт отчет
Таблица «Услуга (трансфер)» включает в себя такие поля как: Услуга; Трансфер; Уровень комфорта; Стоимость; Код услуги (трансфер); Код операции.
Таблица «Прокат (экипир)» включает в себя такие поля как: Наименование; Стоимость руб/ч.; Код услуги (экипировка); Код операции.
Таблица «Подъемник» включает в себя такие поля как: Номер подъемника; Тип подъемника; Номер склона; Стоимость подъема (руб/ч.); Код услуги (подъемник); Код операции.
Таблица «Код операции» включает в себя такие поля как: Код заказа; Код карты; Код услуги (прокат); Код услуги (экипир); Код услуги (инструктор); Код услуги (подъемник).
Таблица «Склон-Трансфер» включает в себя такие поля как: Номер склона; Код услуги (трансфер).
Таблица «Клиенты» включает в себя такие поля как: ФИО клиента; Номер телефона; Возраст; Код карты.
Для каждой сущности выбран ключ — атрибут, значения которого однозначно идентифицируют кортеж:
Таблица «Главная» — ключевое поле «Код операции»
Таблица «Прокат (прокат)» — ключевое поле «Код услуги (прокат)»
Таблица «Склоны» — ключевое поле «Номер склона»
Таблица «Инструкторы» — ключевое поле «Код услуги инструктор»
Таблица «Услуга (трансфер)» — ключевое поле «Код услуги (трансфер)»
Таблица «Прокат (экипир)» — ключевое поле «Код услуги (экипировка)»
Таблица «Подъемник» — ключевое поле «Код услуги (подъемник)»
Таблица «Код операции» — ключевое поле «Код заказа»
Таблица «Склон-Трансфер» — ключевое поле «Номер склона»
Таблица «Клиенты» — ключевое поле «Код карты»
Все ключевые поля являются идентификационным номером, что облегчает работу с данными.
Все таблицы связаны между собой. Все связи таблиц, как видно из схемы, имеют различные отношения:
Например, между таблицей «Главная» и почти всеми остальными таблицами осуществляется связь «один ко многим» так как ключевое поле «Код операции» связывает поля с идентичным названием в других таблицах. С помощью этого можно осуществлять контроль над тем, какие именно операции проводятся в той или иной отрасли.
Самая основная таблица «Код операции». Она имеет связь с другими таблицами «многие к одному». Эта таблица является учетной, так как в ней указывается код карты клиента и соответственно, все выбранные клиентом услуги.
Остальные таблицы лишь информационные и содержат информацию либо об отдельной услуге, операции или о клиентах.
Предполагается также решение следующих задач:
- получение информации об определенной услуге;
- получение информации о персонале;
- получение информации о клиентах;
- получение информации об совершенных сделках;
- ввод данных в таблицы;
- удаление данных из таблиц.
Реляционная база данных состоит из отношений, структура которых определяется с помощью особых методов, называемых нормализацией.
Международный рынок услуг
... международного рынка услуг; Рассмотреть направления совершенствования развития международного рынка услуг. Объект исследования: международный рынок услуг. Предмет исследования: экономические отношения, возникающие в процессе функционирования международного рынка услуг. Структура курсовой работы ... и внешнеэкономических операций. Крайней неопределенностью отличается и само понятие "услуга". При ...
Эти отношения обладают следующими характеристиками:
- отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;
- каждая ячейка отношения содержит только одно элементарное (неделимое) значение;
- каждый атрибут имеет уникальное имя;
- значения атрибута берутся из одного и того же домена;
- каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;
- порядок следования атрибутов не имеет значения;
- теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним)
набор возможных значений для данной позиции отношения определяется множеством, или доменом, на котором определяется эта позиция. В таблице все значения в каждом столбце должны происходить от одного и того же домена, определенного для данного атрибута;
- во множестве нет повторяющихся элементов. Аналогично, отношение не может содержать кортежей-дубликатов;
- поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.
Реляционная база данных может состоять из произвольного количества нормализованных отношений. Общепринятое обозначение реляционной схемы включает имя отношения, за которым (в скобках) располагаются имена атрибутов. При этом первичный ключ (обычно) подчеркивается.
Достоинствами реляционной модели данных являются простота, гибкость структуры, удобство реализации на компьютере, высокая стандартизация и использование математического аппарата реляционной алгебры и реляционного исчисления.
К недостаткам можно отнести атомарность, ограниченность и предопределенность набора возможных типов данных. Это затрудняет использование реляционных моделей для некоторых современных приложений. Названная проблема решается расширением реляционных моделей в объектно-реляционные.
В объектно-реляционной модели отдельные записи базы данных представляются в виде объектов. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Объектно-ориентированные модели сочетают особенности сетевой и реляционной моделей и используются для создания крупных БД со сложными структурами данных.
В реляционной модели все данные представляются как факты о сущностях и связях, это и понимают под основными свойствами. Сущность — это, например, человек, место, вещь, событие, концепция, о которых хранится информация. Сущности именуются обычно существительными, такими как «покупатель», «компьютер», «служащий», «продажа».
Более точно, сущность — это множество индивидуальных объектов — экземпляров, причем все эти объекты являются различными.
Связь — это функциональная зависимость между сущностями. Например, «служащий» совершает «продажи».
Каждая сущность обладает атрибутами. Атрибут — это свойство объекта, характеризующее его экземпляр. Сущность «служащий» может иметь атрибуты «имя», «дата рождения» и т.д.
Новый маршрут как форма повышения конкурентоспособности турфирмы ...
... санаторный и индивидуальный режимы. Общекурортный режим распространяется на всю территорию курорта и реглам ... и Шафраново климатолечебные и кумысолечебные. Расположены в предгорьях на возвышенных плато. Растительность представлена лиственными и смешанными лесами. ... время и после пребывания на курорте. Важнейший принцип санаторно-курортного лечения - его комплексность, т. е. использование разнообразных ...
Общепринятым видом графического изображения реляционной модели данных является ER — диаграмма. На такой диаграмме сущности (таблицы) изображаются прямоугольниками, возможно, соединенными между собой линиями (связями).
Такое графическое представление облегчает восприятие структуры базы данных по сравнению с текстовым описанием.
Различают целостность по сущностям и целостность по ссылкам. В целостности по сущностям не разрешается, чтобы какой-либо атрибут, участвующий в первичном ключе базового отношения принимал неопределенные значения.
Базовые отношения — это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.
Целостность по ссылкам основана на понятии внешнего ключа.
Пусть даны отношения R1 и R2. Пусть k1, — это первичный ключ отношения R1.
Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 — это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.
Достоинствами реляционного подхода являются:
- Наличие простого, и в тоже время мощного математического аппарата
- Возможность навигационного манипулирования данными без знания физических основ хранения данных.
Чтобы база данных была надежной, необходимо чтобы существовала нормализация. Существуют три нормальных формы.
Итак, условия первой нормальной формы:
Определить требуемые элементы данных, потому что они становятся столбцами в таблице. Поместить связанные элементы данных в таблицу.
Гарантировать отсутствие повторяющихся групп данных.
Гарантировать наличие первичного ключа.
Значение всех атрибутов атомарны.
Информационная система находится в первой нормальной форме.
Условия второй нормальной формы:
Отношение в первой нормальной форме.
Независимость первичных ключей и столбцов
Информационная система находится во второй нормальной форме.
Третья нормальная форма является заключительным шагом. Существуют нормальные формы с более высокими порядковыми номерами, но они гораздо сложнее и не обязательно ведут к созданию более эффективной базы данных. В базе данных требуется выбирать компромисс между минимизации избыточности данных и эффективностью.
Условия третьей нормальной формы:
Отношение во второй нормальной форме.
Все поля, не входящие в первичный ключ, зависят от первичного ключа.
Информационная система находится в третьей нормальной форме.
Таким образом, нормализация отношений успешно достигнута.
После нормализации отношений было создано 7 таблиц. Проиллюстрируем эти таблицы в режиме конструктора:
Рисунок 2.2 — Главная таблица в режиме конструктора
Рисунок 2.3 — Таблица «Инструкторы» в режиме
База данных туристической фирмы
... время. Использование баз данных в туристической фирме выступает одним из важнейших направлений повышения эффективности функционирования данных фирмы. Такие базы данных используются для решения определенных задач. Целью курсовой работы является создание и разработка базы данных для работы туристической фирмы, а ...
Рисунок 2.4 — Таблица «Клиенты» в режиме
Рисунок 2.5 — Таблица «Код операции» в режиме
Рисунок 2.6 — Таблица «Подъемник» в режиме
Рисунок 2.7 — Таблица «Прокат (прокат)» в режиме
Рисунок 2.8 — Таблица «Прокат (экипировка)» в режиме конструктора
Рисунок 2.9 — Таблица «Склон — Трансфер» в режиме
Рисунок 2.10 — Таблица «Склоны» в режиме
Рисунок 2.11 — Таблица «Услуга (трансфер)» в режиме
Дизайн разработан на основе понятия о «диалоговых окнах». Существует главное окно, или так называемая «Главная кнопочная форма». Открыв ее, пользователю предлагаются следующие действия:
- посмотреть отчеты;
- ввести информацию в таблицы;
На рисунке ниже предоставлено диалоговое окно Главной кнопочной формы:
Рисунок 3.1 Окно «Главная кнопочная форма»
Переход по вкладке «Отчеты»:
Рисунок 3.2 Просмотр отчетов
Если перейти по вкладке «Отчеты», то откроется диалоговое окно, в котором будет две другие вкладки: «Список инструкторов» и «Отчет по стоимости услуг». При переходе на вкладку «Список инструкторов» открывается диалоговое окно со списком инструкторов, упорядоченном по фамилиям. Продемонстрирую работу формы:
Рисунок 3.3 Переход к отчету «Список инструкторов»
При переходе на вкладку «Отчет по стоимости услуг» открывается диалоговое окно со списком инструкторов, упорядоченном по фамилиям.
Рисунок 3.4 Переход к отчету по стоимости услуг
Рисунок 3.5 Кнопочная форма в таблице Switcboard Items
В таблице «Switcboard Items» отображены все данные о создании кнопочной формы.
Благодаря созданию кнопочной формы, база данных горнолыжного курорта значительно упрощает работу пользователя и делает ее более понятной.
Следующая форма нужна для нахождения кода заказа клиента. Простым пролистыванием страниц можно переключать клиентов и просматривать код клиента и код его заказа. Таким образом, можно с легкостью найти заказ нужного клиента:
Рисунок 3.6 Форма «Идентификационный код заказа клиента»
Массовые праздники как форма организации досуга населения
... .Выявить этапы организации массовых мероприятий. Объект исследования Предмет: особенности формирования и влияния массового праздника на общественное сознание. Глава 1. Массовые праздники: элементы и ... совершенствование воспитательного влияния массовой культурно-просветительной работы невозможно без более конкретного исследования потребности в празднике и создания на ее основе праздничного календаря ...
Рисунок 3.7 Форма в режиме конструктора
Форма «Идентификационный код заказа клиента» была создана в режиме конструктора с помощью выбора нужных строк из таблиц. Эти таблицы связаны друг с другом логической цепочкой, поэтому при подстановке данных строк в конструктор мы в итоге получаем нужный нам результат.
Форма «Склоны» идентифицирует номера склонов и трансфер на данный склон. Суть в том, что у каждого склона есть свой собственный транспорт, который доставляет людей на данный склон. Поэтому, чтобы приехать на нужный склон нам нужно знать какой трансфер ему соответствует. Поэтому для удобства была создана форма «Склоны» с которой можно ознакомиться ниже:
Рисунок 3.8 Форма «Склоны»
Теперь посмотрим создание данной формы в режиме конструктора (Рисунок 3.9).
С помощью дополнительной формы (Склон-Трансфер) и таблицы «Склоны» (Рисунок 2.10) была создана данная форма:
Рисунок 3.9 Форма «Склоны» в режиме конструктора
В любой базе данных для эффективности работы создаются формы. Чтоб конкретно знать результаты проделанной работы за определенный период времени, надо проводить подсчеты. Но в нашем случае все намного проще, когда можно создать формы.
Для удобства просмотра информации в базах данных создаются зачеты. В кнопочной форме были представлены два отчета о создании которых будет так же сказано в данном пункте.
Демонстрацию отчетов можно посмотреть в первом пункте третьей главы (Рисунок 3.3, Рисунок 3.4).
С данными отчетами в режиме конструктора можно ознакомиться по рисункам, представленным ниже:
Рисунок 3.10 Отчет по стоимости услуг в режиме конструктора
=Date (),=Time ())
) . В данном отчете вычисляется суммарная стоимость услуги за час (вычисление суммарной стоимости вычисляется с помощью формулы =Sum ([Оклад])) и средняя стоимость услуги за час (вычисление средней стоимости вычисляется с помощью формулы =Avg ([Оклад]) ).
Рисунок 3.11 Отчет «Список инструкторов» в режиме
Данный отчет не особенно отличается от предыдущего. Данные были взяты так же из трех таблиц «Инструкторы», «Главная» и «Код операции» (Рисунок 2.3, Рисунок 2.2, Рисунок 2.5 соответственно).
Данный отчет нужен для просмотра реально работающих инструкторов в горнолыжном комплексе.
Благодаря созданию запросов можно значительно упростить поиск нужной информации в созданной базе данных.
В данной главе будет продемонстрирована работа некоторых из созданных запросов.
Программы для работы с архивами данных
... столько архиваторов и все для одной цели - сжимать размер файла. Различные программы различаются форматом файлов архива, скоростью работы, степенью сжатия файлов при их вставке в архив и простотой ... Более изощренный метод сжатия данных, используемый в том или ином виде практически любым архиватором, - это так называемый оптимальный префиксный код и, в частности, кодирование символами переменной ...
Следующий запрос выводит имена клиентов, которые начинаются на букву «М», их номера телефонов и возраст. В основе запроса данные из таблицы «Клиенты» (Рисунок 2.4):
Рисунок 3.12 Запрос «Клиенты на букву «М»»
Благодаря условию отбора (Like «M”) ФИО клиентов отображается только с условием, что все фамилии начинаются на букву «М».
Рисунок 3.13 Запрос «Клиенты на букву «М»» в режиме конструктора
Следующий запрос был создан для того, чтобы по коду услуги (инструктор) можно было определить: каких именно клиентов обслуживает данный инструктор. При выборе данного запроса выводится диалоговое окно, в которую следует ввести идентификационный код инструктора, после выводится следующее окно:
Рисунок 3.14 Запрос «Инструктор-Клиент»
Запрос «Инструктор-Клиент» был создан с помощью использования логических взаимосвязей. С данным запросом в режиме конструктора можно ознакомиться ниже:
Рисунок 3.15 Запрос «Инструктор-Клиент» в режиме
В Access при обращении к БД также применяется язык SQL (Access изнутри организован по системе «клиент-сервер»).
Любой запрос, построенный с помощью мастера или конструктора, имеет соответствующее представление на языке SQL. Конструктор — лишь визуальное средство для создания запросов. В Access имеется возможность редактировать запросы непосредственно в режиме SQL. Причем, не всякий составленный на SQL запрос, может быть отображен в режиме конструктора — SQL имеет более широкие возможности, чем визуальный
Для запроса была выбрана таблица «Код услуги (экипир)». Сам запрос идентифицирует код услуги — экипировка и выводит на экран информацию о том, сколько раз клиенты заказали данную услугу. Для успешного функционирования бизнеса нужно всегда знать и предугадывать желания потребителя. Для демонстрации этого правила и был создан данный запрос. С работой данного запроса можно ознакомиться ниже:
Рисунок 3.7 Запрос «Количество клиентов»
Запрос был создан с помощью синтаксиса SQL. Продемонстрирую запрос «Количество клиентов» в режиме SQL:
Принято считать, что использование концепции баз данных позволяет:
- повысить надежность, целостность и сохранность данных;
- сохранить затраты интеллектуального труда;
- обеспечить простоту и легкость использования данных;
- обеспечить независимость прикладных программ от данных (изменений их описаний и способов хранения);
- обеспечить достоверность данных;
- обеспечить требуемую скорость доступа к данным;
- стандартизовать данные в пределах одной предметной области;
- автоматизировать реорганизацию данных;
- обеспечить защиту от искажения и уничтожения данных;
- сократить дублирование информации за счет структурирования данных;
- создать предпосылки для создания распределенной обработки дaнныx.
Данные распределены по таблицам, которые связаны между собой не только «физически» (с помощью инструментов программирования), но и логически. Базируясь на логической связи таблиц между собой, строится запрос к базе данных, который как по цепочке вытаскивает нужную нам информацию в единую «выписку».
Разработка базы данных для санатория
... данных? Подобные базы данных способны хранить самую различную информацию, например: информацию о клиентах/заказчиках; каталог товаров/услуг; отчеты персонала; статистическую информацию; Объектом работы является некоторый курортный санаторий. Целью проекта является процесс разработки ...
Базы данных удобно использовать в различных организациях, и горнолыжный курорт — не исключение. Для горнолыжного курорта характерна высокая степень отчетности. Учитывая значительный объем и темпы оборота, специфические требования к его хранению и реализации, здесь очень важно наладить быстрый и качественный сбор, обработку и анализ информации. Создание базы данных на горнолыжном курорте позволит собрать все данные в одном месте и организовать доступ к ним всем сотрудникам, а также клиентам, позволит вести четкий структурированный учет всей информации, предоставит быстрый доступ к ней, поможет автоматизировать стандартные процессы и в результате всего оптимизирует работу курорта.
В данной работе использовались такие объекты, как: таблицы, запросы, формы, отчеты, макросы. Но программа Microsoft Office Access 2003 намного обширней, разнообразней и имеет больше возможностей. Например, для создания запросов можно использовать структурированный язык SQL, можно подготовить данные для Интернета и т.п. Поэтому, конкретный вывод о применимости Access можно сделать только после ее всестороннего анализа, что выходит за рамки данной курсовой работы.
В итоге, на основании задачи, поставленной в работе, разработана база данных горнолыжного курорта, готовая к использованию. Но, как и всякое другое программное средство, она может быть дополнена и редактирована.
1. Вейкас Д. Эффективная работа с Microsoft Access 2/: Перев. с англ. — СПб.: Питер, 1995. — 864 с.: ил.
- Карпова Т.С. Базы данных: модели, разработка, реализация/: — СПб.: Питер, 2001. — 304 с.: ил.
- Манфред Х., Шпильман К.
Access: сотни полезных рецептов/: пер. с нем. — К.: BHV, 1997. — 400 с.
- Аблязов В.И., Редько С.Г. Проектирование баз данных в среде Microsoft Office Access 2003. Методические указания по выполнению лабораторных работ/: — Москва:
- Гончаров А.Ю., Access 2003.
Самоучитель с примерами/: Электронная версия. — Кудиц-образ: 2004. — 272 с.
- Симонович С.В., Евсеев Г.А., Специальная информатика: Учебное пособие/: — М.: АСТ-ПРЕСС: Инфорком-Пресс: 2000. — 163с.
- Мейер М.Н., Теория реляционных баз данных/: — М.: Мир: 1987.
— 145с.
- Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем/: — М.: Финансы и статистика: 1989. — 251с.
- Бакаревич Ю.Б., Пушкина Н.В.
Самоучитель Microsoft Access 2002/: — СПб.: БХВ-Петербург: 2002. — 276с.
- Григорьев В.А., Ревунков В.И. Банки данных. Учебник для вузов/: — М., МВТУ им. Баумана: 2002. — 304с.
