## 3 Methodology
### Multilevel Security Techniques  
To propose an MLS integrated with a database system for implementing the projected mechanism efficiently, a strong database system is required. Figure 5 provides a flowchart detailing the proposed system administration framework, which administrators use to manage user accounts for system access. The proposed paradigm includes several data manipulation declarations. The model manages data through INSERT and DELETE operations, allowing for data manipulation based on standard SQL queries. The MLS data model explains how these INSERT and DELETE operations function, as outlined below:  
* **INSERT operation**: This operation performed by a subject at the class level \(L\) follows the general form outlined in Equation (1). \[\textbf{INSERT\;Intro}\big{[}\big{(}A_{j1}\big{[},A_{j2}\big{]}\ldots\big{)} \big{]}\textbf{VALUES}\big{(}a_{j1}\big{[},a_{j2}\big{]}\ldots\big{)} \tag{1}\]  
According to this equation, \(R\) represents the relation's name, and \(\big{(}a_{j1}\big{[},a_{j2}\big{]}\ldots\big{)}\) are the corresponding attribute names where \(\big{[}\big{(}A_{j1}\big{[},A_{j2}\big{]}\ldots\big{)}\big{]}\) are the relative attribute names and \(1\leq j_{1},j_{2},\ldots\leq n\). Each INSERT statement is limited to inserting a single tuple into the relation \(R\). The process of inserting a tuple \(t\) is carried out through the following steps, ensuring all attributes in the database relation are addressed:  
* **Step 1**: Obtain the security level from the subject running the insert operation. Figure 4: Simplified MLS/DBMS model process for checking an account in the database. **Step 2**: When the attribute is included in the attribute list of the insert statement, its value will be obtained from the value list of the insert statement. **Step 3**: The security level of all attributes will match that of the subject performing the insert action. **Step 4**: The goal is to insert values from a list into relations with a single security level, ensuring the user's defined security level matches the values and aligns with the relations' characteristics. **Step 5**: \(A_{i}\) should have the value set to null because it is not an attribute in the INTO clause's list. **Step 6**: The subject whose class level is used to perform the insert statement will be set to the tuple-class. **II. DELETE operation**: This operation, known as DELETE, performed by a topic with class level \(L\), is typically represented in Equation (2). \[Delete\;From\;R \tag{2}\]  
According to our model, \(R\) represents the relational name, assuming the relation R includes data attributes \(A_{1},\ldots,A_{n}\); \(P\) is an expression that may include the delete operation as a predicate according to Figure 5. Only the tuples \(t\in r\) with \(t[TC]=L\), where \(L\) is the classification level of the subject executing the delete statement, are affected. For tuples \(t\in r\) that satisfy the predicate expression \(P\), \(r\) is modified through the following steps to address the issue until an optimal solution is achieved:  
**Step 1**: Check the security level of the subject for the deletion operation. **Step 2**: Remove all of the tuples that are contained within single-level relations and that are in accordance with the deletion prerequisites, with \(P\) being able to delete operations and having a security level that matches that user's level. **Step 3**: Deletion will occur for tuples that fulfill the predicate expression. **Step 4**: The value of any attribute in a higher-level tuple that depends on an attribute in the deleted tuple will be set to null if found. The process starts with \(i\) to 1 as shown in Figure 5, traversing a user list. Users meeting criterion \(P\) are stored in \(t(A)\). This denotes a provisional array or list containing these selected users. The loop iterates through users in \(t(A)\), evaluating standards and setting \(Cpk\) to \(L(user)\). Parameter \(A_{i}\), within range \(R[A_{i}]\), filters entries \((A_{i})\) meeting condition \(P\).