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

Содержание

• Введение
• 1. Системный анализ и анализ требований к базе данных
• 2. Концептуальная (инфологическая) модель предметной области
• 3. ERD-диаграмма
• 4. Физическая модель проектируемой базы данных в методологии IDEF1X
• 5. Создание форм, запросов и отчетов в среде СУБД Visual FoxPro 8.0
• Заключение

Введение

В современном мире распространены различные виды развлечений, в том числе и путешествия в различные страны и по нашей стране так же. Люди хотят провести свой отпуск как можно ярче, что бы остались приятные впечатления. Собираясь в другие страны необходимо оформить определенные документы (виза, загранпаспорт). На это необходимо потратить и время, и силы. А зачем мучиться, когда есть туристические фирмы, которые с радостью сделают все за вас? Услуги таких агентств и фирм пользуются широкой популярностью.

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

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

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

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

Задачами курсового проекта будут являться:

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

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

1. Системный анализ и анализ требований к базе данных

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

Но проблема в том, что используемые программные средства не являются специализированными, часто это Excel, Access и Word. А если фирма имеет сеть филиалов в одном городе, то обеспечение сетевой работы практически не ведется.

Создание специализированной базы значительно упростило бы работу менеджера.

Входной информацией для данной базы может быть:

1. Сведения о клиентах:

· Код клиента

· Фамилия Имя Отчество

· Серия и номер паспорта

· Дата оформления договора

2. Сведения о путевках:

· Код путевки

· Код курорта

· Код номера

· Код услуги

· Продолжительность

· Дата, с которой путевка действительна ("Дата начала")

· Стоимость путевки всего

3. Сведения о курортах:

· Код курорта

· Название

· Расположение

· Страна

· 4. Сведения о номерах:

· Код номера

· Количество мест

· Тип номера

· Стоимость в сутки

5. Сведения об услугах:

· Код услуги

· Загранпаспорт

· Виза

· Стоимость визы

· Стоимость страховки

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

2. Концептуальная (инфологическая) модель предметной области

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

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

Основными объектами концептуальной модели являются сущности и связи.

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

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

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

На концептуальном уровне данные информационной системы состоят из двух основных сущностей "Клиенты" и "Путевки".

Состав атрибутов для этих сущностей и их описание представлены в таблицах 1 и 2.

Таблица 1 - Атрибуты сущности "Клиенты"

Имя атрибута	Описание
Код клиента	Первичный ключ, однозначно идентифицирующий клиента туристической фирмы.
Фамилия Имя Отчество	Фамилия Имя Отчество клиента.
Серия и номер паспорта	Документ (в данном случае паспорт), его серия и номер.
Дата оформления договора	Дата, когда клиент оформил путевку.
Код путевки	Внешний ключ к сущности "Путевки". Код путевки, которая оформлена на клиента.
Комментарии	Характеристика клиента по своевременной оплате путевки или услуг. Возможна и другая информация. Например, особенности по здоровью или его пожелания.

Таблица 2 - Атрибуты сущности "Путевки"

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

В таблице 3 представлены атрибуты сущности "Курорты".

Таблица 3 - Атрибуты сущности "Курорты"

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

В таблице 4 представлены атрибуты сущности "Номера".

Таблица 4 - Атрибуты сущности "Номера"

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

В таблице 5 находятся атрибуты сущности "Услуги".

база данные диаграмма запрос

Таблица 5 - Атрибуты сущности "Услуги"

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

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

Таблица 6 - Состав базы данных информационной системы.

№	Сущности концептуальной модели	Таблицы физической модели
		Название	Информация
1.	"Клиенты"	klient	Сведения о клиентах фирмы.
2.	"Путевки"	putevka	Сведения о предлагаемых путевках фирмы.
3.	"Курорты"	kurort	Сведения о курортах.
4.	"Номера"	nomer	Номера, которые можно забронировать.
5.	"Услуги"	uslugi	Набор услуг, которые предлагает агентство.

Для создания концептуальной модели выполняются в CASE-средстве методологии IDEF1X с помощью Erwin.

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

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

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

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

Case-средство ERwin поддерживает методологию IDEF1X и стандарт IE (Information engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу "сверху вниз".

Верхний уровень состоит из Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах). Диаграмма сущность-связь определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области.

Нижний уровень состоит из Transforination Model (Трансформационная модель) и Fully Attributed (Полная атрибутивная модель). Трансформационная модель содержит всю информацию для реализации проекта, который может быть частью общей информационной системы и описывать предметную область. Трансформационная модель позволяет проектировщикам и администраторам БД представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям информационной системы. Фактически из трансформационной модели автоматически можно получить модель СУБД, которая является точным отображением системного каталога СУБД.

3. ERD-диаграмма

Первым шагом при создании логической модели БД является построение диаграммы ERD, которая состоит из трех частей: сущностей, атрибутов и взаимосвязей.

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

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



Рисунок 1 - Логическая модель базы данных "TyrFirma"

Далее необходимо определить ключевые атрибуты и типы атрибутов. Типы атрибутов представлены в таблице 7.

Таблица 7 - Типы атрибутов, использованные в базе данных "TyrFirma"

Атрибут	Тип
Код клиента	Number
Код путевки	Number
Фамилия Имя Отчество	String
Серия и номер паспорта	Number
Дата оформления договора	Date
Комментарии (о клиенте)	String
Продолжительность	Number
Дата начала	Date
Стоимость путевки всего	Number
Код курорта	Number
Название	String
Расположение	String
Страна	String
Характеристика (о курорте)	String
Код номера	Number
Количество мест	Number
Тип номера	String
Стоимость в сутки	Number
Адрес гостиницы	String
Характеристика (о номере)	String
Код услуги	Number
Загранпаспорт	Number
Виза	String
Стоимость визы	Number
Стоимость страховки	Number

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

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

В модели каждая сущность или атрибут идентифицируется с помощью имени. В ERwin поддерживает корректность имен следующим образом:

* отмечает повторное использование имени сущности и атрибута;

* не позволяет внести в сущность более одного внешнего ключа;

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

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

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

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

4. Физическая модель проектируемой базы данных в методологии IDEF1X

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

Трансформационная модель

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

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

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

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

Модель СУБД

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

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

Таблица 8 - Сопоставление компонентов логической и физической модели

Логическая модель	Физическая модель
Сущность	Таблица
Атрибут	Столбец
Логический тип (текст, число, дата, blob)	Физический тип (конкретный тип, зависящий от выбранной СУБД)
Первичный ключ	Первичный ключ, индекс PK
Внешний ключ	Внешний ключ, индекс FK
Альтернативный ключ	AK - индекс - уникальный, непервичный индекс
Правило бизнес-логики	Триггер или сохраненная процедура
Взаимосвязи	Взаимосвязи, определяемые использованием FK-атрибутов

Получим физическую модель, сгенерированную ERwin. Данная модель изображена на рисунке 2.

Рисунок 2 - Физическая модель базы данных "TyrFirma"

В полученной модели необходимо организовать типы и размеры полей, результат отображен в таблице 9.

Таблица 9 - Свойства колонок таблиц физической модели базы данных "TyrFirma"

Атрибут	Тип	Размер	Правило валидации
Код клиента	Numeric	4	<2000
Код путевки	Numeric	4	<6000
Фамилия Имя Отчество	Character	27
Серия и номер паспорта	Numeric	11
Дата оформления договора	Date
Комментарии (о клиенте)	Memo
Продолжительность	Numeric	3	< 60 суток
Дата начала	Date
Стоимость путевки всего	Numeric	10,2
Код курорта	Numeric	4	<3000
Название	Character	20
Расположение	Character	30
Страна	Character	10
Характеристика (о курорте)	Memo
Код номера	Numeric	4	<4000
Количество мест	Numeric	1	1 или 2 или 3
Тип номера	Character	13
Стоимость в сутки	Numeric	7,2
Адрес гостиницы	Character	40
Характеристика (о номере)	Memo
Код услуги	Numeric	4	<5000
Загранпаспорт	Numeric	10,2
Виза	Character	15
Стоимость визы	Numeric	10,2
Стоимость страховки	Numeric	10,2

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

После установки правил валидации в диалоговом окне Validation Rule Editor должны получиться следующие правила (рисунок 3).



Рисунок 3 - Правила валидации в ERWin

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

5. Создание форм, запросов и отчетов в среде СУБД Visual FoxPro 8.0

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

Рисунок 4 - Структура и связи базы данных "TyrFirma"

Далее необходимо заполнить таблицы данными.

Рисунок 5 - Таблица о клиентах фирмы

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

Рисунок 6 - Таблица по путевкам, имеющимся у фирмы

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

Рисунок 7 - Таблица о курортах

Рисунок 8 - Таблица о номерах, которые может предложить фирма.



Рисунок 9 - Таблица по услугам фирмы

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

Рисунок 10 - Форма, представляющая путевки на определенные курорты.

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

1. В какие страны поедут клиенты фирмы, оформленные в мае 2007 года? При создании запросов с использованием даты, необходимо обращать внимание на ее формат. В данном случае формат даты - mm/dd/yy. Данные изображены на рисунках 11 и 12.



Рисунок 11 - Условия (фильтр) для выполнения первого запроса.

Рисунок 12 - Данные, полученные по первому запросу.

2. Какие имеются путевки на курорты Египта? Данные изображены на рисунках 13 и 14.

Рисунок 13 - Фильтр для выполнения второго запроса.



Рисунок 14 - Данные, полученные по второму запросу.

3. Какова стоимость номеров "Люкс" на различных курортах? Данные изображены на рисунках 15 и 16.

Рисунок 15 - Фильтр для выполнения третьего запроса

Рисунок 16 - Данные, полученные по третьему запросу.

Чтобы представить запросы в наглядной форме необходимо создать отчеты. Отчеты могут создаваться по имеющимся таблицам или по созданным запросам. На рисунках 17, 18 и 19 представлены отчеты по ранее созданным запросам.



Рисунок 17 - Отчет по первому запросу (Клиенты, оформленные за месяц май)

Рисунок 18 - Отчет по второму запросу (Наличие путевок в Египет)

Рисунок 19 - Отчет по третьему запросу (Стоимость номеров "Люкс")

Заключение

В моей курсовой работе были рассмотрены приемы проектирования и реализации реляционных баз данных и таблиц в СУБД Visual FoxPro 8.0. А так же была создана концептуальная модель предметной области с помощью Case-средства Erwin. Физическая модель проектируемой базы данных в методологии IDEF1X, была спроектирована структура реляционной таблицы, в нее были внесены данные.

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

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

Для внедрения БД "TyrFirma" нужно установить компьютер на рабочем месте менеджера, провести инструктаж по работе с системой, составить подробную инструкцию по работе с БД.

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

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

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

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