Data Attributes: Understanding the Details
Data attributes, characteristics, and unique information are necessary elements of the database. For example, it can be a number, a name, etc.
Certain types of attributes are used to solve various problems. Each of them requires specific keys and references, as well as the choice of one of several methods of execution.
The concept and place of an attribute
When describing the process of organizing database management systems (DBMS) with a tree structure, such concepts as element, aggregate, record, group relation, and database are used.
- Data attributes are the smallest unit of their structure. When describing a database, each element is given a separate name by which it is called during database processing (an element is sometimes called a field).
- Records are called a set of attributes with the name. Thanks to them, obtaining a related data set during one call to the database is possible. Records are subject to addition, deletion, and modification operations. A set of attributes sets their type. The record instance is a specific string with specific element values.
- A group relationship is a hierarchical arrangement of two types of rows. The parent or source record acts as the “owner” of such a hierarchy, and the child acts as a subordinate. Only two hierarchical structures can be stored in a tree-like record database.
The root record of a separate structure necessarily contains a unique key, and for a non-root record, the requirement for uniqueness is valid only within the group relation. Identification of any set of attributes (records) occurs using a concatenated key (a system that includes all records keys, starting from the root and further along the location in the tree structure).
In graphical form, the hierarchical arrangement of records is carried out using the arcs of a directed graph. Row types are displayed by records – vertices of the Bachman diagram.
In the tree structure, group relationships are subject to automatic inclusion and fixed membership. In other words, the database must obtain its parent entry to remember a non-root row. Accordingly, when the “owner” of the hierarchy is deleted, all child rows also disappear.
Attribute examples
Let’s give an example in which the minimum unit of the database structure has received the attributes: Name, Code, Subcategory, StandardCost, ListPrice, and FilePhoto. Attributes act as descriptions of database fields. In this case, any individual element is represented by a separate record of attribute values.
In the example, the Product database object includes:
- free-form attributes Name, Code, StandardCost, and ListPrice;
- attribute given a subset of the Subcategory;
- file description metadata FilePhoto.
The Subcategory object is applied as the minimum unit of entry based on a subset of the Product entity. In turn, the Category object is used as the minimum unit of record based on a subset of the Subcategory entity. Like the Product object, the Category and Subcategory entities unconditionally include the Name and Code attributes.
Attribute types
String fields
To consider the attributes of the database, let’s make a spreadsheet document.
| StrDesc | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES ObjType(Id) | Database object type pointer |
| CHAR(10) | Short parameter name |
| ItemName CHAR(30) | Full name of the parameter (only used in relation to the interface) |
All objects with a database receive properties inherent in a particular type. For example, an object of type “EMPLOYEE” includes the following string properties:
“FAMILY” – surname
“FIRSTNAME” – name
“LASTNAME” – patronymic
“ADDRESS” – address
“EMAIL” – e-mail
The Objects.ItemName line for employees is filled in by the application server in the form of a combination of FAMILY + FIRSTNAME + LASTNAME attributes.
Attributes are stored in tabular form:
| Strings | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES StrDesc(Id) | Reference to parameter type |
| ObjectId INTEGER REFERENCES Objects(Id) | Object reference |
| Value VARCHAR(255) | Parameter value |
To display a list of employees who have email, a query can be entered:
SELECT O.ItemName, S.Value
FROM Objects O
INNER JOIN ObjType OT ON O.TypeId = OT.Id
INNER JOIN Strings S ON O.Id = S.ObjectId
INNER JOIN StrDesc SD ON S.TypeId = SD.Id
WHERE OT.Code = ‘EMPLOYEE’
AND SD.TypeId = OT.Id
AND SD.Code = ‘EMAIL’
To display a list of employees with e-mail data (if any), you need to change the query:
SELECT O.ItemName, S.Value
FROM Objects O
INNER JOIN ObjType OT ON O.TypeId = OT.Id
LEFT JOIN Strings S ON O.Id = S.ObjectId
LEFT JOIN StrDesc SD ON S.TypeId = SD.Id
WHERE OT.Code = ‘EMPLOYEE’
AND SD.TypeId = OT.Id
AND SD.Code = ‘EMAIL’
You can get a rather interesting result when creating attributes for different types of objects with identical data in the Code field. The EMPLOYEE (employee) and FIRM (company) objects have the same string attributes: ‘EMAIL’. In this case, by one request, you can display a list of addresses for all mail details available in the database.
SELECT O.ItemName, OT.ItemName, S.Value
FROM Objects O
INNER JOIN ObjType OT ON O.TypeId = OT.Id
INNER JOIN Strings S ON O.Id = S.ObjectId
INNER JOIN StrDesc SD ON S.TypeId = SD.Id
WHERE SD.Code = ‘EMAIL’
ORDER BY OT.ItemName, O.ItemName
In case of further addition of a new object with the same attribute, it will be immediately taken into account and displayed in the list without changes in the database. Getting a similar effect in a database with a regular structure will be much more difficult.
Numeric attributes
To simplify things, let’s assume that all numeric attributes are stored using the same data type (for example, DECIMAL(20,4). This approach is useful when using MONE type servers.
If organizing the database involves allocating a certain type of data, then it is possible to decide to allocate a separate group of tabular forms for this. Other features of storing data of the selected type will not differ from working with string values. Attribute descriptions will be presented in tabular form:
| PropDesc | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES ObjType(Id) | Reference to object class |
| CHAR(10) | Short parameter name |
| ItemName CHAR(30) | Full name of the parameter (only used in relation to the interface) |
And the attributes themselves are in the table:
| Properties | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES PropDesc(Id) | Reference to parameter type |
| ObjectId INTEGER REFERENCES Objects(Id) | Object reference |
| Value DECIMAL(20,4) | Parameter value. It is convenient to store the MONEY data type on servers that support it (analogues of Currency in Delphi). |
You can supplement the PropDesc ​​tabular form with fields that specify the smallest and largest attribute value, default property, etc. Checking the correctness of the specified values ​​can be carried out in the Properties tabular form modification trigger.
Chronological attributes
In certain time intervals, the state of database objects may change. For example, an employee may be hired for a probationary period, dismissed, transferred, etc. The description of the states is displayed in tabular form:
| Status | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES ObjType(Id) | Reference to object type |
| CHAR(10) | Brief name of the state |
| ItemName CHAR(30) | Full name of the parameter (only used in relation to the interface) |
For example, for a person, acceptable states might include:
- WASBORN – Date of birth
- “EMPLOYEED” – Recruited
- “DISMISS” – Fired
In this case, providing a principle in which each object’s state will appear repeatedly is possible. For example, an employee is hired, fired, and hired again.
The history of changes is saved in tabular form:
| History | |
| ID INTEGER | primary key |
| StatusId INTEGER REFERENCES Status(Id) | Link to state type |
| ObjectId INTEGER REFERENCES Objects(Id) | Object reference |
| ItemDate DATETIME | State change date |
As states change, an entry appears in the History table that refers to a specific state and when it occurred. So, when applying for a job, an entry appears in the history with the date and a link to the EMPLOYEED status. After leaving, a link to the status DISMISS appears, and when rehired, it is EMPLOYEED. To obtain a list of employees who are registered on a specific date, the following type of queries can be used:
SELECT O.ItemName, H.ItemDate AS Employeed
FROM Objects O
INNER JOIN ObjType OT ON O.TypeId = OT.Id
INNER JOIN History H ON H.ObjectId = O.Id
INNER JOIN Status S ON H.StatusId = S.Id
WHERE OT.Code = ‘EMPLOYEE’
AND S.Code = ‘EMPLOYEED’
AND H.ItemDate = (SELECT MAX(H1.ItemDate)
FROM History H1
INNER JOIN Status S1 ON H1.StatusId = S1.Id
WHERE H1.ObjectId = O.Id
AND H.ItemDate <= :DateParam
AND S1.Code IN (‘EMPLOYEED’, ‘DISMISS’))
Attributes with a limited number of values
The enumerated types of data attributes act as the final form (they can have only one value from a predefined set). The storage of such values ​​is carried out not in two tabular forms, as with other attributes, but in three at once. The first table defines enumerations that are valid for an object of the selected type:
| EnumDesc | |
| ID INTEGER | primary key |
| TypeId INTEGER REFERENCES ObjType(Id) | Reference to object type |
| CHAR(10) | Brief name of the state |
| ItemName CHAR(30) | Full name of the parameter (only used in relation to the interface) |
The second defines the possible values ​​for the enumerated type:
| EnumValues | |
| ID INTEGER | primary key |
| DescId INTEGER REFERENCES EnumDesc(Id) | Reference to enum type |
| CHAR(10) | Short value name |
| ItemName CHAR(30) | Full name of the parameter (only used in relation to the interface) |
The third one directly stores the values ​​associated with the object:
| Enums | |
| ID INTEGER | primary key |
| ValueId INTEGER REFERENCES EnumValues(Id) | Reference to value |
| ObjectId INTEGER REFERENCES Objects(Id) | Object reference |
An illustrative example of the use of this type of data is the form of ownership of a company. To answer this question, you need to include the line in the EnumDesc:
| TypeId | Code | ItemName |
| Reference to ObjType for type “FIRM” | OWNERFORM | Type of ownership |
And in EnumValues:
| DescId | Code | ItemName |
| Link to EnumDesc for | HPI | Individual private enterprise |
| type “OWNERFORM” | OOO | Limited Liability Company |
| … |
As we can see, now it is possible to describe any set of object properties, information about which is presented in the database. In addition, data about an arbitrary entity can be mapped to objects that are stored uniformly. But the database still needs to be toused in this form to solve more complex problems. This is because, in certain areas, data objects have multiple relationships with each other. The database in question is not yet able to map such dependencies.
Attribute Execution Methods
The values ​​of certain properties of specific objects determine the methods that can be used to create specific entities. It makes no sense to consider the methods themselves separately since they are quite obvious, in contrast to the methods of execution that form the computing environment (with their help, the change in the state of values ​​occurs as a result of external influence by the rules established in the form of the data model).
Calling a method (method) of execution by an external influence on the state of the data. There are four such methods: Create, Set, Get and Update.
The first method in this list corresponds to the metaclass and applies to any class object. Its parameter is the IDC handle of the target class. With the help of the Create method, objects are created as elements accompanying the attributes of the specified class. In this case, the class is registered in the tabular form of the DAT allocation, following the free IDO descriptor.
The Set, Get, and Update methods are meta attributes. They are used to work with the values ​​of data objects. The Set attribute method assigns the value, Get fetches it, and Update initiates a re-formation of the derived value stored in the database.
The IDO specifier provides the identification of the target value in attribute methods. At the same time, the target object itself is available only for the class attribute (the path to this attribute is specified in the IDC + IDA data model descriptors).
Thus, all operations on the value occur on the name of the class attribute. The mechanism for executing attribute methods differs in that during such an action, the method iterates over the sockets in the attribute tuple and calls a similar method on the target attribute addressed by the connector (if the flag corresponding to the method is on the socket).
Since the execution of the methods: Create, Set, or Update changes the state of the values, the data call can only occur within the transaction session. An atomic external effect on the database occurs when any of these methods is called. Such a process is easy to formalize as a transaction and save in a log.
The database processed in this way can store descriptions of any objects using different attributes. In this way, relationships between entities can be dynamically identified and established. Such a mechanism will be sufficient for solving many problems with unique objects.
