Разработка и проектирование базы данных агенства недвижимости ТОО «Камила»

Содержание
1 Этап начальной разработки и планирования ..................................................... 14
1.1 Постановка задачи ............................................................................................. 14
1.2 Анализ предметной области ............................................................................. 14
1.3 Задачи проектирования базы данных .............................................................. 15
1.4 Структура агентства........................................................................................... 15
2 Формирование концептуальной модели ............................................................. 16
2.1 Сущности ............................................................................................................. 16
2.2 Типы отношений ................................................................................................ 18
2.3 Выбор и построение модели ............................................................................ 18
2.2.1 Выбор модели.............................................................................................. 18
2.2.2 Составление реляционных отношений.................................................... 21
2.4 Нормализация с помощью метода ER-диаграмм........................................... 25
2.5 Расчет места, занимаемого БД........................................................................ 27
3 Проектирование и разработка программного обеспечения.............................. 34
4 Безопасность жизнедеятельности........................................................................ 52
4.1 Анализ труда........................................................................................................ 52
4.1.1 Рабочее помещение...................................................................................... 52
4.1.2 Параметры оборудования ......................................................................... 54
4.2 Освещение рабочего места................................................................................. 55
4.2.1 Расчет искусственного освещения ............................................................ 55
4.3 Кондиционирование ......................................................................................... 57
5 Технико-экономическое обоснование ................................................................ 60
5.1 Определение затрат на создание программного продукта ........................... 60
5.2 Трудовые ресурсы используемые в проекте .................................................. 60
5.3 Оборудование, используемое в работе ........................................................... 61
5.4 Программное обеспечение, используемое в разработке................................ 61
5.5 Сроки реализации проекта ............................................................................... 61
5.6 Расчет стоимости работы по проектированию и разработке ....................... 62
5.6.1 Расчет затрат на оплату труда ................................................................... 63
5.6.2 Расчет затрат по социальному налогу ..................................................... 67
5.6.3 Расчет амортизационных отчислений ...................................................... 67
5.6.4 Расчет затрат на электроэнергию ............................................................. 68
5.6.5 Расчет накладных и прочих расходов...................................................... 69
5.8 Цена интеллектуального труда ........................................................................ 70
Заключение ................................................................................................................ 72
Приложение А ........................................................................................................... 73
Список литературы ................................................................................................... 74

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

1.1 Постановка задачи
Разработать структуру базовых таблиц (не менее четырех) базы данных
агентство недвижимости.
Данная БД содержит информацию:
- сведения о недвижимости;
- сведения о клиентах: фамилия, имя и отчество, адрес, телефон,
стоимость недвижимости или аренды недвижимости;
- сведения о сотрудниках: фамилия, имя и отчество сотрудника;
- сведения об операциях с недвижимостью.
Распределим эту информацию по трем таблицам:Клиенты,Недвижимость, Операции, Сотрудники.
1.2 Анализ предметной области
База данных разрабатывается для агентства недвижимости ТОО
«Камила». Данное приложение будет использоваться в этом агентстве всеми
сотрудниками и обычными пользователями.
Цель создания программы состоит в следующем:
- сокращение времени обработки информации;
- простоте реализации различных запросов и скорости обработки
данных;
- автоматизации труда.
Анализ предметной области обычно осуществляется:
- на основании существующих сведений о предметной области в
широком или узком смысле, то есть в масштабах, в которых она должна быть
представлена в создаваемой БД и работающих с ней приложениях;
- исходя из целей проектирования программной системы;
- на основании представления о том, какое место БД и работающие с ней
приложения займут в структуре эксплуатирующей ее организации;
- на основании представлений о том, какие изменения потоков
организации последуют после внедрения программной системы в эксплуатацию.
В конечном итоге анализ предметной области должен привести к
созданию эскиза БД. Сначала желательно изобразить сущности и связи между
ними. Как правило, каждой сущности в БД соответствует таблица. Затем - в
эскизе второго порядка - для каждой таблицы БД приводится список полей
записи.
1.3 Задачи проектирования базы данных

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

1.4 Структура агентства
Работа агентства недвижимости ТОО «Камила» подразделяется на
несколько направлений:
- квартира;
- участок;
- дома;
- офисы.
Агентство недвижимости - компания, специализирующаяся на оказании
риэлторских услуг на рынке жилой недвижимости.
2 Формирование концептуальной модели
2.1 Сущности

При проектировании структуры новой базы данных определяют
сущности предметной области, которые должны найти своё отражение в базе
данных.
Вначале необходимо изобразить сущности и связи между ними. Как
правило, каждой сущности (объекту) в базе данных соответствует таблица.
Затем для каждой таблицы базы данных приводится список полей записи.
Начальная стадия проектирования включает в себя анализ объектов
реального мира, которые будут отражены в базе данных.
Формирование концептуальной модели базы данных включает в себя [1]:
- идентификацию функциональной деятельности предметной области;
- идентификацию объектов (сущностей), которые осуществляют эту
функциональную деятельность, и формирование из их операций
последовательности событий, которые помогут идентифицировать все
сущности и взаимосвязи между ними;
- идентификацию характеристик этих сущностей;
- идентификацию взаимосвязей между сущностями;
- функциональную деятельность и формирования из их операций.
В качестве предметной области данного курсового проекта
рассматривается база данных "Агентство недвижимости" для фирмы,
занимающейся коммерческой деятельностью в сфере недвижимости.
Из выше сказанного следует, что для правильного анализа
функциональной деятельности организации, а также для последующего
выделения объектов и описания их атрибутов, необходимо детально изучить
процесс подачи заявки на приобретение или продажу недвижимости для
отдельно взятого клиента.
Происходит это следующим образом: клиент, желающий продать либо
купить недвижимость, обращается в агентство по продаже недвижимости.
Здесь он общается непосредственно с оператором (сотрудником фирмы),
который в свою очередь со слов клиента, а также на основании нескольких
документов, составляет заявку на покупку или продажу (исходя из пожеланий
клиента) недвижимости. Заявку можно разделить на две основные части -
учётную карточку клиента и учётную карточку объекта недвижимости.
Остановимся более подробно на этих двух документах.
В агентство недвижимости могут обращаться разные клиенты, как
физические лица, так и юридические. Соответственно документы, подаваемые
для составления заявки от разных клиентов, будут различными. В соответствии
с законодательством, основными документами для проведения операций по
продаже - покупки недвижимости для физического лица являются паспорт и
карточка физического лица - платящего налоги (идентификационный код).
Паспорт удостоверяет личность клиента, а наличие идентификационного кода
позволяет гарантировать уплату налогов от проведённых операций государству.
Для юридических лиц законодательство предусматривает также два основных
вида документов. Это "Свидетельство о регистрации" и номер банковского
счёта.
Следовательно, для клиента физического лица в заполняемой карточке
должны находиться следующие пункты: номер по порядку, тип клиента (в
данном пункте выбирается тип клиента из двух возможных вариантов -
покупатель или продавец, в зависимости от того, продаёт клиент недвижимость
или хочет приобрести), код клиента (уникальный код клиента, в котором
отображён порядковый номер клиента, его тип, а также номер заявки).
Например: код 1ПР1 - это значит, что номер клиента по порядку 1, ПР -
обозначает, что клиент продавец, в случае покупателя ПР изменяется на ПК, 1 -
номер заявки, следовательно, клиенты обращается в фирму в первый раз),
фамилия и инициалы клиента, адрес по которому проживает клиент, телефон
клиента, серия и номер паспорта, а также идентификационный код.
В случае юридического лица учётная карточка аналогична, за
исключением пунктов серия номер паспорта и идентификационный код,
которые заменяются номером регистрационного свидетельства и номер
банковского счёта соответственно. Второй составной частью заявки является
учётная карточка объекта недвижимости.
Для различных клиентов, будь-то физическое лицо или юридическое,
покупатель или продавец она (учётная карточка) будет состоять из одних и тех
же пунктов. Пунктов характеризующих особенности отдельно взятого объекта.
А именно код клиента (код клиента, который продаёт данный объект либо
хочет купить такой объект), код заявки (номер заявки данного клиента), дата
составления заявки, а далее следуют пункты, непосредственно
характеризующие объект, на основании которых, возможный покупатель
сделает вывод, подходит ему данный объект или нет. Это название объекта, его
площадь, этаж на котором расположен, количество комнат, адрес объекта и
цена.
После того как оператор зарегистрировал клиента в базе данных
агентства, он (оператор) производит поиск наиболее подходящего варианта для
этого клиента. В случае успешного поиска будет произведена операция
продажи-покупки объекта и начислена прибыль агентства. В обратном же
случае, будет проводиться поиск в соответствии с поступлением новых заявок и
в случае успешного поиска, клиент будет уведомлён по телефону и приглашён
для заключения сделки.
Из выше рассмотренного случая в качестве функциональной
деятельности определяется необходимость выдачи информации о клиентах
фирмы (будь-то покупатели или продавцы), составление заявок на покупку
определённого вида недвижимости либо на её продажу. Формирование отчётов,
отображающих результаты работы фирмы (списки выполненных операций за
определённый временной промежуток, список заявок на покупку, список заявок
на продажу, количество клиентов покупателей и т. д.).
В созданной базе данных существуют 3 объекта:
- дома;
- квартиры;
- участки.

2.2 Типы отношений

Между атрибутами вышеперечисленных объектов существуют 2 типа
отношений:
"Один-ко-многим" - отношение имеет место, когда одной записи
родительской таблицы может соответствовать несколько записей в дочерней
таблице. Различают две разновидности связи "Один-ко-многим" - в первом
случае выдвигается жесткое требование, согласно которому всякой записи в
родительской таблице должны соответствовать записи в дочерней таблице. Во
втором случае некоторые записи в записи родительской таблице могут не иметь
связанных с ними записей в дочерней таблице.
К данному типу относятся отношения между атрибутами:
Связи между остальными атрибутами объектов определены как "многие-
ко-многим".
"Многие-ко-многим" - отношение имеет место, когда:
записи в родительской таблице может соответствовать больше одной
записи в дочерней таблице;
записи в дочерней таблице может соответствовать больше одной
записи в родительской таблице.
Многие СУБД не поддерживают связи "многие-ко-многим" на уровне
индексов и ссылочной целостности, хотя и позволяют реализовывать ее в
таблицах неявным образом. Аналогично, многие CASE - средства (программы
для разработки структуры базы данных в виде диаграмм и генерации на их
основе физической базы данных) также не позволяют определять эту связь
между таблицами проектируемой базы данных. Считается, что всякая связь
"многие-ко-многим" может быть заменена на одну или более связь "один-ко-
многим".

2.3 Выбор и построение модели

2.2.1 Выбор модели

На сегодняшний день наиболее часто используются три модели данных:
иерархическая, сетевая и реляционная. Кроме них существуют и другие
модели, например модель данных, основанная на инвертированных списках или
объектно-ориентированная, однако они не имеют широкого распространения,
так как базы на инвертированных списках использовались на заре развития
СУБД, а объектно-ориентированные базы данных ещё не до конца изучены.
Таким образом, выбор сокращается до трёх вышеназванных моделей данных.
Иерархические базы данных. Этот вид баз данных одним из первых
получил широкое распространение и стал промышленно использоваться.
Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из
упорядоченного набора нескольких экземпляров одного типа дерева. Тип
дерева состоит из одного "корневого" типа записи и упорядоченного набора из
нуля или более типов поддеревьев (каждое из которых является некоторым
типом дерева). Тип дерева в целом представляет собой иерархически
организованный набор типов записи. Примерами типичных операторов
манипулирования иерархически организованными данными могут быть
следующие операторы:
- найти указанное дерево БД;
- перейти от одного дерева к другому;
- перейти от одной записи к другой внутри;
- перейти от одной записи к другой в порядке обхода иерархии;
- вставить новую запись в указанную позицию;
- удалить текущую запись.
Одним из основных преимуществ иерархической модели данных является
скорость поиска по базе.
Типичным представителем (наиболее известным и распространенным)
является Information Management System (IMS) фирмы IBM. Первая версия
появилась в 1968 г. До сих пор поддерживается много баз данных, что создает
существенные проблемы с переходом, как на новую технологию БД, так и на
новую технику.
Сетевая модель данных. Сетевой подход к организации данных является
расширением иерархического подхода. В иерархических структурах запись-
потомок должна иметь в точности одного предка; в сетевой структуре данных
потомок может иметь любое число предков. Сетевая БД состоит из набора
записей и набора связей между ними, а если говорить более точно: из набора
экземпляров каждого типа из заданного в схеме БД набора типов записи и
набора экземпляров каждого типа из заданного набора типов связи.
Тип связи определяется для двух типов записи: предка и потомка.
Экземпляр типа связи состоит из одного экземпляра типа записи предка и
упорядоченного набора экземпляров типа записи потомка. Для данного типа
связи L с типом записи предка P и типом записи потомка C должны
выполняться два условия:
- каждое экземпляр типа P является предком только в одном экземпляре
L;
- каждый экземпляр C является потомком не более чем в одном
экземпляре L.
На формирование типов связи не накладываются особые ограничения;
возможны, например, ситуации:....