- •1. Характеристика предметной области.
- •2. Создание таблиц.
- •2.1 Разработка структуры бд
- •2.2 Структура и создание таблиц
- •2.2.1.Реляционная схема базы данных
- •2.2.2 Нормализация базы данных
- •Оперирование данными
- •2.3.1 Создание запросов
- •2.4Создание форм
- •2.4.1 Создание кнопочной формы
- •2.3.1. Отчеты.
- •3. Заключение
- •4 Библиографический список
- •5. Приложение .
Федеральное агентство по образованию
ГОУ ВПО «Уральский государственный технический университет – УПИ»
Кафедра «Интеллектуальные информационные технологии»
Дисциплина «Информатика»
База данных «Туристическая фирма»
Пояснительная записка к курсовой работе
Вариант № 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. Указывается наличие или отсутствие заграничного паспорта. В поле «тип данных» выбираем тип данных «логический (да/нет)».
Постоянным клиентам предоставляется скидка.
Определим типы связей и построим начальную ER-модель данных (Рисунок 1.1).
Преобразование концептуальной модели в концептуальную схему выбранной реляционной СУБД осуществляется в следующей последовательности.
Для каждой сильной сущности ER-модели создается отдельная таблица, а для каждого атрибута сущности создается столбец таблицы. Ключевой атрибут становится первичным ключом, а дополнительные ключевые атрибуты - потенциальными ключами.
Для каждой слабой сущности также создается отдельная таблица, в которой должны присутствовать ключевые столбцы доминирующих таблиц. В зависимости от вида связи устанавливаются ключевые атрибуты таблицы.
Далее необходимо создать внешние ключи, обеспечивающие ссылочную целостность, по указанному типу связи в ER-модели.
Вполне возможно, что в ER-схеме будет присутствовать избыточность данных, поэтому необходимо нормализировать базу данных, как минимум, до нормальной формы Бойса-Кодда (Таблица 4).
В физической модели каждой сущности будет соответствовать таблица базы данных, а каждому атрибуту – поле таблицы. (Таблицы 5,6)
2. Создание таблиц.
2.1 Разработка структуры бд
Удачная разработка базы данных обеспечивает простоту ее поддержания. Данные следует сохранять в таблицах, причем каждая таблица должна содержать информацию одного типа, например, сведения о поставщиках. Тогда достаточно будет обновить конкретные данные, такие как адрес, только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Одним из наиболее сложных этапов в процессе проектирования базы данных является разработка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы.
При проектировании таблиц лучше разработать структуру на бумаге и только затем начинать работу с СУБД Access. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:
- Не должно быть повторений и между таблицами.
Когда определенная информация храниться только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и фамилии клиентов.
- Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если содержаться они в независимых друг от друга таблицах. Например, адреса и заказы клиентов хранятся в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы. Например, в таблице с данными о поставщиках могут содержаться поля с названием компании, адресом и номером телефона. При разработке полей для каждой таблицы необходимо помнить:
- Каждое поле должно быть связано с темой таблицы.
- Не рекомендуется включать в таблицу данные, которые являются результатом выражения.
- В таблице должна присутствовать вся необходимая информация.
- Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).