# Study on Effective Temporal Data Retrieval Leveraging Complex Indexed Architecture
## 4 Indexing
### The Proposed Solution--NULL Value Origin Representation  
The limitation of the already proposed definitions is just based on the NULL value notation. It is clear, that there are no additional size demands, however, there is a strict limitation of the representation. We, therefore, developed another solution proposed in this paper as an extension of the current solutions. As stated, the undefined value can be physically associated with the various circumstances, like delayed value, improper value, the value provided by the compromised network, etc. There is therefore inevitable to distinguish the reason, undefined value itself is not feasible. The architectural solution reflecting the model is the same in comparison with [28], thus the second level indexing for the temporality (first dimension) and spatiality (second dimension) is used. For this solution, undefined values are also categorized based on origin. Categories can be user-defined, or automatic segmentation can be used. To create a new category for the undefinition, the following command can be used. The name of the database object must be unique among the users. It is associated with the treating condition specified similarly as the Where clause of the Select statement is defined. Multiple conditions can be present for the representation, delimited by the AND and OR connections. Moreover, the same condition can be used in multiple definitions, as well. In that case, the undefined value is categorized by multiple types and present in the index not only once. Physically, it is modeled by using ROWID pointers, thus the object itself is used only once, but several addresses (similar to the standard indexing) can point to that:  
**Create null_representation _name_ defined as _condition;_**  
For dealing with the delayed data caused by the network, the following notation can be used:  
**Create null_representation network_delay defined as sent_time--received_time > 3 s;**  
For dealing with the delayed data caused by the database system interpretation, the following notation can be used:  
**Create null_representation network_delay defined as received_time--processed_time > 1 s;**  
The definitions are stored in the data dictionary--null_representation prefixed by the user (only objects created by the current user), all (created by the user or granted to him), or dba (covering all definitions across the database instance). They can be granted to multiple users via grant command:  
**Grant usage on _name_ to _user_list;_**  
After the NULL representation creation, the definition is put to the data dictionary, so they can be associated with the defined tables, respectively, attributes or the whole database can be used. The whole representation model unioning the set is used, thus, if the representation is defined for the whole table, it is automatically granted to each attribute, which can hold undefined value. Moreover, the definitions can be extended by the attribute reflection, as well. It is done by the following syntax:  
**exec dbms_null_assoc_tab(table_name, null_representation_name);**:  
- for dealing with the table
**exec dbms_null_assoc_attr(table_name, attribute_name, null_representation_name);**:  
- for dealing with the attribute
**exec dbms_null_assoc_db(username, null_representation_name);**:  
- for dealing with the user  
Note, that if the username is not defined in the last command, the current user executing the code is used, by default. Figure 9 shows the proposed architecture consisting of three core internal elements. The Management handler is responsible for associating NULL representation, to interconnect undefined value categories (NULL_representation) stored in the data dictionary with table data by the definition. Any used category is created as the separate elements in the memory, (NULL_representation memory pointer layer) to which individual data can be directed.