Слой доступа к базе данных

РЕФЕРАТ

Звіт з переддипломної практики містить 23 сторінок,29 рисунков.

Об’єктом формалізації є існуючі сервіси звернення громадян

Мета роботы – зробити автоматизацію системи звернення громадян і відповідей посадових осіб.

Метод розробки – розробка ведеться у сучасній середовищі розробки, яка дозволяє Intellisense, Refactoring, автоматичну генерацію UML структурних діаграмм.

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

 

СОДЕРЖАНИЕ

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

Введение. 3

1  Модели и алгоритмы.. 4

1.1  База данных. 4

1.1.1 Архитектура. 4

1.1.2 Модель. 5

1.2  Слой доступа к базе данных. 7

1.2.1 Особенности внедрения. 7

1.2.2 Схема доступа. 8

1.2.3 Авто заполнение сервисных колонок. 9

1.2.4 Json модели. 12

1.3  Безопасность доступа. 14

1.3.1 Анонимный доступ. 14

1.3.2 Регистрация. 16

Выводы.. 23

Список источников. 24

 

 

ПОСТАНОВКА ЗАДАЧИ

 

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

а) Система должна быть готова к большим нагрузкам.

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

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

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

д) Параметры элементов при добавлении или поиске, выводить исходя из подхода, что если он списочный (выбираемый из группы вариантов), то в случае если вариантов меньше 30, показывать его select-списком, если же больше пользоваться autocomplete полем, с вспомогательным описанием возможных вариантов. Если же может существовать понятие короткого частого списка, показывать его в виде select, и в случае выбора пункта «Другие», показывать autocomplete поле.

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

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

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

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

ВВЕДЕНИЕ

 

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

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

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

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

МОДЕЛИ И АЛГОРИТМЫ

База данных

Архитектура

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

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

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

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

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

Также сервисными полями выступает IsDeleted. Этот подход позволяет виртуально удалять и восстанавливать объекты базы. Иногда существует поле IsModerated, указывающее на некое разрешение на показ объекта.

UrlName также используется повсеместно в системе. Это поле некоторым образом должно быть связано с названием данного элемента, обычно трансформация производиться функцией специального транслита. Главное что символы не должны противоречить спецификации символов, описывающего форму url. [24]. В дальнейшем это поле используется как уникальный идентификатор, повышающий SEO системы [23].

Модель

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

Основными жалобными элементами выступают компании и люди. В будущем идёт расчёт на расширение жалобных элементов также до продуктов и групп компаний.

Рисунок 2.1 – Таблица компании и персоны

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

Рисунок 2.2 – Связанные фильтры к компании

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

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

Рисунок 2.3 – Жалоба и теги

При создании таблицы жалоб я выбрал не самую масштабированную, однако более удобную в некоторых случаях схему. С одной стороны жалоба по своей сути должна позволять присоединяться к любому Entity. Если первичный ключ элемента, на который жалуются, был бы числовым, как это обычно и бывает, это приводило бы к конфликтам. Для этого приходилось бы вводить дополнительное поле с указанием таблицы. Ещё один вариант, был бы создание единой таблицы для всех общих элементов (Personal, Company) и специальные поля как Address для Company или LastName для Personal, скрыты в наследуемых таблицах. Тогда можно было бы использовать числовое Id. В случае Guid его можно использовать без надобности в общей таблицы, так как все id уникальные. В данном случае, потребовалось ссылаться жалобой на несколько элементов. Это можно было бы решить дополнительной таблицей, не ограничивая себя количеством ссылок на жалобные объекты. Но в данном случае потребовалось также возможность использовать ForeignKey, который позволял в ORM иметь дополнительные связи и с тем создавать сложные запросы.

Tag обычная реализация web 2.0 параллельных неиерархических ярлыков. Суть связок основано на идеи категоризации основанной на некоем списке названий почти не связанных друг с другом. Таким образом, любое множество тегов, может прикрепляться к множеству элементов. Здесь они используются для указания типов жалоб: на обслуживание и качество, серьозные, юридически выйгрышные дела или менее важные.

 

Слой доступа к базе данных