Разработка Интернет-представительства для задач риэлтерской деятельности

Длины/значения – позволяют задавать размер поля, либо перечислить варианты для полей типа “Enum”.

Ноль – определяет, может ли поле быть пустым. Соответственно имеет одно из двух значений: “null” или “not null”.

По умолчанию – значение поля по умолчанию (чтобы оставить поле пустым прописывается “null”).

Дополнительно – возможность выставить параметр “auto increment”, обеспечивающий автоматическое увеличение счетчика.

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

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

Таблица “Объявления” (“Adverts[1]”) – см. рисунок Д.1:

      “Идентификатор объявления” – “id”: целочисленный формат, значения присваиваются автоматически и будут уникальными,  что позволит однозначно идентифицировать запись в таблице, кроме того, поле не может быть пустым;

      “Идентификатор типа” – “type”: целочисленный формат, размер – 11 символов, значение по умолчанию равно “1”, кроме того, поле не может быть пустым;

      “Идентификатор района” – “district”: целочисленный формат, размер – ХХ, значение по умолчанию равно “1”, кроме того, поле не может быть пустым;

      “Идентификатор планировки” – “plan”: целочисленный формат, размер – ХХ, значение по умолчанию равно “1”, кроме того, поле не может быть пустым;

      Описание – “description”: текстовое поле без ограничения длины, поле может быть пустым и является таковым по умолчанию;

      Цена – “price”: строка длиной 128 символов, поле может быть пустым и является таковым по умолчанию;

      Контакт – “contact”: строка длиной 128 символов, поле может быть пустым и является таковым по умолчанию;

      Действие – “act”: поле типа “Enum”. Выбирается одно из двух значений: “B” (от английского buy) – покупка, “S” (от английского sell) – продажа. По умолчанию установлено “S”, поскольку объявлений о продаже, как правило, намного больше. Пустым поле быть не может;

      Решение – “verdict”: поле типа “Enum”. Выбирается одно из двух значений: “Y” и “N”, соответственно от английских yes и no, будет определять, публикуется ли объявление в пользовательской части. Данное поле также не может быть пустым, по умолчанию выбрано значение “N”;

Таблица “Типы квартир” (“Types”) – см. рисунок Д.2:

      Идентификатор типа – “id”, аналогично соответствующему полю таблицы “Объявления”;

      Имя типа квартиры – “name”: строка длиной 255 символов, может быть пустой, какой и является по умолчанию;

Таблица “Районы” (“Districts”) – см. рисунок Д.3:

      Идентификатор района – “id”, аналогично соответствующему полю таблицы “Объявления”;

      Имя района – “name”: строка длиной 255 символов, может быть пустой, какой и является по умолчанию;

Таблица “Планировки” (“Plans”) – см. рисунок Д.4:

      Идентификатор планировки – “id”;

      Имя планировки – “name”: строка длиной 64 символа, может быть пустой, какой и является по умолчанию;

      Путь – “path”: строка длиной 255 символов, может быть пустой, какой и является по умолчанию. Будет содержать имя графического файла, соответствующего конкретной планировке;

Для таблиц “Типы квартир”, “Районы” и “Планировки” названия полей сделаны одинаковыми, это в некоторой степени противоречит теории баз данных, однако несет в себе дополнительную функциональность. Такой подход позволит использовать одну процедуру для обработки любой из этих таблиц.

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

Таблицы “Типы квартир”, “Районы” и “Планировки” в процессе функционирования сайта изменяться не будут. Заполняются они только один раз (Приложение Е), внесение изменений возможно только при полной реорганизации сайта. Это в определенной степени ограничивает гибкость, но упрощает работу с сайтом для конечных пользователей. Поскольку таблицы базы данных строились на основе наработок агентства, которые за несколько лет доказали свою применимость и достаточность, то их структура и содержание вряд ли потребует скорой модификации.

Помимо значимых записей было решено добавить в вышеуказанные таблицы вариант “Не определено”, с параметром “id” равным единице (т.е. первой записью в любой из таблиц). Соответственно, в таблице “Объявления” параметры “Идентификатор типа”, “Идентификатор района” и “Идентификатор планировки” по умолчанию равны единице.

Таблица “Районы” (“Districts”). Во внутренних рабочих документах агентством выделялись шесть районов. Итого в таблицу было внесено семь записей (Рисунок Е.1).

Таблица “Типы квартир” (“Types”): Все многообразие объектов недвижимости, с которым работает агентство, разделено на семь типов. В результате таблица состоит из восьми записей (Рисунок Е.2).

Наиболее трудоемким оказалось заполнение таблицы “Планировки” (“Plans”). Были отсканированы и обработаны тридцать три схемы типовых планировок квартир (Рисунок 2.2).

Рисунок 2.2 – Пример схемы типовой планировки

Для хранения этих, а также других графических файлов в корневом каталоге сайта была создана поддиректория “/images”. В ней соответственно поддиректория “plan” для хранения файлов планировок. Все файлы были названы по шаблону: “тип”_“описание”_“номер”.jpg. В итоге таблица включает в себя 34 записи (Рисунок Е.4).

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

Для организации сервиса “Вопрос-ответ” также необходимо создать таблицу, которую можно включить в уже имеющуюся базу данных. Созданная таблица была названа “Вопросы” (“Questions”) и включила в себя 5 полей (см. рисунок Д.5):

      Идентификатор вопроса – “id” целочисленный формат, значения присваиваются автоматически и будут уникальными,  что позволит однозначно идентифицировать запись в таблице, кроме того, поле не может быть пустым;

      Вопрос – “quest”: текстовое поле без ограничения длины, поле может быть пустым и является таковым по умолчанию;

      Ответ – “answer”: текстовое поле без ограничения длины, поле может быть пустым и является таковым по умолчанию;

      Автор – “author”: строка длиной 64 символа, поле может быть пустым и является таковым по умолчанию;

      Решение – “verdict”: поле типа “Enum”. Выбирается одно из двух значений: “Y” и “N”, соответственно от английских yes и no, будет определять, публикуется ли объявление в пользовательской части. Данное поле также не может быть пустым, по умолчанию выбрано значение “N”;

Для отладки работы сайта с базой данных, в таблицу “Вопросы” (“Questions”) также были внесены несколько тестовых записей.

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

Таблица “Пользователи” (“Users”) – см. рисунок Д.6:

      Идентификатор пользователя – “id”, аналогично соответствующему полю остальных таблиц;

      Имя пользователя – “login”: строка длиной 128 символов, может быть пустой;

      Пароль – “password”: строка длиной 128 символов, может быть пустой, здесь главная особенность – использование алгоритма кодирования md5, восьми символьный пароль преобразуется с его в строку длиной 128 символов;

Таблица “Сессии” (“Sessions”) – см. рисунок Д.7:

      Идентификатор сессии – “id”, аналогично соответствующему полю остальных таблиц;

      Имя пользователя – “login”: строка длиной 128 символов, может быть пустой;

      Индивидуальный идентификатор сессии (“sid”) – строка длиной 128 символов, может быть пустой, также используется алгоритм кодирования md5.

Таблица “Пользователи” аналогично таблицам “Типы квартир”, “Районы” и “Планировки” заполняется один раз, в ней хранятся логин и пароль для доступа к администраторской части, поэтому предполагается единственная запись, которая не будет изменяться в течение длительного времени. Данные в нее также были внесены (рисунок Е.3).

Таблица “Сессии” заполняется при авторизации пользователя, этот процесс также будет описан в следующей части.

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

2.2                    Создание динамического web-сайта на основе PHP

Создание сайта можно разделить на три этапа: определение структуры, компоновка страниц и их информационное наполнение.

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

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

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

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

Разработка структуры

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

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

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

      «Главная» – здесь будет сказано приветственное слово, в сжатой форме изложены цели сайта и самого агентства, будет указан его адрес и телефоны, а также разместится ссылка на схему проезда;

      «Наши услуги» – краткое описание операций с недвижимостью, которыми занимается агентство;

      «О компании» – история компании, ее цель, положение на данный момент и перспективы развития;

      «Гарантии» – страницу условно можно назвать «уголок покупателя», здесь будут указаны телефоны контролирующих организаций и представлена некоторая документация агентства (свидетельство о внесении в Единый Государственный Реестр, доверенность начальнику агентства, свидетельство на товарный знак).

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

      «Инструкции» – памятка для агентов по работе с сайтом, содержит краткое описание разделов и краткие инструкции;

      «Вопросы» – аналог F.A.Q., ответы на возможные вопросы;

      «Почта» – инструкции по работе с почтой, как через web-интерфейс так и при помощи почтовых программ;

      «Итоги» – суммарная статистика работы сайта: количество объявлений и вопросов в базе данных, их распределение по типам.

Ко второму разделу будет отнесена работа с объявлениями, реализованная на страницах:

      «Объявления» – для пользовательской части это пять последних опубликованных объявлений, для администраторской части – это не опубликованные объявления;

      «Добавить» – форма для добавления нового объявления, в администраторской части включен полный набор полей, в пользовательской – сокращенный;

      «Найти» – поиск объявлений по параметрам, идентичен для обеих частей, разница в отображении найденных объявлений;

      «Все» – для пользовательской части – все опубликованные объявления, для администраторской – все объявления в принципе.

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