Проектирование базы данных "Риелторская контора"

Частное образовательное учреждение среднего профессионального образования

«КРАСНОДАРСКИЙ ТЕХНИКУМ УПРАВЛЕНИЯ, ИНФОРМАТИЗАЦИИ И СЕРВИСА»

Отчет по практике

специальность 230150 «ПО ВТ и АС»

Тема: «РИЕЛТОРСКАЯ КОНТОРА»

Воробьёв Алексей Андреевич

Студент группы ПО 3-1

Научный руководитель

Рожкова Вера Григорьевна

Краснодар 2010 г.

Введение

Под базой данных (БД) понимают хранилище структурированных данных, при этом данные должны быть непротиворечивы, минимально избыточны и целостны.

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

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

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

Хорошо спроектированная база данных:

Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более "прозрачными" и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.
Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу "высвечивая" все недочеты этапа проектирования.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть – ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других – нет, но логически такое разделение можно провести во всех СУБД.

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

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

Автоматизированная информационная система (АИС)

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

АИС являются, с одной стороны, разновидностью информационных систем (ИС), с другой — автоматизированных систем (АС), вследствие чего их часто называют ИС или АС.

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

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

Основной причиной создания и развития АИС является необходимость ведения учёта информации о состоянии и динамике объекта, которому посвящена система. На основании информационной картины, создаваемой системой, руководители различного звена могут принимать решения об управляющих воздействиях с целью решения текущих проблем.

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

Побочными, возможными, но не гарантированными эффектами от использования системы могут выступать:
повышение производительности работы персонала;
улучшение качества обслуживания клиентов;
снижение трудоемкости и напряженности труда персонала;
снижение количества ошибок в его действиях.

АИС «Риелторская контора»

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

Цель создания программы состоит в следующем:

сокращение времени обработки информации;
простоте реализации различных запросов и скорости обработки данных;
автоматизации труда.

Благодаря тому, что программа реализована при помощи Microsoft® Access 2000, она имеет внешний вид (интерфейс) характерный для всех приложений разработанных под операционную систему Microsoft® Windows, который очень прост и дружелюбен по отношению к пользователю.

Разработка ПП. Выбор среды программирования

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

построитель таблиц;
построитель экранных форм;
построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры. Опыт показывает[источник не указан 55 дней], что даже для проектов на 5-20 пользователей предпочтительно использовать клиент-серверные решения.

Существенно расширяет возможности MS Access по написанию приложений механизм связи с различными внешними СУБД: "связанные таблицы" (связь с таблицей СУБД) и "запросы к серверу" (запрос на диалекте SQL, который "понимает" СУБД). Также MS Access позволяет строить полноценные клиент-серверные приложения на СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

Выбор модели

На сегодняшний день наиболее часто используются три модели данных: иерархическая, сетевая и реляционная. Кроме них существуют и другие модели, например модель данных, основанная на инвертированных списках или объектно-ориентированная, однако они не имеют широкого распространения, так как базы на инвертированных списках использовались на заре развития СУБД, а объектно-ориентированные базы данных ещё не до конца изучены. Таким образом, выбор сокращается до трёх вышеназванных моделей данных.

Иерархические базы данных. Этот вид баз данных одним из первых получил широкое распространение и стал промышленно использоваться. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева. Тип дерева состоит из одного "корневого" типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи. Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие операторы:

- Найти указанное дерево БД;

- Перейти от одного дерева к другому;

- Перейти от одной записи к другой внутри;

- Перейти от одной записи к другой в порядке обхода иерархии;

- Вставить новую запись в указанную позицию;

- Удалить текущую запись.

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

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом, как на новую технологию БД, так и на новую технику.

Сетевая модель данных. Сетевой подход к организации данных является расширением иерархического подхода. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.

Сетевая БД состоит из набора записей и набора связей между ними, а если говорить более точно: из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться два условия:

- Каждое экземпляр типа P является предком только в одном экземпляре L;

- Каждый экземпляр C является потомком не более чем в одном экземпляре L.

На формирование типов связи не накладываются особые ограничения; возможны, например, ситуации:

а) Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

б) Данный тип записи P может быть типом записи предка в любом числе типов связи.

в) Данный тип записи P может быть типом записи потомка в любом числе типов связи.

г) Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

д) Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

е) Предок и потомок могут быть одного типа записи.

Примерный набор операций может быть таковым:

Найти конкретную запись в наборе однотипных записей (инженера Сидорова);
Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);
Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
Создать новую запись;
Уничтожить запись;
Модифицировать запись;
Включить в связь;
Исключить из связи;
Переставить в другую связь и т.д.

К достоинствам сетевой СУБД можно отнести возможность экономии памяти за счет разделения подобъектов.

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол.

Описанные выше модели данных относятся к так называемым ранним СУБД. У этих моделей есть существенные недостатки так то:

Слишком сложно пользоваться;
Фактически необходимы знания о физической организации;
Прикладные системы зависят от этой организации;
Их логика перегружена деталями организации доступа к БД.

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

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

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

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

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

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

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

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

Логическая модель

Рисунок 1 (схема данных)

Информационная модель

Рисунок 2 (Таблица «ИНФО»)

Рисунок 3 (Таблица «Проданные»)

Рисунок 4(Таблица «Риелторы»)

Рисунок 5(Таблица «Договора»)

Рисунок 6(Таблица «Покупатели»)

Интерфейсы

Рисунок 7(Главная кнопочная форма)

Рисунок 8(Карточка покупателя)

Рисунок 9(Карточка риелтора)

Входные данные

Рисунок 10(Таблица «Договора»)

Рисунок 11(Таблица «Инфо»)

Рисунок 12(Таблица «покупатели»)

Рисунок 13(Таблица «риелторы»)

Рисунок 14(Таблица «проданные»)

Выходные данные

Рисунок 15 (результат запроса «каталог»)

Рисунок 16 (результат запроса «имущество за риелтором»)

Рисунок 17 (результат запроса «прибыль»)

Рисунок 18 (результат запроса «продано риелтором»)

Рисунок 19 (результат запроса «проданные»)

Рисунок 20(Отчет «комнат < или >»)

Рисунок 21 (отчет площадь < или >)

Рисунок 22 (отчет сумма < или >)

Рисунок 23(Отчет «тип»)

Алгоритм решения задачи

Запросы SQL

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

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

Запрос «Каталог» - данный запрос выбирает из таблицы «ИНФО» информация о имуществе.

SELECT ИНФО.№_договора, ИНФО. тип, ИНФО. Площадь_ кв_ метр, ИНФО. Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО. , Риелторы.ФИО Риелтора, Риелторы.телефон_риелтора

FROM Риелторы INNER JOIN ИНФО ON Риелторы. ID_риелтора = ИНФО.ID риелтора;

Запрос «имущество за риелтором» - выводит информацию о количестве имущества закрепленного за каждым риелтором.

SELECT Риелторы.ФИО_Риелтора, Count(ИНФО.тип) AS [Count-тип], Sum(ИНФО.стоимость) AS [Sum-стоимость]

FROM Риелторы INNER JOIN ИНФО ON Риелторы.ID_риелтора = ИНФО.ID_риелтора

GROUP BY Риелторы.ФИО_Риелтора;

Запрос на копирование – выполняет копирование всех полей проданного имущества из таб. «Инфо» в таб. «Проданные».

INSERT INTO Проданные ( №_договора, заявка, тип, Площадь_кв_метр, Адрес, [Этаж(ей)], Колл_комнат, стоимость, [стоимость_ аренда], ФИО_покупателя, Телефон_покупателя, ФИО_Риелтора, Телефон_риелтора )

SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимость, ИНФО.[стоимость_ аренда], Покупатели.ФИО_Покупателя, Покупатели.Телефон_покупателя, Риелторы.ФИО_Риелтора, Риелторы.телефон_риелтора

FROM Риелторы INNER JOIN (ИНФО INNER JOIN Покупатели ON ИНФО.№_договора=Покупатели.№_договора) ON Риелторы.ID_риелтора=ИНФО.ID_риелтора

WHERE куплено=true;

Запрос на удаление – удаляет данные о проданном имуществе из таб. «Инфо»

DELETE ИНФО.№_договора, ИНФО.куплено, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимость, ИНФО.[стоимость_ аренда], ИНФО.ФИО_продавца, ИНФО.Телефон_Продавца, ИНФО.ID_риелтора

FROM ИНФО

WHERE (((ИНФО.куплено)=True));

Комнат больше(меньше) – выводит поля из таб. «Инфо» по критерию.

SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимость

FROM ИНФО

WHERE (((ИНФО.Колл_комнат)>=(<=)[введите колличество комнат]) AND ((ИНФО.куплено)=False));

площадь больше(меньше) – выводит поля из таб. «Инфо» по критерию.

FROM ИНФО

WHERE (((ИНФО.Площадь_кв_метр)>= (<=) [введите площадь]) AND ((ИНФО.куплено)=False));

Прибыль – выводит сумму проданного имущества из таб. «Проданные»

SELECT DISTINCTROW Sum(Проданные.стоимость) AS Сумма

FROM Проданные;

Продано риелтором – выводит сумму проданного имущества каждым риелтором.

SELECT Проданные.ФИО_Риелтора, Sum(Проданные.стоимость) AS [Sum-стоимость]

FROM Проданные

GROUP BY Проданные.ФИО_Риелтора;

Проданные Запрос – выводит все поля из таб. «Проданные»

SELECT Проданные.№_договора, Проданные.заявка, Проданные.тип, Проданные.Площадь_кв_метр, Проданные.Адрес, Проданные.[Этаж(ей)], Проданные.Колл_комнат, Проданные.стоимость, Проданные.[стоимость_ аренда], Проданные.ФИО_покупателя, Проданные.Телефон_покупателя, Проданные.ФИО_Риелтора, Проданные.Телефон_риелтора

FROM Проданные;

Сумма больше(меньше) – выводит поля из таб. «Инфо» по критерию.

FROM ИНФО

WHERE (((ИНФО.стоимость)>=(<=)[введите сумму]) AND ((ИНФО.куплено)=False));

Тип – выводит поля из таб. «Инфо» по критерию.

FROM ИНФО

WHERE (((ИНФО.тип)=[введите тип]) AND ((ИНФО.куплено)=False));

Этаж больше(меньше) – выводит поля из таб. «Инфо» по критерию.

FROM ИНФО

WHERE (((ИНФО.[Этаж(ей)])>=(<=)[введите этаж(ей)]) AND ((ИНФО.куплено)=False));

Макрос - программный объект, при обработке «развёртывающийся» в последовательность действий или команд.

Макрос(Рисунки 24 и 2) - выполняет функцию поиска по номеру договора.

Рисунок 24 (макрос 1)

Рисунок 25(макрос 1 поле «найти запись» )

Макрос(Рисунок 26) – выполняет функцию обновления таблиц «Инфо» и «Проданные»

Рисунок 26 (макрос 2)

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

Электронная встроенная гипертекстовая справочная система Microsoft Access, файл MSACC20.HLP, 4.7 Мбайт
Журнал "PC Magazine Russian Edition" ¹7 1999, "Microsoft Access"
Бойко И., Объектно–ориентированные СУБД.- Киев: Высшая школа, 1999
Майкл. Хэлволсон, Майкл Янг, Эффективная работа с Microsoft Office. C.Петербург: Питер, 2001
Рыбакова О. О., Проектирование автоматизированных информационных систем. Методический материал для проведения аудиторных занятий и самостоятельной работы. Издание первое. – Запорожье: ЗЕТК, 2001