Using the HTMS API to work with a relational network database

Introduction

In the article “Relational network data model” a new concept of HTMS data modeling was proposed, which is a development of the canonical relational model. This article will demonstrate examples of how it can be practically used using the logic level API.



Examples are tied to the well-known educational and methodological solution for creating sites - a template for a web-based survey project on the Django framework in MS Visual Studio .



Understanding this article requires knowledge of the basics of the Python language and the Django framework.

Database Description

A conceptual data schema is four tables and a description of the dependencies between them:

Notes:

• sequence number of the response in the survey - used only to form a queryset when displaying the page with the survey
• name of the survey participant registered on the site of the survey - it is filled out only for users who have registered (voters who have not registered can vote and comment). Registered users may suggest creating new polls, but we do not consider such subtleties in this article.

Dependencies:

1. Each poll (row in the Polls table) corresponds to 2 or more answers, i.e. rows in the Answers table
2. Each answer (a row in the Answers table) corresponds to 0 or more comments, i.e. rows in the Comments table
3. If the site visitor voted for the first time, then a new row is created for him in the Visiters table. Users are identified by ip-address
4. After each vote, the number of votes cast for the selected answer in the survey increases by 1
5. The site should remember what answers each visitor gave and what comments he left: each user comment is written in a new line of the Comments table

Formalization of a database by means of ORM Django

First, we show how the database would be described traditionally - using the classes of the models Django package.

Notes:

• The polls attribute may seem redundant, since it is possible to get a list of polls through a list of answers, but this is done so as not to lose the fact of participation in the poll if the answer is removed from the poll
• Django physically creates (or modifies) the database before starting the first start of the site program based on user subclasses of models.Model using the python manage.py migrate and makemigrations commands that are executed in the application context

Formalizing a database using HTMS

To create a database description, you must define its classes:

Polls_db is the main database class for the survey site application. The main class of the database is defined as a subclass of HTdb , which in HTMS serves as a superclass for application databases (there can be several).

Polls, Answers, Comments, Visiters - classes for database tables. Table - one of the main classes of HTMS, serves as a superclass for classes of specific tables.

HTMS creates (or opens an existing) database directly during the execution of the site program. Relevant options:

1. Create a new database with the name "polls":
   
   my_db = Polls_db (db_name = "polls", new = True )
   
   
   • the main database files ("empty") will be physically created,
   • in the OP, the main database object my_db will be created - an instance of the Polls_db class.
   
   
   
2. Open a database with the name "polls":
   
   my_db = Polls_db (db_name = "polls")
   
   
   • the main files of the existing database will be physically opened,
   • the object my_db will be created in the OP, the attributes of which contain the basic information about the database read from its files.

When there is a new database created during initialization of an instance of the HTdb subclass, it is necessary to determine the actual structure (schema) at the logical level. This is done once at the first launch of the site, but, unlike the ORM technology, in the program code of the site itself.

1. Define all database attributes - their names and data types:
   
   
   
   
2. Define attribute types with links (the rest will default to type 'cause'):
   
   
   
   
3. Define table objects and select attributes (columns) for them from the set of all attributes of the GT:
   
   
   
   

The execution of this code will lead to the formation of the database structure and the creation of the corresponding files on the server, if the database is new.

If the database has already been created, to work with it you only need to create instances of the table classes:

Comparing HTMS and ORM

Obviously, the formalization of the data scheme at the logical level in HTMS and ORM are similar, but there are a number of fundamental differences.

In HTMS, attributes and data types are defined as a single space; in ORM, they are bound to separate tables.

The whole set of database attributes in ORM is created “additively”, as models are defined, they cannot be changed programmatically, but in HTMS for the entire database as a whole, and you can add or remove them in the application without migration.

The attributes for each individual model in the ORM are static, while in the HTMS they are dynamic. Table structures in HTMS are defined as projections of a single attribute space - it is simpler and more visual than in ORM. HTMS website algorithms can provide options for changing the original database structure, for example, adding new attributes or deleting existing ones, which is impossible in principle in ORM technology .

Note that HTMS technology, if applied in the Django framework, only expands its capabilities, and does not require the abandonment of the use of ORM. For example, Django’s entire excellent authentication system, based on the models and the User class (from the django.contrib.auth.models module), can be used. Therefore, in reality, a Django site with HTMS will usually be “multimodel”, that is, one part of the overall database will be purely relational, the other relational-network.

Logical level HTMS usage examples for survey databases

Utility function for initial filling of a database from a JSON file

The function of forming a set of objects with polls (queryset for class based view - CBV polls)

The function of forming a set of objects with survey answers (queryset for CBV survey answers)

The function of forming a set of objects with the results of voting on a survey (queryset for CBV)

Function for recording the voting result in the database (called via the URL from the voting form)

---

We hope that readers will appreciate the simplicity and naturalness of working with data in HTMS!