Re: Data vs. Information

From: Stephane Faroult <>
Date: Sat, 05 Sep 2009 09:11:39 +0200
Message-ID: <>

chet justice wrote:
> I recently tried to make a case for views
> <>, in the last
> line of the post I wrote:
> Records in a table typically constitute data. Tables, joined
> together, in a view, tend to /*turn that data into information.*/
> A very good friend and mentor who has like 27 masters degrees took
> umbrage with this statement. He said that data is information.
> While I don't necessarily disagree with him, I tried to frame it in
> the context of a database. I've always been told, or read, or heard,
> that a database stores data and from that, you get information (in the
> form of queries, reports, etc).
> Am I off my rocker here? Am I misinformed? Or just misspeak?
> More than anything I think it was more of a theoretical discussion,
> but I have enough respect for this individual to give it further thought?
> Anyone have an opinion or links on the subject?
> chet
> --
> chet justice
> <>


  I have just read Nuno's answer, I second it and want to elaborate a little - What is data is what you find in one particular column. What you call "record" (which Chris Date would call "tuple") IS information, because in one row of a table you create information by relating data (that's why it's called "relational"). When in table EMP you say that King is President and earns a miserable 5000 (not even 7 times more than the lowest salary - this guy should be locked up), that's information. King, President and 5000 mean nothing by themselves and are just data. Data isn't information, but two related pieces of data are.

Now, joins in themselves don't create information - everything is already here. Views are just an alternate vision, that may be more appropriate in certain cases, like using polar rather than Cartesian coordinates is more appropriate for studying some mathematical functions. Or like a change of base in a vector space. And if your views are soundly built, they should exhibit all the main characteristics of tables - they should have keys (a set of columns that uniquely identifies each rows), they should be in 1NF with respect to the questions they are expected to answer (this is a tricky point - but if you are just interested in lists of people in departments, having a column in a view that contains a list of names doesn't violate 1NF. It violates it if afterwards you want to split it up to check each name). Modeling depends on what you want to do with the data, and it may be that an application relies on a set of views that might have been tables in their own right if the application has been in isolation.

I hope that if you're still confused, it's at a higher level :-).

Stephane Faroult
RoughSea Ltd <>

Received on Sat Sep 05 2009 - 02:11:39 CDT

Original text of this message