Orientation
In both semantic model standards Topic Maps and RDF/OWL and in many other NoSQL approaches to solve efficiently the problem of how to represent relations and relationships one major stumbling block is raised beyond all efforts: the namespace. It is a language problem, the babel we have in our civilized world is transferred into our IT systems. But machines do not have to understand our language, we do.
Good news for everyone, there is an alternative way of thinking on modelling data:
Hence AtomicDB Data Model or as I call it AIR
Atomic Information Resource Data Model
The Entity-Attributes 'Silo' Structure
The problem here is that from a semantic point of view, similar diagrams are in need from users that want to express business processes but when we reach the implementation stage software engineers have to marry business requirements with the technical constrains of the database system hence the ER diagram you see. Generally speaking this is known as "The Model", a conceptual view of the user on data. The ER version of the model has several limitations, due to the architecture of RDBMS. The main one is that each attribute remains enclosed in the table structure and in the case the same attribute appears in another table, the dataset that it represents has to be repeated. In our example above, the primary key (pid) of "Parts" is repeated as a foreign key (catpid) in Catalog. The difficulties that arise in data aggregation due to this limitation are substantial.
How to Break Free from the Entity-Attribute-Value Paradigm
The relational and the entity-relationship model made a huge impact in the IT world for nearly half a century. But during this long period of standardization it meant also one thing, everyone had to comply with the rules and requirements of the model. Everyone had to think in terms of Entity-Attribute-Value or Subject-Predicate-Object as it is known in the RDF semantic model. Programming languages have been affected to from this monolithic way of thinking. Although it proved to be advantageous to program with classes and objects, it created an artificial problem of how to map these onto persistent data structures on the disk, also known as the object-relational impedance mismatch problem. Knowledge representation frameworks did not escape from this too. Ontologies expressed in OWL followed the same paradigm with classes, attributes, and values. Serialization methods such as JSON (object-name-value) and XML (element-attribute-value) also came after the same rationale.
The Signified - Sign - Signifier Alternative Paradigm
The aforementioned Entity-Attribute bond and distinction plays its role here too. But most important another concept, 'value', is added to make this triplet even more difficult to handle in our digital world. This is mainly due to the fact that three perspectives, the conceptual, the representative and the physical layer encoding are mixed in such a way that it is very hard to separate and work with them at distinct levels of abstraction. The R3DM, or S3DM, conceptual framework that we discuss in Part 3 is based on the natural process of semiosis where the signified, i.e. concept, entity, attribute and the signifier, i.e. value are referenced through symbols, i.e. signs, at discrete layers. The same philosophy is shared in the architecture of this database management system and we demonstrate this with the following example.
Join Data Science Central to comment on this post.
Posted 1 March 2021
© 2021 TechTarget, Inc.
Powered by
Badges | Report an Issue | Privacy Policy | Terms of Service
Most Popular Content on DSC
To not miss this type of content in the future, subscribe to our newsletter.
Other popular resources
Archives: 2008-2014 | 2015-2016 | 2017-2019 | Book 1 | Book 2 | More
Most popular articles
You need to be a member of Data Science Central to add comments!
Join Data Science Central