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

Проектирование архитектуры данных

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

На рисунке 9 представлена ER-диаграмма проектируемой базы данных.

Рисунок 9. ER-диаграмма базы данных для проектируемой системы.

Базовой сущностью для хранения данных обо всех пользователях системы, за исключением администраторов, является таблица «user_tab1», содержащая личную информацию пользователя. Таблицы «user_tab2» и «user_tab3» содержат временные характеристики и контактную информацию пользователя.

Таблица 5

Атрибуты таблиц для сущности Пользователь

По приведенной выше ER-диаграмме и указанным атрибутам можно сгенерировать SQL-код для созданий таблиц «user_tab1», «user_tab2», «user_tab3» в базе данных «olymp» .

CREATE TABLE IF NOT EXISTS `user_tab1` (.

`id_user` int (11) NOT NULL,.

`login` varchar (45) NOT NULL,.

`password` varchar (45) NOT NULL,.

`active` binary (1) NOT NULL DEFAULT '1',.

`result` int (11) DEFAULT NULL,.

`pre` varchar (45) DEFAULT NULL,.

`role` int (11) DEFAULT NULL,.

ADD PRIMARY KEY (`id_user`), ADD UNIQUE KEY `id_user_UNIQUE` (`id_user`);

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `user_tab2` (.

`id_user` int (11) NOT NULL,.

`time_login` datetime DEFAULT NULL,.

`time_logout` datetime DEFAULT NULL,.

`time_start` datetime DEFAULT NULL,.

`time_finish` datetime DEFAULT NULL,.

`date_create` datetime DEFAULT NULL,.

`date_edit` datetime DEFAULT NULL,.

ADD PRIMARY KEY (`id_user`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `user_tab3` (.

`id_user` int (11) NOT NULL,.

`name` varchar (255) DEFAULT NULL,.

`surname` varchar (255) DEFAULT NULL,.

`class` int (11) DEFAULT NULL,.

`sex` binary (1) DEFAULT NULL,.

`country` varchar (255) DEFAULT NULL,.

`city` varchar (255) DEFAULT NULL,.

`region` varchar (255) DEFAULT NULL,.

`email` varchar (255) DEFAULT NULL,.

ADD PRIMARY KEY (`id_user`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Таблицы для остальных элементов базы данных представлены ниже:

Таблица 6

Атрибуты сущности Олимпиада

CREATE TABLE IF NOT EXISTS `olymp_base` (.

`id` int (11) NOT NULL,.

`pre` varchar (45) NOT NULL,.

`name` varchar (255) NOT NULL,.

`duration` int (11) DEFAULT NULL,.

`randomize` int (11) DEFAULT NULL,.

ADD PRIMARY KEY (`id`);

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Таблица «admin_tab» аналогична «user_tab1», но содержит только уникальный идентификатор, логин и пароль администратора.

CREATE TABLE IF NOT EXISTS `admin_tab` (.

`id_admin` int (11) NOT NULL,.

`login` varchar (45) DEFAULT NULL,.

`password` varchar (45) DEFAULT NULL,.

ADD PRIMARY KEY (`id_admin`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

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

CREATE TABLE IF NOT EXISTS `role_tab` (.

`role_id` int (11) NOT NULL,.

`role` varchar (45) DEFAULT NULL.

ADD PRIMARY KEY (`role_id`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Отдельное внимание стоит уделить таблице «note_tab». Это таблица всех сущностей, в которую копируются идентификаторы всех имеющихся в системе наборов данных. Так как связи между таблицами не предусматриваются на уровне СУБД, целостность данных должна поддерживаться некоторым другим путем, в роли такой связи выступает таблица «note_tab». Дублирование данных оправдывается дополнительным уровнем безопасности содержащейся в БД информации, поскольку планируется, что при каждом запросе необходимые таблицы будут связываться с таблицей всех сущностей. Это позволит избежать нежелательной подмены данных, тем самым обеспечивая их безопасность.

Таблица 7

Описание таблицы объединения типовых сущностей

CREATE TABLE IF NOT EXISTS `note_tab` (.

`note_id` bigint (20) NOT NULL,.

`note_name` varchar (45) NOT NULL,.

`deleted` Binary (1) DEFAULT NULL,.

ADD PRIMARY KEY (`note_id`).

) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

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

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

Сначала в таблицу «note_tab» добавляется запись о вводимой в систему сущности, например, «olymp». По дефолту в столбец «deleted» записывается 0, автоинкрементный идентификатор сам сохраняет необходимое значение. Этот же идентификатор сообщается нужной таблице, «olymp_base». Далее, в таблицу «olymp_base» записываются все остальные параметры «pre», «duration» и «randomize» .

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

CREATE TABLE IF NOT EXISTS `info_answ_tab` (.

`answ_id` int (11) NOT NULL,.

`answ_text` text NOT NULL,.

ADD PRIMARY KEY (`answ_id`), ADD UNIQUE KEY `answ_id_UNIQUE` (`answ_id`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `info_quest_tab` (.

`quest_id` int (11) NOT NULL,.

`quest_text` text NOT NULL,.

`quest_istext` text,.

ADD PRIMARY KEY (`quest_id`), ADD UNIQUE KEY `quest_id_UNIQUE` (`quest_id`).

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `info_quest_to_answ_tab` (.

`quest_id` int (11) NOT NULL,.

`answ_id` int (11) NOT NULL,.

`iscorrect` int (11) NOT NULL,.

ADD PRIMARY KEY (`quest_id`,`answ_id`);

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

При необходимости заведения нового пользователя происходит похожая операция:

Сначала в таблицу «note_tab» добавляется запись о новой строке с названием сущности «user», ей присваивается идентификатор, следующий за последним в таблице объединения всех сущностей. Далее в таблицы «user_tab1», «user_tab2″, „user_tab3″ записываются нужные данные о пользователях, с идентификатором, который равен только что присвоенному в таблице „note_tab“. При заведении нового пользователя, для него создается новая таблица, которая будет хранить результаты прохождения олимпиады. Шаблон названия таблицы: „result_tab_for“ +“ id» пользователя. Таким образом, получаем некоторую иерархическую модель.

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

Базы данных, которые основаны на нереляционной модели, как правило, называют «NoSQL», что означает Not Only SQL или No SQL. Термин был придумал Эриком Эвансом. Надо понимать, что «NoSQL» отнюдь не означает замену или полный отказ от использования реляционных СУБД. Это понятие получило известность в 2009 году, когда развитие социальных сетей, различных web-технологий подготовило почву для изобретения множества других способов хранения и обработки данных. NoSQL — это большое количество различных технологий баз данных, которые позволяют решать ряд специфических задач с реализацией которых традиционные СУБД не справляются в желаемой степени: они оказываются либо слишком дорогими, либо недостаточно производительными. При конструировании реляционных баз данных не поднималось вопросов масштабирования, гибкости и других, которые сейчас поставили современные приложения.

Говоря о NoSQL, как правило, подразумевают следующие преимущества:

1 Гибкость и динамичность

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

2 Скорость работы

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

3 Масштабируемость

Такое хранилище без особых проблем может быть разнесено на несколько серверов, то есть, горизонтально масштабировано.

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

4 Надежность работы

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