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

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

ОГЛАВЛЕНИЕ

• ВВЕДЕНИЕ
• 1. СИСТЕМНЫЙ АНАЛИЗ
• 1.1 Актуальность задачи
• 1.2 Выбор средств разработки
• 1.3 Выбор базы данных
• 1.4 Описание работы информационной системы
• 1.5 Анализ существующих программных продуктов
• 1.6 Постановка задачи
• 2. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
• 2.1 Разработка функциональной структуры подсистемы
• 2.2 Обоснование выбора архитектуры базы данных и СУБД
• 2.2.1 Выбор архитектуры базы данных
• 2.2.2 Обоснование выбора СУБД
• 2.3 Разработка мер по защите информации
• 2.4 Моделирование потоков данных (DFD диаграмм)
• 2.5 Проектирование инфологической модели данных с использованием модели «сущность-связь»
• 3. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
• 3.1 Выбор web-сервера
• 3.2 Технология ASP.NETMVC 4
• 3.3 Технология JavaScript
• 3.4 Физическое моделирование системы
• 3.5 Комплекс необходимых программных средств
• 3.6 Функции, используемые в системе агентства недвижимости
• 3.7 Сценарий диалога пользователя с системой
• 4. ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ
• 4.1 Технико-экономическое обоснование необходимости разработки информационно - аналитической системы агентства недвижимости «Центр жилья»
• 4.2 Планирование разработки
• 4.2.1 Календарное планирование
• 4.2.2 Организационный, юридический и финансовый аспекты разработки
• 4.3 Стоимостная оценка проекта
• 4.4 Формирование цены разработки
• 4.5 Анализ экономической целесообразности внедрения объекта проектирования
• 5. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ А. ЛИСТИНГ ПРОГРАММЫ

ВВЕДЕНИЕ

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

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

1. СИСТЕМНЫЙ АНАЛИЗ

1.1 Актуальность задачи

Благодаря автоматизации работы агентства, могут быть выделены выделены следующие положительные моменты:

1) Полное отсутствие бумажной работы с частью поиска подходящих объявлений: не нужно будет описывать каждое объявление, чтобы потом можно было рассказать о нем клиенту.

2) Перенос части работы агентства по поиску подходящих вариантов на пользователя: он сам ищет подходящее объявление, а агенту сообщает лишь номер этого объявления.

3) Благодаря разделению ролей на сайте, агент может узнать всю информацию о необходимой квартире на сайте агентства.

1.2 Выбор средств разработки

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

При выборе средств разработки необходимо учесть следующие особенности проекта:

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

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

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

Наиболее распространенным, удобным и подходящим средством разработки является программный продукт MSVisualStudio. В качестве языка программирования будем использовать C#, а в качестве архитектуры - MVC, в последнее время ставшую весьма популярной среди разработчиков.

MVC (Model-view-controller, «Модель-представление-поведение») - схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные. Данная схема проектирования часто используется для построения архитектурного каркаса, когда переходят от теории к реализации в конкретной предметной области.

1.3 Выбор базы данных

Для выбора СУБД рассмотрим следующие критерии, которые являются существенными для выполнения требований к разрабатываемому проекту:

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

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

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

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

- не гибкий дизайн логической структуры;

2. Метод запросов. Запрос - это формализованный способ выражения информационных потребностей пользователем системы. Методы запросов:

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

- независимость от конкретной СУБД. Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов могут быть достаточно легко перенесены из одной СУБД в другую;

- декларативность. С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса;

- Объектный язык запросов - намного легче SQL, что является важным преимуществом для большинства задач, предоставляет разработчику те же возможности что и SQL;

- TSQL -- имеет ряд дополнительных возможностей по сравнению с SQL:

- управляющие операторы;

- локальные и глобальные переменные;

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

- поддержка аутентификации Microsoft Windows;

3. Манипулирование наборами данных на сервере.

MapReduce - модель распределённых вычислений, представленная компанией Google, используемая для параллельных вычислений над очень большими наборами данных в компьютерных кластерах. Преимущество:

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

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

4. Поддерживаемые операционные системы - является важным критерием, так как возможность установки сервера на операционной системе семейства Unix влияет на стоимость использования системы и на защищённость системы от возможных атак;

5. Лицензия - влияет на конечную стоимость продукта;

6. Модель хранения данных:

- реляционная таблица. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы - один элемент данных;

- все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.);

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

- JSON (англ. JavaScript Object Notation) - текстовый формат обмена данными, основанный на JavaScript. За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур. Если говорить о веб-приложениях, в таком ключе он уместен в задачах обмена данными как между браузером и сервером, так и между самими серверами. Формат JSON также хорошо подходит для хранения сложных динамических структур в реляционных базах данных или файловом кэше;

- BSON (англ. Binary JavaScript Object Notation) это компьютерный формат обмена данными. Это бинарная форма представления простых структур данных и ассоциативных массивов(которые называют объектами или документами). В сравнении с JSON, BSON является эффективным как в плане размера хранения данных, так и сканирования. Большие элементы в документе BSON имеют префикс с длинной документа для облегчения сканирования;

7. Производительность -- количество запросов которое база данных может обработать в заданный промежуток времени.

Выдвинутым требованиям удовлетворяет многим известная СУБД MSSQL. Она будет использована для работы с базой данных. Непосредственно для извлечения и сохранения данных будет использоваться EntityFramework, который позволяет работать с базой данных даже без SQLзапросов, посредством linqзапросов. Хотя в конечном итоге linqзапрос представляет собой SQLзапрос, программисту нет необходимости составлять SQLзапрос, хотя знать этот язык нужно для составления linqзапросов, так как они похожи между собой.

1.4 Описание работы информационной системы

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

Также, на сайте будет предусмотрена система авторизации и аутентификации пользователей для разделения ролей пользователей. Это нужно для возможности администрирования БД администратором, для возможности размещения пользователем объявлений, для просмотра гостем объявлений.

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

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

Кроме основной таблицы, в базе данных будут таблицы-справочники. Они будут содержать информацию о районах в городе, типах недвижимости и т.д. В таких таблицах будет всего 2 поля: ID и Name. Все идентификаторы во всей базе данных будут типа GUID (Globally Unique Identifier). Это статистически уникальный 128-битный идентификатор. Его главная особенность -- уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3,4028Ч1038), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала. В тексте GUID записывается в виде строки из тридцати двух шестнадцатеричных цифр, разбитых на группы дефисами, и окружённой фигурными скобками:

{6F9619FF-8B86-D011-B42D-00CF4FC964FF}

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

1.5 Анализ существующих программных продуктов

Аналогичные проекты:

1) В Новочеркасске существует агентство недвижимости «Давиденко и Ко». Его сайт расположен по адресу http://davidenko-estate.ru/. Его интерфейс представлен на рисунке 1.

Здесь мы видим слева панель для связи с работниками агентства, справа - весь основной интерфейс. Имеется возможность выбора типа недвижимости: квартира, дом, гараж, гостинка, комната в коммуналке, дача, малосемейка, часть дома, земельный участок, коммерческие объекты. Также можно выбрать ориентировочную цену, кол-во комнат, ориентир. Говоря о ползунке количества комнат, можно сказать, что верхняя граница его чересчур завышена, так как 260 комнат в доме или квартире трудно даже представить, не говоря уже о необходимости такого поиска. Далее, при клике по любому из типов недвижимости сразу можно увидеть все результаты для соответствующего типа, что вполне логично. Это показано на рисунке 2.

Рис. 1. Интерфейс сайта АН «Давиденко и Ко».

Рис 2. Результат поиска квартиры в АН «Давиденко и Ко»

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

2) Агентство недвижимости «Ключ-Н». Почему-то данное агентство имеет сайт, названием никак не связанный с названием агентства. Сайт доступен по адресу http://domnadonu.ru/. Его интерфейс представлен на рисунке 3.

Рис 3. Интерфейс сайта АН «Ключ-Н»

Трудно себе представить более неудачный интерфейс. Чтобы узнать, как им пользоваться, нужно прочитать инструкцию, которая «висит» на главной странице. Выбор типа недвижимости, района, кол-ва комнат - все это перепутано вместе, и пользоваться этим совершенно невозможно. Однако, это еще не самый главный недостаток. Справа расположена панель выбора квартир. Если опуститься примерно на 1,5-2 экрана вниз, где заканчивается панель с инструкцией, список выбора квартир все еще длится. Это показано на рисунке 4.

Рис 4. Расположение панелей на сайте АН «Ключ-Н».

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

3) Сайт «slando». Его раздел для Новочеркасска расположен по адресу http://novocherkassk.ros.slando.ru/nedvizhimost/arenda-kvartir/. Он имеет достаточно незатейливый интерфейс, представленный на рисунке 5.

Рис 5. Интерфейс сайта «slando.ru».

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

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

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

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

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

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

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

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

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

Программный интерфейс обычного пользователя должен предоставлять возможность:

- Искать походящее объявление;

- Оставить заявку на осмотр квартиры с агентом;

Программный интерфейс зарегистрированного пользователя должен предоставлять возможность:

- Просматривать те же данные, что и обычный пользователь;

- Разместить объявление на сайте

Программный интерфейс администратора системы должен предоставлять возможность:

- Управлять информацией в БД.

Приложение должно находиться на хостинге, поддерживающем приложения с архитектурой MVC4, а также СУБД MSSQL.

2. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ

2.1 Разработка функциональной структуры подсистемы

Информационно-аналитическая система агентства недвижимости представляет собой программный продукт,рассчитанный на повышение эффективности функционирования компании и качества обслуживания. Основными плюсами будут:

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

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

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

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

- система разделения ролей;

- аутентификация и авторизация на сайте;

- ведение базы данных

- поиск объявлений;

- размещение и редавтирование объявлений в системе.

Все перечисленные функции система выполняет, опираясь на базу данных. Архитектура «клиент - сервер» предоставляет удаленный доступ к базе. Используется тонкий клиент, что позволяет не использовать стороннее ПО клиентами, работниками, администраторами.

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

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

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

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

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

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

- предоставление интерфейса для работы с данными.

Клиентское приложение - это часть системы, которую пользователь использует для взаимодействия с данными. Клиентские приложения в СУБД клиент-сервер выполняют следующие задачи:

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

- выполнение логики приложения, например, вычисление полей в форме ввода данных.

- проверка допустимости данных.

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

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

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

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

Рис 2.1. Функциональная схема информационно-аналитической системы

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

На рисунке 2.2 представлена блок-схема алгоритма работы информационно-аналитической системы.

Рис 2.2. Блок-схема алгоритма работы системы.

2.2 Обоснование выбора архитектуры базы данных и СУБД

2.2.1 Выбор архитектуры базы данных

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

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

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

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

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



Рис 2.3. Блок-схема алгоритма работы взаимодействия клиента и сервера.

К преимуществам клиент-серверной архитектуры:

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

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

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

Недостатки:

- неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

- поддержка работы данной системы требует отдельного специалиста - системного администратора;

- высокая стоимость оборудования.

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

Достоинства:

- толстый клиент обладает широким функционалом, в отличие от тонкого;

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

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

- имеет возможность подключения к базамбез использования сети Интернет;

- высокое быстродействие.

Недостатки:

- большой размер дистрибутива;

- многое в работе клиента зависит от того, для какой платформы он разрабатывался;

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

- довольно сложный процесс установки и настройки;

- сложность обновления и связанная с ней неактуальность данных;

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

Web-клиент как программа - это браузер. Web-клиент как устройство - это устройство, основным приложением которого (с точки зрения разработчика устройства или маркетолога) является браузер.

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

Кроме общего случая, следует выделить аппаратный тонкий клиент (например, Windows- и Linux-терминалы) - специализированное устройство, принципиально отличное от ПК. Аппаратный тонкий клиент не имеет жёсткого диска, использует специализированную локальную ОС (одна из задач которой организовать сессию с терминальным сервером для работы пользователем), не имеет в своём составе подвижных деталей, выполняется в специализированных корпусах с полностью пассивным охлаждением.

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

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

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

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

- Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД.

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

- масштабируемость;

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

- высокая безопасность;

- высокая надёжность;

- низкие требования к скорости канала (сети) между терминалами и сервером приложений;

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

Недостатки вытекают из достоинств:

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

- сложнее в разворачивании и администрировании;

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

- высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

Схема взаимодействия клиента и серверов приведена на рисунке 2.4.

2.2.2 Обоснование выбора СУБД

Реляционная база данных -- это база данных, основанная на таблицах или, лучше сказать, на отношениях. Чтобы пользоваться реляционными базами данных, достаточно знать их основы -- таблицы, столбцы, строки, значения и ключи.



Рис 2.4. Схема взаимодействия клиента и серверов.

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

Реляционные системы берут свое начало в математической теории множеств. Они были предложены в конце 1968 года доктором Э.Ф.Коддом из фирмы IBM, который первым осознал, что можно использовать математику для придания надежной основы и строгости области управления базами данных.

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

Достоинства реляционной модели:

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

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

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

- Для построения запросов и написания прикладных программ нет необходимости знания конкретной организации БД во внешней памяти.

Недостатки реляционной модели

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

- Далеко не всегда предметную область можно представить в виде совокупности таблиц.

Так же, нужно отметить более серьезную проблему реляционных БД.

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

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

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

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

2.3 Разработка мер по защите информации

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

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

Наиболее распространенной хеш-функцией является md5:

vardata = "Hello World";

var hash = md5(data);

MessageBox.Show(hash); // b10a8db164e0754105b7a99be72e3fe5

MD5 (англ.MessageDigest 5) - это алгоритм хеширования (128-битный). В 1991 году он был разработан Рональдом Л. Ривестом (профессор Массачусетского технологического института).Результатом применения md5 всегда будет строка из 32 символов в шестнадцатеричном виде. Технически хеш может быть 128-битным. В функцию md5() можно поместить числа и строки любой длины, но результат на выходе будет в 32 символа. Это подтверждает односторонность функции.

Поэтапный процесс регистрации:

- заполнение формы регистрации с полем «пароль» пользователем;

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

- обработка пароля хеш-функцией перед записью в базу.

Нигде не применяется оригинальное значение пароля.

Поэтапный процесс входа в систему:

- ввод пользователем логина и пароля;

- хеширование этого пароля скриптом-обработчиком;

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

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

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

Коллизией хеш-функции является равенство значений хеш-функции на различных двух блоках данных. То есть, когда при хешировании двух разного типа данных выходит один результат, возникает коллизия. На это оказывает влияние используемая функция. Например, функция crc32() возвращает в качестве результата 32-битное целое. Значит, возможно только 232 (4 294 967296) вероятных вариантов на выходе.

Хешируем пароль:

echocrc32('supersecretpassword');

// навыходе: 323322056

Допустим, база данных вместе с этим паролем стала доступна для злоумышленников. Они не могут преобразовать 323322056 в «supersecretpassword», но используя простой скрипт, они легко подберут другой пароль, имеющий точно такой же хешированный вид как у нашего пароля:

set_time_limit(0);

$i = 0;

while (true) {

if (crc32(base64_encode($i)) == 323322056) {

echo base64_encode($i);

exit;

}

$i++;

}

Через какое-то время скрипт вернет строку «MTIxMjY5MTAwNg==», которую можно будет использовать вместо «supersecretpassword» и получить возможность входа в систему под именем настоящего владельца пароля.

echo crc32('supersecretpassword');

// навыходе: 323322056

echo crc32('MTIxMjY5MTAwNg==');

// навыходе: 323322056

Любой, даже самый простой, домашний компьютер дает возможность использования в секунду миллиардов хеш-функций. Значит надо подобрать хеш-функцию с наибольшей генерацией значений в секунду. Подойдет md5, она способна генерировать 128-битные хеши. Вариантов подбора будет значительно больше (2128). Пройтись по всем итерациям, чтобы найти коллизии станет практически невозможно.Sha1() возвращает 160-битный хеш и является хорошей альтернативой md5.

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

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

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

$password = "easypassword";

// такой пароль может найтись в Радужной таблице

// т.к. пароль содержит два распространённых слова

echo sha1($password); // 6c94d3b42518febd4ad747801d50a8972022f956

// для соли используем любое количество случайных символов

$salt = "f#@V)Hu^%Hgfds";

// такой хэш никогда не будет найден в Радужных таблицах

echo sha1($salt . $password);

// cd56a16759623378628c0d9336af69b74d9d71a5

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

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

Например, хеш-строки «easypassword» есть в первоначальной радужной таблице. В новой таблице с учетом «соли» будет значение «f#@V)Hu^%Hgfdseasypassword». При запуске скрипта некоторые совпадения наверняка будут.

Для защиты можно использовать «уникальную соль», различную для каждого пользователя. Чтобы «соль» стала уникальной, добавим id пользователя:

$hash = sha1($user_id . $password);

Само собой, id пользователя будет неизменным. Можно для каждого пользователя сгенерировать случайную строку и также получить уникальную «соль». Хранить эту «соль» надо вместе с записью о пользователе:

// сгенерируем строку длиной 22 символа

functionunique_salt() {

return substr(sha1(mt_rand()),0,22);

}

$unique_salt = unique_salt();

$hash = sha1($unique_salt . $password);

// сохраним $unique_salt в записи пользователя

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

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

Допустим, если пароль состоит из цифр, из прописных, заглавных букв, то это всего 62 (26+26+10)возможных символов.Пароль из 8 символов включает в себя 628 вариантов комбинаций, то есть немного больше 218 триллионов. При обработке в секунду одного миллиарда хешей за 60 часов злоумышленники подберут пароль. Ну, а для пароля из 6 символов на эту процедуру уйдет чуть более минуты. Следовательно, требование от пользователей введения 9-10-значного пароля будет вполне обоснованным.

2.4 Моделирование потоков данных (DFD диаграмм)

DFD - общепринятое сокращение от англ. DataFlowDiagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях, смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются в анализе информационных систем.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.

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

На рисунке 2.5 показана DFD диаграмма системы АН.

2.5 Проектирование инфологической модели данных с использованием модели «сущность-связь»

Данная диаграмма «сущность-связь» строится при помощи использования графических обозначений, приведенных в таблице. Такое представление данных имеет тип диаграммы ER(ERD).

Таблица 2.1. Графические обозначения ER-диаграммы.

сущность	ассоциация (связь)	атрибут сущности

Рис 2.5. DFD диаграмма подсистемы онлайн консультаций

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

Более полной является формальная базовая реляционная модель, разработанная Е. Коддом, для которой модель “сущность-связь” можно считать основой.

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

- Квартира;

- Тип;

- Район;

- Адрес;

- Пользователь;

- Клиент;

- Статус;

- Файл;

- Лог.

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

Сущность «Квартира» описывает объявление об аренде и содержит информацию о нем. Данная сущность имеет следующие атрибуты:

- Тип:idтипа недвижимости (квартира, дом, дача, гараж и т.д.);

- Район: idрайона для недвижимости;

- Кол-во комнат;

- Без хозяев;

- Посуточно: возможность посуточного съема квартиры;

- Цена;

- Описание: комментарий к объявлению;

- Регистратор: idпользователя, зарегистрировавшего данное объявление.

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

- Дата добавления;

- Статус: id статуса для недвижимости (сдана, сдается и т.д.);

- Клиент: id клиента, который снял данную недвижимость.

Сущность «Тип» является справочником и описывает типы недвижимости. Помимо атрибута id содержит атрибут «Название», в который записывается название типа недвижимости в том виде, который будет показан в списке типов.

Кроме справочника типов, есть также справочник «Статус», который содержит один атрибут «Название».

Сущность «Район» является справочником районов недвижимости и содержит следующие атрибуты:

- Название;

- Название в родительном падеже: нужно для читабельного отображения информации о квартире (например, «квартира в районе круга»).