This is the second module
in six on databases.
In this module we will be
talking about data models.
You'll remember from
the first module that we
said that data can be structured
in a variety of ways.
The data that you put
in a database system.
Has assumptions about how to
structured and that is a data model.
There are different database systems
which are built on different types of
data model and in this module we will
review number of different database,
number of different data models
that are used in, in the field.
A data model is a collection of concepts
which describes how your data is
structured, and
how it can be represented and accessed.
Within a particular data model, a schema.
Is the set of descriptions of
a particular collection of data.
So, I may have my data in a tabular or
relational data model.
And the schema would then
be the description of
the tabular format that it's
used the columns, the the data.
Value types, that sort of information.
The schema is stored in
a data dictionary and
that can be represented in number
of different technologies.
It can be represented in,
in SQL for relational databases.
It can be represented in XML for
XML databases.
In RDF for triple stores and ontological
databases, and that sort of thing.
And in semantics, which is
the knowledge management layer in,
in the the pyramid that we saw in
module one, that third layer up.
A data model is equivalent to an ontology.
We'll mention this a bit in Module 6.
And an ontology is a formal
explicit specification of
a shared conceptualization.
It's essentially a schema for
a knowledge map.
So, data models are very important.
To the functioning of, of databases.
This is an example of
a relational data model.
This is a data model for
a database which is holding a genetic and
image data about zebra fish.
And you can see a set of connected tables.
Related tables each with different
data dig from data types, but
there are a number of relationships
prescribed between the different tables.
And this gives us the data model for
this particular database.
Any data in this database Will be
structured according to this data model.
With the different bits of
information that are relevant to
a particular data item in the database.
Arranged in this fashion.
So, the first, and
possibly the simplest data model consider,
is the flat or file data model.
This is essentially Data files
that contain records with no
structural relationships.
It's just the basic data.
obviously, additional
information is required to
interpret these such as
file format properties.
I may have.
The data in three different flat
file models, on my hard drive.
One would basic asky columns,
one might be comma separated variable,
one might be in the form
of some basic table.
HTML table for displaying on a web page.
This would be a flat file model.
The data is structured in
the sense that there columns and
there are rows in this particular case.
And then there is some
representational information about it.
But additional information is
required to interpret these files,
such as maybe which column is which and
that sort of thing with the spacing is.
The first example, and one of the most
famous examples in history about this,
is the Hollerith 1889 Patent for
compiling Statistics.
This was for census information.
And it describes how every US
resident can be represented by
a string of 80 characters and numbers.
The legacy of this Hollerith patent
is the, screen width of 80 characters
that was on many early computer screens,
and many early computer formats.
So it's nice to see that
this very first data model.
Already had an impact in
the history of computing.
To say an example of the Flat Far model
is to limit the separated data on my
hard drive.
Obviously, this is possibly not
the most useful data model.
I'll say a more sophisticated one,
is the Hierarchical Model.
And a heirarcheal model, as the name
suggests, data is organized in a,
a tree structure.
So you have a number of levels.
These consist of records of the same type.
Data records of the same type.
This may be that at a particular level
there's the same set of field values.
Same set of measurements of
data at a particular level.
And then the rules to be a field on up
level to ensure a particular ordering.
In a tree structure,
obviously with levels,
you have parent objects and
children objects, In a hierarchical model,
there is a 1 to n parent/child
relationship between 2 record types.
A child can only have 1 parent.
But a parent can have many children.
This was a very popular data model
in the late 1960's and 1970's.
historically, IBM's
information management system.
The IMS system.
Make use of this.
And the XML data format that we
use today transport agnostic,
platform agnostic data format is
fundamentally a hierarchical model.
And so if you're working with
an XML document in any fashion,
you are actually employing
a hierarchical data model.
An example of the hierarchical
data model is the.
For example, in this case we have the CATH
database of protein structures in
the Protein Data Bank.
This has five levels.
It has class, architecture, topology,
homologous super-family and
sequence family.
And you have different
types of protein structure.
In this database,
at these different levels,
with relationships between
the different levels.
As you all see, each level,
each item only has one parent, but
one parent can have many children.
So this is an example of a hierarchical
data model in use in, in scientific data.
The network data model,
data is organized as sets and records.
Collections and records.
A set has an owner, it has a name,
and it has one or more members.
A record.
A data item.
May be an owner.
And any number of sets and
a member and, and any number of sets.
And, this allows the modeling
of many-to-many relationships.
This was a data model formally defined
by the CODASYL specification in 1971,
and has been used in
a number of applications.
An example is shown here
of things related to concrete.
And you have a number of sets,
and you have a number of members.
For example, you have the joint seal set,
which has as members silicon sealant and
asphalt sealant, but the joint seal
itself is also in the Richmond pavement.
The way this is from the net,
From the heretical date model though
is as you can see that, certain,
Objects can have more than one parent for
example Asphalt Sealant is both,
A member of the joint seal set and
also in the patching set.
So this is, a more networked,
less hierarchical.
The next data model,
is object-oriented model.
Anyone familiar with object-oriented
programming will be very familiar with
this, essentially what
an object-oriented data model does is,
is adds database functionality
to object-oriented languages.
By allowing persistent storage
of programming objects.
So if I am using a object
oriented language like Java,
I have a complex object that I am using in
Java and I want to make that persistent.
I want to store it, so
that I can retrieve it off hand later.
An object oriented database
maybe the sort of thing I want.
One of the advantages of actually having
a specific object oriented database which
allows the storage of objects, is that it
means I do not need to convert information
from a database representation to an
application representation all the time.
The object in the oriented
model allows me to.
Already make use of object oriented
structures for doing this.
This means that less code is required,
and also that because I
may already have a database structure
which maps to the types of objects that
I'm using in my programs, there's a more
natural modeling between the two.
This can be very good for
very complex data objects.
And when you have very complex
relationships between different types of
data objects.
And there are a number of
commercial databases out there, and
a number of free databases as well which
make use of this particular data model.
Here's an example, where I am
dealing with maintenance reports.
And I have an object oriented model
where I have an object which is
a maintenance report, and I have a second
object which is maintenance activity, and
there is a relationship between those two.
And then what I'm storing
are instances of those objects,
,containing the relevant information,
about this particular data structures,
according to this data structures.
Possibly the, the most famous or
the most widely used data model
is the relational data model.
And we will be talking more about that and
the technology supporting that in,
in the next three modules.
In the relational data model,
data is organized as,
as relations, as attributes,
and as domains.
Those are the formal names.
Or prosaically a relation is,
is a table relational
model databases, relational databases
essentially work with tabular data.
So relation is a table which has
attributes which the columns and
it has rows which are the,
the, the tuples.
And the domain in a relational
model is the set of
values that the attributes
are allowed to take.
That is the set of values that columns
of the table are allowed to take or
allowed to hold.
And within the relation within a table,
each row is unique.
Column order is immaterial doesn't matter.
What order you have your columns, and
each row contains a single value for
each of its attributes.
So that means that, each row is only
a single value for each column.
There are some relaxtion,
relaxations of these.
Particular constrains in variance
on the relation database model.
But as it stands this was originally
proposed by Codd in 1969, 1970.
And has formed the basis for all
the relational data base technology that
drives our lives today and
depends our lives today.
This is an example of relational model.
In this particular case we
have 3 relations, 3 tables.
They each have 2 attributes,
or one has 2 attributes,
2 columns, the other one,
the 2 have got 3 columns, 3 attributes.
Individual rows and
then you can see there are relations
between them where the particular column,
particular attribute in one of the tables
is expanded in one of the other tables.
Activity code with information
associated with it.
Associative data model.
In this particular way,
data is modeled as entities,
having a discrete independent existence,
and associations.
So you could could vi,
envision this as a set of facts, and
then connections between the associations
between those facts which are meaningful.
It's organized as items.
Identify and name a type and
in the terms of links,
links also have each other and identify.
They have a source, they have a verb which
shows you something about the nature of
the link, [INAUDIBLE] have a target.
Example of how I may have represent,
A particular data item in,
in such a model is,
say I was running a database of
flight time arrivals and departures.
Flight BA1234 arrived at LAX on
the 10th of April 2012 at 1:25 p.m.
The items that I would
have the individual facts.
Each of these would have,
my identifier and name of the type.
They would be the flights.
BA 1234.
The location, LAX.
The date.
The arrival time.
And then, arrived at on and that.
And then I would have a links,
putting those together.
So I'd have flight BA1234
arrived at LAX and
then there would be on the 10th
of April 12 and at 1:25 pm.
So I'd put that together in that way and
it could store that in a safety way.
This is.
Quite similar to the way
a lot of the web works,
and you can consider the web to be an
associate to data model in some contexts.
Other data models that we aren't
going to talk about really but you may be
interested in, is semi-structured models.
These are graph based, for information
that cannot be constrained by schema.
The web for
example in its more general way, is,
is a desperate collection of facts but we
could consider it to be semi-structured,
and we could try and impose some sort
of interface layer on top of it,
to make management retrieving that
information, more you, more viable.
And then we have object relational data
models which are trying to combine some
of the features of the object oriented
model with relational database model and
in that, for example, we add object
capabilities to relational systems.
An example of this is,
is adding location tasks
to, relational databases.
For doing, temporal work, geographical
work, restoring geographical data.
And with that, we will finish this module.
Thank you.