The navigation term means moving of focus or joining of data within selection operation from one entity to another one. It is implied that data can be navigated based connection of entities. Often connections in technical realization are expressed via links from one entity to another one. In relational data model foreign key plays this role, and connection is called relation. The term of relation is used because navigation is not just movement of current focus like in many other data models, but mass data joining from several related entities within the same selection operation.
In the frame of relational model, FSDB has all advantages of relational operations. As entities of FSDB are represented by individual records in strongly normalized table, in this meaning the navigation actually means movement or joining from one record of the table to another one. This navigation is expressed via foreign keys turned to the same table.
Therefore navigation in FSDB over RDB is expressed via standard join operation (natural join). Entities are identified by unique ID, foreign keys are related to Parent Sign and Generator Sign. Therefore navigation by these two pairs of directions gives us the following ways: Parent to Child sign, Child to Parent sign, Generated sign to Generator, Generator to Generated signs. Despite join operation allows to apply various criteria of building relation, FSDB in this concept significantly limited in such degree of freedom, and it is not limitation but specifics of strongly normalized data structure. Potentially we can build relation based on representation property of Sign but it is rather incorrect way that hardly gives good results (taking into account homonyms and repitition/replication of representations from Generator to Generated signs).
As FSDB proposes very compact data structure, gathering of the similar data volume like standard relational tables requires more joining operations. As a minimum the following join operations restore:
- table level,
- column level,
- row level
However each of those three levels can be increased twice or more. For example, if row is identified by composite Primary Key (from two or more columns), each field in Primary Key requires additional join operation. Also significantly number of joins in restore data into table view depends on rules of table normalization (packing to FSDB view).
At the same time such relations in FSDB are based on indexed fields, therefore even complex expression with a big number of join operations will be executed quite fast.