Common languages for databases

Common languages for database definitions and database contents Language defining ontologies I advocate to adopt and/or develop formalized natural languages for database design as well as for the harmonization of database content. Such formalized languages should be defined in language defining ontologies that are distinct from knowledge modeling ontologies (as I have explained in another more

Unique identifiers – synonyms and homonyms

Unique identifiers, synonyms and homonyms It is widely recognized that there is a difference between things (or concepts) and the various names by which those things can be denoted. Nevertheless, in databases and date exchange messages, things are usually denoted only by names, which results in interpretation problems and difficulties for interoperability of systems and more

Two kinds of ontologies

Two kinds of ontologies: language defining and knowledge modeling Ontologies are models that express formalized knowledge (or requirements) in some application domain. Typically every organization creates its own ontology on the basis of its own business needs and domain knowledge. Creating your own ontology is often advocated because of differences in business needs. The general more

Constraints and requirements

Constraints and requirements modeling and verification

Databases and data exchange messages may contain specifications of constraints and specifications of requirements for information. Those constraints and requirements specifications may also be used to verify whether the same or other databases and data exchange messages satisfy those constraints and requirements. This article introduces the modeling and verification of various kinds of them.


Semantic consistency verification

Semantic consistency verification Databases and data exchange files should be verified on the semantic consistency of their content. Semantic consistency verification checks whether collections of expressions contain redundant statements or statements that are in conflict with other statements. The verification possibilities and processes for the content of conventional databases, such as in relational (entity-attribute-relationship) data more

Dialogues, inserts and queries in one common language

Dialogues, inserts and queries in one common language Computer interpretable dialogues among various parties require that assertions, queries, answers, denials, etc. are expressed in one common language. This article describes how that can be achieved. In natural languages, queries and assertions have nearly the same structure and use the same terminology. Thus the sentences used more

Database design – a new approach

Database design – a new approach Conventional database development and modification requires that first a physical data model is created or modified, from which the database tables are generated, before those tables can be loaded with ‘instances’. The physical data model tables then specify what can and cannot be expressed, because the tables are the more

Modeling by binary relations

Modeling by binary relations

In conventional data modeling usually various attribute types that provide information about the same kind of thing are grouped into entity types (or ‘object types’). As a consequence of that higher order relations (tables) are created. However, many of those higher order relations must be changed when business requirements change. Thus most conventional data models have structures that are business requirements specific.


Modeling of higher order relations (N-ary relations)

Modeling of higher order relations (N-ary relations) Conventional ‘entities’ with their ‘attributes’ are usually higher order relations, because they relate more than two ”attributes”. Some of such relations appear to be natural higher order relations, whereas others appear to be artificial higher order relations. Higher order relations can also be represented by equivalent collections of more