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

Введение

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

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

· Формирование и поддержание БД

· Обработка информации

· Прием запросов

· Предоставление информации пользователям

· Обеспечение целостности и реорганизации ценностей БД

· Организация совместной работы пользователей

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ стержневые

§ ассоциативные

§ характеристические.

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

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

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

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

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

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

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

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

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

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

«Имеет» - бинарная связь, которая связывает сущности «Клиент» и «Требования», клиент может иметь несколько различных требований, т.е. хотеть приобрести несколько различных квартир, но требования принадлежат только одному клиенту. (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

Таблица 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 (((Квартиры.[Количество комнат])=[:Количество комнат]) And ((Квартиры.Площадь)>=[Площадь_не_меньше]) And (([Наличие балкона])=[:Кол-во балконов]) And (([Этаж])>=[:Этаж не меньше]));

Запрос «Поиск Сделки по дате больше указанной»

Данный запрос выводит сделки по дате больше указанной.

Данные для этого запроса берутся из таблицы Сделки.

В режиме SQL запрос выглядит так:

SELECT Сделки.[Код сделки], Сделки.[Код клиента], Сделки.[Код услуги], Сделки.[Код квартиры], Сделки.Дата

FROM Сделки

WHERE (((Сделки.Дата)>[Введите дату сделки]));

Вводим дату сделки для поиска сделок по дате больше указанной.

Запрос «Поиск Сделки по дате меньше указанной»

Данный запрос выводит сделки по дате меньше указанной.

Данные для этого запроса берутся из таблицы Сделки.

В режиме SQL запрос выглядит так:

SELECT Сделки.[Код сделки], Сделки.[Код клиента], Сделки.[Код услуги], Сделки.[Код квартиры], Сделки.Дата

FROM Сделки

WHERE (((Сделки.Дата)<[Введите дату сделки]));

Вводим дату сделки для поиска сделок по дате меньше указанной.

Запрос «Поиск Сделки по дате равно указанной»

Данный запрос выводит сделки по дате меньше равноуказанной.

Данные для этого запроса берутся из таблицы Сделки.

В режиме SQL запрос выглядит так:

SELECT Сделки.[Код сделки], Сделки.[Код клиента], Сделки.[Код услуги], Сделки.[Код квартиры], Сделки.Дата

FROM Сделки

WHERE (((Сделки.Дата)=[Введите дату сделки]));

Вводим дату сделки для поиска сделок по дате равно указанной.

Запрос «Запрос по фамилии»

Данный запрос выводит клиентов в определенном порядке (по возвраствнию).

Данные для этого запроса берутся из таблицы Клиенты.

В режиме SQL запрос выглядит так:

SELECT Клиенты.[Код клиента], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Адрес, Клиенты.[№ Паспорта], Клиенты.Телефон

FROM Клиенты

ORDER BY Клиенты.Фамилия;

Запрос «Добавление информации клиента»

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

Данные для этого запроса берутся из таблицы Клиенты.

В режиме SQL запрос выглядит так:

INSERT INTO Клиенты ( [Код клиента], Фамилия, Имя, Отчество, Адрес, [№ Паспорта], Телефон )

VALUES ([Код клиента], Фамилия, Имя, Отчество, Адрес, [№ Паспорта], Телефон);

В итоге получаем в таблицу Клиенты еще одного клиента.

Запрос «Удаление клиента по Фамилии»

Данный запрос служит для удаления клиента по его фамилии(удаляются все его данные).

Данные для этого запроса берутся из таблицы Клиенты.

В режиме SQL запрос выглядит так:

DELETE Клиенты.[Код клиента], Клиенты.Фамилия, Клиенты.Имя, Клиенты.Отчество, Клиенты.Адрес, Клиенты.[№ Паспорта], Клиенты.Телефон

FROM Клиенты

WHERE (((Клиенты.Фамилия)=[Введите фамилию клиента]));

У нас существует таблица с клиентами:

Мы хотим удалить клиента Упарова и все его данные. Для этого открываем Запрос на удаление по фамилии и вводим фамилию клиента, которого хотим удалить.



Как видно выше на рисунке клиент Упаров был удален из таблицы Клиенты с последующими его данными.

3.2 Формы

Формы создавать достаточно просто. Для этого в режиме «мастер форм» выбираются значения из таблиц и формируются по усмотрению разработчика базы.

Моя база данных содержит 7 форм:

Форма «Квартиры»

Простая форма, выводящая всю информацию о квартирах, ее стоимости, расположение и.т.д.

Форма «Клиенты»

Выводит всех клиентов, которые нужны для осуществления сделок и услуг.

Форма «Район»

Эта форма позволяет посмотреть район, в котором находится квартира.

Форма «Сделки»

Эта форма выводит клиентов, которые совершают сделки.

Форма «Требования к квартирам»

Выводит требования, которые необходимы для подборки клиента.

Форма «Услуги»

Выводит услуги, которые доступны клиенту.

Форма «Кнопочная форма»

Создана для удобного пользования базой.

3.3 Отчеты

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

Отчет «Прайс-лист на квартиры»



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

Отчет «Прайс-лист на услуги».

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

Отчет «Ведомость для продавцов».



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

Отчет «Ведомость о покупателях совершивших покупку и возможных покупателях».

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



4. Основной интерфейс базы данных

Основным интерфейсом для СУБД MS Access служит главная кнопочная форма. Для ее открытия надо зайти так:

Сервис-Служебные программы-Диспетчер кнопочных форм

При загрузке базы данных открывается Кнопочная Форма.

В ней можно:

· Осуществить поиск

· Добавить данные.

· Изменение данные.

· Посмотреть отчеты.

· Удалить данные.

· Выйти из программы.



Заключение

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

СУБД МS Ассеss является в настоящее время одной из самых популярных среди настольных систем. Среди причин такой популярности следует отметить:

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

- производит поиск данных в таблицах по определенным критериям;

- контролирует ключевые поля;

- создает любые формы отчетов, в которых можно менять содержание и стиль оформления;

- дает возможность пополнять базу данных новыми таблицами и решать новые задачи, т.е. составлять новые отчеты и формы.

Все это позволяет считать Access надежной программой.



Список литературы

Информатика. Базовый курс: Учебник для вузов / Под ред. С.В.Симоновича.-СПб.: Питер, 2007.-640 с.

Хомоненко А. Д. Базы данных: Учебник для вузов / А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев; под ред. А. Д. Хомоненко.-СПб: КОРОНАпринт, 2004.-736 с.;

Робинсон С. MicrosoftAccess 2000: учебный курс. СПб: «Питер». 2000.

Электронный учебник Microsoft Access 7.0.

Лекции БД. УГАТУ, 2006.

Методические указания к лабораторным работам по дисциплине «Информатика»

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

...