Re: Data vs. Information
- From: Stephane Faroult <sfaroult@xxxxxxxxxxxx>
- To: chet.justice@xxxxxxxxx
- Date: Sat, 05 Sep 2009 09:11:39 +0200
chet justice wrote:
> I recently tried to make a case for views
> <http://www.oraclenerd.com/2009/09/case-for-views.html>, 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
> www.oraclenerd.com <http://www.oraclenerd.com>
>
Chet,
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 <http://www.roughsea.com>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
