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

ГОУ ВПО «Уральский государственный технический университет – УПИ»

Кафедра «Интеллектуальные информационные технологии»

Дисциплина «Информатика»

База данных «Туристическая фирма»

Пояснительная записка к курсовой работе

Вариант № 17

Преподаватель ______________________ Кармацкий А.Н.

(подпись преподавателя)

Студентка ______________________ Куприянова В.Н.

(подпись студентки)

Группа: Х-110802

Дата сдачи ____________

Екатеринбург 2012

СОДЕРЖАНИЕ

1. Характеристика предметной области. 3

2. Создание таблиц. 5

2.1 Разработка структуры БД 5

2.2 Структура и создание таблиц 7

2.2.2 Нормализация базы данных 11

2.2 Оперирование данными 12

2.3.1 Создание запросов 12

4 Библиографический список 20

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

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

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

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

список атрибутов сущностей;

описание взаимосвязей между сущностями.

После анализа предметной области мы выделили три сущности: «Клиент» , «Путевка», «Заказ». (Таблица 1)

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

Примечания:

1. Указывается наличие или отсутствие заграничного паспорта. В поле «тип данных» выбираем тип данных «логический (да/нет)».

2. Постоянным клиентам предоставляется скидка.

Определим типы связей и построим начальную ER-модель данных (Рисунок 1.1).

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

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

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

3. Далее необходимо создать внешние ключи, обеспечивающие ссылочную целостность, по указанному типу связи в ER-модели.

Вполне возможно, что в ER-схеме будет присутствовать избыточность данных, поэтому необходимо нормализировать базу данных, как минимум, до нормальной формы Бойса-Кодда (Таблица 4).

3. В физической модели каждой сущности будет соответствовать таблица базы данных, а каждому атрибуту – поле таблицы. (Таблицы 5,6)

2. Создание таблиц.

2.1 Разработка структуры бд

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

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

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

- Не должно быть повторений и между таблицами.

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

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

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

- Каждое поле должно быть связано с темой таблицы.

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

- В таблице должна присутствовать вся необходимая информация.

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