Let's now look at some structured data.
An example of a database that stores
songs, their lyrics, the albums that
contain those songs, and the artists who
may have sung them.
This example is taken from a Sigmont
paper, which talks about searching
relational databases, as opposed to using
queries.
Let's see what it would take in sequel, to
get the albums with, World in their title.
One might write a Sequel.
Such as this, which is an Oracle, sequel.
You select star from the album table,
where the title contains the string,
world.
Things get a little more difficult.
If one now wants more information from
this, complex schema.
So let's ask, how many sequels.
Will it take.
To retrieve the names of each artist.
And the lyrics of every song.
In an album, that has world in its title?
Take a look at the schema and answer the
question.
Please avoid complex joints which joins
every single table in the schema.
You could do that but we are trying to get
at how many simple queries will it take.
Here is how we could do this.
We first retrieve the algum.
From the album table then we have to
traverse this table to find out all the
songs in that album and their lyrics from
this table.
We also have to find out all the artists
that composed this album, B1.
From the artist album table and then
retrieve the actual artist names.
Each of these can be done with a single
query, to allow a one table traversal
joint.
Otherwise each of these will require two
separate queries.
Quite complicated for doing something
which is easy to do, if one just had a
Google like search on this database.
Unfortunately, that is quite difficult to
achieve.
Imagine, if we had a search interface, so
that we could issue a query, like, off
the, the world, since we didn't really
remember the exact title of the album.
The sequel approach would end up missing
partial matches such as the album title
World or the album title, Off The Wall.
Next the schemer needs to be understood
quite carefully in order to issue the
multiple sequence needed to retrieve the
information that we want.
Some times a complex join might be needed.
But there's even more.
Suppose there were multiple databases,
each with a different schema.
And partial, or duplicated data, across
these databases.
And suppose the keys used in the vate, in
each database were different, with no
relationship to each other.
Most importantly, suppose we have some
unstructured data in documents, like text
files which contain the lyrics or
biographies of artists.
And the others in structured databases
like the lyrics database.
How to search both of these together.
When you [inaudible], when you search a
set of documents and you get an album, can
you find the songs in that album by
looking at the lyrics database, and vice
versa?
The point I'm trying to make is that
searching structure data well, in a query
like manner remains a research problem.
The fact that so much structured data is
being accessed using applications, is only
because a lot of complicated programming
using C quill goes in to accessing that
data.
Let us conclude now by asking whether
looking is the same as searching.
When we look around a room for example and
recognize objects and people doing
activities.
We're not really searching for anything.
Or when we're browsing a book shelf or
flipping the pages of a book or even
looking at some data, like some time
series or a histogram or charts, to see if
there might be any hidden patterns in the
data.
In the first case while seeing, we are
visualizing a scene.
Computationally this involves techniques
such as clustering and classification.
In the second and third examples, we're
trying to get a feel for a document A
collection of documents or some data.
Which requires, techniques such as
automatically summarizing documents,
discovering the topics and documents.
And discovering interesting correlations
in data without direct intervention.
Each of these are deep research areas of
current interest.
And we'll get into them as we go beyond
looking to listening, learning,
connecting, and predicting.
So see you next week.