Использование API HTMS для работы с реляционно-сетевой базой данных
- четверг, 15 августа 2019 г. в 00:18:39
В статье «Реляционно-сетевая модель данных» была предложена новая концепция моделирования данных HTMS, являющаяся развитием канонической реляционной модели. В настоящем материале будет показано на примерах, как ее можно практически использовать с применением API логического уровня.
Примеры привязаны к широко известному учебно-методическому решению по созданию сайтов — шаблону веб-проекта опросов на фреймворке Django в MS Visual Studio.
Для понимания статьи требуется знание основ языка Python и фреймворка Django.
Концептуальная схема данных — это четыре таблицы и описание зависимостей между ними:
Примечания:
Зависимости:
Сначала покажем, как база данных была бы описана традиционно — средствами классов пакета models Django.
Примечания:
Для создания описания базы данных необходимо определить ее классы:
Polls_db — главный класс базы данных для приложения сайта опросов. Главный класс БД определяется как подкласс HTdb, который в HTMS служит суперклассом для баз данных приложения(их может быть несколько).
Polls, Answers, Comments, Visiters — классы для таблиц БД. Table — один из основных классов HTMS, служит суперклассом для классов конкретных таблиц.
HTMS создает (или открывает уже имеющуюся) базу данных непосредственно при исполнении программы сайта. Соответствующие варианты:
Когда имеется новая БД, созданная при инициализации экземпляра подкласса HTdb, необходимо определить собственно структуру (схему) на логическом уровне. Делается это один раз при первом запуске сайта, но, в отличие от технологии ORM, в самом программном коде сайта.
Выполнение этого кода приведет к формированию структуры БД и созданию на сервере соответствующих файлов, если БД — новая.
Если БД уже была создана, для работы с ней нужно только создать экземпляры классов таблиц:
Очевидно, что формализация схемы данных на логическом уровне в HTMS и ORM схожи, но имеется ряд принципиальных отличий.
В HTMS атрибуты и типы данных определяются как единое пространство, в ORM они привязаны к отдельным таблицам.
Все множество атрибутов базы данных в ORM создается «аддитивно», по мере определения моделей, менять их программно нельзя, а в HTMS – для всей базы данных в целом, причем можно их добавлять или удалять в приложении без миграции.
Атрибуты для каждой отдельной модели в ORM – статичны, а в HTMS – динамичны. Структуры таблиц в HTMS задаются как проекции единого пространства атрибутов — это проще и нагляднее, чем в ORM.В алгоритмах сайта на HTMS может быть предусмотрены возможности для изменений первоначальной структуры БД, например добавление новых атрибутов или удаление имеющихся, что в принципе невозможно в технологии ORM.
Заметим, что технология HTMS, если ее применять в фреймворке Django, только расширяет его возможности, и не требует отказа от использования ORM. Например, вся великолепная система аутентификации Django, основанная на моделях и классе User (из модуля django.contrib.auth.models ), может использоваться. Поэтому реально сайт на Django с HTMS обычно будет «мультимодельным», то есть одна часть общей базы данных будет чисто реляционная, другая — реляционно-сетевая.
Функция-утилита для первичного заполнения БД из JSON файла
Функция формирования множества объектов с опросами (queryset для class based view — CBV опросов)
Функция формирования множества объектов с ответами по опросу (queryset для CBV ответов к опросу)
Функция формирования множества объектов с результатами голосования по опросу (queryset для CBV)
Функция для записи результата голосования в базу (вызывается через URL из формы голосования)