data_modeling_and_database_design_in_gellish_english
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
data_modeling_and_database_design_in_gellish_english [2018/10/02 01:14] andries Revision of the first part of the text |
data_modeling_and_database_design_in_gellish_english [2018/10/02 01:39] andries Text revised up to par 2.3 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== How to write Gellish enabled software ===== | ===== How to write Gellish enabled software ===== | ||
| - | ===== 1. Limitations of conventional database design ===== | + | ==== 1. Limitations of conventional database design ==== |
| Conventional data modelling for any application domain typically results in a domain specific (conceptual, logical and physical) data model, also called a scheme. Such a data model documents the requirements and capabilities for storage of data in a database or data exchange messages. Thus it defines the semantic capabilities for expressions of ideas that can be stored in the database or exchanged between systems. \\ | Conventional data modelling for any application domain typically results in a domain specific (conceptual, logical and physical) data model, also called a scheme. Such a data model documents the requirements and capabilities for storage of data in a database or data exchange messages. Thus it defines the semantic capabilities for expressions of ideas that can be stored in the database or exchanged between systems. \\ | ||
| Line 6: | Line 6: | ||
| Once conventional data models are created, they are fixed and specific for the application domain specific (the Universe of Discourse), whereas software is dedicated to that fixed structure. Thus the storage capabilities of the resulting databases are fixed and limited to the application domain. As a consequence modifications of the storage capabilities are time consuming and costly. \\ | Once conventional data models are created, they are fixed and specific for the application domain specific (the Universe of Discourse), whereas software is dedicated to that fixed structure. Thus the storage capabilities of the resulting databases are fixed and limited to the application domain. As a consequence modifications of the storage capabilities are time consuming and costly. \\ | ||
| - | ===== 2. The Gellish Semantic Modeling Methodology ===== | + | ==== 2. The Gellish Semantic Modeling Methodology ==== |
| The Gellish Modeling Methodology extents the conventional data modeling methods in various ways: | The Gellish Modeling Methodology extents the conventional data modeling methods in various ways: | ||
| Line 17: | Line 17: | ||
| Below it is described how systems can be created that can import, export and store Gellish data and how flexible user interfaces can be created that allow exchanging a large variety of information without the need to modify their data structure. | Below it is described how systems can be created that can import, export and store Gellish data and how flexible user interfaces can be created that allow exchanging a large variety of information without the need to modify their data structure. | ||
| - | == 2.1 Semantic information models in Gellish == | + | === 2.1 Semantic information models in Gellish === |
| The Gellish methodology enables that knowledge and requirements as well as information about individual things (instances) are expressed in the Gellish languages. Gellish then requires that all concepts in the expressions shall be selected from the Gellish dictionary or in case they are not present, they shall ad-hoc be added to that dictionary. This is required in order to ensure the use of a common unambiguous language between application systems that send or receive or store information. Thus standardized concepts and standardized kinds of relations are used to a maximum extent, and concepts and definitions are not reinvented again and again. When concepts or kinds of relations are not available in the Gellish dictionary, then they shall be added as proprietary extensions according to the [[:Proper definition of a concept|rules for extension of the Gellish dictionary]]. | The Gellish methodology enables that knowledge and requirements as well as information about individual things (instances) are expressed in the Gellish languages. Gellish then requires that all concepts in the expressions shall be selected from the Gellish dictionary or in case they are not present, they shall ad-hoc be added to that dictionary. This is required in order to ensure the use of a common unambiguous language between application systems that send or receive or store information. Thus standardized concepts and standardized kinds of relations are used to a maximum extent, and concepts and definitions are not reinvented again and again. When concepts or kinds of relations are not available in the Gellish dictionary, then they shall be added as proprietary extensions according to the [[:Proper definition of a concept|rules for extension of the Gellish dictionary]]. | ||
| Line 44: | Line 44: | ||
| For details of the process to convert domain knowledge and requirements into a data model it is recommended to use a conventional data modelling methodology, such as ORM, in combination with the guidelines on the [[:Knowledge modeling in Gellish|modelling of knowledge and specifications]]. Here we assume that a data model that is expressed in Gellish English and stored in a Gellish database table is available. | For details of the process to convert domain knowledge and requirements into a data model it is recommended to use a conventional data modelling methodology, such as ORM, in combination with the guidelines on the [[:Knowledge modeling in Gellish|modelling of knowledge and specifications]]. Here we assume that a data model that is expressed in Gellish English and stored in a Gellish database table is available. | ||
| - | == 2.2 A data model stored as instances in a universal Gellish database == | + | === 2.2 Knowledge and requirements stored as instances === |
| - | In conventional data modelling it is common practice to convert a conceptual data model (also called a knowledge model) into a database design (a physical data model). This is also possible for the above example knowledge. However, it is not necessary for a Gellish database, because a Gellish database has a predefined general purpose data structure and consists of tables that all have the same standardized database table definition (see ‘The Gellish Database table definition’). This means that for a Gellish database there is no separate database design required. Table 1 is an example of the core of such a Gellish database table, loaded with facts that specify the data model with knowledge about pumps. | + | Conventional data modeling starts with the creation of a knowledge and requirements model (also called a conceptual data model), followed by converting that into a database design (a physical data model) or data exchange interface. However, in Gellish that is not necessary, because a Gellish database or exchange message (file) has a predefined general purpose data structure and consists of expressions that all have the same standardized structure definition (see ‘The Gellish Syntax and contextual facts' that defines the Gellish Expression format). This means that for a Gellish database there is no separate database design required. Table 1 is an example of the core of Gellish expressions in such a Gellish Expression format, loaded with statements that specify knowledge about pumps. |
| - | This means that the data model that is specified in Table 1 does not need to be converted into a database design, but can be directly used to guide the process to create instances that can be stored in a Gellish database table with the same structure (although with other relation types). This is done as is described below. | + | This means that the knowledge that is expressed in Table 1 does not need to be converted into a database design, but can be directly stored or exchanged or used to guide the process of creating instances that can also be stored in the Gellish expression format with the same structure as the knowledge (although using other kinds of relations). How such information about individual things (instances) are created is described below. |
| - | == 2.3 Creation of instances == | + | === 2.3 Creation of instances === |
| - | Each fact in a data model that is expressed in Gellish English as a relation between concepts can result in "instances" that consist of one or more facts that are expressed in Gellish English as a relation between individual things, together with classification relations between the individual things and the concepts (classes) that classify them. \\ | + | Each idea that expresses knowledge in Gellish is expressed as a relation between concepts. And each such idea can be used for creating "instances" that consist of one or more ideas that are expressed in Gellish as relations between individual things, together with classification relations between the individual things and the concepts (classes) that classify them. \\ |
| For example, assume that we want to store facts about a particular centrifugal pump, which is called P-1301. In other words we want to create an individual thing that is classified as a centrifugal pump and we want to create expressions of facts with information about that individual thing. To create that individual thing in Gellish it is required to specify a classification relation between the individual thing P-1301 and the concept (class) that classifies the thing. Such a fact is expressed in Gellish English as follows: | For example, assume that we want to store facts about a particular centrifugal pump, which is called P-1301. In other words we want to create an individual thing that is classified as a centrifugal pump and we want to create expressions of facts with information about that individual thing. To create that individual thing in Gellish it is required to specify a classification relation between the individual thing P-1301 and the concept (class) that classifies the thing. Such a fact is expressed in Gellish English as follows: | ||
| * P-1301 <is classified as a> centrifugal pump (fact 301) | * P-1301 <is classified as a> centrifugal pump (fact 301) | ||
data_modeling_and_database_design_in_gellish_english.txt · Last modified: 2018/10/02 15:00 by andries
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
