Проектирование БД «Реэлтовское агенство» в среде БД MS Access
МИНОБРНАУКИ РОССИИ
ФГБОУ ВО «Тульский государственный университет»
Кафедра «Вычислительная техника»
Дисциплина «Базы данных»
КУРСОВАЯ РАБОТА
СОЗДАНИЕ БД «РИЭЛТОВСКОЕ АГЕНСТВО»
Проверил:
Тула 2016
Содержание
Введение 3
1 Проектирование базы данных
1.1 Описание предметной области 4
1.2 Инфологическое проектирование
1.3 Даталогическое проектирование
1.4 Проектирование БД «Реэлтовское агенство» в среде БД MS Access 5
2 Проектирование приложения
2.1 Постановка задачи 7
2.2 Формализация задачи 7
2.3 Схема решения задачи 8
3 Руководство пользователя
3.1 Архитектура программно-
3.2 Характеристика приложения 9
3.3 Руководство пользователя 9
Заключение 20
Список использованной литературы 21
Приложение 1. Листинг программы
Приложение 2. Описание компонентов, использованных при создании приложения
Введение
Базы данных – совокупность данных, организация по определенным правилам, предусматривающая общие принципы описания, хранения, манипулирования данными, независимыми от прикладных программ.
СУБД – система управления базами данных – совокупность программ, предназначенных для управления БД и возможности получения пользователями необходимой информации из базы. В задачи СУБД входят следующее:
- Формирование и поддержание БД
- Обработка информации
- Прием запросов
- Предоставление информации пользователям
- Обеспечение целостности и реорганизации ценностей БД
- Организация совместной работы пользователей
На сегодняшний день существует множество различных систем управления базами данных. Они все используют разные средства и функции, но преимущественно у всех СУБД в основе лежат одинаковые понятия. Поэтому для обобщения этих понятий, приемов и методов на весь класс СУБД, я хотел бы взять программу, входящую в Microsoft Office, Microsoft Access.
Microsoft Access – реляционная СУБД, в
которой предусмотрены все
Access – функционально полная система, имеющая мощные средства для работы в этой программе. Ее преимуществом перед другими является простота, наличие всех средств для успешной обработки и управления БД.
1. Создание базы данных
Администрация агентства недвижимости заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о квартирах, которые покупает и продает агентство, расценках на квартиры, расценках на оказываемые услуги, о покупателях и совершенных сделках. Система должна выдавать отчеты по запросу менеджера: прайс-лист на квартиры (возможно с группировкой по различным признакам), на услуги, отчеты по возможным вариантам сделок для покупателей и продавцов.
1.1 Этапы проектирования базы данных
- Определение цели создания базы данных
На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать.
Моя база данных разработана для операций с недвижимостью. Существует таблица о квартирах (таблица Квартиры), которая содержит информацию о квартирах, выставляемых на продажу, о клиентах (таблица Клиенты), для хранения информации о клиентах, об услугах (таблица Услуги), эта таблица содержит информацию обо всех услугах, перечень которых предоставляется клиенту, требованиях к квартирам (таблица Требования к квартирам), эта таблица содержит информацию о требованиях клиентов к покупаемым квартирам.
Остальные таблицы, формы, запросы будут нужны для информационной, правильно, четкой работы. Чтобы можно было узнать, прайс-лист на квартиры, услуги, информацию о клиентах и их сделках, услугах и т.д.
2.Определение таблиц, которые должна содержать база данных.
Один из наиболее сложных этапов в процессе создания базы данных – разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.
Таблицы должны содержать всю информацию разрабатываемой базы. В моем случае это Клиенты, Квартиры, Район, Сделки, Требования к квартирам, Услуги. Все таблицы хранят максимально полную характеристику, информацию и описание для дальнейшей успешной работы с базой данных.
3. Присвоение ключевых полей.
Для связи данных из разных таблиц каждая таблица должна содержать набор полей или поле где будут задаваться индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом. Именно благодаря ключам будут функционировать база данных, сопоставляя, связывая и формируя информацию из разных таблиц. Количество ключей варьируется от одного до нескольких. Вообще, ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.
4.Редактирование структуры базы данных.
Для проверки правильности работы базы необходимо создать несколько таблиц, определить связь между ними и ввести несколько записей в каждую таблицу, а затем посмотреть отвечает ли база данных поставленным требованиям. Рекомендуется также создать черновые выходные отчеты и формы и проверить, выдают ли они требуемую информацию. Кроме того, необходимо исключить всевозможные повторения данных. Иначе база не будет работать и выдавать нужный запрос или информацию или будет работать с ошибками, что для серьезной организации неприемлемо.
5. Добавление данных и создание других объектов базы данных.
Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные ( в режиме конструктора таблиц). После ввода создаются любые запросы, формы, отчеты, макросы и модули (удобнее проще и правильнее создавать все с помощью мастеров).
1.2 Инфологическая модель
Прежде чем начинать проектирование базы данных, необходимо разобраться, как функционирует предметная область создаваемой БД. Для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Вообще лучше сначала нарисовать на бумаге таблицы с данными, потом преобразовать их из 1 Нормальной Формы во вторую, и из Второй – в Третью. Так будет удобнее.
Определяют три основных класса сущностей:
- стержневые
- ассоциативные
- характеристические.
Стержневая сущность –независимая сущность, которая имеет независимое существование, хотя может обозначать другие сущности.
Характеристическая сущность (характеристика) – это связь вида “многие-к-одному” или “одна-к-одной” между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности предметной области.
Ассоциативная сущность (ассоциация) – это связь вида “многие-ко-многим” мужду двумя или более сущностями или экземплярами сущности.
Это теория. Для наглядности покажу на примере соей БД.
С помощью инфологической модели можно наглядно представить сущности, атрибуты сущностей и связи между сущностями. Инфологическая модель может быть создана средствами Erwin или в выбранной студентом инструментальной среде для разработки ER-моделей.
На рисунке 1приведенаERD-модель выбранной предметной области
В модели присутствуют две бинарные и одна тернарная связи. Необходимо обратить внимание на то, что степень связи указывается только для бинарных связей.
Связи между сущностями:
«Сделка» - это тернарная связь, которая связывает сущности «Клиент», «Услуга» и «Квартира». Каждый покупатель может заключать различные сделки на оказание услуг. Это означает, что у покупателя может быть несколько сделок. Клиент может продавать несколько квартир, но квартира принадлежит только одному клиенту и может быть продана только один раз.
Тернарная связь, соединяя три сущности, предполагает наличие кольца при переходе к даталогической модели.
«Имеет» - бинарная связь, которая связывает сущности «Клиент» и «Требования», клиент может иметь несколько различных требований, т.е. хотеть приобрести несколько различных квартир, но требования принадлежат только одному клиенту. (1:М). Класс принадлежности не обязательный для сущности «Клиент» и обязательный для сущности «Требования».
«Расположена» - связывает сущности «Квартира » и «Район», в одном районе может находиться несколько квартир, но квартира может находиться только в одном районе (М:1). Класс принадлежности обязательный.Тернарная связь, соединяя три сущности, предполагает наличие кольца при переходе к даталогической модели.(схема 1)
Схема:Информационно-логическая модель
- Даталогическая модель
После анализа полученной модели выполняется её пошаговое преобразование в реляционную схему по следующим правилам:
1. Каждая простая сущность
2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.
3. Компоненты уникального
4. Связи "многие к одному" (и
"один к одному") становятся
внешними ключами. Для этого делается
копия уникального
5. В таблицах, построенных на
основе ассоциаций, внешние ключи
используются для
6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
- все подтипы размещаются в одной таблице;
- для каждого подтипа строится отдельная таблица.
7. Выполнить шаги по
8. Указать ограничения
9. Создать индексы для
Полученные таблицы и связи могут быть реализованы средствами любой СУБД, например, с помощью приложения DatabaseDesktop создаются таблицы (Таблицы 3.1-3.6).
Таблица 3.1 – Услуги
Название таблицы |
Поле |
Тип |
Размер |
Описание |
Услуги |
Код услуги |
+ (Autoincrement) |
Ключевое поле | |
Наименование услуги |
Alpha |
30 |
||
Цена |
Long Integer |
Таблица 3.2 – Клиенты
Название таблицы |
Поле |
Формат |
Размер |
Описание |
Клиенты |
Код клиента |
+ (Autoincrement) |
Ключевое поле | |
ФИО |
Alpha |
20 |
||
Адрес |
Alpha |
40 |
||
№ паспорта |
Long Integer |
|||
Телефон |
Long Integer |
Таблица 3.3 – Квартиры
Название таблицы |
Поле |
Тип |
Размер |
Описание |
Квартиры |
Код квартиры |
+ (Autoincrement) |
Ключевое поле | |
Кодклиента |
Long Integer |
|||
Количество комнат |
LongInteger |
|||
Площадь |
Long Integer |
|||
Площадькухни |
Long Integer |
|||
Наличие балкона |
LongInteger |
Таблица 3.4 – Район
Название таблицы |
Поле |
Тип |
Размер |
Описание |
Район |
Код района |
+ (Autoincrement) |
Ключевое поле | |
Наименование |
Alpha |
20 |
Таблица 3.5 – Требования к квартирам
Название таблицы |
Поле |
Тип |
Размер |
Описание |
Требования к кв. |
Код требований |
+ (Autoincrement) |
Ключевое поле | |
Кодклиента |
Long Integer |
|||
Количество комнат |
LongInteger |
|||
Площадь |
LongInteger |
|||
Наличие балкона |
Long Integer |
|||
Район |
Long Integer |
Таблица 3.6 – Сделки
Название таблицы |
Поле |
Тип |
Размер |
Описание |
Сделки |
Код сделки |
+ (Autoincrement) |
Ключевое поле | |
Кодклиента |
Long Integer |
|||
Код услуги |
Long Integer |
|||
Код квартиры |
Long Integer |
|||
Дата |
Data |
2.1 Структура моей базы данных
Таблицы.
Моя база данных содержит 6 таблиц:
-Клиенты
- Квартиры
- Услуги
- Требования к квартирам
- Район
- Сделки
Во всех таблицах в режиме конструктора указываются первичные или внешние ключи.
Таблица Клиенты: (код клиента, ФИО, адрес, № паспорта). Этот объект был выделен для хранения информации о клиентах.
Код клиента – индивидуальный код клиента (тип поля счетчик).
Фамилия – Фамилия клиента.
Имя – Имя клиента.
Отчество – Отчество клиента.
Адрес– Место, где проживает клиент.
№ Паспорта – индивидуальный номер паспорта (у каждого свой).
Телефон – номер телефона для связи с клиентом.
Таблица Квартиры:(код квартиры, код клиента, кол-во комнат, площадь , кухня, наличие балкона, этаж, кол-во этажей в доме, адрес , район, цена, дополнительная информация, статус). Объект содержит информацию о квартирах выставляемых на продажу.
Код квартиры – персональный код квартиры (тип поля счетчик).
Код клиента – индивидуальный код клиента.
Кол-во комнат – количество комнат в квартире.
Площадь – Общая площадь квартиры.
Кухня – Общая площадь кухни.
Наличие балкона – количество балкона (1, 2, 3 и.т.д)
Этаж – этаж, на котором расположена квартира.
Кол-во этажей в доме – сколько всего этажей в доме.
Район – Где находится квартира, местоположение (район.)
Адрес – Адрес квартиры.
Цена – цена за квартиру.
Таблица Район:(Код района, наименование). Объект служит для показания место положения квартиры.
Код района – индивидуальный код района (тип поля счетчик).
Наименование– наименование района.
Таблица Сделки: (Код сделки, Код клиента, Код квартиры, Дата). Объект ,который связывает сущности «Клиент», «Услуга» и «Квартира».
Код сделки– индивидуальный код сделки (тип поля счетчик).
Код клиента– индивидуальный код клиента.
Код квартиры –индивидуальный код квартиры.
Дата – дата сделки.
Таблица Требования к квартирам: (код требований, код клиента, кол-во комнат, площадь не меньше, наличие балкона, район, дополнительная информация, статус). Объект содержит информацию о требованиях клиентов к покупаемым квартирам.
Код требований – индивидуальный код требования (тип поля счетчик).
Код клиента – индивидуальный код клиента.
Кол-во комнат – количество комнат в квартире.
Площадь не меньше – площадь не менее (указать).
Наличие балкона– количество балкона (1,2,3 и.т.д).
Район – Где находится квартира, местоположение (район.)
база данные нормализация таблица
Таблица Услуги: (код услуги, наименование услуги, стоимость). Объект содержит информацию обо всех услугах, перечень которых предоставляется клиенту. Код услуги – индивидуальный код услуги (тип поля счетчик). Наименование услуги. Стоимость – Стоимость услуги.
2.2 Нормализация
Нормализация – процесс уменьшения избыточности информации в таблицах реляционной БД и как следствие построение оптимальной структуры таблиц и связей. Можно выделить 4 основных правила, которыми следует руководствоваться при проектировании и последующей нормализации таблиц базы данных:
1. Каждое поле любой таблицы должно быть уникальным.
2. Каждая таблица должна иметь уникальный первичный ключ, который может состоять из одного или нескольких полей таблицы.
3. Для каждого значения
4. Должна иметь возможность изменять значения любого поля (не входящего в первичный ключ), и это не должно повлечь за собой изменения другого поля.
1НФ (Нормальная Форма)
Имя поля |
Тип данных |
Описание |
Код квартиры |
Числовой |
Индивидуальный код квартиры |
Код клиента |
Числовой |
Индивидуальный код клиента |
Количество комнат |
Числовой |
Кол-во комнат клиента |
Площадь |
Числовой |
Площадь комнаты |
Площадь кухни |
Числовой |
Площадь кухни |
Наличие балкона |
Числовой |
Количество балконов |
Адрес |
Текстовый |
Адрес квартиры |
Этаж |
Числовой |
Этаж квартиры |
Кол-во этажей в доме |
Числовой |
Кол-во этажей в доме |
Цена-квартиры |
Денежный |
Цена квартиры |
Фамилия |
Текстовый |
Фамилия |
Имя |
Текстовый |
Имя |
Отчество |
Текстовый |
Отчество |
Адрес-клиента |
Текстовый |
Адрес-клиента |
№ Паспорта |
Числовой |
№ Паспорта |
Телефон |
Числовой |
Телефон |
Код сделки |
Числовой |
Индивидуальный код сделки |
Код услуги |
Числовой |
Индивидуальный кодуслуги |
Дата |
Дата/время |
Дата |
Код требований |
Числовой |
Совершение покупки |
Количество комнат-т |
Числовой |
Количество комнат - требование |
Площадь-т |
Числовой |
Площадь- требование |
Наличие балкона-т |
Числовой |
Наличие балкона - требование |
Код района-т |
Числовой |
Код района - требование |
Наименование услуги |
Текстовый |
Наименование услуги |
Цена-услуги |
Денежный |
Цена |
2НФ:
Выполняются ограничения 1НФ, и каждый не ключевой атрибут функционально полно зависит от составного первичного ключа.
3 НФ: Все не ключевые атрибуты
отношения взаимно независимы
и полностью зависят от
Таким образом база данных удовлетворяет всем требованиям нормализации таблиц и Третья нормальная форма – окончательный результат нормализации моей Базы данных.
После анализа и нормализации система предложила вариант разбиения на 6 таблиц:
2.3 Схема данных
Отношения – это правила, поддерживаемые на уровне механизма реализации СУБД. Различают три типа отношений:
- Отношение «один-к-одному»: для каждой строки в одной таблице существует не более одной строки связанной таблицы.
- Отношение «один-ко-многим»: одна таблица не содержит вообще или имеет набор связанных «дочерних» записей из другой таблицы.
- Отношение «многие-ко-многим»: для каждой строки первой таблицы может существовать набор строк в другой таблице и наоборот. Такая связь организуется, как правило, при помощи третьей связующей таблицы, содержащей значения первичных ключей обеих таблиц в качестве внешних ключей.
При разработке БД необходимо принимать во внимание правила обеспечения целостности данных (обеспечивает каскадное обновление записей в связанных таблицах).
3. Создание пользовательского интерфейса
3.1 Запросы
В моей БД содержатся 10 запросовразличных типов.
Запросы бывают:
- запрос на обновление
- запрос на удаление
- запрос на выборку
- запрос на создание.
Ниже я опишу каждый из своих запросов.
Запрос «Поиск Квартир по количеству комнат»
Данный запрос при выполнении осуществляет поискквартир, в которых содержится определенное количество комнат и выдает всю информацию.
Данные для этого запроса берутся из таблицы Квартиры.
В режиме SQL запрос выглядит так:
SELECT Квартиры.[Код квартиры], Квартиры.[Код клиента], Квартиры.[Количество комнат], Квартиры.Площадь, Квартиры.[Площадь кухни], Квартиры.[Наличие балкона], Квартиры.[Код района], Квартиры.Адрес, Квартиры.Этаж, Квартиры.[Кол-во этажей в доме], Квартиры.Цена
FROM Квартиры
WHERE (((Квартиры.[Количество
Вводим количество комнат. Например: 3. Происходит вывод на экран.
Выдается вся информация о квартирах, которая содержит Количество комнат равное 3.
Запрос «Поиск клиентов по адресу»
Данный запрос осуществляет поиск клиентов, у которых совпадает адрес их проживания.
Данные для этого запроса берутся из таблицы Клиенты.
В режиме SQL запрос выглядит так:
SELECT Клиенты.[Код клиента], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Адрес, Клиенты.[№ Паспорта], Клиенты.Телефон
FROM Клиенты
WHERE ((([Клиенты].Адрес)=[Введите
Вводим адрес клиента (где проживает клиент).
Выдается вся информация о клиенте, который проживает по указанному адресу.
Запрос «Поиск Клиентов по фамилии»
Данный запрос осуществляет поискклиентапо фамилии.
Данные для этого запроса берутся из таблицы Клиенты.
В режиме SQL запрос выглядит так:
SELECT Клиенты.[Код клиента], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Адрес, Клиенты.[№ Паспорта], Клиенты.Телефон
FROM Клиенты
WHERE (((Клиенты.Фамилия)=[Введите фамилию]));
Вводим фамилию для поиска клиента.
Выдается вся информация о клиенте, фамилия которого была указана в запросе.
Запрос «Поиск по требованиям клиента»
Данный запрос осуществляет поиск квартиры по требованию клиента.
Данные для этого запроса берутся из таблицы Квартиры.
В режиме SQL запрос выглядит так:
SELECT *
FROM Квартиры
WHERE (((Квартиры.[Количество
Запрос «Поиск Сделки по дате больше указанной»
Данный запрос выводит сделки по дате больше указанной.
Данные для этого запроса берутся из таблицы Сделки.
В режиме SQL запрос выглядит так:
SELECT Сделки.[Код сделки], Сделки.[Код клиента], Сделки.[Код услуги], Сделки.[Код квартиры], Сделки.Дата
