Re: RM's Canonical database

J M Davitt wrote:
paul c wrote:
...
It was, I believe, David McGovern who said, "Databases don't
store data, they store facts!" To be precise, I suppose he
should have said "representations of facts."

The point is that every tuple in every relation represents
something that is true and the database represents the entire
truth. Different applications with different concepts of
truth require different databases - at least to the extent
that their rules defining truth differ. These relations may
all be held in the same "instance" or on the same "server"
and some relations used by one application may be used by the
other, but each has a different database. And declaring the
constraints necessary to ensure the truthfulness of stored representations of facts for each can certainly be done in
each database; there's no reason to throw up one's hands and
say, "It can't be done in the database! We have to do it in
the application."

I do believe it is more productive to talk of facts rather than data. For me that emphasizes that constraints are facts as much as extensions are, stating certain facts in a different 'representation' than the extensions do.

I don't know to what extent current products exploit this but clearly some optimizations to avoid accessing a large extension would be possible, eg., some queries or updates might be evaluated without reading 'user data'. It's hard for me to imagine a way to ensure all apps could exploit those constraints unless they are facts in the db.

p
.

Relevant Pages

  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... model already allows surrogate keys. ...
    (comp.databases.theory)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... facts cannot be thought of just in terms of instances of predicates. ... Yes, that's all facts are, though constraints mean that your facts are ...
    (comp.databases.theory)
  • Re: Wiki software for genealogy (long)
    ... those specific facts. ... Data can substantiate other data (although not prove ... documents of interest in my database. ... only connections I wish to make are all assumptions, either mapping a ...
    (soc.genealogy.britain)
  • Re: Database design, Keys and some other things
    ... except maybe that a database contains dead objects in the sense then as soon as they are in the database they stop behaving - food for another thread). ... some of their facts to establish that reason. ... to a refutation of the idea that there's any essential difference between the industry standard external identifier and the database-specific surrogate key: it's a matter of context merely, and not anything intrinsic to that data, or how it is managed. ... What is essential to this question is what their nature is. ...
    (comp.databases.theory)
  • Re: Where do business rules belong... OCP and SPs
    ... Database stuff is all about persistence. ... It's true that a database is a representation of facts, ... called business rules and they can and should be represented in the ... They are a lot better for that than general-purpose programming ...
    (comp.object)
Loading