Реалізація ієрархії користувачів

Обновленная база данных должна иметь продвинутую структуру пользователей для использования на информационном портале под управлением новой CMS. Для построения ее модели нами будет применено UML моделирование.

Структура пользователей сайта под управлением CMS WordPress должна иметь следующую структуру:

• 1) Администратор. Управляет подключаемыми расширениями, добавляет и удаляет новых пользователей, без ограничений редактирует как страницы сайта, так и записи блога. Настраивает визуальное оформление, управляет рассылками.
• 2) Редактор. Редактирует записи в блоге. Создает и редактирует новые записи без ограничений предварительной модерации.
• 3) Автор. Создает новые статьи в блоге с возможностью их редактирования. Статьи добавляются на сайт только после предварительной модерации.
• 4) Участник. Может редактировать свой профиль и оставлять комментарии. Его именем могут быть подписаны записи в блоге.
• 5) Подписчик. Может оставлять комментарии на сайте, авторизовываться, участвовать в голосовании.

Данную структуру пользователей можно представить в виде модели:

Рис. 14. Диаграмма иерархии пользователей UML

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

Средства реинжиниринга MySQL Workbench.

Программные средства MySQL Workbench позволяют построить первичную ER диаграмму из существующего SQL скрипта.

Необработанная база данных не содержит связей и имеет следующий вид:

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

Вот перечень имеющихся таблиц и их назначение:

• 1) commentmeta, comments — хранят информацию о комментариях;
• 2) gg_folders, gg_galleries, gg_galleries_excluded, gg_galleries_resourses, gg_photos, gg_photos_pos, gg_photos_settings, gg_photos_presets, gg_settings_sets, gg_stats — таблицы надстройки Grid Gallery для управления и настроек изображений, галереи фотографий и их миниатюр. В системе CMS WordPress будет использоваться аналог, поэтому данные таблицы использоваться не будут;
• 3) links — используется для хранения ссылок;
• 4) options — таблица настроек;
• 5) postmeta — хранение мета-тегов записей;
• 6) posts — содержимое записей;
• 7) terms — ассоциация с категориями;
• 8) term_taxonomy — описывает метки ссылки и категории;
• 9) usermeta — пользовательские теги;
• 10) users — информация о пользователях.

Помимо данных таблиц требования предписывают создать дополнительную структуру базы данных для хранения данных карт на основе Google Maps, которые так же могли бы использоваться в записях нашего ресурса. Для начала отредактируем структуру нашей базы таким образом, чтобы она соответствовала требованиям CMS WordPress.

Для этого удалим лишние таблицы и составим функциональную диаграмму из необходимых элементов:

Рис. 16. Функциональная диаграмма модернизированной БД

Данную диаграмму необходимо дополнить таблицами данных модуля карт Google.

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

• 1) wpgmza — таблица, описывающая работу модуля карт и хранящая необходимые сервисные данные;
• 2) wpgmza_categories — таблица хранящая настройки категорий карт;
• 3) wpgmza_category_maps — хранит в себе настройки карт принадлежащих к той или иной категории;
• 4) wpgmza_maps — данная таблица хранит в себе настройки, маркеры, установленные координаты, прочую сервисную информацию;
• 5) wpgmza_polygon — хранит координаты для построения полигонов на картах;
• 6) wpgmza_polylines — хранит координаты для построения линий на картах.

Выглядят данные элементы следующим образом:

Рис. 17. Представление таблиц модуля в классической нотации ER диаграмм

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

Рис. 18. ER диаграмма таблиц хранящих информацию модуля карт Google

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

Рис. 19. Связь элементов модуля карт с общей функциональной диаграммой

На этом работа с MySQL Workbench в рамках данной модернизации закончена. После построения полной функциональной диаграммы ER, встроенная функция Reverse Engineer переводит преобразованную базу данных в вид SQL скрипта, который мы можем использовать в дальнейшем на нашем сервере.