0:00	foreign
0:07	welcome back in this presentation we are
0:10	going to focus on chords 12 rules and
0:13	this is a set of 13 rules is it
0:16	confusing no worries once we step into
0:19	the topic of the day you will understand
0:20	things clearly let's step into cards 12
0:23	rules basically chords 12 rules are a
0:27	set of 13 rules for defining certain
0:30	requirements what are the requirements
0:33	if a database management system is
0:36	considered to be a relational database
0:38	management system simply rdbms then it
0:42	must satisfy all these 13 rules in
0:45	simple terms there are 13 rules for
0:48	defining the requirements for a dbms to
0:51	be considered to be relational and these
0:54	13 rules are proposed by the English
0:56	computer scientist Edgar Frank card and
1:00	this is considered to be the pioneer of
1:02	the relational model for databases
1:04	chords 12 rules are also referred as
1:07	chords 12 Commandments now we need to
1:10	understand one thing then why the name
1:12	course 12 rules though it has 13 rules
1:15	because the rules are numbered from 0 to
1:19	12. so a total of 13 rules are there and
1:22	the last rule is rule number 12 because
1:25	the first rule starts with rule number
1:27	zero in simple terms chords 12 rules are
1:31	a set of 13 rules numbered from 0 to 12.
1:34	let's see all the rules one by one now
1:37	basically it has 13 rules the rule
1:40	starts from rule number zero and it ends
1:42	with rule number 12. so there are a
1:45	total of 13 rules let's see rule number
1:48	zero rule number zero is the foundation
1:51	rule
1:52	what do we mean by this this is the
1:54	foundation for any system that is
1:57	advertised as or claimed to be a
1:59	relational database management system
2:01	that system must be able to manage the
2:04	databases entirely through its
2:06	relational capabilities I already told
2:08	you in the previous lecture that rdbms
2:11	is having a close association with the
2:13	mathematical concept called relations so
2:16	any system that is claimed or advised to
2:18	be a relational database management
2:20	system simply rdbms then that system
2:23	must be able to manage the databases
2:25	entirely through its relational
2:27	capabilities this is rule number zero
2:29	the foundation rule we are done with
2:31	rule number zero let's now move on to
2:34	rule number one which is the information
2:36	rule what do we mean by this it means
2:39	all information in a relational database
2:42	is represented explicitly at The Logical
2:45	level and in exactly one way and that
2:48	way is by values in the table in simple
2:51	term all the information that we are
2:53	going to process in rdbms it is
2:55	represented explicitly at The Logical
2:58	level by referring to the values in the
3:00	table and this is what rule number one
3:03	is the information rule
3:05	and coming to rule number two the
3:07	guaranteed access rule what do we mean
3:10	by this each and every datum datum means
3:13	it's singular the plural form of datum
3:15	is data so when we say data it is
3:18	already in the plural form let's come to
3:20	the definition of the guaranteed access
3:22
rule each and every datum which is
3:24
already an atomic value in a relational
3:27
database I hope you know what is an
3:29
atomic value it is indivisible in nature
3:32
if you are not sure about the atomic
3:34
values I request you to watch my
3:36
previous lecture where I have explained
3:37
about Atomic values let's continue
3:39
dealing with this definition each and
3:42
every datum which is already an atomic
3:44
value in a relational database
3:46
management system is guaranteed to be
3:48
logically accessible by resorting to a
3:51
combination of table name primary key
3:54
and column name in simple terms each and
3:57
every data that we are going to access
3:59
in rdbms it should be referred through
4:02
the table name primary key and the
4:04
column name anyway we will understand
4:06
things clearly when we see SQL where we
4:08
are going to give some SQL queries which
4:10
contains the table name primary key
4:13
attribute and also the column names
4:15
we are done with rule 2 let's now focus
4:18
on rule 3 the systematic treatment of
4:21
null values if you recall the previous
4:24
lecture where I have explained about
4:26
null values we must understand clearly
4:28
that null values are not empty character
4:30
string or a string of blank characters
4:32
even it is not 0 or any other number
4:35
these null values are either missing
4:38
information or inapplicable information
4:40
and that should be treated in a
4:43
systematic way by the relational
4:44
database management system this is what
4:47
exactly rule number three is and these
4:50
null values must be independent of the
4:52
data type for example number data type
4:55
the role number should accept null value
4:57
character data type name should also
5:00
accept null value date of birth data
5:02
type should also accept null value and
5:04
that's why I quoted these null values
5:07
must be independent of the data type and
5:10
all these null values must be supported
5:12
by the relational database management
5:14
system this is all of about rule number
5:16
three let's assume there are two
5:19
different tables when we join these two
5:21
tables and produce a new table when we
5:24
do that there are chances for some
5:26
inapplicable information in the result
5:28
table where that result table may not
5:31
have the exact value what is required
5:33
while joining the table these
5:35
inapplicable or missing information we
5:37
call as null values no worries we will
5:40
be elaborately understanding about null
5:42
values when we deal with SQL and coming
5:45
to rule number four which is dynamic
5:47
online catalog what do we mean by this
5:49
the database description is also
5:52
represented at The Logical level so this
5:54
Dynamic online catalog is related to
5:57
database description and also it deals
5:59
with the authorization which users can
6:02
access what kind of data and coming to
6:04
rule number five which is the
6:06
comprehensive data sub language rule a
6:09
relational system May support several
6:11
languages and various modes of terminal
6:15
use this terminal use means we are going
6:17
to access the database from a terminal
6:19
application or a terminal software and
6:22
this can be of any type it may be a GUI
6:24
application the graphical user interface
6:26
and it can also be like the fill in the
6:28
blanks mode anyway I am just
6:30
representing it as a terminal
6:32
application program or a terminal
6:33
software or The Terminal usage mode
6:36
however there must be at least one
6:38
language though we have several
6:41
languages there must be at least one
6:43
language whose statements are
6:45
expressible with some standard syntax
6:48
some character strings and also it
6:50
should support the following items the
6:52
data definition the ddl the view
6:55
definition I know it will be difficult
6:56
for you to understand what is a view
6:58
anyway in the next rule that is rule
7:00
number six I will explain about views
7:02
then data manipulation Integrity
7:05
constraints authorization and operations
7:07
related to transactions so all these
7:10
things should be expressible in the
7:12
statements and there may be multiple
7:14
languages and and there should be at
7:16
least one language that can support all
7:19
these we are done with Rule 5 let's see
7:22
the view updating rule which is Rule 6.
7:25
see for a table we can create multiple
7:27
views whenever we update any view that
7:31
should also update the table basically
7:33
all the data are stored in the relations
7:35
and we can create multiple views for the
7:38
relation both View and relation are
7:41
referring to the same data item in the
7:43
same memory location both are referring
7:46
to the same memory so whenever we make
7:48
any modifications in the view it means
7:51
the relation is also getting modified
7:52
because both are referring to the same
7:55
data item only thing is all the
7:57
information are stored in the relation
7:59
and we are creating multiple views as
8:01
per the need so rule number six states
8:04
that any rdbms that should support the
8:07
view updating rule simply whenever we
8:09
update the rule the table or the
8:11
relation should also be updated we are
8:13
done with rule number six let's now move
8:16
on to rule number seven the rule is it
8:19
is possible for higher level insert
8:21
update and delete so the name itself
8:23
says that there should be a possible
8:25
ability for the relational database
8:27
management system to perform higher
8:29
level of insertion updation and deletion
8:32
operations what do we mean by higher
8:34
level
8:35
whenever we want to insert some records
8:37
or update the records or delete the
8:39
records it doesn't mean that we should
8:41
always go to the database access the
8:43
table and perform the operation even we
8:45
should be able to do that from the
8:47
application program whenever we do these
8:49
operations from the application program
8:51
or from the client end or the front end
8:54
so that should also be supported it
8:56
doesn't mean that we should always
8:57
Supply queries to the database to
8:59
perform the operation in other words the
9:02
capability of handling a base relation
9:04
or a derived relation as a single
9:06
operand applies not only to the
9:08
retrieval of data but also to the
9:11
insertion updation and the deletion of
9:14
the data and hence rule number seven is
9:16
also called as relational operation rule
9:19
we should always have the possibility
9:21
for higher level insert update and
9:24
delete operations no worries when the
9:26
course progresses you will be able to
9:28
understand rule number seven even more
9:30
clearer we are done with rule number
9:32
seven let's now move on to rule number
9:34
eight which is physical data
9:36
Independence we have already seen about
9:38
this generally any application program
9:41
or any terminal activities it should
9:44
remain logically unimpaired Whenever
9:46
there are changes made in the storage or
9:49
the access method let's take the
9:51
three-tier architecture we have front
9:53
end at the top level a database at the
9:56
low level whenever any changes are made
9:59
in the low level I mean whenever we make
10:01
any changes in the storage
10:03
representations or access method it
10:06
should not affect the application
10:07
program level access that is what is
10:10
called as physical data Independence
10:12
simply changes made in the low level
10:15
data storage representation or the data
10:18
access methods should not impact the
10:20
application programs or The Terminal
10:22
activities and coming to rule number
10:25
nine which is logical data Independence
10:28
in rule number eight we dealt with the
10:30
physical aspect right whenever we make
10:32
changes in the storage it shouldn't
10:33
affect the application Level access and
10:35
coming to this one where the application
10:37
programs and terminal activities it
10:40
should be logically unimpaired when any
10:42
modifications are turned to the base
10:44
table so this is about rule number nine
10:47
coming to rule number 10 the Integrity
10:49
Independence we have already seen about
10:52
integrity constraints right all these
10:54
Integrity constraints that are specific
10:56
to a particular relational database
10:58
management system must be definable in
11:01
the relational data sub language and
11:03
also it should be stored in the catalog
11:05
what do we mean by this it means all the
11:08
Integrity constraints that we are going
11:10
to enforce on the database should be in
11:12
the database only to be precise it
11:14
should be in the relational database
11:16
only but not in the application programs
11:19
say for example the banking database and
11:22
let's assume there is a table called
11:23
account or a relation called account in
11:26
this account relation we have a column
11:28
called balance and this balance should
11:30
not be lesser than or equal to zero
11:32
let's assume this is the constraint we
11:34
are enforcing for this particular
11:35
relation this enforcement of Integrity
11:38
constraints should be in the dbms level
11:40
not from the application Level say we
11:43
may be writing an application program in
11:45
Python or Java or C plus plus the
11:48
constraint should not be applied there
11:50
rather it should be applied in the
11:52
relational database of language or
11:54
simply relational databases we are done
11:57
with rule number 10 the Integrity
11:58
Independence coming to rule number 11
12:01
the distribution Independence when we
12:04
say data are stored in a single place
12:06
maybe in a single server it is always
12:08
good to have a backup because all
12:11
systems are subject to failures it could
12:13
be a hardware failure or a software
12:15
failure whatsoever generally a failure
12:18
failure in a system should not be
12:20
permitted I personally believe in
12:23
technology two is one and one is none
12:25
when you have one it means it is none
12:27
because there is no redundancy so we
12:30
should always have enough backup for all
12:32
the activities let's assume you are
12:34
having a database it's always
12:36
recommended to have another copy of the
12:39
database somewhere in a distant location
12:41
because not only hardware and software
12:45
failures can cause damage to the
12:46
database there may be natural disasters
12:49
like earthquake or hurricane may affect
12:51
your data center and hence we are
12:53
required to distribute the data and this
12:56
distribution of data not only helps us
12:58
to achieve a duplicate copy of the
13:00
database and also it protects the data
13:03
from the natural disasters say if one
13:05
site is affected by the natural disaster
13:08
obviously the other site will contain
13:10
the duplicate copy of the database
13:11
because it is in a remote or a distant
13:14
location and this distribution of data
13:17
should not be known to the end user
13:19
let's assume there are two sites where
13:21
our databases are stored site a and site
13:24
B let's assume site a and site B are
13:27
geographically separated by thousands
13:29
and thousands of miles
13:30
it is always good to have like this
13:32
let's say user is now connected to site
13:35
a and he is retrieving or accessing all
13:37
the data from site a let's assume site a
13:41
is encountered with some Hardware or
13:43
software failure or even the natural
13:45
disaster so obviously ITA cannot give
13:48
data to the user the end user in this
13:51
scenario site B comes into action and it
13:54
starts scattering the need of the user
13:56
by providing all the data that is
13:58
required user must not be able to see
14:01
that the data is distributed across
14:03
various locations users should always
14:05
get the impression that the data is
14:07
stored only in one place or in one site
14:09
and he should not be aware that the data
14:11
is distributed this is rule number 11
14:14
the distribution Independence and coming
14:17
to rule number 12 the last rule the
14:19
non-subversion rule what we mean by this
14:22
if a relational system has a low level
14:24
language it means we can perform the
14:27
operations of single record at a time
14:29
that is what I represent it as low level
14:31
language if a relational system has a
14:34
low level language that low level cannot
14:37
be used to subvert or bypass the
14:39
Integrity rules or the constraints
14:41
expressed in the higher level relational
14:43
language the higher level language what
14:45
I mean is multiple records can be
14:47
accessed at the same time or multiple
14:50
records can be processed at the same
14:51	time so rule number 12 states that if
14:55	relational database system has a low
14:56	level language that low level language
14:59	cannot be used to either subvert or
15:02	bypass the Integrity rules and
15:04	constraints expressed in the higher
15:06	level relational language so this is
15:08	what rule number 12 is all about
15:11	we are done dealing with all the 13
15:13	rules these are the rules that are
15:16	designed to Define what is required from
15:18	a database management system in order
15:20	for it to be considered as relational
15:22	database management system at the BMS in
15:25	simple term course 12 rules are designed
15:28	to Define what is required from a dbms
15:31	in order for it to be considered rdbms
15:34	and that's it guys I hope you guys
15:36	enjoyed this presentation and thank you
15:38	for watching
15:39	[Music]
15:40	[Applause]
15:48	thank you