Re: In an RDBMS, what does "Data" mean?

Tony wrote:
> Where did you get that axiom from that "data comes in tuples"? Codd's
> rule #1 says that all data in the database is to be REPRESENTED in
> only one way: as values in attributes of tuples.

Here's a thought: where do constraints fit in? They are kind of like data, since they give you some information about the real-world system you are modelling.

For a fixed snapshot of a database I guess they don't add anything extra, since the tuples satisfy the constraints already. But if you think about a database evolving over time, they do add information. For example suppose you had a constraint "Age < 60" on some relation/column. Then you could ask the question: "Can I add a person aged 65 to my database?" Now in current DBMSs I think you'd do that by trying it and seeing if you get an error. (or maybe by querying the system tables).

In databases we assume anything that isn't true is false (closed world assumption). So maybe constraints give a stronger form of truth that tuples in this sense: If I have no-one aged 65 in my tuples I could say: "the real-world system I'm (partially) modelling may have people aged 65, but my database doesn't". But If I have a constraint "age < 60" it's like I'm making a stronger claim: that not only does my database have no-one over 60, but also the real-world situation I'm modelling has no-one over 60.

Another question: do current systems use the constraints when optimising queries? Would it be feasible for them to do so? For example suppose I have a billion people in my table, with the constraint "Age < 60". If I do "SELECT * FROM people WHERE age = 65" the optimizer could in theory use the constraint to quickly return an answer.

You could also think of examples where an index wouldn't be feasible: constraint: "name NOT LIKE '%x%'"
query: "SELECT * FROM people WHERE name LIKE '%axw%'

Paul. Received on Tue Jun 08 2004 - 13:44:55 CEST