Re: Database design, Keys and some other things

This answer needs "longer" explanation. I defined knowledge in section 2. As knowledge is the monster concept, I limited knowledge to data which are basically in database. Second, I have concentrated on data which are in facts attributes values. Idea was to gradually built knowledge. Incorporate the "attribute" knowledge in the entity knowledge etc. Almost all the data in the database are the attribute level. My key which is the name of the relation's instance and the entity's instance (Ack and Ark attributes) is the entity level in the database. Gene's message about the birth date is tricky because it is knowledge about entity. It is not about an entity's attribute. It is about when the person starts to be the person.
The building of knowledge begins at the attributes because they are "atoms". The atoms do not have the parts. But there are some facts about the atoms. For example: "This atom was created on 1 September 2005." or " John put this atom there", etc. Let mi denote these facts by Fi ( i = 1,...,n). Is it possible to work only with the facts? For example, can we subtract f (Fi) - g (Fj) where Fi is the fact: "Mery was born on 22/8/1950" and Fj is "This is today date which is calculated by the system's procedure" and f is mapping which somehow assign a number1 and g is mapping which somehow assign a number2 and number2 - number1 = age and the age is the attribute of the corresponding person. I didn't write about this in my text, but I believe that there are a lot of interesting things there. I wrote that the age is derived from the birth date because knowledge about the data that I tried to define can make a bridge (or a connection) between a data and many other things. If there is no knowledge about one person birth date then we will never know when he/she was born and how old is this person. Let me explain this on one example. Fifteen years ago I made a very complicated DB project where I tried to store columns separately, to represent some level of knowledge and some other things (BTW, I have some experience :-)) It was working so good that I couldn't believe. Knowledge representation helps me tremendously. It connected the database, the systems knowledge, and knowledge of people who were out of IT department. www.dbdesign10.com example 2.5 is an example similar to technique which was applied in that project. So the example 2.5 is very close to the real life project. In this example an operator can enter 5 (or 10) same rows (except the primary key which is always unique), nothing stops him, i.e. operator can cheats, or enter what he wants, there are no security things (it is supposed that the operator has a data entry screen). The goal is that database can solve who made the fault (or cheats), where is fault, by which procedure etc. So the database should have kind of "immune system", i.e. to recognize some things. Here there is only one attribute. But knowledge added here connects many "small worlds" which are related to this one attribute. So there are the things which connects different things but this is I believe another monster subject matter.

 Vladimir Odrljin Received on Tue Sep 27 2005 - 21:21:20 CEST