АРМ менеджера по продаже недвижимости (стр. 2 из 6)
- База данных должна удовлетворять актуальным информационным потребностям организации. Получаемая информация должна по структуре и содержанию соответствовать решаемым задачам.
- База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.
- База данных должна удовлетворять выявленным и вновь возникающим требованиям всех пользователей.
- База данных должна легко расширяться при реорганизации и расширении предметной области.
- База данных должна легко изменяться при изменении программной и аппаратной среды.
Для разработки инфологической модели предметной области необходимо выделить информационные объекты и их атрибутивный состав.
На основании обследования предметной области выделим следующие сущности с атрибутами (ключевые атрибуты выделены подчеркиванием)
Сотрудники: (RNN_SOTR, FAM_SOTR, NAME_SOTR, OTH_SOTR, ADRES_SOTR, TELEFON_DOM, TELEFON_SOT, DOLGNOST, FOTO, DOP);
Клиенты: (RNN_KL, FIO_KL, ADRES_KL, TELEFON_DOM, TELEFON_SOT);
Предложения: (ID_KV, RNN_KL, KOL_KOM, ZENA, ULIZA, DOM, KV, ETAG, TELEFON, BALKON, LIFT, REMONT, PLOSHAD, STATUS, DOP);
Сделки: (ID_SDELKY, RNN_POKUP, RNN_PROD, RNN_SOTR, SUMMA, OPLATA_USLUG, DATA);
После выбора сущностей, задания атрибутов и анализа связей между сущностями проектируем инфологическую модель в виде ER-диаграммы, представленную на Рис.1.
 | |
 | |
Рис.1 - Инфологическая модель предметной области
1.2. Проектные решения по информационному обеспечению
Любая автоматизированная система предполагает наличие в своем составе подсистемы информационного обеспечения, питающая другие подсистемы данными, на основе которых осуществляется принятие решений, включая их оптимизацию с использованием математических методов и ЭВМ.
Для проектирования будет использована реляционная модель данных, так как в реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой модели. Предсказуемость результатов работы с данными обеспечивается математической моделью данных, которая лежит в основе реляционной модели. Любой запрос, составленный на конкретном языке, влечет ответ, однозначно определенный схемой данных и конкретными данными. Выбранная предметная область достаточно естественно описывается в терминах отношений, нет излишнего дублирования записей. Модель наглядна и при необходимости можно осуществить доступ к данным любого уровня.
На основании вышеизложенного можно сделать вывод, наиболее эффективной моделью данных для отображения выбранной предметной области и реализации запросов пользователя является реляционная модель.
1.3. Проектные решения по программному обеспечению
Программное обеспечение должно соответствовать стандартам Windows. Программное приложение должно позволять формировать запросы к данным с помощью простых визуальных средств настройки, должно организовывать возможность быстро находить нужную запись, если известно только содержание нескольких полей, с целью сокращение затрат времени пользователя.
Программное приложение должно поддерживать русский интерфейс, быть приложением Windows.
Данная разработка должна соответствовать следующим требованиям:
- защита информации от несанкционированного доступа;
- оперативность информационного обмена и управления;
- рациональная организация информационных фондов;
- квалификация специалистов, участвующих в процедурах обработки информации.
Приложение должно включать в себя дружественный интерфейс, который подразумевает под собой всплывающие подсказки, и справки доступные пользователю во время работы с приложением.
2. Разработка автоматизации рынка недвижимости
2.1. Информационное обеспечение комплекса задач
2.1.1. Инфологическая модель, схема данных и ее описание
Для проектирования схемы данных, необходимо привести отношения к 3НФ необходимо провести анализ функциональных зависимостей между атрибутами в пределах каждого отношения.
1. Сотрудники: (RNN_SOTR, FIO_SOTR, ADRES_SOTR, TELEFON_DOM, TELEFON_SOT, DOLGNOST, FOTO, DOP).
Учет сотрудников ведется с помощью РНН сотрудника. Атрибут RNN_SOTR – уникален и является первичным ключом. Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
Первичный ключ – простой и функциональная зависимость всех не ключевых атрибутов от первичного ключа – полная, следовательно, отношения находятся во 2НФ.
Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.
2. Клиенты: (RNN_KL, FIO_KL, ADRES_KL, TELEFON_DOM, TELEFON_SOT).
Учет клиентов ведется с помощью РНН клиентов. Атрибут RNN_KL – уникален и является первичным ключом. Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
Первичный ключ – простой и функциональная зависимость всех не ключевых атрибутов от первичного ключа – полная, следовательно, отношения находятся во 2НФ.
Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.
3. Предложения: (ID_KV, RNN_KL, KOL_KOM, ZENA, ULIZA, DOM, KV, ETAG, TELEFON, BALKON, LIFT, REMONT, PLOSHAD, STATUS, DOP).
Учет поступающих предложений ведется по коду квартиры. Атрибут ID_KV – уникален и является первичным ключом. Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
Первичный ключ – простой и функциональная зависимость всех не ключевых атрибутов от первичного ключа – полная, следовательно, отношения находятся во 2НФ.
Все не ключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.
4. Сделки: (ID_SDELKY, RNN_POKUP, RNN_PROD, RNN_SOTR, SUMMA, OPLATA_USLUG, DATA).
5. Учет совершаемых сделок ведется по коду сделки. Атрибут ID_SDELKY – уникален и является первичным ключом. Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
Первичный ключ – простой и функциональная зависимость всех не ключевых атрибутов от первичного ключа – полная, следовательно, отношения находятся во 2НФ.
Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.
Таким образом, в результате приведения отношений к 3НФ получили следующие отношения КЛИЕНТЫ, СОТРУДНИКИ, СДЕЛКИ, ПРЕДЛОЖЕНИЯ. На Рис.2 представлена схема данных после нормализации отношений.
Рис.2- Схема данных предметной области после нормализации
2.1.2. Используемые классификаторы и системы кодирования
Классификацией информации называется упорядоченное расположение значений единиц информации. Система классификации характеризуется как совокупность правил и результат деления заданного множества на подмножества по одному или нескольким признакам. Полученные в результате деления подмножества называются классификационныи группировками: классы, подклассы, группы, подгруппы и др.
После классификации выполняется кодирование информационных единиц, согласно выбранной системе, в результате чего определенные условные обозначения присваиваются конкретным элементам экономических номенклатур. При кодировании информации на практике в большинстве случаев применяются порядковый, серийный и позиционный коды.
В справочниках «Статус» и «Должность» будет использоваться порядковая система кодирования, она предпологает последовательное присвоение единицам информации кодов, которые выражаются числами натурального ряда в возрастающем или убывающем порядке либо алфавитными символами. Кодирование будет организовано посредством чисел натурального ряда в возрастающем порядке.
При построении кодов учитывается ряд требований. Коды должны быть минимальными по длине, максимально логичными по структуре, легко воспринимаемыми зрительно, обеспечивать удобство и эффективность обработки информации, автоматическую группировку и получение итогов по нужным классификационным признакам, быстрый поиск данных.
В таких справочниках как, «Справочник о сотрудниках» и «Справочник о клиентах» используется единый казахстанский классификатор Регистрационных Номеров Налогоплательщиков (РНН). Этот класификатор является стандартным и относится к разряду серийных классификаторов.
2.1.3. Характеристика входной, выходной и нормативно-справочной информации
В системе можно выделить входную, нормативно-справочную и выходную информацию.
Входная информация представлена в виде документа «Заявка на оказание услуг». В этом документе указываются такие данные как: РНН клиента, Ф.И.О. клиента, телефон домашний, телефон сотовый, адрес клиента, количество комнат, адрес квартиры, этаж, цена квартиры. Указывается статус заявки (покупка или продажа), если заявка на продажу квартиры указывается, есть ли наличие лифта, балкона, телефона и ремонта.
Нормативно-справочной информацией являются следующие справочники:
Справочник «Статус продаж», содержит информацию о том, какой статус имеет квартира (продается, покупается, продано).
Справочник «Должность сотрудника», содержит информацию о том, какую должность занимает сотрудник.
Справочник «Сотрудники», содержит информацию о сотрудниках.
Справочник «Клиенты», содержит информацию о клиентах.
Выходная информация представлена в виде документа «Договор на оказание посреднических услуг». В этом документе указываются такие данные как: дата составления, Ф.И.О. сотрудника, Ф.И.О. клиента, РНН клиента, количество комнат, адрес квартиры, этаж. Указывается, есть ли наличие лифта, балкона, телефона и ремонта. Так же указывается стоимость квартиры и размер оплаты услуг агентства.