Разработка информационно-справочной системы для автоматизации процесса работы агентов по недвижимости

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

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

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

на тему:

"Разработка информационно-справочной системы для автоматизации процесса работы агентов по недвижимости"

Введение

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

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

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

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

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

Целью данного курсового проекта является разработка программного продукта, предназначенного для просмотра информации об агентствах недвижимости, а также для работы с этой информацией (выборка данных по разным критериям, добавление, изменение, удаление), применяя принципы объектно-ориентированного анализа и реляционного моделирования данных, а также используя современные CASE-средства визуального моделирования данных, программные средства СУБД и технологии программирования приложений БД в операционной системе MS Windows 2000/XP.

1.2 Основы разработки баз данных

При разработке БД можно выделить следующие этапы работы:

I этап. Постановка проблемы

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

II этап. Анализ объекта

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

III этап. Синтез модели

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

IV этап. Способы представления информации, программный инструментарий

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

1) С использованием форм;

2) Без использования форм.

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

V этап. Синтез компьютерной модели объекта и технология его создания

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

VI этап. Работа с созданной базой данных

Работа с БД включает в себя такие действия, как:

1) Поиск необходимых сведений;

2) Отбор данных;

3) Изменение и дополнение данных.

1.3 Анализ предметной области. Разработка бизнес-правил и глоссария

Имеется следующее описание предметной области:

а) таблица с основной информацией о агентствах недвижимости:

Таблица 2.1 - Описание ПрО «Агентства по недвижимости»

Название агентства	Адрес объекта недвижимости	Вид фонда	Общая площадь (кв. м.)	Ф.И.О. клиента	Адрес клиента	Стоимость услуги (у. е.)
NEW_WORLD	Петровского 32	нежилой	180	Иванов Л.П	Калинина 49,43	400
YOUR_HOUSE	Грязнова 45	жилой	65	Петров Н.И.	Самонская 12,32	50000
……	…….	…….	……	………….	……	……

б) на основе таблицы с основной информацией составляем систему бизнес-правил ПрО «Агентства по недвижимости»:

1. Агентство может владеть несколькими объектами под недвижимость.

2. Один и тот же клиент может брать в аренду или покупать несколько объектов недвижимости, если он может себе это позволить.

3. Недвижимость имеет фонд: жилой и нежилой.

4. Недвижимость может быть куплена или сдана в аренду.

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

6. Об агентстве известна информация: название, телефон и адрес.

7. Об клиенте известна информация: Ф.И.О, адрес, телефон, номер паспорта.

8. Один и тот же продавец занимается несколькими клиентами.

9. Цена за аренду зависит от срока пользования, от расположения и площади недвижимости.

10. У разных клиентов не может быть одинаковым номер паспорта, так как он индивидуален и не повторяется.

11. Об продавце известна такая информация: Ф.И.О., агентство к которому он относится и телефон.

12. О недвижимости имеется такая информация: агентство к которому относится, вид фонда, площадь и адрес нахождения этого объекта недвижимости.

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

14. Цена за аренду оплачивается сразу при заключение аренды.

15. При регистрации продажи должно быть учтено: номер недвижимости, которая будет куплена, номер клиента-покупателя, номер продавца, дата продажи и цена недвижимости.

Проанализировав систему бизнес-правил, получаем следующий глоссарий ПрО «Агентства по недвижимости»:

1. Агентство - это посредническое учреждение которое занимается недвижимостью «продажа - аренда».

2. Недвижимость - недвижимое имущество, состоящего из земельного участка строения.

3. Клиент - лицо, пользующееся услугами агентства по недвижимости.

4. Фонд - совокупность зданий, помещений, земель.

5. Продажа - вид услуги агентства занимающееся в передаче продавцом агентства клиенту за определенную плату.

6. Аренда - услуга агентства заключая во взятие какого-то имущества, земли, помещение во временное пользование, осуществляется за определенную плату.

7. Продавец - должностное лицо агентства занимающееся продажей и арендой недвижимости.

8. Площадь - величина недвижимости в длину и ширину, измеряемая в квадратных единицах.

9. Дата_начала - это день, месяц и год вступления клиента во временное пользование недвижимостью агентства.

10. Дата_окончания - это день, месяц и год прекращения права пользования клиентом недвижимостью агентства.

11. Цена - это денежное выражение стоимости недвижимости.

1.4 Разработка модели данных

При разработке любой информационной системы все необходимые элементы и структуры данных должны быть объединены в соответствующую модель данных. Такая модель данных представляет собой информационную модель определённой предметной области и служит для решения следующих задач:

1. Модель данных - это основа для создания соответствующей базы данных.

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

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

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

Одним из наиболее эффективных методов для этого является метод моделирования данных на концептуальном уровне с использованием ЕR - диаграмм. Рассмотрим сначала её основные понятия:

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

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

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

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

При построении ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь), в них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово «много» - m) и необходимое пояснение.

Между двумя, например, А и В сущностями возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В.

Второй тип - связь ОДИН-КО-МНОГИМ (1:N): одному представителю сущности А соответствуют 0,1 или несколько представителей сущности В.

Также между двумя сущностями возможны связи в обоих направлениях: существует еще два типа связи МНОГИЕ-К-ОДНОМУ (N:1) и МНОГИЕ-КО-МНОГИМ (N:M).

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

Для заданной ПрО:

а) выделены сущности (entities) - agency, client, sale, rent, salesman, building, foundation;

б) определены основные информационные атрибуты (attributes) всех сущностей;

в) определены ключевые атрибуты (key attributes): id_ agency, id_ client, id_sale, id_rent, id_salesman, id_building, id_foundation;

г) определены семантические отношения (relations) между сущностями, их размерность (1:1, 1:N, N:М) и типы принадлежности (обязательный, необязательный).

Концептуальная модель данных приведена в ПРИЛОЖЕНИЕ А.

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

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

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

- существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации;

- отсутствие необходимости ручной подготовки SQL-предложений для создания базы данных;

- возможность легко вносить изменения в модель при разработке и расширении системы;

- разработчики прикладного программного обеспечения снабжены удобными в работе диаграммами;

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

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

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

Реляционная модель в виде ER-диаграммы была разработана средствами CASE-средством Computer Associates Erwin 4.0 (ПРИЛОЖЕНИЕ В, C). Это средство было выбрано по той причине, что оно позволяет получить скрипт базы данных для СУБД. Данное средство является очень удобным для разработчиков баз данных и программистов. Оно позволяет автоматизировать работу по жизненному циклу разработки БД (разработка, документация, генерация кода).

1.5 Структура разработанной базы данных

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

- agency - сущность, представляющая собой информацию о агентстве;

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

- sale - сущность, представляющая собой информацию о продажи недвижимости;

- rent - сущность, представляющая собой информацию о аренде недвижимости у агентства;

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

- building - сущность, представляющая собой информацию о объекте недвижимости;

- foundation - сущность, представляющая собой информацию о виде фонда у недвижимости.

2. Проектирование и реализация информационной системы

2.1 Основы проектирования информационных систем

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

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

Главные компоненты системы:

1) данные;

2) аппаратное обеспечение;

3) программное обеспечение;

4) пользователи.

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

2.2 Информация о трехуровневой схеме программных сервисов в информационной системе

Возрастающие потребности в разработке сложных информационных систем, требуют выработку подходов и методов проектирования информационной системы, которые позволили сделать так, чтобы сложность процесса создания не возрастала экспоненциально от сложности проекта. На протяжении истории развития информационных технологий для решения этой проблемы предпринималось много попыток. Можно сказать, что даже если они и не приводили к окончательному успеху, однако они породили множество концепций и методик, которые позволили пройти на шаг вперед в решении этой проблемы. Первой попыткой стало решение общий код программы делить на функции. Второй попыткой было применение модельного программирования, то есть разделения всех функций по модулям. После этого возникло объектно-ориентированное программирование, которое предполагает выполнение трех основных принцип: инкапсуляции, наследования, полиморфизма. Сутью этого подхода является разделение функций по классам. Потом идею объектно-ориентированного подхода перенесли на проектирование сетевых приложений. В настоящее время следствием этого является наличие трехуровневой схемы программных сервисов[1]. Основная идея этой схемы является логическое разделение всей программы на три части:

1) уровень доступа и хранения данных (Data Access Layer)

2) уровень бизнес-логики (Business Logic Layer)

3) уровень представления данных (Data Presentation Layer)

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

2.3 Выбор архитектуры информационной системы

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

1) двухуровневая «клиент-сервер» с толстым клиентом - классическая архитектура информационных систем. Отличается тем, что функции бизнес-логики распределены по клиенту, серверу, причем большинство функций расположено на клиенте. Такие информационные системы характеризуется плохой масштабируемостью, то есть в какое-то время нагрузка на сервер достигает предела и как следствие это возникает невозможность работы новых клиентов, а также невозможностью модернизации и обновления сервера, так как это требует обновления всех клиентов, которые находятся в работе. Программный код сервисов бизнес логики СБД легче сопровождать и модифицировать на выделенном сервере БД (уменьшение затрат), уменьшается сетевой трафик за счет возможности получения на рабочей станции данных, которые получают по соответствующему запросу. Этот тип архитектуры представлен на рисунке 2.1.

Рисунок 2.1 - «Двухуровневая «клиент-сервер» с толстым клиентом»

2) двухуровневая «клиент-сервер» с тонким клиентом - в данном случае большая часть функций перенесена на уровень сервера, однако клиент все еще содержит набор бизнес-функций, и поэтому при данном подходе возникает невозможность простой модернизации сервера. С появлением Интернета возникает новый тип архитектуры

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

4)

Рисунок 2.2 - «Веб-ориентированная архитектура»

5) трехуровневая «клиент-сервер» с сервером приложений - данная архитектура очень похожа на веб-ориентированную, за тем исключением, что вместо веб-сервера используется сервер приложений. Эта архитектура также позволяет с успехом реализовать схему трехуровневых программных сервисов в информационной системе. Функции бизнес-логики можно разместить на сервере приложений, а функции представления данных - на клиенте. На рисунке 3.3 представлен такой тип архитектуры.

Рисунок 3.3 - «Трехуровневая архитектура с сервером приложений»

В данной курсовой работе была выбрана двухуровневая архитектура «клиент-сервер» с толстым клиентом.

3. Средства реализации программного обеспечения

3.1 Обзор средств реализации программного обеспечения

При реализации программного обеспечения использовались следующие средства разработки: СУБД MySQL, структурированный язык запросов SQL, Builder C++ 6.0.

3.2 СУБД MySQL

В качестве реляционной СУБД (системы управления базами данных) была выбрана система MySQL.

«MySQL - компактный многопоточный сервер баз данных. MySQL характеризуется большой скоростью, устойчивостью и легкостью в использовании. MySQL поддерживает язык запросов SQL в стандарте ANSI 92, и кроме этого имеет множество расширений к этому стандарту, которых нет ни в одной другой СУБД. «

Краткий перечень возможностей MySQL:

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

- количество строк в таблицах может достигать 50 млн.;

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

- простая и эффективная система безопасности.

Для обращения к базе данных используется SQL (Structured Query Language) - Структурированный Язык Запросов - стандартный язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры, и его прототип был разработан в конце 70-х годов в компании IBM Research. Он был реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот язык применялся во многих коммерческих СУБД и в силу своего широкого распространения постепенно стал стандартом «де-факто» для языков манипулирования данными в реляционных СУБД.

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

3.2 Описание методологии IDEF1X и автоматизированного средства проектирования Computer Associates ERWin 4.0

IDEF1Х (IDEF1 Extended) - методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе.

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

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

Для отображения отношений между сущностями используются связи.

Методология IDEF1X позволяет:

· эффективно описать систему бизнес-правил информационно-справочной системы;

· наиболее просто и прозрачно описывать объекты реальной модели и связи между ними;

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

· существуют автоматизированные средства, реализующие данную методологию (Computer Associates ERWin 4.0).

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

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

Автоматизированное средство проектирования Computer Associates ERWin 4.0 реализует методологию IDEF1X. В нем также содержаться средства визуального проектирования концептуальных моделей базы данных, как на логическом уровне, так и в привязке к конкретному типу СУБД.

Система ERwin - это программное средство из категории т.н. CASE (Computer-Aided Software Engineering) - систем для моделирования и проектирования баз данных (БД). Система ERwin поддерживает процесс проектирования модели данных, генерацию схемы БД на языке SQL для целевой системы управления базы данных (СУБД). Система Erwin позволяет также проводить реинжиниринг (reengineering) существующей БД. Сама аббревиатура названия системы - ERwin - указывает на то, что в основу ее функционирования положено представление о ER (Entity-Relationalship) - модели данных или модели «сущность-связь». Основным объектом работы пользователя системы являются модели данных в виде ER-диаграмм.

Применение системы ERwin существенно повышает эффективность разработки информационных систем. Среди основных преимуществ его использования можно назвать:

- повышение скорости разработки за счет мощного редактора ER-диаграмм, автоматической генерации схемы БД, автоматической подготовки документации;

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

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

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

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

С точки зрения классической теории моделирования данных в СУБД логическая модель системы ERwin представляет собой т.н. концептуальный уровень описания данных (Conceptual level), а физическая модель системы ERwin представляет собой т.н. логический уровень (Logical level).

3.3 Выбор языка программирования

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

Язык программирования Builder C++ 6.0 является мощным средством для разработки программного обеспечения. Ориентированный для разработки системных программ, в связи с чем имеет усовершенствованную адресную арифметику, большой набор операторов соответствующих непосредственным командам процессора. Но эти усовершенствования влекут за собой усложнения синтаксиса. В этом проекте, что является прикладной программой, все эти мощные механизмы остаются в стороне.

Из всего выше сказанного можно сделать вывод, что наиболее приемлемой средой разработки для данного проекта является Borland C++ Buiulder 6.

Были использованы следующин компоненты из вкладки Zeos Access:

­ TZConnection. Выполняет подключение к базе данных и управляет транзакциями (управляет соединением с сервером);

­ TZTable. Организовует доступ к отдельной таблице базы данных по её имени (соединяется с TZConnection);

­ TZQuery. Организовует доступ к одной или нескольким таблицам определенной базы данных в процессе выполнения команды SQL. Может выполнять любые команды SQL, в том числе SELECT, INSERT, DELETE, ALTER TABLE, но с помощью этой компоненты нельзя выполнить SQL-выражения, которые не возвращают набор записей;

Остальные:

­ TDataSource - предназначен для связывания визуальных компонентов с компонентами - источниками данных (соединяется с TZTable или TZQuery);

­ TDBGrid - сетка (соединяется с TDataSource).

Программа с компонентом TZConnection <-> клиентская библиотека libmysql.dll <-> сервер MySQL

4. Разработка и использование программного обеспечения

4.1 Стадии процесса разработки программного продукта

Прежде чем приступить к разработке программного обеспечения необходимо было установить на рабочей станции необходимое программное обеспечение: SQL Server 5.0.21, SQL Server Configuration Manager, EMS SQL Manager 2005., Builder C++ 6.0, инсталляцию библиотеки компонентов Zeos для C++Builder 6.0.

4.2 Работа пользователя с программным обеспечением

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

Рисунок 4.1 - Главная форма программы

С помощью меню «Файл» можно выйти из программы.



Рисунок 4.2 - Использование меню «Файл»

С помощью меню «Таблица» можно выбрать таблицу, которую вы желаете просмотреть.

Рисунок 4.3 - Использование меню «Таблица»

Например, вы хотите просмотреть таблицу «Агентства»:

Рисунок 4.4 - Просмотр таблицы «Агентство»

Также на главной форме в специальном месте можно писать запросы, это может делать только администратор. Для выполнения запросов типа SELECT необходимо нажать кнопку «Показать», а для INSERT, UPDATE, DELETE - кнопку «Выполнить».

Пример такого запроса SELECT вместе с результатом приведен на рисунке 4.5.

Рисунок 4.5 - Просмотр результата запроса SELECT

Пример написания запроса INSERT приведен на рисунке 4.6.

Рисунок 4.6 - Пример написания запроса INSERT

4.3 Минимальные требования к аппаратному обеспечению пользователя

информационный реляционный база данный

При работе с программным обеспечением информационно-справочной системы «Агентства недвижимости», следует соблюдать следующие требования к аппаратному и программному обеспечению компьютера:

1) Microsoft Windows 2000/XP/NT4.0;

2) Процессор Pentium 1Hz или совместимый;

3) Оперативная память 256 Mb;

4) Монитор SVGA True Color 800x600 (лучше True Color 1024x768);

5) Клавиатура;

6) Мышь;

7) СУБД MySQL 5.0.21;

8) C++Builder

Заключение

В результате выполнения данного курсового проекта была создана информационная система, на основе предметной области «разработка информационно-справочной системы для автоматизированного управления процесса работы агентства недвижимости», была разработана система бизнес-правил и составлен глоссарий проекта, разработана и исследована модель данных по заданной ПрО, которая после была сгенерирована в СУБД My SQL 5.021.

После была разработана концептуальная модель данных «сущность-связь» с использованием метода построения ER/EER диаграмм. Также была проделана процедура преобразования полученной информационно-логической модели в схему реляционной модели базы данных с использованием правил преобразования.

После чего полученная модель была сгенерирована в СУБД My SQL 5.021. На языке SQL были записаны запросы.

Предложенная модель данных позволяет получать информацию о проведенных в агентстве операциях: о клиентах, продаже, покупке и т.п. Модель реализована в виде ER-диаграмм в системе ERwin с возможностью воспроизведения в виде таблиц в системе My SQL 5.021, что позволяет наглядно и просто демонстрировать все данные, изменять их, удалять их без потери другой информации, добавлять новые данные. Таким образом, она предельно проста в применении и может быть использована пользователями с разными уровнями знаний компьютерной техники.

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

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

1. Хомоненко А.Д., Цыганков В.М. и др. Базы данных: учебник для высших учебных учреждений. - С. Пб.: «Корона принт», 2002

2. Маклаков С.В.BPwin и ERwin: CASE - средства разработки информационных систем. - М.: «Диалог - МиФи», 2000

3. Информатика. Под ред. Макаровой Н.В. СПб, 1998

4. Конолли Т. и др. Базы данных: проектирование, реализация и сопровождение. - М. «Вильямс», 2001. (2003) - 1120 с.

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