Проектирование БД «Реэлтовское агенство» в среде БД MS Access

 

 

МИНОБРНАУКИ РОССИИ

ФГБОУ ВО «Тульский государственный университет»

Кафедра «Вычислительная техника»

 

 

Дисциплина «Базы данных»

 

 

 

 

 

 

 

КУРСОВАЯ РАБОТА

 

СОЗДАНИЕ БД «РИЭЛТОВСКОЕ АГЕНСТВО»

 

 

 

 

 

 

 

 

 

 

 

 

 

Проверил:                

 

 

 

 

 

 

 

Тула 2016

Содержание

Введение 3

1 Проектирование базы данных

1.1 Описание предметной области 4

1.2 Инфологическое проектирование 4

1.3 Даталогическое проектирование 4

1.4 Проектирование БД «Реэлтовское агенство» в среде БД MS Access  5

2 Проектирование приложения

2.1 Постановка задачи 7

2.2 Формализация задачи 7

2.3 Схема решения задачи 8

3 Руководство пользователя

3.1 Архитектура программно-аппаратного  комплекса 9

3.2 Характеристика приложения 9

3.3 Руководство пользователя 9

Заключение 20

Список использованной литературы 21

Приложение 1. Листинг программы 

Приложение 2. Описание компонентов, использованных при создании приложения

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

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

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

• Формирование и поддержание БД
• Обработка информации
• Прием запросов
• Предоставление информации пользователям
• Обеспечение целостности и реорганизации ценностей БД
• Организация совместной работы пользователей

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

Microsoft Access – реляционная СУБД, в  которой предусмотрены все необходимые  средства для определения и  обработки данных, а также управления  ими при работе с большим  объемом информации.

Access – функционально полная система, имеющая мощные средства для работы в этой программе. Ее преимуществом перед другими является простота, наличие всех средств для успешной обработки и управления БД.

 

1. Создание базы данных

 

Администрация агентства недвижимости заказала разработку информационной системы для отдела работы с клиентами. Система предназначена для обработки данных о квартирах, которые покупает и продает агентство, расценках на квартиры, расценках на оказываемые услуги, о покупателях и совершенных сделках. Система должна выдавать отчеты по запросу менеджера: прайс-лист на квартиры (возможно с группировкой по различным признакам), на услуги, отчеты по возможным вариантам сделок для покупателей и продавцов.

 

1.1 Этапы проектирования базы данных

 

1. Определение цели создания базы данных

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

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

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

2.Определение таблиц, которые  должна содержать база данных.

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

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

3. Присвоение ключевых  полей.

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

4.Редактирование структуры  базы данных.

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

5. Добавление данных  и создание других объектов базы данных.

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

 

1.2 Инфологическая модель

 

Прежде чем начинать проектирование базы данных, необходимо разобраться, как функционирует предметная область создаваемой БД. Для этих целей используют искусственные формализованные языковые средства. В связи с этим под инфологической моделью понимают описание предметной области, выполненное с использованием специальных языковых средств, не зависящих от используемых в дальнейшем программных средств. Вообще лучше сначала нарисовать на бумаге таблицы с данными, потом преобразовать их из 1 Нормальной Формы во вторую, и из Второй – в Третью. Так будет удобнее.

Определяют три основных класса сущностей:

• стержневые
• ассоциативные
• характеристические.

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

Характеристическая сущность (характеристика) – это связь вида “многие-к-одному” или “одна-к-одной” между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности предметной области.

Ассоциативная сущность (ассоциация) – это связь вида “многие-ко-многим” мужду двумя или более сущностями или экземплярами сущности.

Это теория. Для наглядности покажу на примере соей БД.

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

На рисунке 1приведенаERD-модель выбранной предметной области

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

Связи между сущностями:

«Сделка» - это тернарная связь, которая связывает сущности «Клиент», «Услуга» и «Квартира». Каждый покупатель может заключать различные сделки на оказание услуг. Это означает, что у покупателя может быть несколько сделок. Клиент может продавать несколько квартир, но квартира принадлежит только одному клиенту и может быть продана только один раз.

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

«Имеет» - бинарная связь, которая связывает сущности «Клиент» и «Требования», клиент может иметь несколько различных требований, т.е. хотеть приобрести несколько различных квартир, но требования принадлежат только одному клиенту. (1:М). Класс принадлежности не обязательный для сущности «Клиент» и обязательный для сущности «Требования».

«Расположена» - связывает сущности «Квартира » и «Район», в одном районе может находиться несколько квартир, но квартира может находиться только в одном районе (М:1). Класс принадлежности обязательный.Тернарная связь, соединяя три сущности, предполагает наличие кольца при переходе к даталогической модели.(схема 1)

 

 

Схема:Информационно-логическая модель  

2. Даталогическая модель

 

После анализа полученной модели выполняется её пошаговое преобразование в реляционную схему по следующим правилам:

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