Re: Help! I can't support normalization
Date: Fri, 8 Nov 2002 18:57:38 -0000
Message-ID: <aqh1gn$eu4$1_at_sp15at20.hursley.ibm.com>
"Paul" <pbrazier_at_cosmos-uk.co.uk> wrote in message
news:51d64140.0211080438.72f6fcb4_at_posting.google.com...
> > Don't confuse possible representations (read D&D) from the actual values
> > themselves.
>
> D&D = Date & Darwen? Which book would you recommend as a good
> introduction to relation databases from a theoretical viewpoint? i.e.
> with links to set theory and predicate logic theory?
OK, you've outed me. Hands up. I've pretty much only read Date (and Darwen) in depth when it comes to relational databases. I like to blame the fact that my university omitted to include even one relational DB course on my CS degree (too busy teaching us OO I reckon ).
Others in this ng have recommended other more theoretical books, which I myself intend to have a browse through to see what I am missing.
> What is the "actual value" of a complex number though?
What ever it is, there is only one for each number. :-)
> Surely a
> database can *only* store representations of values, and which one you
> choose is kind of arbitrary?
Arbitrary and the actual one(s) chosen should be hidden from the users. I don't care if the DMBS stores timepoints as Binary Coded Decimal or as the number of half seconds since England last won the world cup. All I need it to be exposed to the granuarality, max/min and any other domain constraints and as long as the things look and work as timepoints, then I'm happy. If all the domain constrains are the same between different possible representation, then the actual storage format is completely hidden from me.
> I'm reading up at the moment on logic and I was wondering if the
> system catalog tables are based on second-order predicates.
Well the system catalog is one place where relation valued attributes are desirable (and maybe required?), but that is to do with things like not wanting to have to give each AK in the model a (surrogate) name.
> As I
> understand it:
>
> suppose I have a predicate "p" with two "parameters" so p(x,y) means:
> "x's favourite colour is y" say.
> Then the relation based on the predicate is the set R defined by:
> (forall x,y)((x,y) is an element of R iff p(x,y)) where x and y are in
> the appropriate domains. First-order logic means the things in our
> "forall" clause can only be parameters to the predicates. Second-order
> logic means that the things in our "forall" clause can be predicates
> themselves.
>
> So a system catalogue table that contains a list of relations in the
> database has the (second-order?) predicate S(p) meaning p is a
> predicate in our system.
> And the relation is the set T defined by
> (forall p)(p is an element of T iff S(p))
>
> Is this right?
> Or am I confusing the string "foobar" with the table (or relation)
> foobar?
> i.e. the string "foobar" is a representation of the relation known as
> foobar?
The catalog only contains the names and definition of the relations, not the relations themselves.
If the catalog contained the actual relations, then you would need to do every update twice, once for the relation in the database and once for the relation in the system catalog relation in the database. Not a good idea methinks.
> Can we "encode" second-order logic within our first-order logic
> system?
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Fri Nov 08 2002 - 19:57:38 CET