📜 ⬆️ ⬇️

CMS architecture. Data model Part 1

A content management system (CMS) is required to provide flexible, comprehensive functionality to manage site content, facilitate the work of the administrator-configurator, and facilitate the creation of an easy-to-use site. The content of the site can be called news posted on it, as well as articles, comments, photos. The content also includes entire information structures: news feeds, catalogs, forums, blogs. Generally: the content is the data posted on the site.

The CMS can simply transfer data upon request to a client application, such as a network program, a flash clip, or an AJAX application. But more often, the CMS provides the client with the data already prepared for display in HTML format. In this case, in order to ensure accessibility, ease of perception and ease of use of the contents, it is styled and combined with design elements (themes, templates), navigation (menus, links) and controls (forms and links too), and all of these must also be managed .

Idea


The world around us is perceived by us as an object, we think of “objects”, an object model of the world is built in our minds. Therefore, we will not be difficult to create an object model of site content and manage it. News, product in the catalog, forum posts and the forums themselves, and everything else can be represented as objects. By establishing links between objects, you can create data structures of any complexity, from adding comments to articles to creating social networks and more.
')
Objects, classes, and data connections are information that you need to be able to create, store, use, modify, and delete. We have a relational database for storing information. Actions performed with information are part of the CMS functioning logic, which for the most part will be implemented by the Data data module. We are talking about the created CMS Boolive. Previous article on CMS architecture.

In fact, the data module will implement an object-relational projection ( ORM ) - to provide object-oriented access to the database. At the same time, the entities of the object model (classes, relations, objects) will be defined in the database, not programmatically, which will allow, without programming, to create new classes of data - new content types.
In order not to be confused with the objects and classes of the programming language, the terms “data object” and “data class” are used.
To store objects of the same type in a relational database, in principle, a single table is enough, the fields of which will correspond to the attributes of the object. But objects can have connections to other objects and more often only they have them. Instead of creating fields (foreign keys) in the table of objects for communication with other objects, it is better to create a separate table for relations - this, by the way, will allow you to store additional information about the connections, in particular, the naming and their type. The link forms a property of the object that owns the link A property is a collection of a connection and an object to which a connection is established.

Attributes and properties of objects are determined by the class. In fact, the attributes are determined by the table - its fields. The definition of properties for objects can be realized by the presence of connections between the corresponding classes. Classes themselves also need to be stored, so they also need to create a table. A class with its objects will be determined by the class name.

Each entity (class, object, and relationship) must have an identifier — a unique integer that is unique among all entities. That is, there should not be, for example, a class and an object with the same identifier. The uniqueness of the identifier among different types of entities allows, in particular, to store the connections of classes in a table together with the connections of objects. The term “entity” means both an object, and a class, and a relationship.

One of the basic concepts of the object model is class inheritance. Inheritance also needs to be represented in a relational form and this is fairly easy to do by defining an integer field in the class table for storing the identifier of the inherited class (foreign key), and using this information to merge the corresponding object tables when querying. If the class “B” inherits the class “A”, then the attributes of the objects of the class “B” will be stored in table “A” and “B”.

Classes are objects! No explanation yet. Since a class is an object, and any object has a class, it means that the class has a class that defines attributes for it, in particular, the name and identifier of the inherited class. Relationships are also objects, respectively, and they have their own class. Thus, everything is an object, but in order not to be confused with the assignments of objects of different types, the term “essence” will be used for generalization purposes.

Implementation


So, based on the above, each entity has an identifier and a class, or more precisely, a link to a class. We proceed to the implementation and for all the entities we will create a table with the name “id”. In the table, two fields are the entity identifier and the entity class identifier. We have created (not yet fully) the base class “entity” - all other classes will be obliged to inherit the class “entity”, otherwise there will be no sense in their creation.

CREATE TABLE `id` ( `id` int(10) unsigned NOT NULL auto_increment, `class` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `index_class` (`class`) ); 


Create a second class with the name "class". While class creation is reduced to table creation. Create a table with the name "class" and the fields " id ", " sys_name ", " extend ", " final ". The “ id ” field is used to link one-to-one with the entity table, the “ id ” field is used by the system logic to merge records when implementing inheritance. “ Sys_name ” is the system class name that matches the name of the table in which objects of the corresponding class will be stored. “ Extend ” is the identifier of the inherited class. " Final " - a sign of the possibility of class inheritance (if 0).

 CREATE TABLE class ( `id` int(10) unsigned NOT NULL, `sys_name` VARCHAR(255) NOT NULL, `extend` int(10) unsigned NOT NULL default '1', `final` tinyint(1) unsigned NOT NULL default '0', PRIMARY KEY (`id`), UNIQUE `index_sys_name` (`sys_name`) ); 


Now it will be difficult to understand the picture of interconnections - this is the case with chicken and egg, like, what was the first? In this case, it is even erroneous to tell the appearance of two entities (classes) sequentially, since they must appear simultaneously and cannot exist without each other.
Two tables are created - two classes are created as if, but just like that, the tables are empty - there are no entities. The first entity is the base class “id” called “entity”. From the fact that this entity is a class, the record associated with it must be both in the “id” table and in the “class” table. The first entity identifier is 1. Note the system name of the class - it coincides with the name of the table “id”. The second entity is also a class, so the entry is also in the table “id” and in the table “class”. The second class system name “class” is the same as the table name created for the classes. The second class inherits the first - this is defined in the "extend" field. The second class is forbidden to inherit.

Tables "id" and "class"
Now let's pay attention to the “ class ” field in the first created table. Both entities are defined by class with identifier 2. Yes, exactly! The first entity is defined by class 2, therefore it is a class, it has all the attributes defined for classes. The second entity is also a class and inherits the first class, therefore objects of class 2 have an identifier and a link to the class. Analyze the relationships, see how everything concisely defines itself — both tables and attributes and the fact that both entities are classes.

Let's create a class for links now. The link class defines the attributes specific to the links:

 CREATE TABLE `link` ( `id` int(10) unsigned NOT NULL, `define` int(10) unsigned NOT NULL default '0', `sys_name` varchar(255) NOT NULL, `kind` tinyint(1) unsigned NOT NULL default '0', `size` tinyint(1) unsigned NOT NULL default '1', `is_mandat` tinyint(1) unsigned NOT NULL default '1', `is_define` tinyint(1) unsigned NOT NULL default '1', `primary` int(10) unsigned NOT NULL, `secondary` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `index_define` (`define`), KEY `index_sys_name` (`sys_name`), KEY `index_primary` (`primary`), KEY `index_secondary` (`secondary`) ); 


Connections have a dual purpose, used by the logic of the Data module. The first purpose is the direct connection between objects to implement properties, the second purpose is the definition of these properties by a class. A class, by establishing a relationship with another class, defines properties for its objects. But if we consider a class as an object, then it can also have properties. It means that the mere presence of a connection between classes cannot determine that this relationship describes a property of objects. Therefore, the link has attributes define and is_define . By the attribute "define" you can find the relationship between the classes that define this relationship. The “ is_define ” attribute is a sign that takes the value 0 if it is a normal link between objects and 1 if this link describes a property and is applied by the class.

Relationships are of two types: “use” (aggregation, association) or “consist” (composition, be part of). View is determined by the attribute " kind ". Objects that are associated with another object by a “composed” link and are subordinate will depend on the object that owns the link. The dependence is reduced to the fact that removing the main object will automatically delete all the subordinate objects connected by the link "to consist". There are other features, for example, an object cannot be “part of” for more than one object.
Links of the second type - the “use” type retain independence of the related objects. Without limitations and consequences, both the property owner object and the property object can be independently deleted. An object can be “used” by any number of objects.

If the connections of the object with the class and the relation of inheritance of the classes were optimized, then in general there would be four types of connection. In addition to the described ones, there would be connections of the form “to be” and “inherit”.

The next important attribute of communication is “ size ” (power), taking the value of “many” or “one”. For example, an article may have several comments that will be determined by a multiple property. This attribute is used by a class relationship describing properties for objects. In fact, the article will have exactly as many links as there are comments to be associated with it, but these links will have the same attribute values, the only difference is in the identifier and the object (comments) with which linking is performed. The table below shows examples of the properties of the article object (the power of links is shown in parentheses). Attributes, except for the identifier, are absent from the article.

Article:
composeduses
header (1);
creation date (1);
text (1).
category (1);
author (1);
comment (Many);
file (Many);
photograph (many);

The “ is_mandat ” attribute is also used by the class association that defines properties for objects, and is a sign that a property must necessarily exist for an object if the attribute value is not 0 (a logical value).

The attributes “ primary ” and “ secondary ” carry out the direct connection between entities by their identifiers — they are foreign keys for linking tables of objects. The binding itself is performed by the logic of the Data module.

Tables "id", "class" and "link"
As a result, we have three main classes - three entities, on the basis of which the site content model will be completely built. The diagram shows the three entities created. I even had to compose a way to display them simultaneously in the form of classes and objects. A simple object from a class in a diagram will differ in the absence of a rectangle with the definition of attributes.

Base class diagram
The logic of the Data data module distinguishes only these three types of entities and provides basic actions: creating new entities, loading them from the database, and modifying and deleting. Each object can have attributes and properties depending on its class. Classes are endowed with the ability to define properties and attributes for objects and the ability to inherit. Links implement direct reference links between objects in a programmatic sense.

What's next


There are still at least two parts ahead on the topic “data model”. In the next article, we will focus on the Data module itself and demonstrate the process of creating site content using it.

Continued: Data Model. Part 2
Project site: boolive.ru Source codes in free access.

Source: https://habr.com/ru/post/53388/


All Articles