Re: some information about anchor modeling

How should we design a database, so that it supports the decomposition of relvars into corresponding binary relvars?

In current database theory, database design is influenced by functional dependencies. My approach to database design is reversed. That is what I wanted to express with the title.

Let me briefly explain my solution to this problem. My solution only works with entities, relationships, intrinsic/extrinsic properties and simple keys. First, I will describe the general case:

Case 1. All-key entity. In my data model the general case is that the entity has intrinsic properties. This means that properties of the entity take values freely. This entity corresponds to a relation which has mutually independent attributes.

Case 2. All the entities from a set of entities have the same attributes. For instance, they are all Honda Civics with the same attributes. In this case we introduce the identifier id = VIN as a property of the entity. We can note that there are many identifiers introduced into business applications by international standards.  

(In the case of a relationship, the key is always predefined.)

These two cases are general cases in my database design and we can note that all FDs here are implied only by keys. We can also note that here join can be done only by the key, because the key is only mutual part for all these attributes.  

I introduced Simple Form on May 15, 2006 (see http://www.dbdesign10.com ) and the above two cases satisfy conditions for Simple Form. Simple Form is much better than other normal forms. We don’t need to put relation into 2NF, 3NF, BCNF, 5NF … because the binary schemas can be immediately constructed. In both of the two general cases, the schema of the entity will be: E (identifier, attribute1, ..., attributeN). This schema meets the conditions for the Simple Form, so now we can construct the corresponding binary relations.

Now we can ask what other cases in database design exist besides the two above-mentioned ones? A better question would be: What generates the other cases?

The other cases for the design of entities (or relationships) can be generated by the following: Case-a. By introducing business rules and constraints to entities (or relationships) Case-b. By applying the operation add, delete and update to entities (or relationships)

The mentioned business rules and constrains can ruin every database. The business rules in my database solution are solved by using binary structures because the business rules and constraints should be defined on the level of binary structures.

Note that business rules can be set up so badly that they cannot be brought into compliance with the theory of databases. Case-b in my database model is solved by creation of “History”. Databases which maintain “History” do not have delete nor update operations; my database model keeps all data.

In my data model, for any database data it is known how it was made and who (or which procedures) made it. In my opinion this property is a huge theoretical and practical advantage of my data model. We can ask the question, “Is there a way that someone can break the maintenance of history in my data model?” The answer is no.  

Note that in object-oriented approach there are constructors, destructors, encapsulations, and states, but it is not possible to determine many things related to data. Deleting and updating data is allowed, thus there is no maintenance of states. The identity in OOA often uses a physical location in memory. In “Anchor Modeling” deleting of data is allowed. This implies that updating of data is also allowed. Therefore there is no history. Deleting or updating of data impedes online (internet supported) databases.   

In my data model I work with the conceptual model and the logical model. To switch from one model to another, I use the mapping from one data model to the other. This mapping consists of two mappings: schema mapping and data mapping. Both mappings are determined by binary structures and by identifiers of states of entities (or relationships). See my paper “Database design and data model founded on concepts and knowledge constructs”, Section 6.4 on http://www.dbdesign11.com , from 2008.

Simple Form is on the level of the relational model. However, there is the following problem: how to decompose a structure into binary structures on the conceptual model level? I showed how this can be solved in my paper “Database design and data model founded on concepts and knowledge constructs”, Section 4.2.3, Example 6 on http://www.dbdesign11.com , from 2008 and in my paper “Semantic databases and semantic machines” Section 5.8, on http://www.dbdesign11.com

--
The above text relates to simple databases. Now we will show how to construct a binary structure for complex databases (databases that manage changes, and keep history)
For complex databases, the decomposition into the binary structure is realized by means of states and identifiers of states. See my paper “Database design and data model founded on concept and knowledge constructs", Section 4.2.9 )



(Note that in RM / T and "Anchor Modeling" this decomposition is not proven. For example it is not done at the level of the ER model)