Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases

This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents (digital and paper) as classified aggregates and for data classification. The study also describes a new metamodel for the data structure which assumes that documents, being data structures, form compact aggregates, classified as objects, or event descriptions, thus always assigning them a specific and unambiguous context. Furthermore, the study presents a design method for documents as context aggregates that allows leveling the disadvantages of the relational model and ensures efficient information management. The work also contains practical examples of the application of the described method.

Documents often contain a high volume of different data jointly forming multiple context datasets (aggregates). Application of relational model for the organization of such data leads to the generation of a comprehensive system of relational linked tables, while the removal of redundancies often results in the loss of content context of individual fields in the tables. This gives rise to a necessity to use the highly complex SQL queries so that these documents can be saved in and retrieved from this database. Thus, the database itself solely contains data deprived of the context present in tables, not the documents.

Many authors have pointed out the problem of complexity and the loss of uniform relational model context (Ślęzak et al., 2018). Those authors have suggested that contexts should be separated in large relational data models. However, recommendation of context separation (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), while maintaining the relational model, does not help to solve the issue completely (Awang et al., 2012, 2012, 2012).

Context change often alters the meaning of data (Danesi, 2004). Attempts made for maintaining the meaning of data frequently result in the formation of comprehensive relational data models, thus generating additional costs. Therefore, using one relational data model to save the contents of numerous different documents can make such a system an enormous and indivisible monolith, which is expensive to develop as well as maintain.

Read more…

Publications, including academic handbooks, contain numerous inconsistencies in the descriptions of applications of architectural methods and patterns hidden under the abbreviations such as MOF, MDA, PIM, MVC, BCE. An efficient analysis and the following software design, particularly when we are speaking of projects realized in large teams, requires standardization of the production process and the applied patterns and frameworks. This study attempted to sort out the system of notations describing this process and used to describe architectural patterns. Analysis of key notations—MOF and MDA, patterns MVC and BCE—was carried out, and a consistent system combining them into a whole was created.

In this study, Object Management Group notation systems have been used. MOF (Meta Object Facility) specification describes three abstraction levels: M1, M2, M3 and level M0 that is real items (OMG MOF, 2016). M0 is a real system, M1 level is abstraction of the items of this system (its model). Level M2 comprises of relationships between classes of these objects (names of their sets) that is system metamodel. M3 level is a meta-metamodel describing the modeling method with the use of named elements with specified semantics and syntactic.

The analysis and design process is based on the MDA (Model Driven Architecture) specifications. This process has three phases understood as creation of subsequent models: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) and code creation phase. The CIM model is documented with the use of BPMN (Business Process Model and Notation) (OMG BPMN, 2013) and SBVR notation (Semantic of Business Vocabulary and Rules) (OMG SBVR, 2017). These are, respectively: business process models and notation models and business rules. PIM and PSM models are documented with the use of UML notation (Unified Modeling Language) (OMG UML, 2017).

Between CIM and PIM models, determination of the list of application services (system reactions) occurs, whose realization mechanism is described by PIM model. The standard pattern used for modeling application architecture is MVC pattern. Component Model of this pattern is modeled with the use of the BCE architectural pattern.
Read more…