# A Coding-Free Software Framework for Developing Lightweight Web Data Management Systems
## 3 Framework Architecture and Formal Modelling  
In this section, we will introduces the formal modelling for data management systems with common characteristics, as well as the system architecture and working modules of the proposed framework. Figure 1 shows the system architecture, which is composed of the following three main parts, i.e., RTDDM, DMSWP and GDWI: (1) The DMSWP part aims to extract the core commonalities of the data management system and to design a lightweight web framework; (2) The RTDDM part is a method for offline customization using spreadsheets, in which we design a set of requirements table called ReTa. The RTDDM engine analyses and executes based on the system requirements table and derives the corresponding system instance on the DMSWP; (3) The GDWI module provides users with an interface for data services and an operating environment. This module is based on the DMSWP and is compatible with the RTDDM.  
Before implementing the aforementioned framework, a unified architecture must be designed for the data management system (DMS). To this end, we extract the core commonalities of the DMS and proceed with formal modelling. We abstract the commonalities of the DMS using a five-tuple defined in the following Definition 1:  
**Definition 1**.: _DMS is a five-tuple components:_  
\[\Psi=F(Tenant,Group,User,Schema,Data) \tag{1}\]  
_where \(F\) represents the engine transformation function, and Tenant is the system administrator who uses the framework to create the system; we will use the term tenant instead of administrator below. A data management system consists of five parts: tenant, user, group, schema, and data._  
Figure 2 shows the hierarchy of the general DMS architecture, where the dotted line represents inclusion, the solid line that does not have an arrow indicates membership, and the solid line that has an arrow for further explanation and representation. For example, the tenant information is specifically expressed as id, password, and name, respectively. The notations G\({}_{u}\) denote the group to which the user belongs, in which a user may belong to one or more groups. Any user's permissions are the union set of the authority of group to which it belongs. Additional explanations are given as follows:  
Figure 1: Framework Module and Architecture.  
* The gpermission and oppermission in the schema representation are used to distinguish the permissions of different groups on the schema. For any group that has the permissions of schema, it can have the permissions of any subset of schema.
* FI refers to the field information in the schema. Field information can be further interpreted as field names, field types, and other attributes of fields (OAs).
* Each piece of data belongs to a schema. For each data item belonging to schema, the attribute values of each field must match the attributes of the corresponding schema's field.  
Additionally, the DMS has uniqueness and isolation. That is, only one system administrator with the highest authority corresponds to a system, and multiple systems are independent of each other.