Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Учёт сведений о недвижимости и клиентах в фирме по продаже и обмену жилья

Учёт сведений о недвижимости и клиентах в фирме по продаже и обмену жилья

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 20.03.2012
Размер файла 389,8 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ. ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ФИЛИАЛ ГОСУДАРСТВЕННОГО ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТИХООКЕАНСКИЙ ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ» В Г. ЮЖНО-САХАЛИНСКЕ САХАЛИНСКОЙ ОБЛАСТИ

Кафедра Математики и моделирования

Курсовая работа

на тему: УЧЕТ СВЕДЕНИЙ О НЕДВИЖИМОСТИ И КЛИЕНТАХ В ФИРМЕ ПО ОБМЕНУ И ПРОДАЖЕ ЖИЛЬЯ.

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

Выполнена студенткой 3 курса 131-ПИ группы

специальности 080801 «Прикладная информатика в экономике» экономического факультета обучающейся по основной образовательной программе Neko_des =)

Руководитель Чехонина С.А.

Южно-Сахалинск 2007

ЗАДАНИЕ на курсовую работу

1. Тема курсовой работы: Учет сведений о недвижимости и клиентах в фирме по продаже и обмену жилья

Утверждена приказом по филиалу

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

2. Содержание работы. В работе будут изложены следующие разделы:

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

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

б) Описание входных документов:

Карточка квартиры, заявка клиента на обмен/продажу/поиск кавртиры

в) Описание выходных документов: Табличный отчет: список квартир; группировка по районам и количеству комнат.

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

г) Описание запросов: Упорядочение по полям: ФИО клиентов, площадь квартир;

Поиск: координаты клиента по фамилии, по телефону.

Выборка: трехкомнатные квартиры не на первом этаже; квартиры площадью от АА до ВВ в районе Ново-Александровки;

Вычисления: средняя цена трехкомнатной квартиры; суммарное число заявок по районам города;

Коррекция: удаление сведений о выполненных заявках за прошедший отчетный период; изменение цены квартиры заданного клиента с ХХ на УУ с хранением истории.

д) Описание ограничений: Ограничения целостности: а) дата заявки не позже текущего числа; б) если имеются данные о квартире, то должны быть и сведения о заявителе; в) ФИО и адрес клиента - не пустые значения.

2. Выбор и описание используемой СУБД

А) сравнительная характеристика различных СУБД

Б) Описание возможностей используемой СУБД

В) Описание языка манипулирования данными, языка запросов

3. Инфологическое моделирование предметной области А) ER- модель предметной области, нормализация отношений

4. Функциональная структура программной системы

А) Общая схема приложения, состав меню и подменю

Б) примеры интерфейса входных и выходных форм, отчетов

Содержание

  • ВВЕДЕНИЕ
  • 1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ О ДЕЯТЕЛЬНОСТИ ФИРМ ПО ОБМЕНУ И ПРОДАЖЕ ЖИЛЬЯ
    • 1.1 Цели и задачи фирм по обмену и продаже жилья
    • 1.2 Основные моменты работы фирмы для создания системы автоматизации учета данных о заявках и клиентах
  • 2. Характеристика инструментов разработки базы данных и программы для работы с ней
    • 2.1 Характеристика среды разработки приложения Delphi 7 и её преимуществ
    • 2.2 Характеристика СУБД Paradox и её преимуществ
  • 3. моделирование данных и приложения для работы с ними
    • 3.1 Функциональная модель приложения для учёта сведений о недвижимости и клиентах в фирме методом SADT
    • 3.2 Разработка инфологической модели и создание реляционной структуры требуемой базы данных
    • 3.3. Разработка логической модели базы данных
  • 4. СВЕДЕНИЯ О ПРОГРАММЕ, НЕОБХОДИМЫЕ ДЛЯ КОРРЕКТНОЙ РАБОТЫ
    • 4.1. Состав файлов приложения
    • 4.2. Информация по установке
    • 4.3. Работа с приложением
  • ЗАКЛЮЧЕНИЕ
  • СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

В настоящее время информация является неотъемлемой частью любой экономической деятельности. В некоторых случаях информация - основной товар, в других - «сырье» для производства новых услуг. Но на самом деле такая четкая градация встречается крайне редко. К этой категории и относятся фирмы по обмену и продаже жилья, или риэлторские фирмы. В этих фирмах основным товаром является информация: у кого и за сколько можно купить квартиру, кому и за сколько ее можно продать. Риэлторская фирма выступает в роли посредника, и чем лучше, качественнее и быстрее она находит искомую информацию - тем больше прибыль фирмы.

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

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

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

Задачи при этом будут следующие:

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

2. Определить цели учета на фирме, и, следовательно, выявить основные моменты, подлежащие автоматизации.

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

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

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

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

7. Создать базу данных, приложение, работающее с ней. Описать процесс использования приложения.

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

1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ О ДЕЯТЕЛЬНОСТИ ФИРМ ПО ОБМЕНУ И ПРОДАЖЕ ЖИЛЬЯ

1.1 Цели и задачи фирм по обмену и продаже жилья

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

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

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

Решаемые при этом задачи начинаются в комфортном офисе с дружелюбным персоналом и заканчиваются в том же офисе, но уже при заключении сделки между двумя довольными клиентами. А вот то, что находится в «середине» этого процесса, можно примерно разделить на:

· Примём заявок у клиентов;

· Обработку принятых заявок, ведение базы всех поступивших и оформленных заявок;

· Прогулки с клиентом по предложенным вариантам;

· Подготовка и оформление документов при проведении операции;

· Проверка юридической чистоты истории квартиры - не прописан ли в ней кто еще и не является ли она залогом в банке по еще не выплаченному кредиту;

· Юридический контроль и сопровождение сделок;

· Помощь в оформлении документов;

· Консультации по интересующим вопросам;

· И многое другое.

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

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

1.2 Основные моменты работы фирмы для создания системы автоматизации учета данных о заявках и клиентах

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

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

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

С точки зрения создания требуемой системы, решаемые задачи будут:

· Выдача справок о характеристиках недвижимости (район, площадь квартиры, количество комнат, этажность, цена, адрес);

· Выдача справок о заявках клиентов (обмен, купля, продажа, адрес и телефон, дата заявки);

· Создание табличного отчёта с содержанием списка квартир в группировке по районам и количеству комнат;

· Создание произвольного отчета - письма клиенту с найденным вариантом сделки;

· Поиск координат клиента по фамилии или номеру телефона;

· Выборка квартир по признаку этажности, площади, района;

· Вычисление среднего значения цены квартиры;

· Вычисление суммарного числа заявок по районам города;

Требования к организации и целостности данных тогда будут:

· Возможность изменения цены квартиры, с хранением истории;

· Архивирование сведений о выполненных заявках за прошедший отчетный период;

· Дата заявки не позже текущего числа;

· Если имеются данные о квартире, то должны быть и сведения о заявителе;

· Фамилия, имя, отчество и адрес клиента - не пустые значения;

· Каскадное обновление данных;

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

2. Характеристика инструментов разработки базы данных и программы для работы с ней

2.1 Характеристика среды разработки приложения Delphi 7 и её преимуществ

Для создания программы, обеспечивающей работу с базой данных, более всего подходит среда разработки приложений Delphi 7.

Delphi 7 относится к классу инструментальных средств ускоренной разработки программ (Rapid Application Development, RAD). Визуальное конструирование форм Delphi избавляет от многих аспектов разработки интерфейса программы, так как уже готовы необходимые программные заготовки и соответствующие файлы ресурсов. Все компоненты характеризуются важным свойством: они включают в себя программный код и все необходимые для его работы данные. Это не только значительно ускоряет процесс написания программ, но и существенно снижает вероятность случайный программных ошибок. [3, 19c.]

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

Синтаксис С++ прямо-таки провоцирует создание запутанных программ, в которых трудно разобраться даже автору, в то время как простой и ясный синтаксис Delphi позволяет последнему претендовать на роль языка, идеально подходящего для описания алгоритма (недаром Паскаль происходит от использующегося для этих целей алгоритмического языка АЛГОЛ-60).

Если по каким-либо причинам возможности Delphi окажутся недостаточными, можно программировать на Ассемблере (машинно-зависимом языке программирования), который органично вплетён в Delphi.

Во всех случаях Delphi имеет самый быстрый среди продуктов подобного рода оптимизирующий компилятор, позволяющий создавать быстрые и относительно компактные программы. [3, 20c.]

Наиболее приспособленным для работы с Delphi является СУБД Paradox.

2.2 Характеристика СУБД Paradox и её преимуществ

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

Такие базы данных полезны для развития тех приложений, которые распространены среди многих пользователей, каждый из которых поддерживает отдельную базу данных. Это, например, приложения, обрабатывающие документацию небольшого офиса, фирмы. Каждый пользователь такого приложения манипулирует своими собственными данными на своём компьютере, ему нет необходимости иметь доступ к данным другого пользователя. [1, 557c.]

Выбранная для разработки СУБД - Paradox. Конечно, это уже устаревший формат баз данных, у которого постоянно рушатся индексы, да и базой данных, как таковой он не является - Paradox создаёт отдельные таблицы, которые хранятся в одном каталоге, который я будет являться базой данных. И вследствие этого легко можно нарушить работоспособность всей базы - пользователю достаточно всего лишь удалить один файл из каталога [5, 529c.]. (Будем верить, что в нашем случае пользователь - это сознательное существо, которое умеет работать за компьютером и осознаёт, что лишних и ненужных файлов для него в системных каталогах нет.)

Но с другой стороны, Paradox обладает большей гибкостью и возможностями, чем XML. И не уступает dBase'у, Microsoft Access'у, FoxPro, Oracle'у и многим другим. Единственным отличием может являться факт, что перечисленные СУБД (кроме dBase) хранят базу данных одним файлом. Остальные же возможности у них примерно равны и отличаются лишь их доступом и реализацией.

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

Принимая во внимание легкость работы с Paradox в Delphi и файл-серверную архитектуру Paradox - это является оптимальным решением для поставленной задачи.

фирма учёт клиент

3. моделирование данных и приложения для работы с ними

3.1 Функциональная модель приложения для учёта сведений о недвижимости и клиентах в фирме методом SADT

Метод SADT (Structure Analysis and Design Technique) представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. При этом модель полностью описывает функциональную структуру данных, последовательность выполняемых действий, передачу информации межу функциональными процессами. Не учитываются только отношения между данными (что будет исправлено далее, в ER-модели).

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы -- главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

Одной из наиболее важных особенностей метода SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. [2, 115-117c.]

Ниже будет приведена функциональная модель учёта сведений о недвижимости и клиентах в фирме по продаже и обмену жилья с детализацией до трёх уровней в глубину.

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

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

Рисунок 1. Первый уровень детализации функциональной модели, диаграмма А-0 «Учет сведений о недвижимости и …».

На рис.1 представлен первый уровень детализации функциональной модели, т.е. как это есть в самом начале моделирования. В данном случае объект представляет собой «чёрный ящик», когда известно с чем он работает, но не каким образом.

Входная информация:

· I1- карточка квартиры;

· I2 - заявка клиента.

Выходная информация:

· О1 - регистрация сделки;

· О2 - отказ.

Контроль осуществляется посредством:

· С3 - Жилищного Кодекса Российской Федерации;

· С2 - Налогового Кодекса РФ;

· С1 - Должностных инструкций работников фирмы.

Механизмы, обеспечивающие работу:

· М1 - программное обеспечение;

· М2 - администрация фирмы;

· М3 - агенты купли-продажи.

Далее, при детализации перечисленные выше дуги не изменятся, к ним могут только прибавится новые дуги, не выходящие за пределы исходной диаграммы А-0.

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

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

Рисунок 2. Второй уровень детализации, диаграмма А0 «Учет сведений о недвижимости и клиентах…».

На втором уровне детализации (рис.2) не появляется никаких новых внешних дуг. Только при разбиении учёта сведений на два этапа: работу с заявками и работу с клиентами - появляются дуги, обусловливающие взаимодействие этих двух элементов:

· Группировка по количеству комнат;

· Группировка по районам;

· Письмо клиенту;

· Список квартир.

Далее детализируем отдельно работу с заявками (диаграмма А1, рис.2).

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

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

Рисунок 3. Детализация диаграммы А1 «Работа с заявками».

Работа с заявками при детализации разбивается на приём и сортировку и работу с клиентами (рис.3). Появляются связи между новыми дочерними диаграммами:

· На обмен/покупку/продажу - вид операции;

· Данные квартиры;

· Данные клиента.

Теперь детализируем подробнее работу с клиентами.

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

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

Рисунок 4. Детализация диаграммы А2 «Работа с клиентом»

Работа с клиентами при детализации разбивается на поиск варианта и предложение найденного варианта. Взаимосвязями между ними являются табличный отчет с группировкой по требуемому критерию (площадь, цена, этажность и т.д.), письмо клиенту, выборка некоторых вариантов по критерию. Появляется новая циклическая связь - если вариант не подошел. Она является выходной дугой для диаграммы А2-2, но входной для диаграммы А2-1.

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

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

3.2 Разработка инфологической модели и создание реляционной структуры требуемой базы данных

Выделим сущности, присутствующие в обозначенной предметной области:

1. Клиент - содержит данные клиента, желающего продать/купить/обменять квартиру.

2. Квартира - характеристика продаваемой/меняемой квартиры.

3. Заявка - связывает клиента и квартиру. Одни клиент может сделать несколько заявок, например, на покупку одной квартиры и на продажу другой.

4. Сделка - содержит данные о заключенной сделке: клиенте и квартире (проданной или приобретенной) и данные агент, заключившего сделку.

5. Агент - лицо, заключающее сделку.

6. Вид операции - операции с квартирами бывают трех типов: продажа, покупка, обмен.

7. Справочник районов - квартира может находится в районе, неизвестном клиенту. В справочнике районов содержится описание и характеристики районов.

8. История - цена на квартиру может меняться с течением времени от момента подачи заявки на ее продажу/обмен. Ведение истории позволит определить тенденции изменения цен на квартиры в общем.

После выявления присутствующих сущностей, рассмотрим взаимосвязи между ними.

На рисунке 5 представлена инфологическая модель данных, показывающая эти взаимосвязи.

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

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

Рисунок 5. Инфологическая модель данных.

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

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

3.3 Разработка логической модели базы данных

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

На рисунке 6 представлена логическая модель базы данных с полным списком атрибутов. Первичный ключ на рисунке обозначен `*', внешний `~'. Названия атрибутов также указаны латиницей.

Рисунок 6. Логическая модель базы данных.

Атрибуты и их характеристика каждой сущности представлены по таблицам, где PK - первичный ключ, FK - внешний ключ.

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

Сущность «Агент» - стержень, представлена в таблице 3.1.

Таблица 3.1

Характеристика атрибутов сущности «Агент».

имя

имя поля

описание

тип

размер

ключ

заполнение

(Агент)

Agent

AgNum

индивидуальный номер риэлтора

счетчик

 

PK

автоматически

 

AgFam

фамилия риэлтора

текст

20

 

обязательно

 

AgName

Имя риэлтора

текст

15

 

обязательно

 

AgSFam

отчество риэлтора

текст

15

 

обязательно

Сущность «Клиент» - стержень, представлена в таблице 3.2.

Таблица 3.2

Характеристика атрибутов сущности «Клиент».

имя

имя поля

описание

тип

размер

ключ

заполнение

(Клиент)

client

ClNum

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

счетчик

 

PK

автоматически

 

ClFam

фамилия клиента

текст

20

 

обязательно

 

ClName

Имя клиента

текст

15

 

обязательно

 

ClSName

отчество клиента

текст

15

 

обязательно

 

ClDocs

паспортные данные клиента

текст

70

 

обязательно

 

ClPhone

Номер телефона клиента

Кор.числ

 

обязательно

Сущность «Квартира» - стержень, представлена в таблице 3.3.

Таблица 3.3

Характеристика атрибутов сущности «Квартира».

имя

имя поля

описание

тип

размер

ключ

заполнение

Flat

FlNum

индивидуальный номер квартиры по реестру фирмы

счетчик

 

PK

автоматически

 

ClNum

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

кор.числ

 

FK

обязательно

Flroom

кол-во комнат квартиры

кор.числ

 

 

обязательно

 

Flflor

этаж квартиры

кор.числ

 

 

обязательно

 

FlSq

площадь квартиры

кор.числ

 

 

обязательно

Таблица 3.3(продолжение)

Характеристика атрибутов сущности «Квартира».

имя

имя поля

описание

тип

размер

ключ

заполнение

 

FlAdress

адрес квартиры

текст

100

 

обязательно

 

FlStatus

статус квартиры (на продажу, обмен, уже задействована)

текст

15

 

обязательно

 

FlPlace

название района расположения

текст

20

FK

обязательно

Сущность «Заявка» - ассоциация, представлена в таблице 3.4.

Таблица 3.4

Характеристика атрибутов сущности «Заявка».

имя

имя поля

описание

тип

размер

ключ

заполнение

request

reqDate

дата заявки

дата

 

обязательно

 

FlNum

номер квартиры по реестру

кор.числ

 

 

автоматически

 

ReqNum

индивидуальный номер заявки

счетчик

 

PK

автоматически

 

ClNum

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

кор.числ

 

FK

обязательно

 

OpCode

код операции

кор.числ

 

FK

обязательно

 

ReqNum

индивидуалный код заявки

счетчик

 

PK

автоматически

 

ReqPrice

заявка на сумму

денежн.

 

 

обязательно

Сущность «Сделка» - ассоциация, представлена в таблице 3.5.

Таблица 3.5

Характеристика атрибутов сущности «Сделка».

имя

имя поля

описание

тип

размер

ключ

заполнение

deal

dlNum

индивидуальный номер сделки

счетчик

 

PK

автоматически

 

ClNum

номер клиента, участвующего в сделке

кор.числ

 

FK

обязательно

 

ClFam

номер приобретаемой квартиры

кор.числ

 

FK

обязательно

Таблица 3.5(продолжение)

Характеристика атрибутов сущности «Сделка».

имя

имя поля

описание

тип

размер

ключ

заполнение

 

AgNum

индивидуальный номер агента, проводящего сделку

кор.числ

 

FK

обязательно

 

DealDate

дата проведения сделки

дата

 

 

обязательно

Сущность «История» - ассоциация, представлена в таблице 3.6.

Таблица 3.6

Характеристика атрибутов сущности «История».

имя

имя поля

описание

тип

размер

ключ

заполнение

History

FlNum

индивидуальный номер квартиры по реестру фирмы

кор.числ

 

FK

обязательно

HNum

Номер изменения, подсчет изменен.

Счетч.

PK

 

Hdate

дата изменения цены

дата

 

 

обязательно

 

FlPrice

цена квартиры

денежн.

 

 

обязательно

Сущность «Справочник районов» - характеристика, представлена в таблице 3.7.

Таблица 3.7

Характеристика атрибутов сущности «Справочник районов».

имя

имя поля

описание

тип

размер

ключ

заполнение

Book

FlPlace

название района расположения

текст

20

PK

обязательно

 

about

описание района

большой текст

200

 

обязательно

Сущность «Справочник операций» - характеристика, представлена в таблице 3.8.

Таблица 3.8

Характеристика атрибутов сущности «Справочник операций».

имя

имя поля

описание

тип

размер

ключ

заполнение

Operation

OpCode

код операции

счетчик

 

PK

автомтически

 

OpName

имя операции

тектс

20

 

обязательно

4. СВЕДЕНИЯ О ПРОГРАММЕ, НЕОБХОДИМЫЕ ДЛЯ КОРРЕКТНОЙ РАБОТЫ

4.1 Состав файлов приложения

Созданное приложение со всеми файлами и базой данных располагается на диске, прилагаемом к пояснительной записке. Все файлы приложения расположены в папке «Work», в этой же папке есть еще одна вложенная - «BD» - в ней расположены файлы базы данных.

Work_Project1.exe - скомпилированная программа, остальные файлы - исходники, которые можно открыть в Delphi для просмотра кода программы.

U_W_Agent, U_W_Book, U_W_Client, U_W_Deal, U_W_Flat, U_W_Operation, U_W_Request, U_Work - исходные файлы программы, по именам разделенные на таблицы, с которыми работают. В зависимости от расширения, каждый файл с указанным именем может содержать:

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

- *.pas (Delphi Source File) - текстовый файл, создается к каждой используемой в приложении форме, предназначен для хранения кода, некоторых функций и процедур;

- *.dfm - файл описания формы (содержит информацию о внешнем виде рабочего окна);

- *.dcu - откомпилированный файл модуля *.pas, который компонуется в окончательный исполняемый файл;

Если в начале имени расширения присутствует символ «~», то это значит, что данный файл является резервной копией.

В папке «BD» хранятся файлы базы данных. Файлы с расширением *.db содержат общую информацию о таблицах, а это:

- Agent.db - таблица данных об агентах;

- Book.db - таблица справочника районов;

- Client.db - таблица данных о клиентах;

- Deal.db - таблица данных о заключенных сделках;

- Flat.db - таблица данных об имеющихся квартирах;

- History.db - таблица истории изменения цен на квартиры;

- Operation.db - справочник кодов операций;

- Price.db - таблица цен квартир, указанных в Flat.db;

- Request.db - таблица данных о заявках клиентов на покупку, продажу или обмен жилья.

Другие файлы имеют то же имя, указывающее на принадлежность их к конкретной таблице, но другое расширение. Так файл с расширением *.mb хранит текстовую информацию из поля типа «memo»- длинный текст. Такое поле в данной базе есть только в Справочнике районов. Другие файлы с расширением:

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

- *.px - содержит первичный индекс таблицы;

- *.X0n и *.Y0n - где n может быть от 2 и далее - это вторичные простые пронумерованные индексы таблицы;

- *Xgn и *.Ygn - где n может быть от 2 и далее - это вторичные составные индексы соответствующих таблиц.

Так же там содержится один файл DBDWORK.cfg, хранящий параметры конфигурации.

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

4.2 Информация по установке

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

Приложение открывается запуском файла Work_Project.exe - он не требует установки дополнительных компонентов на компьютер. Также в коде программы реализовано программное создание алиаса базы данных, что позволяет свободно переносить приложение с базой с одного компьютера на другой, и размещать их на разных уровнях директорий. (Имеется в виду, что на одном компьютере приложение может находится в корневом каталоге, а на другом - где-нибудь поглубже в папках. Но указанное выше условие должно выполнятся.)

4.3 Работа с приложением

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

В первую очередь необходимо заполнить таблицы «Агенты», «Справочник районов», «Справочник операций» - это начальные данные, необходимые для заполнения других таблиц.

Далее, при работе с клиентом следует сперва занести его данные в таблицу «Клиент», и только потом оформлять заявку.

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

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

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

Окно приложения в момент открытия показан на рисунке 7.

Рисунок 7. Окно приложения в момент открытия.

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

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

Рисунок 8. Открыта таблица «Список Заявок».

Также в программе предусмотрена возможность поиска данных клиента по фамилии и/или номеру телефона, выборка квартир по этажу и по площади в заданном районе, необходимые вычисления. Эти возможности реализованы на списке закладок внизу рабочей области. Переключение между таблицами осуществляется через меню «Таблицы» (рис.9).

Рисунок 9. Пункт меню «Таблица» приложения.

Открыть окно редактирования и/или добавления новой записи позволяет команда меню «Запись -> Окно редактирования текущей таблицы» (рис.10). в том же пункте меню можно и закрыть все открытые окна редактирования.

Рисунок 10. Пункт меню «Запись» приложения.

В пункте меню «Отчеты» можно создать требуемы отчет: письмо клиенту или список квартир. Также там находится команда группировки по районам и количеству комнат.

ЗАКЛЮЧЕНИЕ

В работе были успешно выполнены все поставленные задачи.

1. Создана модель SADT, показывающая функциональную структуру риэлторской фирмы.

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

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

4. Оптимальной средой разработки приложения является Delphi, оптимальный способ организации данных - СУБД Paradox.

5. Создано приложение с интуитивно понятным интерфейсом, не требующее сложной установки.

Помимо этого, реализованное приложение частично автоматизирует ввод данных (после ввода данных о клиенте в форме ввода данных о заявке автоматически выставляется номер клиента), и отслеживает правильность их введения. Нельзя поставить дату вчерашнюю или завтрашнюю - дата ставится автоматически. Нельзя выбрать несуществующий район или «мертвую душу» для заключения сделки.

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Архангельский А.Я. Программирование в Delphi 7. - М.: ООО «Бином-Пресс», 2003 г. - 1152с.: ил.

2. Вендров А.М. проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2006. - 544 с.: ил.

3. Фаронов В.В. Delphi. Программирование на языке высокого уровня: Учебник для вузов. - СПб.: Питер, 2006. - 640 с.: ил.

4. Фаронов В.В. Программирование баз данных в Delphi 7. Учебный курс. - СПб.: Питер, 2005. - 459 с.: ил.

5. Фленов М.Е. Библия Delphi. - СПб.: БХВ-Петербург, 2004. - 880с.: ил.

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


Подобные документы

  • Программное средство по обмену услугами для владельцев собак

    Разработка приложения по обмену услугами для владельцев собак. Создание личного кабинета с персональными данными. Редактирование: личных данных, объявления, питомца. Алгоритм редактирования и удаления объявления. Тестирование данного программного средства

    дипломная работа [2,8 M], добавлен 14.10.2016

  • Модификация информационной системы компьютерного магазина

    Разработка информационной системы учёта данных о клиентах, товарах и услугах в среде MS Access. Технология функционирования существующей ИС компьютерной компании. Модификация инфологической модели БД, проектирование новых экранных форм и отчетов.

    курсовая работа [1,5 M], добавлен 20.06.2014

  • Разработка базы данных "Автомобильное предприятие"

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

    курсовая работа [981,4 K], добавлен 05.11.2011

  • База даных "Аэропорт"

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

    курсовая работа [3,8 M], добавлен 25.06.2011

  • Проектирование и разработка базы данных для хранения сведений по работе букмекерской конторы

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

    курсовая работа [3,3 M], добавлен 05.12.2012

  • Разработка интернет-магазина по продаже компьютерной техники

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

    дипломная работа [2,6 M], добавлен 10.06.2014

  • Автоматизация работы фирмы по продаже квартир

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

    курсовая работа [65,7 K], добавлен 30.11.2009

  • Разработка Web-приложения "Магазин по продаже продуктов" с использованием PHP и MySQL

    Отличительные особенности языков программирования PHP и CSS. Возможности компактного многопоточного сервера баз данных MySQL. Системный анализ предметной области, проектирование ее инфологической модели. Создание базы данных и web-страниц сайта магазина.

    курсовая работа [1,0 M], добавлен 15.01.2013

  • Создание базы данных "Агентство по трудоустройству"

    Разработка базы данных для автоматизации учета и хранения сведений о заявках от работодателей. Проектирование приложения в СУБД Access. Описание запросов, отчетов и представлений данных. Интерфейс, условия выполнения и тестирование программного продукта.

    курсовая работа [3,7 M], добавлен 05.04.2012

  • Учет товаров в фирме по продаже аудиотехники

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

    курсовая работа [21,4 K], добавлен 26.01.2009

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены