Одной из первых проблем, возникающих сразу после выявления соответствующего типа данных из рассматриваемой предметной области, является выбор способа хранения. Хотя данная задача кажется тривиальной особенно на этапе раннего проектирования, позже, когда разработчик начинает лучше представлять суть предметной области и начинает представлять, как эти словари будут использоваться, становится ясность в необходимости дополнительных требований к словарям.
Одним из таких требований является учет изменений. Бывает, что словарь имеет свойство не только расширяться, но и менять отдельные значения. Во-первых, необходимо определиться с характером изменений. В случае простого синтаксического исправления достаточно изменить поле в строке таблицы с соответствующим идентификатором. В таком случае учет изменений может быть представлен в виде отдельного журнала событий, где будет указано какой пользователь, и когда совершил изменение. Данных способ позволяет четко проследить работу пользователей в системе, однако вызывает зачастую непомерное увеличение объема базы данных.
Рассмотрим теперь пример с изменением словаря дисциплин. В рассматриваемой системе каждый учебный план связан с набором дисциплин. В случае изменения названия дисциплины в более поздних учебных планах, возникнет ситуация, что мы не можем вывести из базы данных старый учебный план в таком виде, в каком он был в свое время распечатан и утвержден, т.к. название одной дисциплины будет отличаться. В этом случае был рассмотрен следующий способ учета изменений. К таблице словаря добавляются два поля: пометка об актуальности записи и ссылка на родительскую запись. При внесении изменений записи добавляется новое поле со значением актуальности true и ссылкой на изменяемую запись, в которой в пометке об актуальности ставится значение false. Таким образом, мы всегда можем проследить историю изменений, и в связанных с этим полем таблицах останется ссылка на старое значение. Данный подход может использоваться в случае необходимости жесткого соответствия представления документов в базе данных и их бумажного эквивалента, если такой имеется.
Для обеспечения уникальности записей словарей в рамках различных программных систем было принято использовать глобальные идентификаторы guid (globally unique identifier). Их статистически уникальные 128-битные значения позволяют избегать конфликтов, вызванных совпадением идентификаторов. Использование глобальных идентификаторов получило смысл в тех словарях, значения которых будут передаваться в виде сервисов для других приложений, как, например, учебный план. Поскольку система имеет распределенную архитектуру, было решено использовать глобальные идентификаторы для всех словарей, кроме тех в которых существовали параметры, обеспечивающие глобальную идентификацию, таких как код специальности.
При реализации интерфейса для работы со словарями было учтено, что данные словарей относятся к тем типам данных, о структуре которых рядовой пользователь системы зачастую не задумывается. По этому интерфейс для прямого редактирования словарей был создан с расчетом на опытного пользователя, имеющего соответствующие права на редактирование. Его характерными чертами стало единообразие для всех словарей и четкое представление взаимосвязей между данными.
Список литературы
- Григорьев В.К. Гетерогенная информационно-управляющая система на основе интегрированного информационного пространства вуза //57-я научнотехническая конференция мирэа. М. 2008. Ч. 1. С. 94- 98.
Рис.1. Пример интерфейса работы со словарем специальностей
Библиографическая ссылка
Акимов В.А., Григорьев В.К. ПОДСИСТЕМА РАБОТЫ СО СЛОВАРЯМИ В СИСТЕМЕ ВЕДЕНИЯ УЧЕБНЫХ ПЛАНОВ // Международный журнал экспериментального образования. – 2010. – № 8. – С. 103-105;URL: https://expeducation.ru/ru/article/view?id=702 (дата обращения: 17.08.2024).