1
00:00:00,280 --> 00:00:04,530
This is the second module
in six on databases.

2
00:00:04,530 --> 00:00:07,880
In this module we will be
talking about data models.

3
00:00:07,880 --> 00:00:10,960
You'll remember from
the first module that we

4
00:00:10,960 --> 00:00:16,580
said that data can be structured
in a variety of ways.

5
00:00:16,580 --> 00:00:19,456
The data that you put
in a database system.

6
00:00:19,456 --> 00:00:22,720
Has assumptions about how to
structured and that is a data model.

7
00:00:22,720 --> 00:00:27,370
There are different database systems
which are built on different types of

8
00:00:27,370 --> 00:00:32,520
data model and in this module we will
review number of different database,

9
00:00:32,520 --> 00:00:38,630
number of different data models
that are used in, in the field.

10
00:00:41,440 --> 00:00:46,580
A data model is a collection of concepts
which describes how your data is

11
00:00:46,580 --> 00:00:52,820
structured, and
how it can be represented and accessed.

12
00:00:54,340 --> 00:00:59,130
Within a particular data model, a schema.

13
00:00:59,130 --> 00:01:02,690
Is the set of descriptions of
a particular collection of data.

14
00:01:04,370 --> 00:01:10,080
So, I may have my data in a tabular or
relational data model.

15
00:01:10,080 --> 00:01:12,910
And the schema would then
be the description of

16
00:01:14,070 --> 00:01:18,920
the tabular format that it's
used the columns, the the data.

17
00:01:18,920 --> 00:01:21,500
Value types, that sort of information.

18
00:01:21,500 --> 00:01:24,540
The schema is stored in
a data dictionary and

19
00:01:24,540 --> 00:01:28,560
that can be represented in number
of different technologies.

20
00:01:28,560 --> 00:01:33,530
It can be represented in,
in SQL for relational databases.

21
00:01:33,530 --> 00:01:37,559
It can be represented in XML for
XML databases.

22
00:01:37,559 --> 00:01:46,980
In RDF for triple stores and ontological
databases, and that sort of thing.

23
00:01:48,050 --> 00:01:54,730
And in semantics, which is
the knowledge management layer in,

24
00:01:54,730 --> 00:01:59,470
in the the pyramid that we saw in
module one, that third layer up.

25
00:02:01,000 --> 00:02:03,300
A data model is equivalent to an ontology.

26
00:02:04,580 --> 00:02:07,920
We'll mention this a bit in Module 6.

27
00:02:07,920 --> 00:02:10,790
And an ontology is a formal
explicit specification of

28
00:02:10,790 --> 00:02:12,770
a shared conceptualization.

29
00:02:12,770 --> 00:02:16,620
It's essentially a schema for
a knowledge map.

30
00:02:18,020 --> 00:02:21,430
So, data models are very important.

31
00:02:21,430 --> 00:02:23,990
To the functioning of, of databases.

32
00:02:26,010 --> 00:02:29,560
This is an example of
a relational data model.

33
00:02:29,560 --> 00:02:36,225
This is a data model for
a database which is holding a genetic and

34
00:02:36,225 --> 00:02:40,530
image data about zebra fish.

35
00:02:40,530 --> 00:02:44,440
And you can see a set of connected tables.

36
00:02:44,440 --> 00:02:48,460
Related tables each with different
data dig from data types, but

37
00:02:48,460 --> 00:02:53,250
there are a number of relationships
prescribed between the different tables.

38
00:02:53,250 --> 00:02:56,580
And this gives us the data model for
this particular database.

39
00:02:56,580 --> 00:03:02,320
Any data in this database Will be
structured according to this data model.

40
00:03:02,320 --> 00:03:05,380
With the different bits of
information that are relevant to

41
00:03:05,380 --> 00:03:08,790
a particular data item in the database.

42
00:03:08,790 --> 00:03:12,360
Arranged in this fashion.

43
00:03:12,360 --> 00:03:12,910
So, the first, and

44
00:03:12,910 --> 00:03:16,470
possibly the simplest data model consider,
is the flat or file data model.

45
00:03:18,040 --> 00:03:22,950
This is essentially Data files
that contain records with no

46
00:03:22,950 --> 00:03:24,740
structural relationships.

47
00:03:24,740 --> 00:03:26,250
It's just the basic data.

48
00:03:27,880 --> 00:03:30,920
obviously, additional
information is required to

49
00:03:30,920 --> 00:03:35,420
interpret these such as
file format properties.

50
00:03:35,420 --> 00:03:36,990
I may have.

51
00:03:36,990 --> 00:03:41,340
The data in three different flat
file models, on my hard drive.

52
00:03:41,340 --> 00:03:46,200
One would basic asky columns,
one might be comma separated variable,

53
00:03:46,200 --> 00:03:50,330
one might be in the form
of some basic table.

54
00:03:52,090 --> 00:03:55,140
HTML table for displaying on a web page.

55
00:03:55,140 --> 00:03:57,710
This would be a flat file model.

56
00:03:57,710 --> 00:04:02,040
The data is structured in
the sense that there columns and

57
00:04:02,040 --> 00:04:04,110
there are rows in this particular case.

58
00:04:05,830 --> 00:04:08,640
And then there is some
representational information about it.

59
00:04:09,960 --> 00:04:13,900
But additional information is
required to interpret these files,

60
00:04:13,900 --> 00:04:22,800
such as maybe which column is which and
that sort of thing with the spacing is.

61
00:04:22,800 --> 00:04:25,840
The first example, and one of the most
famous examples in history about this,

62
00:04:25,840 --> 00:04:30,110
is the Hollerith 1889 Patent for
compiling Statistics.

63
00:04:30,110 --> 00:04:32,750
This was for census information.

64
00:04:32,750 --> 00:04:35,950
And it describes how every US
resident can be represented by

65
00:04:35,950 --> 00:04:38,279
a string of 80 characters and numbers.

66
00:04:39,820 --> 00:04:46,940
The legacy of this Hollerith patent
is the, screen width of 80 characters

67
00:04:46,940 --> 00:04:52,870
that was on many early computer screens,
and many early computer formats.

68
00:04:54,080 --> 00:04:58,810
So it's nice to see that
this very first data model.

69
00:05:00,170 --> 00:05:02,160
Already had an impact in
the history of computing.

70
00:05:02,160 --> 00:05:06,122
To say an example of the Flat Far model
is to limit the separated data on my

71
00:05:06,122 --> 00:05:06,860
hard drive.

72
00:05:09,261 --> 00:05:12,925
Obviously, this is possibly not
the most useful data model.

73
00:05:12,925 --> 00:05:17,770
I'll say a more sophisticated one,
is the Hierarchical Model.

74
00:05:19,110 --> 00:05:22,760
And a heirarcheal model, as the name
suggests, data is organized in a,

75
00:05:22,760 --> 00:05:23,620
a tree structure.

76
00:05:25,790 --> 00:05:28,070
So you have a number of levels.

77
00:05:28,070 --> 00:05:31,080
These consist of records of the same type.

78
00:05:31,080 --> 00:05:33,090
Data records of the same type.

79
00:05:33,090 --> 00:05:37,130
This may be that at a particular level
there's the same set of field values.

80
00:05:38,550 --> 00:05:42,584
Same set of measurements of
data at a particular level.

81
00:05:42,584 --> 00:05:47,720
And then the rules to be a field on up
level to ensure a particular ordering.

82
00:05:52,450 --> 00:05:55,770
In a tree structure,
obviously with levels,

83
00:05:55,770 --> 00:06:01,160
you have parent objects and
children objects, In a hierarchical model,

84
00:06:01,160 --> 00:06:05,610
there is a 1 to n parent/child
relationship between 2 record types.

85
00:06:06,800 --> 00:06:09,520
A child can only have 1 parent.

86
00:06:09,520 --> 00:06:11,460
But a parent can have many children.

87
00:06:14,590 --> 00:06:19,340
This was a very popular data model
in the late 1960's and 1970's.

88
00:06:19,340 --> 00:06:22,110
historically, IBM's
information management system.

89
00:06:22,110 --> 00:06:22,990
The IMS system.

90
00:06:24,040 --> 00:06:25,460
Make use of this.

91
00:06:25,460 --> 00:06:33,640
And the XML data format that we
use today transport agnostic,

92
00:06:33,640 --> 00:06:39,080
platform agnostic data format is
fundamentally a hierarchical model.

93
00:06:40,350 --> 00:06:43,910
And so if you're working with
an XML document in any fashion,

94
00:06:43,910 --> 00:06:46,950
you are actually employing
a hierarchical data model.

95
00:06:49,350 --> 00:06:51,860
An example of the hierarchical
data model is the.

96
00:06:51,860 --> 00:06:54,940
For example, in this case we have the CATH
database of protein structures in

97
00:06:54,940 --> 00:06:56,480
the Protein Data Bank.

98
00:06:56,480 --> 00:06:59,070
This has five levels.

99
00:06:59,070 --> 00:07:01,920
It has class, architecture, topology,
homologous super-family and

100
00:07:01,920 --> 00:07:03,170
sequence family.

101
00:07:03,170 --> 00:07:07,100
And you have different
types of protein structure.

102
00:07:07,100 --> 00:07:10,600
In this database,
at these different levels,

103
00:07:10,600 --> 00:07:14,040
with relationships between
the different levels.

104
00:07:15,490 --> 00:07:20,450
As you all see, each level,
each item only has one parent, but

105
00:07:20,450 --> 00:07:22,230
one parent can have many children.

106
00:07:22,230 --> 00:07:27,810
So this is an example of a hierarchical
data model in use in, in scientific data.

107
00:07:30,720 --> 00:07:36,460
The network data model,
data is organized as sets and records.

108
00:07:37,660 --> 00:07:38,940
Collections and records.

109
00:07:40,260 --> 00:07:45,120
A set has an owner, it has a name,
and it has one or more members.

110
00:07:46,880 --> 00:07:47,380
A record.

111
00:07:48,580 --> 00:07:49,710
A data item.

112
00:07:49,710 --> 00:07:50,550
May be an owner.

113
00:07:52,940 --> 00:07:57,218
And any number of sets and
a member and, and any number of sets.

114
00:07:57,218 --> 00:08:05,845
And, this allows the modeling
of many-to-many relationships.

115
00:08:07,890 --> 00:08:12,980
This was a data model formally defined
by the CODASYL specification in 1971,

116
00:08:12,980 --> 00:08:16,152
and has been used in
a number of applications.

117
00:08:16,152 --> 00:08:21,740
An example is shown here

118
00:08:21,740 --> 00:08:28,529
of things related to concrete.

119
00:08:30,970 --> 00:08:34,870
And you have a number of sets,
and you have a number of members.

120
00:08:34,870 --> 00:08:41,000
For example, you have the joint seal set,
which has as members silicon sealant and

121
00:08:41,000 --> 00:08:45,630
asphalt sealant, but the joint seal
itself is also in the Richmond pavement.

122
00:08:47,620 --> 00:08:49,820
The way this is from the net,

123
00:08:49,820 --> 00:08:55,890
From the heretical date model though
is as you can see that, certain,

124
00:08:55,890 --> 00:09:00,920
Objects can have more than one parent for
example Asphalt Sealant is both,

125
00:09:00,920 --> 00:09:05,590
A member of the joint seal set and
also in the patching set.

126
00:09:05,590 --> 00:09:08,830
So this is, a more networked,
less hierarchical.

127
00:09:12,430 --> 00:09:16,270
The next data model,
is object-oriented model.

128
00:09:16,270 --> 00:09:19,760
Anyone familiar with object-oriented
programming will be very familiar with

129
00:09:19,760 --> 00:09:23,380
this, essentially what
an object-oriented data model does is,

130
00:09:23,380 --> 00:09:26,930
is adds database functionality
to object-oriented languages.

131
00:09:26,930 --> 00:09:30,190
By allowing persistent storage
of programming objects.

132
00:09:30,190 --> 00:09:33,060
So if I am using a object
oriented language like Java,

133
00:09:33,060 --> 00:09:37,810
I have a complex object that I am using in
Java and I want to make that persistent.

134
00:09:37,810 --> 00:09:42,250
I want to store it, so
that I can retrieve it off hand later.

135
00:09:42,250 --> 00:09:45,470
An object oriented database
maybe the sort of thing I want.

136
00:09:47,180 --> 00:09:52,160
One of the advantages of actually having
a specific object oriented database which

137
00:09:52,160 --> 00:09:57,340
allows the storage of objects, is that it
means I do not need to convert information

138
00:09:57,340 --> 00:10:01,450
from a database representation to an
application representation all the time.

139
00:10:01,450 --> 00:10:05,020
The object in the oriented
model allows me to.

140
00:10:05,020 --> 00:10:09,900
Already make use of object oriented
structures for doing this.

141
00:10:09,900 --> 00:10:15,860
This means that less code is required,
and also that because I

142
00:10:15,860 --> 00:10:20,340
may already have a database structure
which maps to the types of objects that

143
00:10:20,340 --> 00:10:25,250
I'm using in my programs, there's a more
natural modeling between the two.

144
00:10:26,260 --> 00:10:29,610
This can be very good for
very complex data objects.

145
00:10:29,610 --> 00:10:32,690
And when you have very complex
relationships between different types of

146
00:10:32,690 --> 00:10:33,380
data objects.

147
00:10:34,510 --> 00:10:37,440
And there are a number of
commercial databases out there, and

148
00:10:37,440 --> 00:10:43,220
a number of free databases as well which
make use of this particular data model.

149
00:10:44,530 --> 00:10:48,760
Here's an example, where I am
dealing with maintenance reports.

150
00:10:49,760 --> 00:10:54,260
And I have an object oriented model
where I have an object which is

151
00:10:54,260 --> 00:10:59,340
a maintenance report, and I have a second
object which is maintenance activity, and

152
00:10:59,340 --> 00:11:01,710
there is a relationship between those two.

153
00:11:01,710 --> 00:11:06,235
And then what I'm storing
are instances of those objects,

154
00:11:06,235 --> 00:11:11,340
,containing the relevant information,
about this particular data structures,

155
00:11:11,340 --> 00:11:12,430
according to this data structures.

156
00:11:16,320 --> 00:11:18,100
Possibly the, the most famous or

157
00:11:18,100 --> 00:11:21,610
the most widely used data model
is the relational data model.

158
00:11:21,610 --> 00:11:26,610
And we will be talking more about that and
the technology supporting that in,

159
00:11:26,610 --> 00:11:28,830
in the next three modules.

160
00:11:28,830 --> 00:11:33,010
In the relational data model,
data is organized as,

161
00:11:33,010 --> 00:11:37,150
as relations, as attributes,
and as domains.

162
00:11:37,150 --> 00:11:38,600
Those are the formal names.

163
00:11:40,600 --> 00:11:46,771
Or prosaically a relation is,
is a table relational

164
00:11:46,771 --> 00:11:52,130
model databases, relational databases
essentially work with tabular data.

165
00:11:52,130 --> 00:11:57,740
So relation is a table which has
attributes which the columns and

166
00:11:57,740 --> 00:12:00,610
it has rows which are the,
the, the tuples.

167
00:12:00,610 --> 00:12:04,900
And the domain in a relational
model is the set of

168
00:12:04,900 --> 00:12:07,160
values that the attributes
are allowed to take.

169
00:12:07,160 --> 00:12:11,980
That is the set of values that columns
of the table are allowed to take or

170
00:12:11,980 --> 00:12:12,500
allowed to hold.

171
00:12:13,590 --> 00:12:16,910
And within the relation within a table,
each row is unique.

172
00:12:18,560 --> 00:12:21,970
Column order is immaterial doesn't matter.

173
00:12:23,600 --> 00:12:28,160
What order you have your columns, and
each row contains a single value for

174
00:12:28,160 --> 00:12:29,640
each of its attributes.

175
00:12:29,640 --> 00:12:35,640
So that means that, each row is only
a single value for each column.

176
00:12:35,640 --> 00:12:40,717
There are some relaxtion,
relaxations of these.

177
00:12:40,717 --> 00:12:47,042
Particular constrains in variance
on the relation database model.

178
00:12:47,042 --> 00:12:52,560
But as it stands this was originally
proposed by Codd in 1969, 1970.

179
00:12:52,560 --> 00:12:56,840
And has formed the basis for all
the relational data base technology that

180
00:12:56,840 --> 00:12:58,750
drives our lives today and
depends our lives today.

181
00:13:00,020 --> 00:13:01,750
This is an example of relational model.

182
00:13:02,760 --> 00:13:09,090
In this particular case we
have 3 relations, 3 tables.

183
00:13:10,470 --> 00:13:16,570
They each have 2 attributes,
or one has 2 attributes,

184
00:13:16,570 --> 00:13:20,389
2 columns, the other one,
the 2 have got 3 columns, 3 attributes.

185
00:13:21,520 --> 00:13:23,002
Individual rows and

186
00:13:23,002 --> 00:13:29,189
then you can see there are relations
between them where the particular column,

187
00:13:29,189 --> 00:13:35,480
particular attribute in one of the tables
is expanded in one of the other tables.

188
00:13:35,480 --> 00:13:37,910
Activity code with information
associated with it.

189
00:13:42,110 --> 00:13:43,190
Associative data model.

190
00:13:44,670 --> 00:13:48,000
In this particular way,
data is modeled as entities,

191
00:13:48,000 --> 00:13:51,990
having a discrete independent existence,
and associations.

192
00:13:51,990 --> 00:13:55,600
So you could could vi,
envision this as a set of facts, and

193
00:13:55,600 --> 00:13:59,470
then connections between the associations
between those facts which are meaningful.

194
00:14:00,910 --> 00:14:03,100
It's organized as items.

195
00:14:03,100 --> 00:14:08,110
Identify and name a type and
in the terms of links,

196
00:14:08,110 --> 00:14:09,690
links also have each other and identify.

197
00:14:09,690 --> 00:14:14,310
They have a source, they have a verb which
shows you something about the nature of

198
00:14:14,310 --> 00:14:16,830
the link, [INAUDIBLE] have a target.

199
00:14:16,830 --> 00:14:20,850
Example of how I may have represent,
A particular data item in,

200
00:14:20,850 --> 00:14:25,080
in such a model is,
say I was running a database of

201
00:14:26,550 --> 00:14:31,490
flight time arrivals and departures.

202
00:14:31,490 --> 00:14:37,499
Flight BA1234 arrived at LAX on
the 10th of April 2012 at 1:25 p.m.

203
00:14:39,050 --> 00:14:42,050
The items that I would
have the individual facts.

204
00:14:42,050 --> 00:14:46,060
Each of these would have,
my identifier and name of the type.

205
00:14:46,060 --> 00:14:47,870
They would be the flights.

206
00:14:47,870 --> 00:14:48,410
BA 1234.

207
00:14:48,410 --> 00:14:50,650
The location, LAX.

208
00:14:50,650 --> 00:14:51,980
The date.

209
00:14:51,980 --> 00:14:53,440
The arrival time.

210
00:14:53,440 --> 00:14:56,964
And then, arrived at on and that.

211
00:14:58,630 --> 00:15:02,480
And then I would have a links,
putting those together.

212
00:15:02,480 --> 00:15:05,490
So I'd have flight BA1234
arrived at LAX and

213
00:15:05,490 --> 00:15:07,939
then there would be on the 10th
of April 12 and at 1:25 pm.

214
00:15:07,939 --> 00:15:16,000
So I'd put that together in that way and
it could store that in a safety way.

215
00:15:16,000 --> 00:15:17,050
This is.

216
00:15:17,050 --> 00:15:23,150
Quite similar to the way
a lot of the web works,

217
00:15:23,150 --> 00:15:26,660
and you can consider the web to be an
associate to data model in some contexts.

218
00:15:29,450 --> 00:15:35,050
Other data models that we aren't

219
00:15:35,050 --> 00:15:39,520
going to talk about really but you may be
interested in, is semi-structured models.

220
00:15:39,520 --> 00:15:42,550
These are graph based, for information
that cannot be constrained by schema.

221
00:15:44,130 --> 00:15:47,180
The web for
example in its more general way, is,

222
00:15:47,180 --> 00:15:52,120
is a desperate collection of facts but we
could consider it to be semi-structured,

223
00:15:52,120 --> 00:15:57,100
and we could try and impose some sort
of interface layer on top of it,

224
00:15:57,100 --> 00:16:01,600
to make management retrieving that
information, more you, more viable.

225
00:16:01,600 --> 00:16:07,350
And then we have object relational data
models which are trying to combine some

226
00:16:07,350 --> 00:16:12,100
of the features of the object oriented
model with relational database model and

227
00:16:12,100 --> 00:16:16,670
in that, for example, we add object
capabilities to relational systems.

228
00:16:16,670 --> 00:16:23,517
An example of this is,
is adding location tasks

229
00:16:23,517 --> 00:16:29,020
to, relational databases.

230
00:16:30,430 --> 00:16:35,240
For doing, temporal work, geographical
work, restoring geographical data.

231
00:16:37,840 --> 00:16:40,860
And with that, we will finish this module.

232
00:16:40,860 --> 00:16:41,360
Thank you.